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.
polyproto federation protocol
@polyproto@amazonawaws.com
