@polyproto

polyproto federation protocol @polyproto@amazonawaws.com

1mo

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

1mo

@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

1mo

@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

1mo

@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

1mo

@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

1mo

@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

1mo

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

1mo

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

0

1

3

0

polyproto federation protocol @polyproto@amazonawaws.com

1mo

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

2mo

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

2mo

Imagine if the amazing digital circus were, like, federated

❤️1

2

4

7

1

polyproto federation protocol @polyproto@amazonawaws.com

2mo

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

2mo

polyproto-rs currently has 325 tests. Who (

←) would do something like this

0

9

0

polyproto federation protocol @polyproto@amazonawaws.com

2mo

un-secures your scuttlebutt

0

10

0

polyproto federation protocol @polyproto@amazonawaws.com

2mo

@esm the hell

0

1

0

polyproto federation protocol @polyproto@amazonawaws.com

2mo

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

polyproto federation protocol @polyproto@amazonawaws.com

2mo

@freeplay Actually, yes, sort of! I only intended to stretch this vowel out for fun and as a vocal stim, but then I actually thought of you, and realized that this would then be a reference to you; so yes, it is canon!

0

4

0

polyproto federation protocol @polyproto@amazonawaws.com

2mo

@PileOfOxides :polyprototrans: p

0

5

0

polyproto federation protocol @polyproto@amazonawaws.com

2mo

@hsza Interesting, thank you for your feedback! Would you care to share some of the passages you didn't like in particular? I am really not a good writer for things like these, and part of the reason why the start page has been very... minimal until now, has been exactly "I don't know how to write stuff and I am not sure I can do a good job", so precise feedback would be much appreciated!

1

0

1

0

polyproto federation protocol @polyproto@amazonawaws.com

2mo

You should check out our new and definitely much improved start page: polyproto.org

(try Ctrl+Shift+R if you still see the old page)

The start page has had the content on it thoroughly overhauled to be heaps more informative about the project, its goals, the protocols' features and its use cases. Do let us know what you think!

1

3

8

19

1