This looks very interesting. I was about to ask what language you plan to use, but then i saw the proof on concept in Rust. I think thats great because Rust has a real focus on correctness, which helps to avoid problems early on, so you spend a lot less time debugging weird edge cases.

Agreed! I got on the Rust hype train a long time ago but sadly other things got in the way of me writing any substantial projects in it, so by the time we got this idea, I was really determined - biased, actually, I would say - to use Rust.

If it takes off, we plan to make another implementation in Go so it can run on Plan 9.

For the protocol, I would recommend you dont define messages by raw bytes, thats a really complicated way to serialise information, and bandwidth is not an issue in this case. Json would work equally well, as would protobuf or something similar. That will also allow you to auto-generate the protocol docs.

Raw bytes is more complicated than JSON or protobuf? I guess we have different definitions of complicated. JSON or protobuf would effectively add a dependency to the protocol and to every implementation. Raw bytes can be parsed and formatted very easily and don’t require linking to a separate document to explain how they work.

Other than that, though, part of the reason I chose raw bytes is that I’m afraid of extensibility. We have examples of protocols or platforms that started out simple, but got endlessly expanded until they were completely beyond mortal understanding and impossible to implement securely, most notably the web, and to a lesser extent Matrix. My beliefs about software have been infleunced a lot by Drew DeVault, and this was one example: “a protocol designer who limits extensibility is a wise one.”

Edit: No message deletion, edits and no multi-device support will severely limit the use cases for this project. I hope you can consider adding this later, even though the project will already require a ton of work.

I’m pretty sure on message deletion and edits, but maybe you’re right on multi-device support. Drew also said when I solicited his feedback that multi-device support was a requirement for “the general purpose messenger space”, so we might have to reconsider that.

(He also pointed out that letting each node along the path know the final recipient is a significant privacy loss relative to Tor-style routing, so we might revise that too.)

Maybe you want to apply to NLnet for funding (they also finance Lemmy development).

That sounds awesome, but me and my two friends working on this are pretty much “nobodies”, so I doubt we’d be getting anything :)

As for recovering a long-term key with a 12-word secret: yeah, we plan to have a feature like that in the future. My friend already implemented that in her own version (which was made a while ago and based on a pretty different idea of what the protocol would be, but it’s not hard to add)

As for offline receiving: are you suggesting storing messages in a DHT so that the recipient can receive them while you’re offline? That crossed my mind early in planning, but we decided against it because we don’t want to store things on peers that might go down at any time, and I’m not sure how it could work with forward secrecy anyway since every message requires a handshake (well, maybe if we used the axolotl/double rachet thingy, but that’s so much more complicated, I would not trust myself to implement it).

Do you mean that we could use IPv6/4 multicast to send packets through multiple peers at once incase one of them is unreliable?

For future-proofing, both of these are probably terrible ideas :)

I assume you mean because of size limits. As of right now, the current number of milliseconds since the epoch only takes 6 bytes to represent; to be exact, it’s less than 8.9e-8 of the max that 8 bytes can represent - so basically safe for all eternity IMO.

As for the group size, I know that some rooms in chat systems such as Matrix and Discord have more than 256 members, but my stance is that E2E encryption is useless in that type of situation because there is no way you personally know and verified all those members, so your chat is not private anyway.

Not sure if that’s good or not. That’s one of the problems with email, leaking so many addresses in the CC field (that’s why we have BCC). Spam protection is hard in p2p networks, but i’d imagine that by “threading” discussions you could generate specific keypairs so that if some spam starts flowing in your direction from a discussion you can just drop that keypair (like email aliases).

Well, you can easily generate multiple key pairs and use them for different rooms, similarly to email aliases. I’m not concerned about the fact that it reveals all recipients to each other, because the point of this feature is to emulate group chats, where that’s desired. If you want to send a message to multiple people without revealing the full list of recipients to each of them, you could just do that (just send the message to each of them with empty other-recipient lists).

That’s pretty cool. Have you considered using I2P or an even-more experimental mixnet (like katzenpost) as transport layer?

We did, early on, actually. I wanted to use Tor as a transport, an idea I borrowed from Tox (which makes no effort to provide anonymity and suggests running it over Tor if you care about that). A friend of mine, one of the two other people involved in the planning, wanted to roll our own similar system. When she convinced me that hers had an advantage over Tor’s (nodes cannot tell if they are the first relay in the chain or not), I conceded on Tor and wanted to use GNUnet as a transport, but sadly accepted that GNUnet is vaporware and we couldn’t depend on it, so I ended up implementing roughly my friend’s suggestion.

We didn’t look at I2P or katzenpost in particular. I had sort of gotten discouraged by the feeling that there were too many interesting dark/mixnets for me to investigate and I wasn’t confident enough in any particular one to want to use it as a transport.

Thanks for the read I’ll finish tomorrow (getting late). In the meantime, are you familiar with the Briar? They also use some gossiping (wifi, USB keys…) as well as onion services to broadcast messages.

Briar was one of the apps I looked at before deciding to make one. The main reason I wrote it off was for requiring a phone. It’s definitely possible that it has some ideas we should borrow, but there were too many of these secure messengers for me to look at all of them in detail.

Update: I contacted an author I respect, Drew DeVault, for feedback on the protocol and he said that sending the recipient ID in plaintext was bad and that we should use some form of onion routing instead. To be honest, I think this is an upside of Tor compared to my friend’s idea that we totally overlooked - that the first and second relay nodes don’t know the final recipient, whereas in sufec they do - so we might change course and do something like that after all.

I haven’t added that level of detail to the spec yet, especially since it could be subject to change anyway, but the implementation I’m currently using is the sodiumoxide crate (I’m aware it got marked as “deprecated” recently so I will look into replacing it with other crates eventually, but I thought that getting most of the protocol hammered out was more urgent than using a better library).