Official Gnoppix Messenger Framework

NullNode is a peer-to-peer encrypted messenger. There is no central server that reads your messages. Messages are encrypted with post-quantum Kyber-768 (ML-KEM) and can be delivered either directly (peer-to-peer) or through a distributed DHT mailbox (like a dead drop).

Part 1: How Nodes Are Discovered

Before a node can send a message, it needs to know the IP addresses and ports of other nodes in the network. This process is called Node Discovery and typically happens in three distinct phases:

[ New Node ] ──> 1. Bootstrapping (Seed Nodes) ──> 2. DHT Lookup (Kademlia/Routing Table) ──> 3. Active Peer List

1. Bootstrapping (The Entry Point)

When a node starts up for the first time, its routing table is completely empty. To find its first peer, it uses a process called bootstrapping:

Hardcoded Seeds: The software contains a built-in list of reliable, static IP addresses or domain names (managed by the project developers) known as Seed Nodes.
Initial Connection: The new node connects to a seed node and requests a list of currently active peers on the network.

2. Distributed Hash Tables (DHT) & Routing Tables

Once the node has an initial list of peers, it populates its own local routing table (often using an algorithm like Kademlia).

Node IDs: Every node generates a unique cryptographic public key or identifier (Node ID).
Distance Metrics: The network organizes nodes logically based on how “close” their IDs are mathematically (e.g., via an XOR metric), rather than geographical location.
Continuous Discovery (Ping/Find_Node): The node continuously sends background RPC requests (PING or FIND_NODE) to its known peers, asking: “Who are the closest nodes you know to ID X?” Through this iterative query process, the node maps out the network and discovers new active peers.

3. Local Network Discovery (Optional)

If nodes are running on the same local network (LAN), they often skip internet routing entirely using local broadcast protocols:

mDNS / UDP Broadcast: A node sends a UDP broadcast packet to the local network saying, “I am a NullNode listener on port X.” Other instances on the same subnet hear the broadcast and automatically open a connection.

Part 2: How Messages Are Sent

Once nodes have discovered each other and built a list of active peers, they can transmit data. Depending on whether the message is intended for a single recipient or the entire network, one of two primary methods is used.

1. Direct Peer-to-Peer Messaging (Unicast)

If Node A wants to send a direct, private message to Node B:

Connection Establishment: Node A looks up Node B’s IP address in its routing table and opens a direct connection (typically via encrypted TCP sockets, gRPC, or WebSockets).
End-to-End Encryption (E2EE): To ensure privacy, the message is encrypted using Node B’s public key before leaving Node A. Intermediate nodes or network sniffers can see that traffic is passing through, but they cannot read the contents.
Handshake & Verification: The nodes exchange a cryptographic handshake to verify each other’s identity (Node IDs) before the payload is transferred.

2. Network-Wide Broadcasting (Gossip / Flood Protocol)

If a node needs to broadcast information to the entire network (such as updating a ledger, announcing a new state, or syncing configuration files), it uses a Gossip Protocol:

Epidemic Spreading: Node A sends the message to a small, random subset of its connected peers (e.g., 3 or 4 neighbors).
Propagation: Each neighbor validates the message, checks if they have seen it before (to prevent infinite loops), and forwards it to 3 or 4 of their neighbors.
Deduplication: Every message contains a unique hash or sequence number. If a node receives a message it has already processed, it silently drops it, stopping network congestion. Within seconds, the message naturally “gossips” across the entire global cluster.

3. Privacy-Preserving / Anonymous Routing (Onion Routing)

Given the privacy focus of distributions like Gnoppix, messaging architectures can also incorporate an onion-routing layer (similar to Tor or OnionShare frameworks):

Instead of connecting directly to Node B’s IP, Node A wraps the message in multiple layers of encryption.
The message is bounced through three random intermediary nodes (Guard, Relay, Exit). Each node only decrypts enough data to know where to send it next. The final node delivers it to Node B without Node B ever knowing Node A’s true IP address.

Link: -> https://github.com/gnoppix/NullNode -> https://gnoppix.org/messenger/