Re: Update v0.6.0 ; Here’s how cryptocurrencies can finally experiment with inbuilt communication systems

I’ve been working on the communication side of my experimental project : CryptEX, and the most interesting recent work has been around the P2P messenger and the mail layer.

Not posting this as a product thing. I’m more interested in the protocol/design discussion, because the main lesson was that “chat” and “mail” stop being UI features pretty quickly and turn into transport problems.

A few things changed in the latest pass.

First, the messenger is now treated as a typed application protocol on top of the node graph, instead of just “broadcast some text and hope the UI sorts it out later.”

The payload model is explicit now:

• public chat
• private chat
• voice-control payloads
• voice-frame payloads
• mail payloads

That sounds simple, but getting the types right matters a lot because it affects routing, replay protection, encryption rules, persistence rules, and what is allowed to be relayed.

For private messaging, the transport is signed and authenticated, and the encryption mode is explicit. Right now the stack supports:

• ECDH-based direct encryption
• RSA-OAEP wrapped-session-key mode
• AES-GCM for payload encryption
• versioned KDF profiles instead of baking one derivation path into the protocol forever

Each payload carries enough metadata to make validation sane:

• sender address
• recipient address
• timestamp
• nonce
• message type
• flags for signed/encrypted state

That helped kill a bunch of ambiguity around “is this a public message?”, “is this transport-only?”, “should this be decryptable by the local wallet?”, and “should this be relayed at all?”

The second big piece was recipient resolution.

Instead of doing username-style identity, the communication model is address-first. The node can resolve a recipient from an address or contact entry into something communication-ready:

• peer label if known
• whether direct messaging is possible
• whether ECDH material exists
• whether RSA material exists
• whether the target can be used for mail delivery

That sounds like a small UX feature, but it ends up being a protocol boundary too. It means the GUI isn’t inventing its own contact logic; the daemon is the one deciding what the network and wallet actually know about that recipient.

The mail layer got the bigger redesign.

The main decision there was: don’t fake mail by treating it as “private chat with a different tab.”

Mail has very different delivery semantics from chat. Chat is about live-ish relay. Mail is about store-and-forward, partial reachability, replication, delayed lookup, receipts, and accountability.

So the mail side now uses dedicated network message families for mailbox behavior:

• store
• find
• results
• receipt
• challenge
• proof
• NAT introduction

That ended up looking much more like a lightweight distributed mailbox overlay than a normal messenger.

The interesting part is how delivery works when the target is not directly reachable.

The mail layer can now combine:

• direct peer delivery when available
• NAT assist / introduction when possible
• relay fallback when direct routing fails
• STUN-derived reflexive endpoint awareness
• optional dedicated relay peer preference
• SOCKS5 proxy configuration for mail transport paths

So instead of having one binary state of “reachable/unreachable”, the system can reason in a more realistic way:

• direct route exists
• direct route does not exist, but introduction might help
• introduction failed, fall back to relays
• relay is allowed or disallowed by policy

That policy side became important enough that it got its own configuration surface.

Current mail policy controls include things like:

• message TTL
• replica target
• max stored item count
• whether imported/expired items get pruned
• proof-of-storage on/off
• challenge interval
• minimum bond
• required verified replicas
• slash-on-failed-proof
• slash penalty score
• NAT assist
• relay fallback
• dedicated relay peers
• STUN servers and timeouts

I’m aware that “slashing” sounds overbuilt for a mailbox system, but once you let peers store encrypted mail blobs for each other, some kind of storage-accountability path becomes hard to avoid if you want the replicated-store part to be more than wishful thinking.

There’s also a security control layer on top of that. For example, mail sending/deletion can be gated behind TOTP, which is not a transport feature by itself, but it matters because mailbox actions are now first-class node operations rather than just UI events.

Another thing that changed is that the messenger and mail logic no longer behave like two disconnected subsystems.

They now share a lot of the same communication assumptions:

• address-first identity
• typed content envelopes
• authenticated sender metadata
• wallet-backed key material
• daemon-mediated resolution and transport
• relay-aware routing decisions

That made the whole communication stack easier to reason about. Before that, “chat”, “mail”, and “directory” each had their own little half-truths about what a recipient was and how delivery should work.

The biggest takeaway for me is that once you go beyond public chat, a P2P messaging system stops being about message encryption and starts being about communication state.

Things like:

• who is known vs currently reachable
• who is directly reachable vs relay-only
• whether a payload is live transport or store-and-forward
• whether the daemon is allowed to relay a given message type
• whether the recipient has enough key material for the requested mode
• whether a mailbox replica is merely stored or actually verified

Those questions end up mattering more than the UI layer.

Anyway, that’s the part I found interesting in the latest update: taking a “P2P messenger” and “P2P mail” feature set and forcing them into explicit protocol roles instead of letting them remain app-level abstractions.

If anyone else has built address-first communication on top of a node graph, I’d be curious how you handled:

• recipient resolution
• relay vs direct routing policy
• mailbox replication semantics
• proof/receipt flows
• NAT introduction without turning the whole thing into a separate signaling service