This is the right question and I won't pretend it's solved yet. Interoperability with SMTP isn't built in currently.
The realistic path is a bidirectional SMTP bridge: your FLUX server accepts inbound SMTP from Exchange, Gmail, etc. and converts it to a FLUX envelope on arrival. Outbound works the other way, FLUX messages destined for a non-FLUX address get handed off to an SMTP relay. You'd get the security and features of FLUX within the network, and graceful degradation to regular email outside of it.
That's on the roadmap but not built yet. You're right that without it, adoption is a chicken-and-egg problem. Nobody migrates to a protocol they can't use to reach the people they already email.
Just to clarify on the 64 character key concern: FLUX supports regular human-readable addresses like [email protected] through the account system. The fx1... keypair is the underlying cryptographic identity but you never have to expose it. You'd give your doctor your normal-looking address just like you do today.
The pre-authorized sending idea and the pending folder flow are genuinely good suggestions though, that's something I want to add. And you're right that backwards compatibility is probably the make-or-break problem. A FLUX-to-SMTP gateway is on my list so you can have a flux address that also accepts regular email as a fallback, lowering the barrier to adoption without forcing anyone to abandon their existing setup.
The spec exists at docs/PROTOCOL.md, and the README itself covers the wire format, cryptographic scheme, and security architecture in detail. HTTP and WebSocket aren't interchangeable choices here: HTTP handles send/API calls, WebSocket handles real-time push delivery. They coexist intentionally.
The version jumps look like churn from the outside but 2.0 and 2.1 each landed substantial additions (persistent inboxes + mesh networking, then integrity chain + E2E encryption). Fair to be skeptical of the "reinvent email" motivation, that's a real conversation worth having, but the architecture criticism doesn't hold up on closer reading.
I have been experimenting with a messaging protocol called FLUX. The goal is to explore what email might look like if it was designed today instead of in the 1980s.
FLUX tries to simplify a few things that feel complicated in the current email stack. Identity is based on cryptographic keys instead of usernames and passwords. Messages are signed and verified automatically. The transport is real time and does not depend on the traditional SMTP relay model.
The current implementation is small and meant as a prototype. The whole server is only a few hundred lines of Python so the protocol is easy to read and experiment with.
I am mostly interested in feedback on the protocol design. What problems would appear in a real deployment. What parts are unnecessary. What would need to exist for something like this to actually work on the open internet.
The realistic path is a bidirectional SMTP bridge: your FLUX server accepts inbound SMTP from Exchange, Gmail, etc. and converts it to a FLUX envelope on arrival. Outbound works the other way, FLUX messages destined for a non-FLUX address get handed off to an SMTP relay. You'd get the security and features of FLUX within the network, and graceful degradation to regular email outside of it.
That's on the roadmap but not built yet. You're right that without it, adoption is a chicken-and-egg problem. Nobody migrates to a protocol they can't use to reach the people they already email.