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
@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.
@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.
@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! :)
@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.
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.
what does this have to do with federation over polyproto? does it all use https under the hood? then you're still importing the issue of CA centralization from that,,, tho there are other ways of securely setting up traffic encryption that dont result in centralization, like DANE. hopefully implementations of polyproto can support and use that by default
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.
polyproto federation protocol
@polyproto@amazonawaws.com
