:boost_requested: Pitching a new federation protocolpolyproto is an up-and-coming federation protocol with features like lossless account migration, resilience against loss of identity because of homeserver shutdown and tamper-resistant data exchange inherent to how it works under the hood.
The best part is that it doesn't re-invent the wheel, and builds on extremely well-known and widely used technologies such as X.509 (the technology powering all the SSL/TLS certificates—the thingies responsible for the padlock 🔒 symbol in your browser), regular ol' digital signature schemes, JSON, HTTP and Websockets.
If you are so inclined, feel free to find out more at polyproto.org or feel free to polyproto.org/docs/protocols/core (which I have tried my best to write in a way that doesn't induce a deep sleep on the reader).
The project wants to eventually yield a federated, self-hosted Discord alternative usable by everyone, not just computer nerds, and hosts it's source code at codeberg.org/polyphony . It is not currently in any usable or demoable state, sadly, but that is being worked on.
:boost_requested: Pitching a new federation protocol@star signing individual messages is an immediate red flag to me. The secure messaging ecosystem has moved beyond that, most notably with OTR in 2004 en.wikipedia.org/wiki/Off-the-record_messaging and later Signal. Any protocol should take great care not designing a privacy nightmare.
:boost_requested: Pitching a new federation protocol@networkexception The message signatures are not just there for fun, but they are required for many of the guarantees and features polyproto offers.
I definitely see your greater point, though. But I would not agree that signing individual messages immediately or inherently makes any given messaging ecosystem a metadata and privacy nightmare.
polyproto is, right now, especially aimed at covering a lot of "regular people" use cases. A lot of those use cases—as demonstrated by Discord—are inherently public: Being in a large community space (i.e. of a Programming Language or some internet celebrity) is an inherently public thing. Complete secrecy is just not compatible with those use cases. However, I would like to be a lot better than Matrix when it comes to enabling private and secure encrypted messaging (just out of spite, tbh). Notthing is really set in stone regarding the topic of encryption yet, beside the fact that (for many reasons) I'd like to use MLS. If you are interested in giving further input or even steering the metaphorical ship on that topic, I wholeheartedly invite you to do so! ​
:boost_requested: Pitching a new federation protocol@startrek
Signed messages are not about secrecy, they're about non-deniability. Anyone being able to read your message will be able to prove the exact words you said, including to a third party. That's especially bad without context. It's impossible to delete these proofs later on. See also: Minecraft's Chat Signing critics.
Also, MLS is not a magic fix and your transport layer would need to be designed around it quite heavily.
:boost_requested: Pitching a new federation protocol@networkexception@startrek Nothing is a magic fix. The cryptographic property of plausible deniability is not, either. "Deniability" has to be contextualized with "in front of whom?". There is strong evidence that plausible deniability in current messengers such as Signal or WhatsApp has little to no real-world impact; neither in a court of law, nor in front of the general public or friends. Designing a system, which can achieve plausible deniability in the real world is possible, but would require that this system is designed with this property as a primary purpose.
I implore you to read petsymposium.org/popets/2025/popets-2025-0018.pdf, a rather recent paper on this exact topic which, on top of providing own research, information and conclusions, meta-analyzes and references currently existing research on the same or similar issues.
For the intents and purposes of how I envision polyproto to be used, the cryptographic property of plausible deniability in signatures is not something I want to focus on achieving, and I firmly hold the belief, that there are plenty of more pressing issues to consider when designing a secure messaging system, such as—in an encrypted, confidential setting—leaking little to no cleartext metadata. In fact, this protocol heavily relies and benefits from the guarantees offered by non-repudiaton properties.
1
1
2
1
1
1
1
1
1
1