Like many others, I had a fun time on mastodon.social this weekend. Many great people from Twitter showed up, as well as other generally cool and famous-ish people.
For those just tuning in, Mastodon is a re-implementation of the GNU Social codebase, which itself is —
(okay, bear with me people, about to serve you a nice big dollup of tasty protocol soup)
— an implementation of the OStatus protocol, originally forking from the GNU FM project and later merging with the StatusNet and FreeSocial projects, from the same people behind Identi.ca, which was later folded into pump.io, which uses the ActivityStreams spec along with protocols like PubSubHubBub, Salmon, WebFinger, and Atom syndication to deliver a federated, open-source Twitter-like experience for the masses.
Got all that? Okay, moving on.
The idea behind federation is a very cool one. If I’m on Twitter, and want to message my friend, I need their Twitter-specific handle:
But if I’m on a federated network, such as Mastodon, I can reference any handle on the broader “fediverse” network, and my message (called a “Toot” in Mastodon) will be delivered to them:
You’ll notice the quite-generous character limit of 500 on Mastodon
This is extremely cool. And before I get into why Mastodon (as is) will fail, I want dissect all of the things Mastodon does right, and why it’s such an important stepping stone in the decentralized computing movement in general.
The first thing to notice is that Mastodon is a beautiful, modern, and ready-to-use application with zero configuration or set-up from the user. Almost every open-source social networking alternative either has very little attention paid to the UI, or is written for people who have extra time on their hands (to set up their own servers, and so forth). Mastodon gets that out of the way; you give an email address, a handle on the mastodon.social instance, and you’re in.
It’s hard to understate how just a small sprinkle of design thinking and caring about the user goes an incredible way in adopting software like this. Consider Mastodon’s closest peer, the venerated GNU Social. If you go to https://gnu.io/social/, you’re greeted with the most basic of Bootstrap UIs, and either an option to self-host or a text file containing a list of instances that mostly look like, well, this:
I should clarify that Richard Stallman is a literal hero, this just happens to be the first instance I clicked
I don’t want to knock too harshly on the hard work that Free Software / open-source platforms do. Many of the people working on these projects are engaged full-time on hard, technical, dredging backend work to make projects like this even possible, and Mastodon’s success piggybacks off of the existing “fediverse” network. But very rarely does a project go the extra mile to make their instance beautiful or usable, and Mastodon scores an A on both fronts, for a project being developed primarily by one person.
Second, functionality. The user experience of Mastodon is a souped-up version of Tweetdeck, one of the most popular 3rd party Twitter applications. And the functionality is there, and it’s intuitive; partly due to the maturity of the OStatus protocol, partly due to Eugen Rochko’s careful crafting of each element, attention to modern application design, and extension of the standardized GNU Social data model (this part is a bit controversial; a topic for another day).
A brief primer of the UI: You have 3 main columns, one for your “feed”, one for your notifications, and one that’s a context-dependent catch-all for whatever you’re currently viewing (like somebody’s profile, or a thread of tweets). Out of the box, you get support for emojis, support for content warnings, private/public/unlisted privacy settings, ability to upload photos/gifs, a robust settings/preferences menu (with support for 2-factor auth, data import/export, and other nice features), favorite “toots”, blocked users, and ability to discover other accounts and activity via a (I’ll admit, slightly cryptic) “local” or “federated” timelines feature. Here’s a sample of what my dashboard looks like:
This is the first attempt I’ve seen at a decentralized alternative to major social networks that feels like a modern, well-designed, user-friendly competitor, actually surpassing the native UI for Twitter in some areas. There are still some bugs, rough edges, and server downtime issues, but overall it cleanly passes the bar for “minimum viable UX”, and this inspires hope for me that open-source alternatives don’t always mean a precipitous drop in user experience quality.
Third, Mastodon’s growth this weekend was crazy. According to https://mastodon.social/@usercount, 18,000 accounts have been added this last week alone, which is like 80% growth, before signups were shut off on Tuesday to curb the scaling issue. The best proof that something works is that it works; so far, users like what they are getting and want more.
Finally, a small note about Mastodon’s codebase. GNU Social, the spiritual forefather of Mastodon, is a PHP codebase that is, by some accounts, a bit rusty and reportedly hard to extend. Mastodon was born out of Gargron (Eugen Rochko)’s frustrations of working with the PHP codebase and is ostensibly a little cleaner and nicer to develop in. I don’t want to step into the hairy hornet’s nest of backend developer holy wars here, but I’m inclined to believe that Ruby is a slightly better choice than PHP to build robust applications with, or at least the UX-aware developer community in Ruby is a bit larger. So if you care about this sort of stuff, it’s worth knowing about the technological differences.
The elephant in the room
Okay, so that all sounds pretty good. Why do I remain convinced that Mastodon, in its current form, will fail?
The foremost problem is that federation is a lie. Well, it’s partially a lie. The benefits described above do work; if you send a message to anyone at @username@custom.website, it will be delivered to them. But if @custom.website is a domain that mastodon.social deems inappropriate, replies from that users on that domain don’t show up in your notifications or on your feed, unless you explicitly follow them.
So if you’re having a conversation with your friend, @person@custom.website, and another user from custom.website wants to chime in, they will be invisible to you.
Okay. So how does one end up on this blacklist? Take a deep breath, folks. Let’s look at mastodon.social’s community policy:
The following types of content will be removed from the public timeline, and may result in account suspension and revocation of access to the service:
- Racism or advocation of racism- Sexism or advocation of sexism- Discrimination against gender and sexual minorities, or advocation thereof- Xenophobic and/or violent nationalism
At this point, my audience will predictably split sharply into two camps. There remains a significant portion of the internet who believes that determining whether someone’s speech is “racist, sexist, discriminatory, or xenophobic” is a totally obvious and non-controversial determination, and is 100% happy with giving a single moderation team the ability to cut off entire instances based off of individual reports of misconduct. The other camp says, hmm, maybe not so much.
Moderation considered “really friggin’ hard”
I don’t have the space here to delve deeply into the conversation about what type of speech is harmful, or should be allowed, or whatever. That’s not to be dismissive of those concerns. Moderation is likely the most difficult topic in all of software engineering history, but ideologues from both ends of the spectrum (from ALL SPEECH ALL THE TIME to BE NICE AT ALL COSTS) will try to construe the problem as simpler than it is. Don’t listen to them. They are wrong.
But we can generalize a few lessons from the thousands of online communities who have struggled with this. The first is acceptable speech is a moving target, and depends on the community. I hate that this isn’t obvious to everybody, but it’s true. This topic encompasses all types of low-quality or harmful content; from spam, to child pornography, to doxxing, to brigading, to harassing behavior, to linking Gawker articles, to advocacy of hateful ideologies, to… well, this is a smattering of our current societal context, but I guarantee you this problem is not new, and represents a genuinely hard area of wrangling humans. I implore people to find philosophical frameworks that address it adequately and universally.
(The “low-quality” part is something that rarely gets addressed, but might be nearly as important as harmfulness. Youtube comments are not only vile, but are likely to have low relevance or information density compared to a commentariat you’d prefer, like one populated from your respected social graph.)
The point is, community leaders can and should have the tools to address moderation issues in a way that 1) grants administrators agency over the groups or types of content they allow, and 2) allows users to switch between well-tended gardens if they disagree with the moderation policy.
(1) is implicit with any new platform you join. (2) is where things get interesting.
The Big, Hairy, Intractable, No-Good Problem of Portable Identities
Suppose you’re a semi-famous content publisher. You have 10,000 followers on Twitter, whom you converse with regularly and have a large history of communications with. If you decide to switch networks to something like Mastodon, you immediately come into contact with the Hardest Problem of Identity on the Internet, which is that your social graph is not portable between platforms.
The only way to get your 10,000 followers on Twitter to “follow” you onto Mastodon is for every single one of them to sign up for Mastodon, find your account, follow you there, and then if you ever want to reference past conversations, link to a bunch of old Twitter threads. By 2021, Twitter will be dead, and you’ll have to use archive.org. Yuck.
This is basically unworkable. If people are super in love with your content, they’ll maybe make the switch, but it’s hard and boring and dumb to build new networks from scratch. Most people won’t bother.
Combined with the moving-target moderation problem above, you have a recipe for disaster. And here’s the first principle of a workable, future-proof social network: Your identity should not be coupled with the moderation policy of whichever platform you host your social graph on. It’s basically a guarantee that at some point, some percentage of your friends will take issue with (or violate) the terms of service of whatever platform you’re on, and at that point you’re at the whims of platform administrators to hear your plea, or you’re SoL.
Without this kind of guarantee, the promise of federation is ultimately hollow. While you can still message anyone on a remote network, friends-of-your-friends can be rendered invisible to you, without notice, appeal, or any form of recourse, and this is kryptonite to social networks whose value is derived from Metcalfe’s law (read: every network).
This is why I can’t recommend people follow me at @johnhenry@mastodon.social. If their moderation policy is changed or enforced in a way I don’t like, I lose the valuable, hard-won community I’ve built by later switching to @johnhenry@something.else and having to build my social graph all over again. No-go.
Putting your mouth where your money is
You might be asking; why not find another Mastodon instance with a dedicated, long-term mission to block only the most heinous and vile instances, like those with demonstrated spam or child pornography?
Besides the moving-target problem, there’s another dilemma we haven’t talked about yet, which is that running and administering your own social server is friggin’ expensive. Gargron has put a ton of work into getting mastodon.social to 40k active users. He is funding the project via a Patreon to pay for server/living costs, but mostly out of passion: At ~$20k / year (at the time of this writing), he is forfeiting a huge amount of market value for the type of work he’s doing, let alone forgoing huge potential attention monetization from taking VC / ad money and building out a full competitor to an existing platform like Twitter.
I should pause here and say, if you’ve used Mastodon and you’re not contributing to his Patreon, friggin’ do so. Here’s even a big pull quote for you. Just $5 will do. I’ll wait.
Give this man money: https://www.patreon.com/user?u=619786
The problem with alternative instances to mastodon.social is that site reliability is a huge, expensive headache. A liberal moderation policy means nothing if your site goes down for hours out of the week, and full-time developers with the skills to administer 1000+ user networks usually won’t do it out of just the kindness of their hearts.
Until now, users have been unwilling to pay directly for social media experiences, and most communities have opted to take the Devil’s bargain with advertisement companies to keep the experience free. Due to the aforementioned Metcalfe’s law, those networks tend to win out, because the 10–20% of users who are unwilling or unable to pay for web experiences diminish the value of the network for everyone else. Plus, the web has a strong existing culture of not paying for social web services, opting to choose mediums that optimize the priorities of advertisers over the values of users.
Here, I’ll let Jessica explain.
This tweetstorm from the wise David Chapman elucidates this point in detail, with far better wording than I could muster. I imagine this will be a tough pill for many to swallow, but the only alternative is more centralized, one-size-fits-all monoliths that carry other issues with data siloing, privacy, and general sleazy behavior. The good news is, the collective memory of the global community of web users builds slowly over time, and I am confident we’ll reach a tipping point where centralized services become simply unusable, even for ordinary users, and a solution like Mastodon will have to step up.
In short, I have no alternatives to mastodon.social because no other instances can offer credible site reliability guarantees without the promise of monetary incentive, and I haven’t seen paid instances of Mastodon or other GNU Social instances available yet. If you want to build one, please contact me, because there a lot of people willing to pay for something like this.
Solving the identity problem
Okay, so what is the actual solution to supporting portable identities while allowing well-moderated communities? Unfortunately, I don’t know. As mentioned before, the problems of identity, centralization, and moderation are not new to the web. This is an open problem; many smart people have tried tackling it, and many new initiatives are currently being tested. I’m not going to do this issue justice in the space we have today, but let’s do a quick whirlwind tour of available alternatives.
There’s a long history of attempts to provide globally unique, neutral identity solutions, with properties conducive to running effective online communities. To the tech-savvy, you have limitless options.
- DNS is currently the gold standard of identity, which is administered by a corporation called ICANN. DNS is probably the best we have so far, and groups like IndieWeb advocate using DNS directly to handle publishing, distribution, and conversations online. Effective for people able to do so.
- PGP is a popular solution using public-key cryptography, which itself provides many ways to uniquely identify users, but doesn’t provide nice usernames. Great for privacy-concerned professionals, but hard to build a network from “Add me on Mastodon at 8hap039jp98sv9dfuvsdfvuxdva!”
- Email flows downstream from DNS (someone@gmail.com relies on gmail.com to operate), and is the most popular way of signing up for web services. Email is a good option, but namespaces on popular providers like Google and Yahoo are crowded as hell, and the use cases of email are too entwined with two decades’ worth of semantic overloading. Plus, setting up your own email server is notoriously a PITA, and dealing with issues of reputation, spam, and email’s own hard-to-navigate protocol soup is too much of a headache to support modern social identities.
- IP addresses can identify and cross-reference users on the internet fairly well, as it’s the primary “source of truth” of which computer is connecting to your network (easily dupable by VPNs). Extremely hard to use directly, which is why DNS was invented.
- Cryptocurrency-based solutions. Requires you to buy into the whole cryptocurrency thing. May actually be a good solution in the long run, but not reliable today for lasting identity management.
To the non-tech-savvy, you have a lot of bad options.
- Platform-specific usernames, like Twitter handles. All of the problems described above.
- Facebook Connect gives you identity at the price of funneling your personal data through their servers, and putting a huge, advertisement-money-driven corporation between yourself and your friends. Yuck.
- Keybase is pretty cool, but provides just one flat namespace, which quickly becomes crowded if you want to secure meaningful usernames. Also run by a private company.
- Phone numbers are another way to identify people, but is far older and more rigid of a technology than email is, hard to make new ones, not very human-readable, etc.
If you’re a shady corporation or powerful entity, you of course have a lot of options, like Google’s Universal Analytics User-ID, LiveRamp’s IdentityLink service, and the NSA’s XKeyScore software. Honestly, if the NSA would just give us our XKeyScore identifier, this problem would be solved tomorrow, albeit with some troubling implications for the whole “privacy” thing.
Finally, there are lot of interesting, forward-looking solutions that are currently being tested, have potential, and are worth watching:
- Matrix.org approaches the problem differently than most. Matrix simply keeps a mapping called an mxid, which maps to any number of 3rd party IDs (like those discussed above), and has interesting strategies for consolidation. I’ll talk about them more in a second.
- Urbit ships are probably the most interesting innovation in identity management recently, and has extremely cool potential for moderation that is worth considering. Urbit is a bit of a crazy system to wrap your head around, but you can read about their address space here.
- Webfinger is what Mastodon is built on top of, and has all of the problems described above without paid Webfinger providers. If anyone wants to run a paid Webfinger registration service, I’d still love to hear it.
- IndieAuth uses your domain name itself as an identifier, requiring you to add a special HTML tag to the root of your domain that acts as verification. Pretty cool, but requires web knowledge to operate.
- Solid (MIT), a web standards group headed by Tim Berners-Lee, uses a protocol similar to Webfinger called WebID, which, if I’m being totally honest, I can’t really tell apart from Webfinger, or figure out what the differences are. Things devolve into protocol soup I have yet to wrap my head around when you get into the W3C history of trying various identity solutions.
I’m forgetting huge swaths of nascent solutions. The point is, identity is very hard; this isn’t people’s first identity rodeo, and we’re still working on an answer to the question of “how do I control one identifier, that I can use across platforms, that my friends can find reasonably find me on”. It’s tough stuff, and smarter people than me are working on it.
The blind users and the elephant
Given all we’ve discussed above, what could Mastodon do to demonstrate seriousness about handling theses nigh-intractable problems regarding moderation, abuse, and identity?
There are a couple paths forward I see. There’s an issue open on Mastodon’s Github with some great discussion on potential solutions, and I admit there’s no solution that’s a home-run. Here are a couple ideas that would make me substantially more comfortable with using and recommending Mastodon.
- Someone runs a paid Mastodon instance, probably between $2 - $10 / month, with a trustworthy and dedicated administrator who will do their best to moderate properly and drop other OStatus-based instances only under egregious violations of norms and with a process that is transparent and subject to appeal.
- Extend the Ostatus spec to allow for “forwarding” an account at @username@mastodon.social to some other address, with additional UI elements / semantics to allow a user to say “Hey, I’m switching addresses, follow me over <here>!”, and have the system respect paths to migration that don’t necessitate dropping your followers / content and rebuilding your network from scratch. An simple implementation of this is described here, and could probably roll out with minimal pain, at the harm of potentially breaking compatibility with the OStatus spec.
- Use an identity mapping system like Matrix.org to correlate between two WebFinger identities, and adapt the Mastodon software to allow following users across multiple instances / identifiers. Unclear precisely how this would work, but the promise of a “mapping” solution like Matrix instead of a typical “provider” solution is that it would greatly increase the ability of developers to scour a larger social graph of followers across instances (with perhaps some implications for privacy).
As of now, I can’t reliably recommend using mastodon.social under current circumstances, but I want to re-iterate how much incredible progress has been made with this experiment, and how desperately we need alternatives to centralized platforms like Twitter. Thank you for listening. If you’d like to continue the conversation, you can follow me on The Damned Birdsite or (sigh, I guess) on mastodon.social, where I rant incoherently about topics like this on a daily basis.
Or, feel free to comment here
(Update: Some good clarifications by Matt Lee, founder of GNU FM / co-founder of GNU social, in the comments here)