Luke's feedback on the permissioned data proposal is pretty interesting. The current proposal has a kind of locational element to permissions, where a record's URI reflects the access control, and I can understand why that would be jarring. I'm talking with the team about whether we think that's something that could change, and what a change like that would cost. We're still in the collecting feedback phase so it's good to hear how it hits people.
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.
a meta-note that i think deserves attention: we never ever seen such a level of engagement around a social media protocol as this. count the number of mastodon protocol discussions that have happened, or dispora, or activitypub. they exist as background. matrix maybe comes close if you look at raw count anywhere, but i'd say has no-where near the visibility, doesn't surface/emerge into the public. atproto is succeeding at being a discussed protocol. at being a socialized social media protocol.
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!
Matrix's biggest blocker is that it doesn't work very well. You try it, you get a worse experience than Discord, you switch back to Discord. I hope the Matrix project figures this out one day.
What do you hope they'll figure out by ambiguous feedback like this? What exactly is worse? Is it possible it's just different, and that translates to "worse" although maybe it's actually on purpose? What specifically is it that doesn't work well for you?
Acute awareness of and attention to the overarching problem. Almost all of the individual issues are likely already known, but too often hand-waved away as minor inconveniences. This is common in the FOSS world and IMO the #1 hurdle for wider adoption.
That said, it would not be fair to not acknowledge that the Matrix 2.0 efforts have been real and massive improvements. Refocusing like this is a massive organizational effort and takes a non-trivial amount of resources. I’d like to take the opportunity to really commend that.
(That said, I have paused my close following of the project due to my frustration with the state of things and rate of progress, but I totally understand some of the reasons for it. It is only becoming more and more important to have an open standard for instant messaging, but I wouldn’t be surprised if at some point something new appeared and immediately captured all attention)
I mean... just use it for a while and see? It's death by a thousand paper cuts. There's no single big problem. It does get messages from A to B.
For instance when you click on a new room and the messages are stuck in a loading state forever. Or when you sign out and sign back in and need to reset decryption keys and can't read message you received before signing in
Or when someone gives you a link to a Space and you click on it and get a loading spinner for a while and then an obscure error. What is a Space anyway? Why can't I organise my own channels into groups but only the admin of a Space can do that? It isn't intuitive. Obviously it makes sense to have groups of channels like Discord guilds, in some way, but it's currently confusing.
When I know the address of a channel I can never find the right textbox to put this in. And when it is the right one, it doesn't give feedback that it's the right one. IIRC it's the same box that searches channels on the current home server, but if you put an address there it shows 0 results, but if you click on continue then it joins the channel anyway. But there's another box somewhere in the app that also does this search thing but can't join a channel address. I think. And neither of them are in obvious places. In Discord, at the end of your list of guilds, is a big + button, which opens a text box asking for the address of a guild.
I really think you should just sit down with some inexperienced or first-time users and watch them do some basic tasks while thinking aloud. This used to be the bread and butter of the UX industry, which has atrophied.
Well, I really appreciate the kind words. I think the atproto dev community in its entirety is full of good people who care quite a bit, and we all know something like this is a big project that we have to earn, so we're doing everything we can to make it happen. It's hard work but it's rewarding, and it's certainly nice to hear something like this. I'll be sure to pass it along.
Mastodon Protocol is a protocol only used between copies of mastodon and its clones. If ATProto was just the Bluesky protocol it would have a similar amount of attention, but it's not, it's trying to be the everything protocol.
Reading articles like this one, I do think people are trying to put a square peg (their applications) through a round hole (ATProto). The ATProto was designed around all data being public. You write public data to a user's PDS and then any application can read that public data and do something with it. If all data was private (encrypted?) by default then that would defeat half of all of ATProto's goals.
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.
> 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:
atproto permissioned data [1] will solve the dilemma you're describing. Ultimately all the data is in the same place (your PDS) and you can always read and write any data there. If startup A goes away, startup B can read that old data and do something useful with it.
> If all data was private (encrypted?) by default then that would defeat half of all of ATProto's goals.
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.
> I don't understand why they succumbed to the idea ATProto must handle private
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).
If the primary user concern is "all data is public", then the utility of ATProto is extremely narrow and will likely lose to something with a different philosophy.
The main need is strong authentication, certainly for enabling P2P microblogging type apps.
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.
The definition of privacy is a spectrum, with what you describe at the most information secops end. Most people are not so worried about metadata leakage (they don't even know what it is, similar to atproto for most bluesky users).
What most want is to not be reposted and ratio'd by terminally online people like Blue MAGA did on Bluesky. They also just want to post to their followers or friends, not the world.
So in your concept if you are A and have two folowers B and C that don't know each other but both comment on your post what should happen? Should you see both but they not see each other?
This is the tip of the iceberg of boring questions that fall out, all of which have annoying user experience implications which are intimately tied to the underlying infrastructure and cryptosystems, effectively setting them in stone. There are reasons these systems fall into the camps of either federated with strong ID or really very centralized.
A core principle of ATProto is that the cost of switching is low, thereby facilitating real competition on social media. So the answer is two parts
1. App views decide permission parameters for their modality and frame the user experience
2. Users use these permission parameters to dial in their personal or community experience
I believe there is more middle ground than you leave space for. See systems like ReBAC/Zanzibar, Anonymous Credentials, and UCANN. Google Workspace is a good model that many many people understand and are happy with (IAM wise).
With a design like this, you can build an enforceable world-read, mutual-following-write version of Bluesky, something users ask for every time Bluesky announces any new feature.
> 1. App views decide permission parameters for their modality and frame the user experience
Yeah, so this is the problem. A system flexible enough for that will be some combination of centralized, hilariously over complicated, massively inefficient, and full of odd unexpected behaviors.
the first version of bluesky was an internal effort to make twitter decentralized. atproto comes from twitter/ig type social media where almost all content is public so not supporting private data for v1 was an obvious choice.
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.
> obvious choice ... decided to expand into other domains after
I'm not sure what the obvious answer is. I imagine the user insights at Twitter would be very informative, but was never on the inside to know. It's also worth noting that many members of the team joined on after ATProto was broken out from Twitter. Only they can provide an accurate recount of the information they had at hand and the decision making process around it.
I've been building a board game community on ATProto. The idea revolves in trying to build the feeling of local clubs but online, instead of "PLAY NOW" being on the landing page (although you can play now if you want) it's organized around clubs. I also wanted to move away from one game oriented community. I play Go and Chess and I would love clubs to be for mixed games. You can create leagues, or tournaments, etc.
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).
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.
This would imply the game state is stored in a centralized app view, at which point the general atproto ethos that you can move your data if an app becomes bad is up to the app.
I believe the viable solution in a rich permission system is one where the user cannot directly modify a record (as defined by a permission schema for a specific app/type) and can only call methods.
> 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.
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.
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.
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.
> 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.
Agree that you need a well designed protocol, but I think for small social, we're drowning in good protocols. A lot of the issues with ActivityPub, for example, come about because of socializing In the Large. Once you're just hanging out in a community it doesn't matter if someone trips and bans you or deletes all your messages; this is par-for-the-course for small social drama. What makes AP so fraught for large scale social is that small social drama affects the network as a whole. AP is just one example. IRC, XMPP, Matrix, mailing lists, they've all been working for years even decades.
I think you need someone to build out a good UX more than anything else. They who builds the UX will win the spoils IMO. There's plenty of protocol prior art to bolt on underneath the fact.
If I do decide to work on a social protocol, I will be keen to not build on existing ones to avoid the prior drama and bikeshedding. (re: the AP vs AT debate pattern that has grown this year)
Will definitely "distill" several ideas from them tho! I maintain a space on my chalkboard for it.
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.
Disclaimer: I have not looked carefully at the permissioned data proposal, but I know atproto reasonably well.
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?
I would prefer this to be more geared towards things like Private social profiles or shared with specific circles than DMs, which are already served by E2EE.
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)
> A restaurant review is a restaurant review whether I am the only one who ever sees it or it gets shouted to the rooftops. A book review I share with my book club is identical to a book review I share with my wife or publish on my web site.
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.
I love tangled, but there are certain repos I don't want public. So with all ATProto data being public you can never have a private repo which is disappointing.
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.
I doubt it, since you'd own your data even less as a user than with ATProto. (stuck to a server without the ability to fully move backlinks, data, and identity to another. at least all those things stay the same when you move between PDSes!)
What's even the point of publishing anything online any more if you don't hope to become an influencer? The nature of the game has changed, and now does everything possible to discourage it.
You could say the same about publishing offline. We can always do it simply because we enjoy it and one or two others might find some enjoyment or utility in it as well. It doesn't have to matter, it doesn't have to influence anyone. It's fine as a relatively solitary practice like any other.
ATProto and its advocates increasingly sound like all the crypto-based decentralized platforms that failed. The difference is that crypto people actually had reasons to run nodes, they got paid to, while ATProto expects enthusiasts to do so for the love of the game or act like bluesky and have 99% of the "decentralized" platform on a centralized node.
It never catches on with application developers because it requires you to already worship the protocol and build around it.
the cultiness is why I left crypto and atproto, it plagues many great ideas by creating in and out groups around opinions on the right way to do things
Really strange, considering there’s more debate, disagreement, and lack of conformity in atproto than I’ve ever seen in crypto.
I think you might mean, “people who disagree with me intensely because they believe strongly in the way they view things.”
Atproto is very, very far from a cult. It is a bunch of poasters, though, and nobody should be surprised when a social protocol has a bunch of, well, really social people in its leadership, and you shouldn’t expect them to act like senior leadership of Intel, IBM, or Nvidia.
The fact Paul makes jokes on a social forum at or with people is a reminder that he’s a human. He’s smart, passionate, nerdy, talented, and sometimes extremely annoying, much like everyone else here, and I’m GLAD the leadership of the company and the protocol are as engaged with the community as they are.
It’s a social protocol, for god’s sake. Remember when everyone would complain that the people who ran Twitter would never use it? I do, and just because Elon is down the K-hole and a posting menace doesn’t mean the criticism was incorrect.
I hope you will agree that Paul's personal attacks towards me are unacceptable and unbecoming for the CTO of Bluesky. This is not the first time, I hope it is the last.
(see his peer comment flagged by the community here)
Wow. Irrespective of what the other commenter did to you outside of this thread (assuming you two have a history) your comments (this and others) here feel indeed like trolling and almost egging.
Are you the CTO? If you are then this just feels like a red flag and kind of tells me as a user to look at this protocol/ecosystem (which truly is BSKY at the moment) with much caution.
I'm not sure why you always feel the need to attempt to troll me personally on HN like this. Last time you did, HN flagged your reply. We do not have to agree, but we can be civil. For HN reader context, Paul (Bsky CTO) and I have discussed the protocol and permission system IRL and have different visions.
My sense it that microblogging platforms like X/Bluesky condition people to discourse in ways online they would not in the physical world, though I have encountered online behaviors manifesting in the real world in recent years. ymmv, I have left them all completely and have a much better mental state since.
Apologies if "worship" came across as calling you a cult, but it doesn't seem that you took what I said too seriously either. Good luck on ATProto, certainly don't want to deal with this kind of replies from you or Dan every time criticism or concerns come up, maybe once the protocol leaves BlueSky, but let me guess, it's planned for some point in the far future like every other concern?
Seriously, the entire separation of Bluesky from ATProto not happening is my main reason for not trusting it at all. You can't have a protocol owned by a for-profit entity and seriously call it "open"
I think a more potent example is who controls the source for the spec and official implementations. This is a notable lack of community governance around this part. In this sense, Bluesky can and does change things at will. I have experienced breaking changes from their devs changing how things work and merging their own PRs in a matter of minutes, while not using versions. (indigo)
When it comes to private/permissioned data, Bluesky people have decided the shape it will take while not participating in the conversation until they shared their already decided upon design. They are letting the community give feedback, but the community never was able to participate in the design phase.
Luke's feedback on the permissioned data proposal is pretty interesting. The current proposal has a kind of locational element to permissions, where a record's URI reflects the access control, and I can understand why that would be jarring. I'm talking with the team about whether we think that's something that could change, and what a change like that would cost. We're still in the collecting feedback phase so it's good to hear how it hits people.
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.
a meta-note that i think deserves attention: we never ever seen such a level of engagement around a social media protocol as this. count the number of mastodon protocol discussions that have happened, or dispora, or activitypub. they exist as background. matrix maybe comes close if you look at raw count anywhere, but i'd say has no-where near the visibility, doesn't surface/emerge into the public. atproto is succeeding at being a discussed protocol. at being a socialized social media protocol.
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.
> you don't see the CTO coming to chat about it.
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!
Matrix's biggest blocker is that it doesn't work very well. You try it, you get a worse experience than Discord, you switch back to Discord. I hope the Matrix project figures this out one day.
What do you hope they'll figure out by ambiguous feedback like this? What exactly is worse? Is it possible it's just different, and that translates to "worse" although maybe it's actually on purpose? What specifically is it that doesn't work well for you?
As an example, deuxfleurs.fr, a french non-profit host, mentions issues with notifications, message history, and message searching as reasons to leave matrix in their latest newsletter: https://blog.deuxfleurs.fr/2026-bilan-de-la-rencontre-ete-20...
Acute awareness of and attention to the overarching problem. Almost all of the individual issues are likely already known, but too often hand-waved away as minor inconveniences. This is common in the FOSS world and IMO the #1 hurdle for wider adoption.
That said, it would not be fair to not acknowledge that the Matrix 2.0 efforts have been real and massive improvements. Refocusing like this is a massive organizational effort and takes a non-trivial amount of resources. I’d like to take the opportunity to really commend that.
(That said, I have paused my close following of the project due to my frustration with the state of things and rate of progress, but I totally understand some of the reasons for it. It is only becoming more and more important to have an open standard for instant messaging, but I wouldn’t be surprised if at some point something new appeared and immediately captured all attention)
I mean... just use it for a while and see? It's death by a thousand paper cuts. There's no single big problem. It does get messages from A to B.
For instance when you click on a new room and the messages are stuck in a loading state forever. Or when you sign out and sign back in and need to reset decryption keys and can't read message you received before signing in
Or when someone gives you a link to a Space and you click on it and get a loading spinner for a while and then an obscure error. What is a Space anyway? Why can't I organise my own channels into groups but only the admin of a Space can do that? It isn't intuitive. Obviously it makes sense to have groups of channels like Discord guilds, in some way, but it's currently confusing.
When I know the address of a channel I can never find the right textbox to put this in. And when it is the right one, it doesn't give feedback that it's the right one. IIRC it's the same box that searches channels on the current home server, but if you put an address there it shows 0 results, but if you click on continue then it joins the channel anyway. But there's another box somewhere in the app that also does this search thing but can't join a channel address. I think. And neither of them are in obvious places. In Discord, at the end of your list of guilds, is a big + button, which opens a text box asking for the address of a guild.
I really think you should just sit down with some inexperienced or first-time users and watch them do some basic tasks while thinking aloud. This used to be the bread and butter of the UX industry, which has atrophied.
Well, I really appreciate the kind words. I think the atproto dev community in its entirety is full of good people who care quite a bit, and we all know something like this is a big project that we have to earn, so we're doing everything we can to make it happen. It's hard work but it's rewarding, and it's certainly nice to hear something like this. I'll be sure to pass it along.
Mastodon Protocol is a protocol only used between copies of mastodon and its clones. If ATProto was just the Bluesky protocol it would have a similar amount of attention, but it's not, it's trying to be the everything protocol.
Reading articles like this one, I do think people are trying to put a square peg (their applications) through a round hole (ATProto). The ATProto was designed around all data being public. You write public data to a user's PDS and then any application can read that public data and do something with it. If all data was private (encrypted?) by default then that would defeat half of all of ATProto's goals.
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.
> 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
- Forums: https://ngerakines.leaflet.pub/3mr3uqjjaxs2d
- Polls: https://ngerakines.leaflet.pub/3mr3waxevjc24
atproto permissioned data [1] will solve the dilemma you're describing. Ultimately all the data is in the same place (your PDS) and you can always read and write any data there. If startup A goes away, startup B can read that old data and do something useful with it.
[1] https://github.com/bluesky-social/proposals/blob/main/0016-p...
> If all data was private (encrypted?) by default then that would defeat half of all of ATProto's goals.
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.
> I don't understand why they succumbed to the idea ATProto must handle private
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).
Yeah, running a social website where you can't write anything in private to just your friends is not very based.
Like this one?
Are you saying you are here to make friends on this thing?
HN is an exception to this rule imo, and remains our diamond in the rough
If the primary user concern is "all data is public", then the utility of ATProto is extremely narrow and will likely lose to something with a different philosophy.
That is about to change very, very soon though: https://dholms.leaflet.pub
Or you just use a different protocol for private stuff. Square peg, square hole. Round peg, round hole.
> The ATProto was designed around all data being public.
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 main need is strong authentication, certainly for enabling P2P microblogging type apps.
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.
The definition of privacy is a spectrum, with what you describe at the most information secops end. Most people are not so worried about metadata leakage (they don't even know what it is, similar to atproto for most bluesky users).
What most want is to not be reposted and ratio'd by terminally online people like Blue MAGA did on Bluesky. They also just want to post to their followers or friends, not the world.
So in your concept if you are A and have two folowers B and C that don't know each other but both comment on your post what should happen? Should you see both but they not see each other?
This is the tip of the iceberg of boring questions that fall out, all of which have annoying user experience implications which are intimately tied to the underlying infrastructure and cryptosystems, effectively setting them in stone. There are reasons these systems fall into the camps of either federated with strong ID or really very centralized.
> what should happen?
A core principle of ATProto is that the cost of switching is low, thereby facilitating real competition on social media. So the answer is two parts
1. App views decide permission parameters for their modality and frame the user experience
2. Users use these permission parameters to dial in their personal or community experience
I believe there is more middle ground than you leave space for. See systems like ReBAC/Zanzibar, Anonymous Credentials, and UCANN. Google Workspace is a good model that many many people understand and are happy with (IAM wise).
With a design like this, you can build an enforceable world-read, mutual-following-write version of Bluesky, something users ask for every time Bluesky announces any new feature.
> 1. App views decide permission parameters for their modality and frame the user experience
Yeah, so this is the problem. A system flexible enough for that will be some combination of centralized, hilariously over complicated, massively inefficient, and full of odd unexpected behaviors.
Perhaps if you are after public square social media. If you are after small social media, the usage patterns and tradeoffs look different.
Modded Minecraft (smp) servers are interesting prior art for me.
the first version of bluesky was an internal effort to make twitter decentralized. atproto comes from twitter/ig type social media where almost all content is public so not supporting private data for v1 was an obvious choice.
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.
> obvious choice ... decided to expand into other domains after
I'm not sure what the obvious answer is. I imagine the user insights at Twitter would be very informative, but was never on the inside to know. It's also worth noting that many members of the team joined on after ATProto was broken out from Twitter. Only they can provide an accurate recount of the information they had at hand and the decision making process around it.
I've been building a board game community on ATProto. The idea revolves in trying to build the feeling of local clubs but online, instead of "PLAY NOW" being on the landing page (although you can play now if you want) it's organized around clubs. I also wanted to move away from one game oriented community. I play Go and Chess and I would love clubs to be for mixed games. You can create leagues, or tournaments, etc.
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).
How do you prevent a player from manipulating game state outside of the app view?
There is a subgroup in the Atmo working on games, have you found them yet?
There's a variety of different attestation strategies folks have cooked up! For example this crate has some tools, https://tangled.org/ngerakines.me/atproto-crates/tree/main/c...
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.
I have a referee server handling that. I haven't! I don't even know what Atmo is, tbh.
"Atmosphere" (atmo) is the self-given name for the broader developer community around atprotocol
https://discourse.atmosphere.community/ has game specific discussions to help you find the people to connect with.
Publish the moves, not the game state?
This would imply the game state is stored in a centralized app view, at which point the general atproto ethos that you can move your data if an app becomes bad is up to the app.
I believe the viable solution in a rich permission system is one where the user cannot directly modify a record (as defined by a permission schema for a specific app/type) and can only call methods.
You can easily reproduce a chess board from the moves if you can implement chess.
Most games are not perfect information games. How would you implement poker?
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
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
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.
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.
Agree that you need a well designed protocol, but I think for small social, we're drowning in good protocols. A lot of the issues with ActivityPub, for example, come about because of socializing In the Large. Once you're just hanging out in a community it doesn't matter if someone trips and bans you or deletes all your messages; this is par-for-the-course for small social drama. What makes AP so fraught for large scale social is that small social drama affects the network as a whole. AP is just one example. IRC, XMPP, Matrix, mailing lists, they've all been working for years even decades.
I think you need someone to build out a good UX more than anything else. They who builds the UX will win the spoils IMO. There's plenty of protocol prior art to bolt on underneath the fact.
If I do decide to work on a social protocol, I will be keen to not build on existing ones to avoid the prior drama and bikeshedding. (re: the AP vs AT debate pattern that has grown this year)
Will definitely "distill" several ideas from them tho! I maintain a space on my chalkboard for it.
https://xkcd.com/927
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.
Disclaimer: I have not looked carefully at the permissioned data proposal, but I know atproto reasonably well.
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?
I would prefer this to be more geared towards things like Private social profiles or shared with specific circles than DMs, which are already served by E2EE.
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)
> A restaurant review is a restaurant review whether I am the only one who ever sees it or it gets shouted to the rooftops. A book review I share with my book club is identical to a book review I share with my wife or publish on my web site.
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.
> it would be very important to have a system where anything I record for a narrow audience doesn't become available to the public
That's precisely what the author is arguing.
Yeah, sorry, you probably saw my comment before I updated with the last paragraph.
I switched from codeberg to tangled, and the transition couldn't have been smoother. Being on the ATmosphere really helps with peace of mind.
I love tangled, but there are certain repos I don't want public. So with all ATProto data being public you can never have a private repo which is disappointing.
That’s not going to be true for much longer.
Speaking about Tangled, is there an article somewhere about how they use ATProto ? Like what are in the records and all
You can check yourself using https://pds.ls, just open any handle there that has Tangled repos
It's very interesting, thank you very much
https://pdsls.dev/at://did:plc:wshs7t2adsemcrrd4snkeqli/sh.t...
I created a web-of-trust forum built on ATProto. https://caterpilla.rs
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.
The intention is good. I like the reviews idea. Since the author has hit the limitations of ATProto, could ActivityPub be an answer?
I doubt it, since you'd own your data even less as a user than with ATProto. (stuck to a server without the ability to fully move backlinks, data, and identity to another. at least all those things stay the same when you move between PDSes!)
Nomadic Identity is an ongoing FEP (Fediverse Enhancement Proposal)
I really think ATProto is decentralized "the right way" for the general public. So I would very much like it to support this kind of thing.
[dead]
What's even the point of publishing anything online any more if you don't hope to become an influencer? The nature of the game has changed, and now does everything possible to discourage it.
You could say the same about publishing offline. We can always do it simply because we enjoy it and one or two others might find some enjoyment or utility in it as well. It doesn't have to matter, it doesn't have to influence anyone. It's fine as a relatively solitary practice like any other.
I've moved off social media to zine making and this couldn't resound more with me these days!
This is the least human take I've seen on this site so far, and I don't even think you're a bot.
ATProto and its advocates increasingly sound like all the crypto-based decentralized platforms that failed. The difference is that crypto people actually had reasons to run nodes, they got paid to, while ATProto expects enthusiasts to do so for the love of the game or act like bluesky and have 99% of the "decentralized" platform on a centralized node.
It never catches on with application developers because it requires you to already worship the protocol and build around it.
I came out to have a good time and I’m honestly feeling so attacked right now
I don't think anyone ever got paid to "run nodes".
I think what they're talking about is like how bitcoin miners get paid in bitcoin for mining
We don't even get paid to be in this cult, that's how organic it is
You do get paid, you're the CTO of Bluesky, are you not?
he's just making a cult joke. it's okay to be silly sometimes.
the cultiness is why I left crypto and atproto, it plagues many great ideas by creating in and out groups around opinions on the right way to do things
Really strange, considering there’s more debate, disagreement, and lack of conformity in atproto than I’ve ever seen in crypto.
I think you might mean, “people who disagree with me intensely because they believe strongly in the way they view things.”
Atproto is very, very far from a cult. It is a bunch of poasters, though, and nobody should be surprised when a social protocol has a bunch of, well, really social people in its leadership, and you shouldn’t expect them to act like senior leadership of Intel, IBM, or Nvidia.
The fact Paul makes jokes on a social forum at or with people is a reminder that he’s a human. He’s smart, passionate, nerdy, talented, and sometimes extremely annoying, much like everyone else here, and I’m GLAD the leadership of the company and the protocol are as engaged with the community as they are.
It’s a social protocol, for god’s sake. Remember when everyone would complain that the people who ran Twitter would never use it? I do, and just because Elon is down the K-hole and a posting menace doesn’t mean the criticism was incorrect.
I hope you will agree that Paul's personal attacks towards me are unacceptable and unbecoming for the CTO of Bluesky. This is not the first time, I hope it is the last.
(see his peer comment flagged by the community here)
[flagged]
Wow. Irrespective of what the other commenter did to you outside of this thread (assuming you two have a history) your comments (this and others) here feel indeed like trolling and almost egging.
Someone mentioned you are the CTO at BSKY, is this true? (Here https://news.ycombinator.com/item?id=49029317)
Are you the CTO? If you are then this just feels like a red flag and kind of tells me as a user to look at this protocol/ecosystem (which truly is BSKY at the moment) with much caution.
I'm not sure why you always feel the need to attempt to troll me personally on HN like this. Last time you did, HN flagged your reply. We do not have to agree, but we can be civil. For HN reader context, Paul (Bsky CTO) and I have discussed the protocol and permission system IRL and have different visions.
My sense it that microblogging platforms like X/Bluesky condition people to discourse in ways online they would not in the physical world, though I have encountered online behaviors manifesting in the real world in recent years. ymmv, I have left them all completely and have a much better mental state since.
You replied to me, man
I did not author it as a personal attack though, apologies if it came through it that way.
Apologies if "worship" came across as calling you a cult, but it doesn't seem that you took what I said too seriously either. Good luck on ATProto, certainly don't want to deal with this kind of replies from you or Dan every time criticism or concerns come up, maybe once the protocol leaves BlueSky, but let me guess, it's planned for some point in the far future like every other concern?
Seriously, the entire separation of Bluesky from ATProto not happening is my main reason for not trusting it at all. You can't have a protocol owned by a for-profit entity and seriously call it "open"
https://atproto.com/blog/kicking-off-the-atp-working-group
https://docs.bsky.app/blog/plc-directory-org
None of these make ATProto removed from Bluesky, the working group scope is not clear from the article either.
Huh.
Tell that to LSP, QUIC, SPDY, GraphQL, WebRTC, BitTorrent, HTTP/2, and other protocols.
I guess they weren’t “open” either for the first 5-10 years of their existence either?
Weird.
Yes? Correct?
You guys are really confused about what atproto has to do with Bluesky and how much of the protocol is developed by or managed through Bluesky.
It really seems you all think the only company or community doing anything on atproto is Bluesky, when that couldn’t be further from the truth.
Have you even paid attention to what’s happening lately?
Well the whole protocol relies on a "PLC server". There can only be one and guess who owns it.
I think a more potent example is who controls the source for the spec and official implementations. This is a notable lack of community governance around this part. In this sense, Bluesky can and does change things at will. I have experienced breaking changes from their devs changing how things work and merging their own PRs in a matter of minutes, while not using versions. (indigo)
When it comes to private/permissioned data, Bluesky people have decided the shape it will take while not participating in the conversation until they shared their already decided upon design. They are letting the community give feedback, but the community never was able to participate in the design phase.
Who owns it?
Blue Sky. Jack Dorsey.
Is it?
https://docs.bsky.app/blog/plc-directory-org