The (Absolute) State of The ATmosphere: 2. The Bad

A screenshot from my brief experience being able to post from a did:web account that did not officially exist.

---------------------------------------------------------

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

Creating a did-method-web identity

Browser tool for creating a did:web

Adversarial PLC migration

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:web for 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 your did:web so 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:web for 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 a did:web when everywhere else it is buggy and/or discouraged. This couldn't be a subpath either, so I made it its own domain (didweb.atproto.bront.rodeo). While I didn't love having to continue tacking prefixes onto my domain to get the DID to work, I can live with it - I'm sure there's some good technical reason for it, and I'm not going to create more anytime soon. But the fact that I couldn't get the feed to work with my serviceEndpoint pointing to /haiku is annoying. I would almost certainly want to run multiple service endpoints if I continued working with feeds, and making a unique subdomain for each one is aesthetically displeasing to me.

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 collections" would be nice.

Useful links

Auth scopes discussion