Update Portable Identity for ActivityPub

site/posts/2023-05-01-activitypub-portable-identity.md

@@ -55,6 +55,8 @@ The hard part however, is the social one: we collectively need to agree that the
 
 Adding to the social problem is the risk that vanity URLs become popular, and then the desire shifts to migrating between identity resolvers. Solving this problem is possible, although it ends up requiring a larger architectural change to existing ActivityPub implementations. One possible approach, using DIDs, is discussed below. Another approach is splitting the identity resolver from the apparent username. A username that's written as `@someone@example.com` could be looked up by using WebFinger on `example.com` which would then respond with the actual AP ID of the user as `https://someone.net` which would in turn be hosted by `example.com` (i.e., DNS records for `someone.net` point to `example.com`). This breaks a number of assumptions Mastodon and clients make about the mention format but it is architecturally possible. I do think this is a problem worth solving, but in the interest of supporting account portability in terms of what people usually care about—moderation decisions, servers going down—it isn't a requirement.
 
+The key advantage of this approach is that resolving a portable identity or object ID into a concrete ActivityPub object is no different than it is now. You just make an HTTP request, and get back an AP object. Where it's actually hosted, and therefore changing the host, does not matter to you. All your references to the migrated people and posts do not change.
+
 ## UX
 
 So under this vision, what does the complete migration process actually look like?
@@ -75,6 +77,8 @@ I am not familiar enough with the Mastodon codebase to say whether moving to the
 
 There is, to the best of my knowledge, only one single ActivityPub project that supports multiple domains: [Takahē](https://github.com/jointakahe/takahe). Multiple accounts across different domains being backed by the same host doesn't get us all the way to portable identity. But the architectural decisions required to support it go a long way towards that vision. I have not taken the time to trawl through the code and work out if it's actually using the domain to look up AP objects in its database or if it, like Mastodon and others, is still just extracting the database ID from a path component and using that for the lookup. Either way, by virtue of supporting multiple domains already, I think Takahē is much closer to reaching this vision.
 
+Migrating existing accounts and content to portable identities, though, is an open and much harder question. The identifier for just about every AP object that's already out there specifies the host. Making those objects portable would mean either making existing domains identity resolvers rather than hosts (not feasible) or getting every instance to update all of its references to the moved objects (basically where we're at now, and it's not feasible either). This is the biggest question regarding this approach, and I readily admit that I do not have a good answer to it.
+
 ### Technical Miscellanea
 
 What follows isn't anything cohesive, just some thoughts that occurred while writing this post and thinking about the architecture I've described.
@@ -106,3 +110,11 @@ ATProto uses [DIDs](https://www.w3.org/TR/did-core/), rather than URIs, for iden
 </aside>
 
 This does solve the caveat mentioned earlier, that the shared identity resolver has to be treated as infrastructure and be above moderation decisions. But, if the goal is to move the existing ecosystem towards portable identity in a reasonably expendient manner—and I believe that is the goal—adopting DIDs in the short term is unnecessary.
+
+#### Moderating Actions Against Hosts
+
+A very good point brought up in reply to this post was that since, right now, a domain/host/instance are all one and the same, they serve as a very useful target for moderation actions, but portable identity seems to interfere with that. If the moderators of a certain instance condone bad behavior from one person, another instance can take action against that entire instance, rather than just the individual, on the reasonable assumption the moderators will permit similar behavior from other people. But adding the layer of indirection I described makes it much harder to take such actions. Where as now it's clear that `@alice@example.com` and `@bob@example.com` are hosted at the same place, if they used their own domains—say, `@alice@alices.place` and `@bob@bob.online`—it's no longer self-evident that they're hosted, and thus moderated, at the same place.
+
+First off, I think that portable identity inherently makes this sort of moderation against the host less useful. Making it easier for everyone to up and move hosts definitionally makes it easier for bad actors to do the same. Taking moderation action against `example.com` has less utility if it's easy for everyone hosted there to relocate.
+
+But, that said, I think this model is still possible—and for one method we need only look to email, where identities (email addresses) are already separate from hosts (SMTP servers). Hosts could require that inbound activities specify the _host_ that they originate from, not just the actor, and then reject activities from blocked domains. To prevent the originating host from being spoofed, the host would sign the message with a private key and then the recipient would then validate the signature against the originating host's public key looked up from DNS.