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)
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.
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.
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.
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.
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.