fybrrChat: Secure P2P Messaging

• fybrrChat is a distributed, secure messaging platform employing a trustless P2P swarm with WebRTC, DHT, and end-to-end encryption to ensure privacy.
• It integrates offline delivery through an IPFS-backed distributed message queue and supports dynamic policy changes via a group consensus mechanism.
• Performance evaluations indicate that fybrrChat offers low-latency direct transfers with efficient fallback methods, reducing energy use compared to centralized platforms.

fybrrChat is a distributed chat application for secure P2P messaging organized as a fully peer-to-peer “swarm” overlay with no single server bottleneck. It is motivated by the claim that a system with no central organisation in control and a trustless network is required for extremely secure communication use-cases, and it combines direct WebRTC DataChannel transfers, a DHT overlay in the prototype using IPFS, end-to-end encryption built atop TweetNaCl.js, a Distributed Message Queue for offline delivery, and a group-voting mechanism for policy changes, membership in private swarms, and bootstrap-node appointment (Halder et al., 2022).

1. Motivation, scope, and trust model

The motivating context is the growth of large-scale chat platforms and the corresponding concentration of policy control and data control in centralized organizations. The paper states that the total number of monthly active users on the top 3 chat applications surpassed 4 billion users in July 2019, and that as of Oct 2020, WhatsApp alone has 2 billion monthly active users sending around 100 billion messages per day. In that setting, fybrrChat is presented as a response to skepticism toward centralized applications for extremely secure communication use-cases.

A central term in the design is the trustless network. In the paper’s formulation, a trustless network is a network which does not requires the participants (users) to trust any central authority. These nodes themselves, as a group, can be trusted to make a decision which aligns with the interests of all. The network substrate is a distributed network, where peers are connected to each other to form a mesh-like network called Swarm.

The system’s scope is therefore not merely encrypted messaging. It also includes storage for offline delivery, content lookup, and policy coordination inside private swarms. This makes fybrrChat closer to a distributed communication fabric than to a thin E2EE overlay atop a centralized relay service. At the same time, the prototype retains some transitional centralized components, which is important for interpreting claims about decentralization.

2. Overlay architecture and peer-resident modules

fybrrChat is organized around three logical entities: peers, a signalling server, and a temporary central database. Every user’s device is a peer; it generates and consumes messages and files, contributes storage for pinning, and participates in DHT maintenance. Peers maintain two kinds of links: a WebRTC DataChannel for direct real-time transfers whenever both endpoints are online, and a DHT overlay, in the prototype IPFS over TCP/WebSockets, used for content lookup and offline-message storage.

The signalling server is a simple WebSocket service that authenticates users via Firebase/Google Auth in the prototype and brokers the initial Session Description Protocol handshake for WebRTC. Once the WebRTC DataChannel is live, messages flow directly peer-to-peer and the signalling path is quiescent. The temporary central database is Firebase Cloud Firestore, which in the prototype holds the Distributed Message Queue indices, namely the set of content-hashes awaiting delivery to offline peers. Future work replaces this with a trustless name service, IPNS, so that not even the message-queue indices are held centrally.

Within each peer, several modules define the operational semantics of the system. The RTC Peer Connection establishes a direct, in-order, encrypted UDP channel, described as WebRTC SCTP-over-DTLS, for minimal-latency messaging when both peers are online. The end-to-end encryption module ensures that all messages, even when delivered over IPFS, are encrypted at the sender with the receiver’s public key. The content-addressing module hashes each encrypted message blob $C$ as

$h = \mathrm{SHA256}(C)$

and uses this 256-bit hash as both the identity and DHT lookup key for the blob. Content pinning replicates encrypted blobs on multiple peers or dedicated bootstrap nodes via Pinata. The DHT module uses IPFS’s Kademlia-style DHT to locate which nodes are pinning content under key $h$. The Distributed Message Queue stores content-hashes for offline recipients. Consensus provides a group-voting mechanism in lieu of central control.

A common misconception would be to treat fybrrChat as already free of all centralized services. The prototype architecture does not support that reading. It explicitly includes a signalling server and a Firestore-backed DMQ index. The stronger trustless claim is instead attached to the intended direction of the system, particularly the proposed replacement of the message-queue indices with IPNS.

3. Cryptographic substrate and stated security properties

The end-to-end encryption layer is built atop TweetNaCl.js, the JavaScript port of NaCl. The paper describes three principal cryptographic elements: key exchange, authenticated encryption, and deniability.

For key exchange, each peer has a long-term key pair $(sk, pk)$. For each new chat session, peers may generate ephemeral key pairs $(a, A = g^a \bmod p)$, exchange public keys, and compute the shared secret

$K_{AB} = g^{a \cdot b} \bmod p.$

The paper states that this yields forward secrecy: compromise of one session’s $sk$ does not break past sessions.

For authenticated encryption, a symmetric AEAD key is derived from $K_{AB}$ via NaCl’s internal hash. Each message $M$ is encrypted with a unique 192-bit nonce $n$:

$h = \mathrm{SHA256}(C)$0

$h = \mathrm{SHA256}(C)$1

The recipient checks the tag before decrypting, ensuring both confidentiality and integrity.

For deniability, the paper emphasizes that messages are not individually signed; they are authenticated with a shared secret. As a result, peers cannot later cryptographically prove to a third party that a particular message flowed from one party to another. The paper explicitly relates this property to Off-the-Record messaging.

The cryptographic design is tightly coupled to the storage and routing model. Because the content-addressed object is the encrypted blob rather than plaintext, IPFS and any pinning layer are positioned as storage and retrieval infrastructure rather than as trusted application-layer intermediaries. This suggests that the security boundary is intentionally placed at the peer endpoints, with the network and storage substrate treated as untrusted.

4. Delivery semantics, offline messaging, and consensus workflow

The delivery path has two modes. When a DataChannel is open, the sender encrypts for the recipient and sends the ciphertext directly. When no DataChannel can be opened because the receiver is offline, the sender uploads the encrypted ciphertext to IPFS, pins it, records the content identifier in the DMQ under the recipient’s ID, and returns. When the recipient next comes online, it polls the DMQ for queued hashes, fetches each blob via the DHT, decrypts it, and delivers it to the application.

In pseudocode form, the paper gives the send path as encryption, hashing, direct send if DataChannel.isOpen(toID), and otherwise ipfs.add(C), pinata.pin(CID), and DMQ.enqueue(toID, CID). The online-recovery path is DMQ.dequeueAll(myID), then ipfs.get(CID), then crypto_box_open(C, nonce, pk_sender, sk_me), and finally deliverToApp(M).

The complexity claims are explicit. Direct DataChannel delivery has $h = \mathrm{SHA256}(C)$2 hops and constant latency. IPFS fallback requires $h = \mathrm{SHA256}(C)$3 DHT lookups to locate pinned chunks. DMQ operations are $h = \mathrm{SHA256}(C)$4 queue enqueue and dequeue per message.

Consensus is described at a high level rather than by a fully specified algorithm. A peer proposes a change, all peers in that private swarm cast Yes/No votes, and when a majority threshold is reached, the change is committed and propagated. The paper summarizes the process as PROPOSE(policyChange), GATHER(votes), COMMIT if ≥ majority yes votes, and PROPAGATE the new policy via DHT broadcast or out-of-band notification.

This division between direct transport and offline fallback is central to fybrrChat’s design. It avoids routing all traffic through an always-on server farm, but it also preserves delayed delivery for offline recipients. A plausible implication is that the system is designed to treat online low-latency exchange and asynchronous resilient delivery as coequal requirements rather than as mutually exclusive deployment modes.

5. Performance, scalability, and operational trade-offs

The reported evaluation compares two users exchanging 500 messages of varying sizes, from 50 to 500 characters. For fybrrChat DataChannel, the average latency is 0.022 s/message and the total for 500 messages is approximately 11 s. For WhatsApp, evaluated via Selenium, the average latency is 0.771 s/message and the total for 500 messages is approximately 385 s. For fybrrChat IPFS fallback, the average latency is 0.866 s/message, used only when the receiver is offline; upon reconnection, messages arrive within less than 1 s.

The paper also presents a feasibility and scalability estimate framed as “0.1% of WhatsApp scale.” Under that scenario, a centralized SignalR setup on Azure would need approximately 2,000 servers at $h = \mathrm{SHA256}(C)$5250/month and approximately 7 MWh/year. Once fully decentralized on IPNS/DHT, the paper states that operating cost and carbon footprint approach zero.

The trade-offs are stated directly. DataChannel yields sub–50 ms latencies but requires both peers online and successful NAT traversal. IPFS fallback permits offline delivery at the expense of approximately 0.8 s/message latency. Consensus and private swarms add organizational security but, depending on implementation, may incur extra protocol rounds.

These measurements and trade-offs indicate that fybrrChat’s performance claims are mode-dependent. The system is fastest in the direct P2P regime, slower in the content-addressed fallback regime, and architecturally more complex when governance functions are active. The paper’s comparison therefore depends on which delivery path is exercised.

6. Position relative to other systems and relation to browser-based virtual interaction

The paper contrasts fybrrChat with two families of systems. Against centralized messaging systems such as WhatsApp, Telegram, and Messenger, it highlights reliance on server farms for routing, storage, and policy enforcement as single points of trust and failure, along with the claim that such systems can access, log, or censor metadata and content. Against P2P Pub/Sub flooding systems such as PolderCast and MILCOM’s dynamic chat, it identifies broadcast of each message to all subscribers on a topic as extreme bandwidth waste and notes the absence of built-in offline messaging without external cloud services.

By contrast, fybrrChat is described as combining efficient direct P2P when possible with fallback to content-addressed DHT storage only for offline peers; end-to-end authenticated encryption with forward secrecy and deniability using TweetNaCl primitives; a built-in Distributed Message Queue that does not require any central queueing server; and a consensus layer for policy and membership changes in private swarms.

A related but distinct direction appears in "WOC: A Handy Webcam-based 3D Online Chatroom" (Yan et al., 2022). WOC is a webcam-based 3D virtual online chatroom for multi-person interaction that captures the 3D motion of users and drives their individual 3D virtual avatars in real-time, using a single camera, ROMP-based monocular 3D pose regression, ByteTrack-style association logic in 3D, OneEuro smoothing, automatic rigging via MeshCNN plus Blender, and a WebRTC-based distributed deployment. Its technical summary concludes that the architecture can be directly adapted for “fybrrChat” or similar metaverse-style platforms. This suggests a possible convergence between fybrrChat’s secure swarm-based messaging substrate and browser-hosted avatar-mediated interaction, although the two papers address different primary problems: secure trustless P2P communication in one case, and real-time webcam-based 3D online chatroom interaction in the other.