P2P Messaging
Ghayas Sher and I are building an educational Python prototype for direct communication between explicitly verified peers. Its local browser workspace combines identity protection, authenticated encryption, separate conversations, encrypted history, and defensive protocol limits without presenting an unaudited system as production ready.
Why direct peer messaging
This shared project with Ghayas Sher began as an attempt to understand what secure messaging requires beneath the interface. Encrypting a string is only one part. Devices need identities, users need a way to verify keys, messages need authenticated structure and freshness, replays need rejection, local history needs protection, and delivery needs evidence from the intended peer.
The application provides a usable local interface for identity setup, contacts, conversation history, message composition, verification, delivery state, and security information while keeping a CLI path for testing and automation.
Cryptographic responsibilities
Long-term identity and per-message protection are separated conceptually. The protocol signs the authenticated message structure, derives encryption material for the intended peer, attaches nonces and sequence information, and verifies everything before plaintext is accepted into conversation state.
Key fingerprints give users a comparison point, but fingerprint display is not the same as successful out-of-band verification. The interface therefore distinguishes a known key from a verified contact rather than presenting encryption as automatic proof of identity.
Local state and conversation behavior
Conversations are organized by contact and retain status information needed to explain whether a message was prepared, sent, acknowledged, rejected, or failed. Parsing and size limits are applied before untrusted content is allowed to consume unlimited resources or mutate stored history.
The design also considers duplicate messages, reordered delivery, restarts, changed contact keys, malformed envelopes, and acknowledgements that do not correspond to an accepted message. The goal is for failure to remain visible rather than silently appearing as success.
Adversarial tests
The current public repository includes 75 automated tests covering browser authentication, CSRF protection, conversation controls, identity handling, authenticated encryption, signatures, malformed input, tampering, spoofing, replay rejection, acknowledgements, persistence, attachment references, and end-to-end delivery.
Those tests are evidence for the implemented paths, not a substitute for an independent security audit. The project does not claim production readiness, forward secrecy, anonymous metadata, NAT traversal, automatic file transfer, multi-device synchronization, or protection after an endpoint is compromised.
Collaboration and roadmap
The repository uses documented suggestions and roadmap material so each contributor has a clear place to continue. Protocol documentation and tests allow changes to be evaluated against shared assumptions rather than merged because the interface appears to work.
Comparable secure messengers show important gaps to study: audited protocol libraries, prekeys and forward secrecy, safety-number workflows, attachment lifecycle, device linking, key changes, abuse controls, backup policy, metadata minimization, and recovery. These are references for learning, not features the project currently claims.
Lessons
The project changed my understanding of secure communication from “use encryption” to maintaining a chain of identity, authorization, freshness, integrity, confidentiality, parsing limits, acknowledgement, and protected local state. A weakness at one boundary can invalidate confidence created by the others.