I like the domain name identity model used by AT (so much so I built handles.net[1] for managing domain name based handles) but during my time reading opinions on Bluesky it has become apparent there's a lot more confusion about and distrust towards domain names amongst non-technical people than I previously thought.<p>I thought that people generally understood that domain names are owned and that their provenance can be independently verified (which is why they're valuable for identity) but there's a fairly large and vocal contingent of Bluesky users that are <i>frustrated</i> by domain names, so much so there are multiple efforts to establish a private verification system on Bluesky like verified.quest[2].<p>A lot of people do not want to look at and understand domain names, instead they want to see a name and a check mark. They want a central authority to tell them who is trustworthy and who is not. Domain names are a great solution for technology-adjacent people and I hope that they become more widely accepted, but I'm not too optimistic.<p>I am optimistic and hopeful that AT has a bright future ahead of it. I think AT has a lot going for it... but I do not think that identity will be a part of that. I suspect many apps built on AT will not bother with handles and will just use local display names.<p>[1] <a href="https://handles.net" rel="nofollow">https://handles.net</a>
[2] <a href="https://verified.quest" rel="nofollow">https://verified.quest</a>
> Ownership of identity<p>This isn't currently a reality with ATProto, though they're making important progress over the status quo.<p>Your identity in atproto is your DID. Your domain (if you use one) is just a handle. Currently all DID resolution goes through <a href="https://plc.directory" rel="nofollow">https://plc.directory</a>, which is completely controlled by Bluesky. Their plan is to eventually have this run more like the DNS by something like a nonprofit, but AFAIK that process hasn't started.<p>The question is if Bluesky turned completely evil today, what recourse would users and app developers have?<p>All the other apps could form a coop for a new DID directory and switch their users over. That might work, but I would like to see something like this in place running alongside Bluesky's directory since the logistics of running such a thing are not obvious.<p>Also, it's not entirely clear to me that running an alternative pseudo-DNS is really better than just using DNS like the fediverse does.<p>One really nice thing about it is that DIDs are opaque values, so squatting should essentially go away. And there's not really any good reason for DIDs to expire like domains do. This is nice for account recovert, since in the worst case if you couldn't prove your identity to the DID registrar your account would just go stale, rather than potentially being taken over by a bad actor[0].<p>[0]: <a href="https://news.ycombinator.com/item?id=42699099">https://news.ycombinator.com/item?id=42699099</a>
ATProto is an interesting technology but the Bluesky app itself is seriously flawed as a Twitter/X competitor.<p>Probably the worst feature is the "nuclear block" which allows a single user to completely disrupt a conversation: if one user blocks any other user in the thread, this removes the blocked user's replies for everyone else reading the thread, and severs the connection between posts so that even if you go directly to a post from the blocked user you can't see what post they were replying to or any of the rest of the thread above that.<p>There are partial workarounds to this with third-party websites that attempt to piece together the thread from various other API calls, but these aren't perfect and it's annoying to have to do this to understand the context of a conversation full of blocked posts.
The problem with atproto is that it's rediculously complicated. Every detail in the spec done in the most difficult and stilted way possible.<p>They could've made something much more like Nostr be at the core of it all, so that the barrier to entry is small for people wanting to write their own implementations, but the developers/designers of atproto put very little value in simplicity. They wanted everything to be as powerful as possible at every single layer, which means far too many levels of abstraction, super heavy-weight implementations, and stacks upon stacks of specs that are hard to unravel, etc.<p>Anyone can learn Nostr in minutes. To learn atproto you need weeks.
To be honest, I hope that the Fediverse can be expanded to support W3C DID for identities. It's challenging to pick a set of tradeoffs that make the most sense for this sort of thing, but other than that I don't think it's impossible.<p>For example, if you just wanted DIDs for verification, I reckon you could go the route of having DIDs be represented as [DID]@[ActivityPub service domain] and treat each ActivityPub service as a different type of PDS.<p>I don't think AT Proto/Bluesky will wind up killing the Fediverse, at least not any time soon, so I think it would make sense to try to figure out ways to take some of the more interesting applicable ideas and try to figure out how they could work.
This concept of multiple applications and companies sharing the same social graph is what makes ATProto and the adoption exciting. ATProto brings real competition to social media and removes the switching cost for users. As OAuth matures, it will become even easier, and that the money is now interested adds another point of legitimacy.
I know I am comparing Bluesky's reality vs ActivityPub potential, but there are extensions that give identity and data portability to ActivityPub, all they need is to be adopted by the likes of Mastodon and PixelFed.<p>Also, there is a whole spec for client-to-server ActivityPub which has been largely unexplored by developers and would allow end-users to be in full control of their whole experience (i.e, no "instance" between you and the rest of the social web.
Caveat: You own your identity only as long as you use did:web, and did:web is not much different from webfinger, which is what activitypub uses.<p>To clarify, the alternative (and default) is to use did:plc, which utilizes Bluesky (the company’s) centralized identity server. It isn’t possible to use other plc servers with any of the Bluesky clients either. Therefore, if you use did:plc it’s simple to get kicked off of.
I've dived head first into Bluesky and AT Proto in the last 2 months. The platform is amazing and I was able to grow an app from 0 to 30k users in that time[1].<p>I have also been long pondering what puts me off social media and how I could fix it. Often times it is the ease by which anyone can create new anonymous accounts, those accounts can be used to easily brew up a Firestorm of Falsehood[2]. Identity is a strong part of this and domain name verification isn't enough to solve this.<p>One potentially radical idea I've had is to form a social network of verified humans. Where each human is only allowed a single account. This is possible, while remaining anonymous to other users. I think the only way in which this can be done is by relying on passport (and other government IDs) verification. I have actually built a prototype of this (still very much a WIP)[3]. Of course, the barrier to entry is tough, if anyone has thoughts/concerns and suggestions on how I can make this happen I'd love to hear them.<p>Edit: To those downvoting I'd love to hear why, please :)<p>1 - <a href="https://listifications.app" rel="nofollow">https://listifications.app</a><p>2 - <a href="https://en.wikipedia.org/wiki/Firehose_of_falsehood" rel="nofollow">https://en.wikipedia.org/wiki/Firehose_of_falsehood</a><p>3 - <a href="https://onlyhumanhub.com" rel="nofollow">https://onlyhumanhub.com</a>
sounds like XRI and XDI and all the associated layers of standards that never went anywhere but produced a lot of architectural spacefaring
<a href="https://www.oasis-open.org/committees/xdi/charter.php" rel="nofollow">https://www.oasis-open.org/committees/xdi/charter.php</a><p>on edit: some things just bring out my cynical side.