Regarding his other concern, I would've loved to make atproto a localfirst protocol -- that's the field the atproto team came from -- but we had to pick & choose where to spend our complexity budget. I wouldn't say it's a nonstarter for the ecosystem; you can use something like iroh in conjuction with atproto to share identities -- dial people at their dids or domain names -- and then commit state to the atproto repo once it's ready to leave your local sync mesh. Maybe that sort of thing makes its way into future versions of the protocol. But, engineering often involves trades, and for the v1 that was one of the trades we had to make.
and that's just amount of discussion. but what about engagement by the people working on it? nothing like this, not by high level people, discussing in open, talking about protocols. you don't see permissioned data blog serieses coming out about the direction. you don't see the same blogsphere posts. you don't see the CTO coming to chat about it.
a huge amount of this is just that Bluesky people really work hard to do the right thing, are humble and trying hard to build good protocols, good network design, trying to build the most distributable most easy to get the content network out there that works the best. i think also though, the ability of the systems / protocols here to be expressed lends itself to being discussable, has good primitives, that make it fruitful and interesting for things like Permissioned Data, or things like the sync 1.1 protocol, to be generally understandable, good primitives, that are discussable.
luke's points about local first are really good. this is hard challenge for "Authenticated Transfer Protocol", at protocol, which prioritized a sense of identity and data coupling, that is harder to do in local context, that is harder to distribute without the online verification. great concern, great area to focus on. i look forward to more people experimenting with interesting PDS architectures & seeing what if anything might possibly relax to accommodate.
Speaking as the CTO at Element (and proj lead for Matrix), i feel like i've spent a bit too much time coming to chat about Matrix on HN over the years ;)
That said, I agree that Bluesky is doing well in terms of breaking through into mainstream awareness - much more so than Matrix (although obviously big-world-social-media is something of a different beast to distributed-instant-messaging).
The reason Matrix hasn't done better here is primarily economic: we spent too much time and money building out Matrix for everyone in the early days... and not enough time focusing on building either consumer (as Bluesky has) or enterprise or government specialised products. We then got traction at Element on the government side of things (https://element.io/en/matrix-in-europe etc) as it turns out governments love their digital sovereign communications - which in turn meant that in order to get sustainable and survive we had to focus hard on building stuff for that market. Now, ideally the stuff which works for Govt would work for mainstream too (after all, we're generally competing with Signal and WhatsApp, which are of course mainstream apps) - but in practice it has been hard to get that balance right. You can see my <del>TED Talk</del> FOSDEM 2025 talk about the road to mainstream matrix here: https://www.youtube.com/watch?v=lkCKhP1jxdk
Meanwhile, the plan on Matrix is to get to profitability via Govtech and then invest the money back into improving Element (and Matrix) so it also works well for mainstream usage - so hopefully we'll get back on the radar then. It's a long haul though. Meanwhile, kudos to Bluesky for getting to focus on the mainstream use case; I'm jealous, and I hope they find a good sustainability model!
Imagine someone starts startup A on-top of the ATProto. They raise some money, get some users, some people love it, but ultimately they die. If the data was private to that service, that data dies with the startup. But if the data is all public future startup B can read that old data and do something with it. As a user that's brings me a ton of utility and comfort trying out new services.
If you're trying to built a local-first, mostly private service I just don't think the ATProto is the right tool for the job.
I agree! I think the "permissioned data" working group is aiming to solve the middle ground – where you want to broadcast something "publicly" but to a specific audience instead of the whole world (e.g. invite-only event, membership club). It's "private" in the sense it's not open to all but not in the sense that only you can see the data.
Nick Gerakines has been sharing some good examples of what you could build using permissioned data:
- Private Events: https://ngerakines.leaflet.pub/3mqxalpvn4k2e
- Bookmarks: https://ngerakines.leaflet.pub/3mqu653us3k2p
- Community content: https://ngerakines.leaflet.pub/3mqzsstcsok25
[1] https://github.com/bluesky-social/proposals/blob/main/0016-p...
Yeah, this is the reason why I don't understand why they succumbed to the idea ATProto must handle private and has started on work trying to figure it out (https://atproto.wiki/en/working-groups/private-data). Instead, focus on just really great public data archiving and displaying, at scale.
The answer is very simple, the people demand it.
Technically, or if you squint the right way, it is a new protocol (atp://) that shares some parts with the public side. Notably the relay is out (for now?) and the data lives in a different sqlite table (iirc/aiui).
I might turn this around to say that ATProto was the square peg trying to fit into the round hole (the vast majority of people want privacy)
The privacy stuff is covered by Signal etc. anyway, and you could layer that on top if you wanted to, but in a P2P setup privacy is always going to be a bit disappointing as so much metadata is inevitably exposed unless you do crazy stuff like flood fill the network with every message without regard to routing.
they only decided to expand into other domains after the elon takeover made people move away from twitter and bluesky got popular way faster than expected.
As an extension of that I've been building a small language to build games (with a nice time traveling debugger and automatic replays) inspired by Elm. Go and Chess are both built on top of this and you could fork them and modify the rules. Want to code a new Chess variant? Go ahead! Want to code a whole new game you want to try? Go ahead!
What I'm very excited with ATProto is that because all games are broadcast on it and each shares a core system of turn-based replays (and review system with branching) software can be built on top to do AI analysis, or a replay view. The idea that my application can be extended without me adding an API is very exciting and very much in the direction I want to take the system (community is the core tenet).
There is a subgroup in the Atmo working on games, have you found them yet?
So far they are mostly trusted authority rather than peer systems. But, since each player owns their own PDS state, one could perhaps just hash the previous state they are working off of. That can at least detect if a game is consistent/agreed to by both sides, allow one player to detect the other's tampering.
> 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.
You can find the discussions here: https://discourse.atmosphere.community/tag/private-data/2
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.
> 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.
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.
Stepping back for a momement, it's clear that permissioned data is driven by real world use-cases (Bluesky needs DMs, Tangled needs private repos, etc). However, I think the synergies with the existing atproto needs to be pretty significant to warrant developing yet another encrypted space spec. We already have various double ratchet protocols, Matrix is having a huge boom. From the point of view of an app developer, does everything need to be handled by atproto, or could we accept that atproto is just for the public stuff?
There's no issue in using ATProto to "link" an external service, like Tangled does with it's "knots" which host the git data.
All of the social stuff (issues, PRs, comments and so on) is on ATProto, and on ATProto you also have a "repository" object, linking to a "knot" object containing the address of the knot.
What's stopping an E2EE DM implementation to use ATProto to point to something like an "accepted matrix server" for all parties, and each having a "matrix identity" ATProto record ? (I don't know about Matrix so idk if this is exactly possible but you get the idea)
That is only true if you completely ignore social context and relationships between the subject (reviewer), the object (the reviewed) and the audience. The author does mention being autistic, so perhaps he doesn't see it this way, but to me it would be very important to have a system where anything I record for a narrow audience doesn't become available to the public.
The thing though is that I've been so conditioned to not trust digital platforms that I never publish anything online unless I am 100% comfortable with having that information available to the public. So, in effect, I'd never put anything on my PDS unless it was meant for public consumption, rendering all this "permissioned data" effectively pointless.
That's precisely what the author is arguing.
Probably one of the most fun projects I’ve ever worked on, and I largely attribute that to the protocol.
I’m particularly interested in the permissioned data spec, but don’t want it to hold me back, so some functionality is on ice, and I went live without it.
It never catches on with application developers because it requires you to already worship the protocol and build around it.