: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
have been following for a while , been in the discord server for it for ages , was trying to create a federated chat service a bit ago and was strongly considering using polyproto
:boost_requested: Pitching a new federation protocol@star "big spec document (which I have tried my best to write in a way that doesn't induce a deep sleep on the reader)" +100 points to the protocol immediately.
: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.
:boost_requested: Pitching a new federation protocol@star Ooh. I haven't been on fedi for a few days and am now slowly discovering the happenings around the discord discourse and that there's already something being worked on. Omg this is great :>
:boost_requested: Pitching a new federation protocol@katzenmann Yes! I've been working on this on my freetime for about 2-3 years now I'm glad you think it's cool!
:boost_requested: Pitching a new federation protocol@star i must've just missed it then i'll have to see what's an alternative to nomadic identity then cause that's the one i prefer for this kind of thing (for fedi, and for my protocol)
@star ok account migration even if the homeserver is down and has been that way for a while (and i guess also if the homeserver is uncooperative) is epic
@star@CauseOfBSOD Yeah, I love that part too because I got bitten by this: the Fediverse account for my hobby project had to move twice. While the first move was a regular one, the second move was after the server went down permanently without warning. Lost all followers. 😭
Oh, and the new account at @ChronoLink doesn't have the older posts. A protocol which would even solve this problem sounds really great. I hope it works out! Good luck.
@tynstar@CauseOfBSOD@ChronoLink a lot of my assumptions are currently made with a discord-like model in mind. a lot of things would apply 1:1 to fedi-posts as well, but there could, of course, be differences. either way, thank you for the encouraging words :)
@star@tynstar@ChronoLink im pretty sure theres some fedi software out there that speaks activitypub as well as some other protocol (no im not talking about the bluesky bridge, im thinking of actual instance software) so having partial support for something like this using polyproto where possible and activitypub where polyproto is unsupported could be viable
@CauseOfBSOD@tynstar@ChronoLink wafrn! wafrn does this. i have also thought of doing this, but i am not... starving for projects now or any time soon, so i personally will not pursue it at this time :3
security questions@luna It's equally late here and I want to answer this after a good night's sleep :3 I hope I do not forget. Please remind me, if you can and want to!
shouldn't the signature field in 3.2.3.5 have some seperator or such defined to deal with canonicalization problems?
Well, if anything, this would apply to the way the concatenation operation works, not the resulting signature. But that might be a good point, especially since this is already defined later in the spec. It should be referenced there.
also how does/would compression deal with mixing secret and untrusted data?
Could you perhaps elaborate on this question? I don't quite understand what it means
> how is server authentication handled? is it pki or something else?
Well, "authentication" means a lot of things, and there are different steps involved (I.e. cold-auth (logging in or registering) vs. hot-auth (using a session token to re-authenticate further requests). I have been thinking about how to handle authentication for a while now, and while the protocol already describes authentication paradigms to ensure requests are, well, authenticated properly, there's stuff like "How do we do registration and login" which are not yet part of the protocol. To make a long story short, I have been considering using OIDC for this, as it is yet another well-known, trusted standard, implemented by many and with vast community support in all sorts of programming languages—just like all the other technologies polyproto builds on. I think that this will be the way to proceed with this, and I want to draft some specifics about OIDC very soon, after I took yet another look at it, deciding whether it is truly a great fit for the protocol.
Thank you for the questions c: please do feel free to ask more!
security questions@star@luna the compression question most likely refers to the BREACH vulnerabilities where compression of secret data led to secret exfiltration without knowing the key.
about compression: I'm referring to attacks such as CRIME and BREACH (both against TLS). As an example, if you can get an account to post arbitrary data (@keysmash is a good example) AND you can monitor the ciphertext going between it's client and server AND session tokens are compressed together with the post, then you can recover the token (see the exploits for how).
about auth: I'm referring to authenticating that the client is talking to the real homeserver/remote server instead of a MITM, not authenticating clients. I was unclear, sorry.
re: security questions@luna Ah! I have not actually yet heard of BREACH and CRIME, so a million billion thanksies for letting me know! I'll research that then!
re: security questions@luna Regarding "verifying server identity": Perhaps more can be done here (input wanted!) but I was intending that this would be covered by existing MITM defense mechanisms such as DNSSEC
I guess you could have a HPKP system; that'd significantly challenge a practical MITM attack.That and having servers compare a given servers cert among themselves (A and B co-operate to check that they get the same cert from C). Maybe even have clients helping.
I think doing both would make a MITM practically impossible unless the server is MITM'd right from the start, though there needs to be more threat modeling done for this.
re: security questions@luna Yes, I think that there would need to be additional threat modeling done for a hardened, more security-focused application of the protocol. I'd like your opinion on my comment about DNSSEC, if you don't mind, because you seem knowledgeable and also second opinions can't hurt
DNSSEC has the advantage that you basically have two root key(set)s (DNS root and TLD) instead of god-knows many. Also, not everyone agrees about what PKI roots are trusted, which I imagine is going to be an utter pain in the ass. Problem is getting people to adopt it.
Oh, sidenote: have you thought about using TLS client certificates for authenticating to remote servers instead of a homebrew auth protocol?
have you thought about using TLS client certificates for authenticating to remote servers instead of a homebrew auth protocol?
i think that as an authr/n protocol, OIDC has lots of advantages in terms of how familiar users are with it, and how very versatile it is inherently.
But no, I have not thought about it yet :3
About DNSSEC: I have just read a blogpost by Cloudflare about it, and this sounds very funny:
In the Root Signing Ceremony, several selected individuals from around the world come together and sign the root DNSKEY RRset in a very public and highly audited way. The ceremony produces an RRSIG record that can be used to verify the root name server’s public KSK and ZSK. Instead of trusting the public KSK because of the parent’s DS record, we assume that it’s valid because we trust the security procedures around accessing the private KSK.
I guess my thought process here is: "If this is ok for the entire internet to use, then I think it should be okay for me as well". And, regardless:
- Unencrypted communications are, by design, not private enough to be used in a scenario where security is of a large concern - Encrypted communications lean in clear-text metadata and encrypted in ways that explicitly exclude the relaying server from the circle of trust already mitigate the consequences of a potential PITM (puppy-in-the-middle) attack to a good extent. Encrypted communications over polyproto will follow such a design
re: security questions@luna Fair. I thought that, for the purposes in which I intend the core of this protocol to be used in, the current threat model is sufficient. Other use cases can impose their own additional restrictions and guidelines.
1
1
1
1
1
1
1
2
1
1
1
1
1
1
