Brolly – Protocol Agnostic, Self Hosted, Community PDS Provider

Self Host a Solid Pod
1

This has been bouncing around my head for a while, and I finally have a working proof of concept: https://www.youtube.com/watch?v=AZD1h9JUIuU

When a user create their account, they get their own URL (<user>.brolly.id) and their own personal data store (oxigraph). They also get a WebID (<user>.brolly.id/profile/card#me) and a DID:Web (`<user>.brolly.id`) and a DID:PLC (randomly generated). We assign keys to the user for signing.

Brolly.id then exposes several protocol interaction surfaces: it can do Solid with access control lists. It can do ATProto with signed CBORs and stuff. It has endpoints for Mastodon clients. It works pretty good!

All the data that gets created with all these apps goes into the users graph on Oxigraph. Its just there data, so you don’t need to share a big graph with other folks. This also makes it trivially easy to export all your data: just download the entire graph.

So: this is one ID and one PDS that works for both protocols. Applications can interop the data however they please, and it all belongs to the user.

Pretty neat.

1 Like
2

Great idea, your YouTube video explains it well!

Only recently I learned about https://jss.live/ which is a project that also solves the same problem, maybe you could join forces to build this together.

Judging by the visualization on the landing page it seems to be missing AT Proto.

3

Hey, I finally got around watching the video and the idea is pretty cool :).

I guess the main challenge here is to make applications using different protocols work together, though that’s probably not possible at the moment. But, if this works well for all the protocols involved, I think it’s pretty cool already!

However, having seen ActivityPods, I wonder if that implementation using a graph database is conforming with the Solid Protocol… Other than login in, have you tried using existing Solid Applications? I did try to use ActivityPods a while ago with one of my apps, and I ran into a lot of problems trying to make it work. I think one of the main reasons why that happens is precisely that they use a graph database, instead of a document-centric store like the Solid Protocol expects. I’m sure there’s also some issues with making ActivityPub work together with Solid, but I don’t think that should be the main problem.

In case you’re interested, I documented my issues with ActivityPods a while ago, and there’s also been a couple of threads in this forum talking about bridging the two protocols (not sure I’ve seen anyone doing it with ATProto, though!): Integrating ActivityPub within Solid specs