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.
6 Likes
I feel obligated to mention that this means you can mix private and permissioned data with what you send to ATProto
Right! The data in the PDS is entirely private by default. If you create AT records those are public. But everything else is private, and can have fine-grained permissions: who can view, who can append, who can edit.
1 Like
Very cool, thanks for sharing!
Impressive! What are your plans / goals / hopes with the brolly.id POC ?
I love this, thank you for sharing!
Great question!
The most pressing goal is to iron out all the kinks and wrinkles so it just works. A big part of that is working through the machine code and making it more human.
After that, the plan is to start spinning up instances of Brolly for communities - my preschool coop for one. The instant, private mastodon server will immediately replace our bad app, and give us more tools for communicating with each other. The solid stuff can be built on for other things we need, like budgeting and book keeping.
The larger goal is to foster greater harmony and cooperation between ATproto dev work and Solid dev work. Let AT be public, let Solid be private. Different use cases that go well together.
This is a project of Stucco Software, my non-profit org dedicated to open source community work, so I’m hoping to maybe even get a little funding to give this more time and attention.
5 Likes