@jdp23 I admit I am not particularly sympathetic to the idea that it is the responsibility of developers or admins to make it impossible to join an instance that is run poorly or even maliciously. Is it the gay bar's fault there's a Nazi bar downtown?

The rest of this, though, I agree with. Building nomadic identity tools, with a clear understanding of the fact that it's not free and not trivial for users even in its best state, is great. So is making it easier to run instances by co-op, and building those organizations.

@promovicz The core reason is that you have to establish ownership somehow or else anyone can just impersonate you. There are two ways to do that: connect it to hosting, or make users manage cryptographic material that proves who they are.

I've taken as axiomatic for a looooong time that asking users to manage key material is unacceptable. However, Bluesky does that* and people seem fine with it. This has lead me to revise this thinking, and I'm actually working on specifying and implementing some of the ideas I previously threw away because they require this.

* ATProto requires that users manage keys. Bluesky allows (and indeed almost requires) users to abdicate that key management to them. This is wildly, catastrophically insecure, of course, but people don't seem to mind.

@noracodes thanks for this!