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 :)