@polyproto

polyproto federation protocol @polyproto@amazonawaws.com

1mo

We are fucking queer to our polyproto-core. Don't like it? Fuck off!

To everyone else: The happiest of pride months to you!

1

1

1

1

1

1❤️1

0

24

41

7

polyproto federation protocol @polyproto@amazonawaws.com

3mo

We have our own 88x31 now, too! It's not the most beautiful one out there, but I did make it myself! Embed it wherever you want :)

Link to image

<a href="https://polyproto.org">
    <img loading="lazy" src="https://88x31.polyproto.org" alt="The polyproto federation protocol" style="image-rendering: pixelated"></img>
</a>

1❤️1⭐1

1

6

19

3

polyproto federation protocol @polyproto@amazonawaws.com

6mo

In the footer of our website, one can now find a bonus fops for when times are tough!

1

1

4

9

2

polyproto federation protocol @polyproto@amazonawaws.com

3d

@lypsilonx Oh, sweet! In that case, I can very much encourage you to join our Zulip! I'd love to collaborate :) - @star

0

2

0

polyproto federation protocol @polyproto@amazonawaws.com

3d

The meeting is set to happen on July 22nd, 6:00pm (Europe/Berlin)! Be there or be

Calendar subscription | Calendar event download (.ics) | Proton Meet Link

1

0

15

11

1

polyproto federation protocol @polyproto@amazonawaws.com

5d

@Nyan Hi! I believe you'll be able to find answers to this on our website (polyproto.org) and specifically also the following blog post: polyproto.org/blog/2026/01/02/prior-art/

0

polyproto federation protocol @polyproto@amazonawaws.com

5d

We are forming a working group to design the best possible federated alternative to Discord, Matrix and co.! And we'd love for you to be a part of it!

For this, we will have regularly scheduled online meetings and asynchronous communication in between meeting dates.
Our first meeting is about figuring out how we'd like to work together. How often do we meet? How do we want to make decisions? How will results get communicated to the broader public?
Sound interesting to you? Read the full agenda and detailed description, help us with choosing a date and time for the first meeting by entering your availability here and/or join the Zulip to stay informed!

- No advanced technical knowledge required for this meeting
- Date/time will be chosen and announced after Sunday, July 12th 2026, 3pm (Europe/Berlin)
- Meeting will be held online, link will be published after date/time is fixed

1

1

1

1

2

1❤️4

5

43

36

12

polyproto federation protocol @polyproto@amazonawaws.com

1w

We are extremely thankful and happy for your feedback thus far!

More working group-related information soon.

0

1

4

0

polyproto federation protocol @polyproto@amazonawaws.com

1w

@hsza @Venefilyn

does it all use https under the hood?

yes. The X.509 from polyproto is purely a layer on top of existing infrastructure, and doesn't commingle with it.

then you're still importing the issue of CA centralization from that

That's true. But you cannot decentralize everything without creating a huge, complex, unimplementable mess of a specification. Tech extensions could be used to replace HTTPS and the fact that the infrastructure behind it is sort of centralized with an alternative transport layer.

With decentralization, you can always go a level deeper. We are focusing on creating a decentralized federated network, not a decentralized IP transport layer. And even if that were solved, you could go deeper again and say "still, the internet itself is very centralized because of ISPs, server providers etc." and demand polyproto-over-meshcore or something like that. But then you could still say "well, semiconductor production used for meshcore radios is quite centralized too, so we should provide a specification to build your own radio from sticks and stones and then do polyproto over that". And, sure, those aren't invalid points, but that'd all take well over a decade to do, so I defer that to other individuals/for later.

1

0

1

0

polyproto federation protocol @polyproto@amazonawaws.com

1w

@hsza @Venefilyn Intermediary certificates being forbidden also means: It isn't (at least easily; everything is doable if you ignore the rules) possible for someone like Google to offer something like LetsEncrypt for polyproto, which would centralize trust, and thus power, around them.

0

2

0

polyproto federation protocol @polyproto@amazonawaws.com

1w

@hsza @Venefilyn Unlike CAs used for HTTPS and such, polyproto does not have trust roots. Trust roots are trusted certificates by big companies, which essentially sign the certificates of other companies acting as certificate authorities "downstream". These trust roots make CAs very centralized in practice. If you tried to host a website using a completely self signed SSL cert, your browser would refuse to load it and display a big fat warning about the SSL cert being untrustworthy. That warning is because there is no valid path from the self-signed certificate to any of the trust roots installed on your device.

In polyproto, intermediary certificates are forbidden. There's only the home server certificate and client certificates. Picking up the "self-signed certificate for your website" example again: If you deploy your own home server, you do that with a self-signed certificate which the server generates and signs. Unlike the website, there is no warning and no refusal from your browser. This is what makes it much more decentralized.

Why this even works from a security perspective is, because we are only building in top of established infrastructure. To make your home server reachable over HTTPS, you still have to get an SSL certificate somewhere, be it from LetsEncrypt or some other service. We use the security guarantees that the infrastructure the entire world runs on give us, and build something less restrictive on top of that. Perhaps this makes sense, perhaps this is too wordy; let me know if there are any questions you still have! :)

2

0

1

0

polyproto federation protocol @polyproto@amazonawaws.com

1w

@hsza @Venefilyn polyproto arbitrarily limits the chain length to 1, meaning it doesn't allow intermediaries between the home server and actor certificates. This was precisely done for the reason you pointed out.

1

0

1

0

polyproto federation protocol @polyproto@amazonawaws.com

1w

@Venefilyn At the risk of oversimplifying a lot: polyproto aims to always have you at the wheel. Our architecture around classic certificate authorities allows you to migrate servers, even if your old home server is actively hostile or long offline, while taking as much of your data with you as possible. ActivityPods is most definitely the more mature solution, as it has been stable for a while now. It has "access" to the whole Fediverse and uses very different technologies to accomplish, essentially, a slightly different goal: Plain JSON vs. JSON-LD+RDF, WebSocket vs. SPARQL and LDP REST, X.509 vs. WebID and "being a federated identity protocol spec, conceptualized from the ground up" vs. "a data storage platform and app framework as an improvement over vanilla AP for the Fediverse".

Disclaimer: I know not much about ActivityPods, and this answer is largely based on me skimming the website you very helpfully linked, search engine results and a bit of the ActivityPods docs start page. Please do point out misconceptions or technical errors in my response, if there are any.

Any misrepresentations are purely on accident and even though I have tried my best, mistakes may have been made.

1

0

5

0

polyproto federation protocol @polyproto@amazonawaws.com

1w

In preparation of this working group, we'd really looooooove to hear your thoughts, wishes, fears and general knowledge that you'd like to share with us, regarding the working group and the chat protocol itself. write.polyproto.org/aolvLTdsS7GzEOHtoVU04g?both

1

7

5

0

polyproto federation protocol @polyproto@amazonawaws.com

1w

@transoptimal have trust in the therians and furries to build something nice :3

0

1

3

0

polyproto federation protocol @polyproto@amazonawaws.com

1w

Following the merge of the JSON canonicalization PURR, a detailed index and overview of all existing PURRs and PAWs were long overdue. We have now added one here: polyproto.org/docs/workflows/overview

1

0

5

0

polyproto federation protocol @polyproto@amazonawaws.com

2w

The Amazing Digital Circus Spoiler/ TADC SPOILER for Episode 9/Finale

Jax wouldn't have abstracted. polyproto could have saved her.

0

1

9

0

polyproto federation protocol @polyproto@amazonawaws.com

2w

Imagine if the amazing digital circus were, like, federated

❤️1

2

4

7

1

polyproto federation protocol @polyproto@amazonawaws.com

2w

PURR-2026-0009 "Enforce JSON canonicalization" has exited the draft phase and will likely be merged tomorrow, if no valid objections arise.

Quoting from the PURR:

polyproto uses JavaScript Object Notation (JSON) as the default format for interchange of data wherever feasible. This is because JSON is the most widely adopted data interchange format in a web-application context, facilitating the protocols ease of adoption.

Digital signatures over JSON data are only verifiable if signer and verifier compute the signature over byte-identical input. Because JSON permits multiple valid serializations of the same logical data (differing key order, whitespace, or number formatting), signing "JSON" without exactly defining its byte representation makes signatures non-reproducible and, in some implementations, exploitable via canonicalization mismatches.

0

4

6

0

polyproto federation protocol @polyproto@amazonawaws.com

2w

polyproto-rs currently has 325 tests. Who (

←) would do something like this

0

9

0

polyproto federation protocol @polyproto@amazonawaws.com

2w

un-secures your scuttlebutt

0

10

0

polyproto federation protocol @polyproto@amazonawaws.com

2w

@esm the hell

0

1

0

polyproto federation protocol @polyproto@amazonawaws.com

2w

Today, I manually end-to-end tested the OIDC support that landed in the main branch of the polyproto SDK just a couple days earlier. Using Dex as an OIDC Identity Provider, the crate was able to parse and verify a sample password-based and even the modern Authorization Code flow from start to finish. I also identified an issue with the specification, which I fixed just a couple minutes ago, and was able to take notes from the testing to improve the crate further for the future.

As it stands now, the December v0.1.0 release goal of our polyproto-core home server still seems very plausible, as I caught myself actually being ahead of schedule now!

The SDK builds the home server and provides Rust functionality for polyproto-core clients at the same time.

1

0

3

11

1