Show HN: Flux, a tiny protocol that rethinks email from the ground up(github.com)
github.com
Show HN: Flux, a tiny protocol that rethinks email from the ground up
https://github.com/levkris/flux-protocol
8 comments
Considering it went through two major versions in mere hours, the changelog specifying POC changes (instead of spec changes) and for some random reason switched from WS to (fetch functions?) I'm pretty confident that there is no thought behind this.
I dig the idea, I dont dig the goal (reinvent email because it's "hard"?), and I don't dig everything after that.
Just write a spec at this point, the POC does nothing more than exist for existence sake
I dig the idea, I dont dig the goal (reinvent email because it's "hard"?), and I don't dig everything after that.
Just write a spec at this point, the POC does nothing more than exist for existence sake
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.
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.
Hi HN,
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.
Repo: https://github.com/levkris/flux-protocol
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.
Thanks for taking a look. levkris (wokki20)
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.
Repo: https://github.com/levkris/flux-protocol
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.
Thanks for taking a look. levkris (wokki20)
I would love to have something better than email, but how do we get there? How do we get everyone to adopt a new system? The biggest thing I would like to see is a system with pre authorized sending. Not sure if your system does this but the ideal situation for me is that I should only ever be able to receive mail from someone I have pre approved.
But you need a simple way to do this pre approval process, perhaps it goes to a special folder in the client the first time you receive from a new sender, and then you can approve the sender for all future mail so it goes into the main inbox?
If I’m talking to my doctor on the phone and they ask for my email I need an easy way to preapprove them, it can’t be some complex system where I must give them a 64 character alphanumeric random string.
Also I think the only way a system like this will succeed is if it is somehow backwards compatible with email, there is just too much momentum with email as is, to be able to successfully migrate everyone off it and without some sort of delay email fallback system.
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 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 biggest issue I have with this is the path to success. There are billions of emails exchanged every day. Thousands of mail servers, millions of mail clients.
This project looks great but how does it get adopted? It will need to support interoperability. It will need to support being a part of the current ecosystem and grow step by step.
So how will that work? How can I set it up and still send an email to a Google Mail account? How can my FLUX server receive emails from Exchange?
This project looks great but how does it get adopted? It will need to support interoperability. It will need to support being a part of the current ecosystem and grow step by step.
So how will that work? How can I set it up and still send an email to a Google Mail account? How can my FLUX server receive emails from Exchange?
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.
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.
This is a really cool idea. In terms of interoperability, FLUX should probably warn users that FLUX specific features may not apply when sending it outside it's protocol, but should allow users to send it anyway.
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.
Repo: https://github.com/levkris/flux-protocol
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.
Thanks for taking a look. levkris (wokki20)