The (Absolute) State of The ATmosphere: 2. The Bad
Though I'm overall optimistic about the direction of atproto, it's a young ecosystem and there are still jagged edges. As I mentioned yesterday, I am open to the possibility that I am wrong about some of the stuff here, and am generally optimistic that it's being addressed, but I think these are worth noting as the big sticking points I ran into during my explorations.
DIDs
I was really excited to try hosting a did:web. Self-signing my own identity from a domain I control felt like the final step in decentralized social. Unfortunately in reality it just breaks stuff a lot, even if you're not fucking up the way I did by creating and then deleting a did:web. Lots of parts of the ecosystem either treat it as a second-class citizen or ignore it entirely. This doesn't seem optimal to me, in an ecosystem that's trying to tout how decentralized it is!
Since Bluesky the company controls the PLC, which is the primary identity provider, your identity on atproto is not meaningfully decentralized in any way. What the devs are saying about creating PLC mirrors and moving the PLC attribute over to a nonprofit is promising, but it's still just talk until it happens.
Understanding the PDS better gives me some hope - as a user, you can still at least access your records if your did:plc is compromised - but in an adversarial scenario you lose the social graph and trusted identity (as I understand it), which is supposed to be the big selling point here. Personally, it was just pretty disappointing to attempt to go the fully self-hosted route and discover how much stuff just doesn't work.
Useful Links
DNS/URL stuff
I think DNS as a first-class citizen is very cool, and while it doesn't get you to self-hosting everything, it at least decentralizes the various forms of authority. I haven't dived deep enough into moving PDS hosting or changing domains, which I'd like to understand/see more of. If your DNS becomes an adversary, can you move your PDS to a new one? If not, that could become a concern. I'd rather avoid the experience of Mastodon federation where servers are constantly breaking and refusing to recognize each other.
Outside of my fear of atproto becoming ActivityPub, the documentation of domain name behavior needs improvement. There are certain rules about what part of the ecosystem can live where on a domain that aren't really explicitly listed anywhere. This led to me getting enormously confused when creating a did:web and later creating a feed:
- I am certain, but cannot prove since I deleted it, that I was successfully able to create a
did:webfor the domain I am hosting my PDS on and also use that as my handle. This ultimately broke when I deleted and re-created the did:web - knowing where in the stack that happened would be great. My best guess is it was in the AppView, but even with the help of some pretty smart strangers I never could figure out exactly what happened. Plenty of other documentation implies that you can't serve your PDS from the same domain as yourdid:webso maybe I hallucinated the whole thing. Regardless this seems like something that should be explained somewhere. - I tried to point my feed service through a subpath (atproto.bront.rodeo/haiku) but that didn't work. The feed generator created a
did:webfor the domain, which I guess makes sense but it wasn't really explained to me why this specific part of the ecosystem needs to be adid:webwhen everywhere else it is buggy and/or discouraged. It's fine that I couldn't create adid:webfor a subpath, I'm guessing there's some significant logic there, but the fact that I couldn't get the feed to work with my serviceEndpoint pointing to/haikuis annoying. I would almost certainly want to run multiple service endpoints if I spent a lot of time on this and making a unique subdomain for each one is annoying.
Generally, while I acknowledge that the ecosystem is young and that I have a unique ability to find edge cases, a lot of this either ought to be better documented or simply shouldn't be a problem in the first place.
Useful links
- We Really Love DNS - blogpost by the new Bluesky DevRel!
AppView
Since the last time I checked in on this, @future.blue proved that you can run your own AppView with Zeppelin Social. The problem is that most applications still don't. Pretty much everyone is still reliant on Bluesky's AppView to relay all the information being broadcast from all the community PDSes out there. There was a big controversy over this when a Blacksky user was banned from Bluesky and, because they're reliant on Bluesky's AppView, they were inaccessible on Blacksky as well.
My impression is that Blacksky has been addressing this, and there are a number of other projects at various stages of hosting their own AppView, but right now this is a single point of failure that gives a lot of cause for concern. More than that, the production code is private, the public versions are poorly documented, and my own attempts at running the test version locally were much more involved than they needed to be. I think some of the AppView-free projects out there are interesting, but I haven't investigated them closely enough to have a strong opinion about their sustainability.
Having mentioned the did:web issues I had earlier, it was personally pretty frustrating to be completely unable to figure out why my did was breaking because it was getting blocked somewhere in the black box of the AppView.
Useful links
- Constellation - one AppView-free approach to gathering data
- Red Dwarf - a Bluesky client built on top of Constellation
Permissions
This essay by the PDSls dev sums up the issues with OAuth scope as they stand pretty nicely. For a decentralized ecosystem with a whole lot of former crypto people, there is a core reliance on trusting developers that can't last. It's kind of nice to see I guess? But very bad things are likely to happen if it doesn't change fast.
I know we're still in early days but the fact that every application gets full write access to your repo by default is BAD. I'm kind of surprised I haven't heard about more attacks using this. I know they're planning to fix it soon but at the very least making the default "this app only writes to its specific lexicon" would be very nice.
Useful links