This author speaks to me!

> it should just be called “private data”

> the resulting design looks very hard to build on

> Private and public data are basically identical. ... The permission is world-read

Way back before Bluesky decided on their own what permissioned data would look like, when the Atmosphere Private Data WG still thought they had a say in the design, I gave a talk on a ReBAC/Zanzibar style system that aligns with what I think the author is looking for.

https://www.youtube.com/watch?v=oYKA85oZc8U&t=3730s

I suppose we could still build on and run a fork like mine if enough people wanted a more robust IAM system. There are some fundamental issues that I am not sure are resolvable without building them into the protocol core from the start. I have personally given up because of the leadership and am waiting/pondering the next protocol. Another design constraint I'd like to see is incentivizing apps to be federated and installable at the PDS as well as incentivizing small social over public square modalities.

https://github.com/verdverm/atproto

▲

Karrot_Kream 39 minutes ago | parent | next [-]

I've followed the ATProto space (and seen you around the space) a bunch over time, and honestly for the private data portion of it, I'm quite bearish on the idea of an ATProto shaped thing winning here.

I do think "small social" is winning in almost every definition of the word. There's Discords for everything, each non-technical person I know is in 10s of group chats, folks on Instagram or Twitter seek their "communities" on these apps. HN and Reddit are somewhat platforms of yesterday, valuable only for the sheer volume of conversation, not really of any particular use, often used to doomscroll on the toilet or in the supermarket line.

But ultimately I don't see why you need a protocol for small social. ActivityPub could do it fine (even though it's largely used as a glorified JSON HTTP API), Matrix or IRCv3 can do it fine, email works and is being used, heck you could even roll a bespoke HTTP or Websocket RPC (de-facto ActivityPub) to fix the problem anyway. ATProto is useful because it's a protocol for socializing In the Large. I think user experience matters for this much more than a protocol. I know Bluesky users want it, but I'm not convinced that an ATProto derived solution is the answer.

	▲	verdverm 33 minutes ago \| parent [-]
		strong agreement here > Ultimately I don't see why you need a protocol for small social. For me, it is less about the technical reasons and more about the movement away from corporate control to community ownership. The desire among people is there because the growing shared belief that what we have today is not healthy for our self or society. One thing Bluesky nailed was simplicity for the average user. UX is super important. That was despite the protocol which almost all users, and non-users who've heard of Bluesky, have no idea about. However, it was the protocol movement that formed the foundation for their success. That being said, you can only realize the vision (of the people taking back social media from the capitalists and enabling real competition in social media) with a well designed protocol. ATProto gave us a lot towards this. So I'm now contradicting(?) my first sentence in this comment.

▲

citelao 3 hours ago | parent | prev | next [-]

My statement is not super constructive, but yes, I also really liked this article. Local-first, privacy, even the example of managing personal restaurant reviews.

I don't have enough meaningful thoughts here to contribute, but you & OP: I hope we can build a federated protocol for sharing stuff again.

▲

verdverm 4 hours ago | parent | prev [-]

btw, for historical context, the reason it is called "permissioned" instead of "private" is because there were sufficient people in the atmo that were very opinionated the E2EE is the only true private. It became an exercise in bikeshedding every time "private data" came up.

You can find the discussions here: https://discourse.atmosphere.community/tag/private-data/2