This week’s implosion of Twitter has set off an unprecedented migration to alternatives, particularly the ActivityPub based Fediverse. Since that implosion included a complete breakdown of  the verification system (What do blue checks mean today? What will they mean tomorrow?) lots of people started off thinking about identity and impersonation in a decentralized space.

The previous verification system at Twitter was the kind of centralized approach most of us are used to.  Twitter publicly attested the identities of about 400000 accounts belonging to institutions, brands, and various celebrities in the same way most people in the developed world rely on an ID card issued by a government.  To think about how to build an identity system without a central authority, we have to look backwards. Before national ID cards, identity was largely managed through social connections.  You were introduced to someone, in person, by a common acquaintance whom you both trust.  That introduction attests your identities to each other.  This is in essence the web of trust that Pretty Good Privacy tried to build via key-signing.

Of course, the process becomes more complicated when you aren’t in person.  What if that letter of introduction is a forgery?   Oddly, existing social media platforms worked on the electronic version of this problem in a roundabout way, with photo tagging.  When I take a picture of someone and tag them when I post it.  I’m attesting that the account I tagged belongs to the person whose image I posted.  If you also recognize that person’s image, you can take that tag as evidence that a particular account belongs to a particular person.

In the Fediverse, such identity verification as there is relies on having control of some other website.  Mastodon, the most popular ActivityPub implementation, allows you to place a link to your profile with a rel=”me” attribute on your website,  When you add the address of that page to your profile, it appears with a green check.  What this actually does is show that the same entity controls the website and the Mastodon account.

If you control a domain, you have another option, creating a Fediverse server within that domain.  Since you control the domain, you control the Fediverse server. This method is an option for institutions as well as individuals.  mastodon.archive.org  has been launched by the Internet Archive and only IA employees are allowed to have accounts on this instance.  Effectively, IA is publicly attesting the identity of the person attached to each of those accounts. It will be interesting to see if other institutions follow suit.

As the on again off again acquisition of Twitter went on again, focus turned back to mastodon, a federated alternative.  As another wave of users dip their toes in the waters, I wanted to share some thoughts.

Scale

The fediverse is predicated on replacing a single site having one set of policies with a network of sites.This is both technically resilient and resistant to the whims of a single owner. There are, however, different ways to realize this concept.

The web interface of mastodon includes a local timeline, A separate local timeline makes sense when each instance is a distinct community. Initially, standing up and administering a server was not for everyone. Mastodon was designed with an administrator role and those administrators are empowered to set policies on their instances. The model here is a collection of “small towns” each with its own culture.

But then something happened — mastodon became popular and more accessible server models became available, including pre- configured VPS’s and hosted options. This opened a new use case, that of the single user instance.  Here, the local timeline becomes unimportant.  This is more like Twitter, which doesn’t have such a thing.  The official iOS Mastodon client has gone as far as not  even showing the local timeline. We have an interesting scenario in which not only policies and standards but also what it means to moderate vary from instance to instance.

Mastodon and protocols 

Mastodon runs on ActivityPub, the under the hood protocol that allows instances to communicate with each other.  It also supports publishing RSS and Atom feeds.  There are other applications that support ActivityPub. For example, A WordPress site can, with the right plugin, publish an Activitypub stream.  This allows a mastodon user to follow that site as if it were a mastodon user. However, that WordPress plugin generates ActivityPub but doesn’t parse it, meaning if you reply in Mastodon, nobody will see it. You end up with different apps using the same protocol to different ends.  Combine this with RSS support and you need to think about your data flows.

Update: Because of incompatibilities with other plugins, I did not test this on my own site. The WordPress site I followed to test was using a custom configuration that I mistook for a default setting.