polyproto: A refreshingly simple decentralised, federated protocol
10 points by cve
10 points by cve
In my perspective these kind of documents should be targeted at people that already have an interest in federated protocols which have been exposed to the existing technologies in this space. Even for people that are not developers and just interested in federated services as users, it's very likely they heard of Mastodon or BlueSky before. A mention of them is in order.
These pages address the readers like all the concepts presented are brand shiny new (except the "Fedration ID", which already exists, and doesn't really need a new "branded" name, ugh).
The documentation sorely lacks a comparison with the existing status quo and why this is a new protocol, why is it's better than AT-Proto or ActivityPub, or an evolution of them with the polyproto's team perceived short-comings addressed.
(PS. Also discord as a community hub for open source is bad.)
To pile on a little, in addition to a comparison, I think it also needs an application that demonstrates its strengths. Reading the description and poking around the repository, I didn't see any links to something that had been built with this. It's hard to assess a protocol when nothing's been built with it.
I absolutely agree and see your point. This is being worked on, though there is no fixed ETA for this yet, especially since I am responsible for about 99% of the current development progress at this time, and there's lots to do.
Sounds like you just got some attention maybe a bit earlier than what would've been ideal/useful! Good luck, and I hope to hear more about it when there's a good worked example of using it.
Thank you! I mean, the attention is not entirely unwelcome! I don't plan to be a "benevolent dictator for life" with this project, and integrating people into the development of everything from the beginning seems like a good way to foster a community, which can eventually take care of itself. The questions and perhaps criticism I receive here are also helpful, because it serves as a test for me on whether I can explain the protocol in a way that makes sense and works, or if there are gaps or gotchas I haven't yet considered.
In my perspective these kind of documents should be targeted at people that already have an interest in federated protocols which have been exposed to the existing technologies in this space
This is what we have the protocol specification for! Admittedly, the website could showcase and explain much more of the protocol. It's just that time and energy are limited resources, and I am currently working on this mostly by myself,
except the "Fedration ID", which already exists, and doesn't really need a new "branded" name, ugh
Well, I thought that "Federation ID" is a very fitting, succint and literal description of what the identifier is. I didn't really think about branding or stuff like that.
The documentation sorely lacks a comparison with the existing status quo and why this is a new protocol, why is it's better than AT-Proto or ActivityPub, or an evolution of them with the polyproto's team perceived short-comings addressed.
I agree, and at some point, it will definitely get that. For now, the best way to find out what is so different is really by reading through the overview or browsing the specification document itself. This is not optimal, but it is how it is right now.
Also discord as a community hub for open source is bad
Yup. Our Zulip, which has already been linked here, is now the primary source of communication regarding on-topic discussions and conversations. The Discord is already pretty old, having turned 3(?) years old in 2025. It is a remnant of when the project was much, much smaller and less ambitioned, and seemed like an ok choice back then (certainly an easy one). I personally despise that so many open source communities use Discord for exchanging on-topic information, as it is not-indexable by search engines, has no exit-strategy, and is centralized and hyper-monetized.
If you're affiliated with the project can you give an overview on why you guys chose to create a new protocol, rather than improve upon ActivityPub or AT-Proto? (I'm an ActivityPub implementer and I'm speaking under that bias :D)
When I started developing it two years ago, AtProto was not as big as it is today. Since then, that protocol has had great success (although quite obviously much amplified through the celebrity-status of some of the involved people + the money behind it), but also lots of controversy and discussion regarding subjects such as "how decentralized is this thing really, and how viable is it to self-host?" and all the drama surrounding moderation decisions. I'm just not really fully sold on AT, I guess.
I adore ActivityPub. But I also think/know that ActivityPub and polyproto have some philosophies/core decisions that are fundamentally different. With what I wanted—migration and a more flexible identity layer, it seemed easiest to start something fresh, rather than trying to transform something that already exists.
And then, of course, this started out as a fun project where I challenged myself to see if this random train of thought I had at 3am was actually viable, or if there is a good reason for why no one has done it this way before. :)
this way before
Which way? It's not obvious to me, which of the benefits of polyproto you're referring to.
With "this way", I just meant the general approach to federation taken by polyproto. That is: Signing messages, building something that encourages extreme decentralization, and taking advantage of the fact that your data is already highly distributed, and taking advantage of the non-repudiation properties of the digital signature algorithms used when it comes to migrating your identity to another server.
Lovely, thank you. :)
What you're saying about extreme decentralization and taking advantage of distributed data, matches pretty well with what my goals are in the way I designed the ActivityPub services I work on, the link aggregator having that as a mission statement of sorts. I feel like the way Mastodon and Mastodon like services encourage the network towards unbound user numbers and caching every piece of information locally is a very wasteful.
Thanks for the link to the specification. Just so you know. The "learn more" page advertizes a link to it which 404s.
Interesting, cannot reproduce; do you mean one of the two "learn more"s on the home page?
Yes. It was the /docs/intro page's link. It works now, even though I still have an old tab with the 404 on the same URL. Maybe it is possible there was a transient server error?
EDIT: I am able to reproduce this every third refresh or so at the link: https://polyproto.org/docs/intro/protocols/core/ but it will load correctly most times.
(PS. Also discord as a community hub for open source is bad.)
The website must be outdated there because it seems that Zulip is now the main way of communication: https://polyphony.zulipchat.com/
@ava I strongly suspect you'll get a lot of "have you looked at {ssb,atproto,nostr,activitypub,xmpp,matrix,irc,smtp}?" And, frankly, please do because there are a few obvious-to-greybeards missteps in the nascent specification. But.
BUT
If we aren't celebrating and supporting any and every attempt to define a simple and useful decentralised protocol, then what are we even doing here???
It's sad that communities like cypherpunks are moribund. They'd have loved this.
I’m against protocols where your public identity is tied to some server you probably don’t control. The docs here say you can “migrate” to a different home server, but I don’t see how, given that your original home server's domain name is baked into your ID. Or by “migrate” do they just mean copying all your data to a new server under a new ID?
That's a fair point, and you're right about one thing: the docs do say your Federation ID has the server's domain baked into it, like actor@domain.tld. So yeah, if you migrate, that human-readable ID string is going to change.
But that's not the whole story. The clever bit is that your actual identity isn't just that text string. It’s tied to a cryptographic "identity key" that you control, not the server. The server just puts its stamp on your key to create an "ID-Cert" that proves you're active on that domain.
This is the whole magic behind the migration promise. You're not trying to keep your old user@old-server.com address. Instead, you go to a new server and ask other servers on which you have sent posts/messages/whatever on to migrate. Then, you can cryptographically prove to the network that the person who used to be at the old address is now at user@new-server.com. This is also how you can migrate even if your old server has been offline for ages; you don't need the old server to forward anything, because you hold the keys to your own identity. Especially if you have distributed your data across multiple different servers, this would, in theory, work very well. Of course, if your instance goes down unexpectedly, the data stored on there is no longer accessible. But polyproto is designed exactly with the use case of "this server hosts your identity, and then you can go play on other messaging/blogging/video-hosting sites and leave that data with them" in mind
So you can leave an old server, and they can serve your old data, but not modify it without your key, right?
Also, can you have multiple home servers?
Finally, and this is important, where is my id cert? How do I replicate it across my phones and tablets and laptops and shit? How do I back then up etc?
Why do you need the server to host your identity? As you said, your identity is a key-pair. That’s how it is in a true decentralized/P2P protocol. The server just attaches a human-readable string to it, but there are ways of doing that which don’t require a server.
I am designing polyproto about usability and have found, that it is much easier to do lots of things if you have a server hosting your identity. And with the guarantees the protocol gives, I found it to be a tradeoff which works well.
Absolutely support the attempt, even though I think they'll probably end up inventing XMPP-but-different. The hard part really isn't writing a federated protocol, it's writing a client with a UI and feature set that people actually want to use.
Is this better than NOSTR?
i wouldn't call it "better". protocols are tools. if you have a given workload, some tools fit the job much better than others. polyproto certainly could be a pretty neat tool, but whether it's "better" depends on the use case. Also, of course, polyproto would need to have software written for it to be able to gauge how well it works in practice.
It does feel like Nostr encompasses all use cases of Polyproto and has similar choices.
Did you consider working on Nostr instead and getting a ton of interoperable software automatically?
In another universe, Nostr and I would be best friends. However comma, since I am the gay transgender nonbinary queer fuck which metaphorical mothers have been warning you about, I cannot, in good faith, root for or support a protocol, which uses "apolitical" as the first (or second, if you don't count the headline) adjective to describe itself. I would very much like to be unpolitical. Unfortunately, there's a lot of people currently out there trying to get my ass in no way I'd consider to be "fun" even remotely.
And I'd personally like to leave it at that. I don't want to spark a discussion about what it means to be apolitical or stuff like that—there are lots of places where one could do that, if they wanted to. This is just my personal stance. And hey, regardless of that, it's nice to have some sort of backup thing or alternative to consider. After all, if one communications protocol could cover all our use cases, we wouldn't have 20.000 (hyperbole) of them, right?
Where did you read "apolitical"?
By the way, I also invite you to join Nostr, we need one good-enough and flexible protocol to create a multitude of experiences and points of view. A communication protocol needs a good network effect to bootstrap, without this we will just have 20.000 fragile toys with little effectiveness, while a dozen of monopolistic and proprietary spaces will stay strong.
Are you affiliated with Nostr in any way? I visited the website before I wrote my last comment. It said "apolitical" there. Now, 5 hours later, it says "inclusive". Since the last capture is in late Nov., you'll have to take my word for this, but here, it very clearly says "apolitical": https://web.archive.org/web/20251126005354/https://nostr.com/
Either this is a coincidence that occurred within the last 5 hours, there is another explanation to this, or someone (you? I don't know) has read this thread and changed it.
fiatjaf did the change: https://github.com/lnbits/nostr.com/commit/b30a99628da9915f448ccc2c8f8f34327a237a93
...why did they change that now, after years of having a different adjective there? hm edit: not years, actually. 6 months. mb
https://nostr.com/ is not "the Nostr website" (Nostr doesn't have a website). it's just a website that talks about Nostr.
Whatever is written there doesn't represent any official position of the proticol. And lots of people in Nostr don't like that website.
Also it's not my website, and it wasn't my tagline, but I told the owners about how that term was causing misunderstanding and they suggested the change.
Is there anything that me or other Nostr people could do to make you consider working on Nostr instead?
That is very nice of you to ask! But I do think I have spent too much of my own time on something that some people seem to think is promising in some way to just switch to another thing now.
This makes it sound like old-skool text-only usenet might make a good federated, decentralized protocol/network