Having worked on it for a while, I now disagree. The permission primitives should be baked in from the start rather than the bolted on after spaces because people continued to ask for these things and eventually Bluesky came around. There are many use cases for permissioned data and experiences that have to be built outside of the protocol, leading to fragmentation and loss of interoperability.
replyIgnoring the history, does spaces solves this problem or are permissions going to remain an issue? I was thinking of doing a project that is going to require a solid permissions system and was thinking of using ATProto.
replySpaces left a number of core authorization building blocks out of the protocol. Those will need to be implemented in "user space" and I expect a number of different approaches will be attempted. I also expect this to become fragmented.
replyI shared my vision for what it could have been in the first ATProto Private Data WG: https://www.youtube.com/watch?v=oYKA85oZc8U&t=3812s (basically Zanzibar, UCANN is also interesting) I have ideas for a new protocol that would be permissioned, more federated, but still draw on the good parts of atproto. It's geared towards small social (think discord server / facebook groups) than big social (most common apps we think of - with reposts, quotes, blocks - features I have sworn off).
The Bluesky team didn't join the conversation until pretty late and then picked their own proposal (blog post series, was not formal at that point).
Here we go again…
reply