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.

▲

verdverm 4 hours ago | parent [-]

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.

▲

fidotron 4 hours ago | parent [-]

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.

▲

verdverm 4 hours ago | parent [-]

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

▲

fidotron an hour ago | parent [-]

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

	▲	verdverm 41 minutes ago \| parent [-]
		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.