mirror of
https://github.com/permissionlesstech/bitchat-android.git
synced 2026-09-19 04:59:59 +00:00
b9bf303d9a
A REQUEST_SYNC reply can carry a message from a peer that has left, on LEAVE or after three minutes of silence. Normally the neighbor re-serves that peer's announcement first, which restores the signing key. When the key is not restored, the message arrives with no key on file and the signature check rejects it. That happens in two cases. An iOS neighbor that relaunched serves messages restored from disk, and that archive holds no announcements. An Android neighbor that missed the LEAVE keeps serving the peer for about three minutes while the receiving device rejects the re-served announcement as a duplicate. iOS keeps a message from a sender that has left when it has verified that sender before, by falling back to its persisted identity. Android persists the signing key for every peer that completed the authenticated peer-state exchange, and the message path did not read it. This addresses the first bullet of #622. The signature check falls back to the persisted signing key when the live registry has none, found by peer ID directly since a peer ID is the prefix of its own fingerprint. The broadcast handler delivers a message from a sender that has left under the cached nickname or the peer ID. A message from a sender that has left is not archived, and nothing the LEAVE purge removed re-enters the archive. Messages from present peers and the receiving device's own broadcasts are archived as before. A live key is always preferred, a sender with no key on file is rejected as before, and a registry entry with an unverified nickname is dropped as before. Receive-side only. Seventeen tests across the security manager, the message handler, the coordinator, the secure store and the sync archive.