Repository navigation
Conversation
NewRemoteSignalClient runs a linked device whose Signal private keys, sessions and message plaintext live outside the client, behind the RemoteSignal interface. The client keeps its socket, receipts, retry receipts, prekey uploads and QR pairing, but never decrypts or encrypts: - receive hands each <enc> payload to the remote store and gets back only delivery metadata (events.RemoteMessage), plus an app-state key share when an own device sent one; errors map to the same retry receipts and nacks as the local path; - prekeys come from a remote-backed PreKeyStore that marks whole upload batches; - pairing keeps the local HMAC and account-signature checks and takes the device signature from the store, refusing one over different details; the store learns its own JIDs before pairing is confirmed; - incoming retry receipts ask the store to resend from its own record; - SendPrebuiltStanza transmits stanzas the store built and waits for the ack. Local SendMessage and pair-code pairing are refused. The device store holds only public material and is marked RemoteKeys; the local Signal store panics instead of using its zero private keys.
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. 🗂️ Base branches to auto review: 1
Please check the settings in the CodeRabbit UI or the ⚙️ Run configuration
You can disable this status message by setting the Use the checkbox below for a quick retry:
Comment |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
golang.org/x/tools v0.50.0 and later require Go 1.26, so installing goimports@latest fails the Go 1.25 build job on every new run. Pin v0.49.0, the newest release on Go 1.25.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d4c58f25a0
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
- Remote retry path calls PreRetryCallback (message unavailable) before resending. - Retry-receipt prekeys from GenOnePreKey are marked published. - A store transport error is neither acked nor retried; the server redelivers. - Verify the remote device signature against the remote identity key. - Reuse unuploaded prekeys and mark only the batch that was uploaded. - SendFBMessage refuses local encryption on a remote client. - Identity changes forget the sender's sessions in the remote store.
- RemoteSignal gains MigratePNToLID. On a remote client, the PN-to-LID migration in decryptMessages goes to the remote store (once per user after success) instead of the unused local session store. - forgetRemoteIdentity sends hosted JIDs as their base user; the store clears hosted devices with it, matching the local cleanup. - Document that PreRetryCallback gets a nil message on remote clients.
Adds a linked-device client whose Signal private keys, sessions, and message plaintext live in a customer-run Signal store. HyperMeow keeps transport, receipts, retries, public prekey uploads, and QR pairing. It forwards each encrypted receive payload to
RemoteSignal, receives delivery metadata plus the explicit own-device app-state-key-share exception, and transmits customer-built stanzas throughSendPrebuiltStanza.Remote upload batches now survive service restarts and requested-count changes.
RemoteSignal.PreparePreKeyUploadreturns the complete outstanding public batch, without truncation or fresh top-up.AcknowledgePreKeyUploadacknowledges the immutable captured token and full ID list only after a successful upload IQ. The literal last returned ID is checked; ID wrap never becomes a numeric cutoff. Lost ACK responses retain their exact snapshot and replay before another prepare. Fresh retry-receipt keys continue to use separateGeneratePreKeys(1)/MarkPreKeysUploadedoperations.This PR remains stacked on #43 and does not modify its branch. No main merge, tag, release, or registry publication has been performed.
Implementation and dependency revisions:
7b77e9876c4058e6e2ec52f9ef688812826173ee, on previous remote/metadata source4f60a67410c9c5d099d2e2f4fcf4facd8c42d777.cherry-pick -xonto the ABprops-compatible integration source3bbdfa9c5e0b252ded2535da8cc6ccf49fba1388, resulting in7e3393b9a6f98eaedb5fe3fb44fdd944e808c143. ABprops guards/notifications and receive metadata remain intact. Stable patch ID matches on both commits:caa3bdb79fcc3fb66e96e711811151f06a71cc17.0ad97727526d317e6609ecdcdca4bbe6ca8c8786, consuming core4b3b13cacd40a27573d0246386db553ef887539band additive private protocol request tags 20/21 and result tag 18. Proto SHA256:fa043d9139c168ed6ef27fb6962cf56148a5f89a7d98875717d8c03f48d27754.Verification on both source and compatible heads:
go test -race -count=1 ./...passes on Go 1.25.14 and Go 1.26.6.go build ./...,go vet ./..., generated MEX binding check,pre-commit run --all-files, and whitespace checks pass.uploadPreKeys->sendIQtests capture the complete ordered public list, inject both transport failure and server IQ error, and prove zero ACK after either failure, including a following prepare. A second client instance recovers the full 812-key batch with a request for 50. Successful IQ precedes ACK; a lost ACK response is replayed exactly before a new prepare.prekeys.go,retry.go, andnotification.goare unchanged by this patch.These local IQ and remote-store fixtures do not prove a live WhatsApp upload, deployed service availability, server redelivery, or backend adoption. Service persistence/real-core proofs belong to its owning source and were not rerun by this HyperMeow slice. Pair-code pairing and bot-message-secret handling remain explicitly unsupported on the remote client; this patch does not add them.
Six-part assessment:
Dependency-ladder assessment:
Crosscutting effects: prekey retry does not move private keys or plaintext into the runner, change immutable ZK custody, create a fresh session lease, grant scopes, or extend funding. QuickLink pairing can recover a pending prekey upload without inventing a replacement child or pairing authority; invitation/consent/expiry behavior remains backend-owned. Browser-tunnel transport and exact Origin/generation gates are unchanged; this patch proves no new custody/tunnel combination. Billing, Usage, analytics, product tracking and audit records gain no quantity or collection. Preserve existing delivery ordering, cancellation and feature authority. Rollout requires a matching service/backend before new operations are used; Unsupported fails closed without generating replacement keys. Rollback must preserve remote pending state and never convert custody.