A tour of JavaScript timers on the web

Pop quiz: what is the difference between these JavaScript timers?

  • Promises
  • setTimeout
  • setInterval
  • setImmediate
  • requestAnimationFrame
  • requestIdleCallback

More specifically, if you queue up all of these timers at once, do you have any idea which order they’ll fire in?

If not, you’re probably not alone. I’ve been doing JavaScript and web programming for years, I’ve worked for a browser vendor for two of those years, and it’s only recently that I really came to understand all these timers and how they play together.

In this post, I’m going to give a high-level overview of how these timers work, and when you might want to use them. I’ll also cover the Lodash functions debounce() and throttle(), because I find them useful as well.

Promises and microtasks

Let’s get this one out of the way first, because it’s probably the simplest. A Promise callback is also called a “microtask,” and it runs at the same frequency as MutationObserver callbacks. Assuming queueMicrotask() ever makes it out of spec-land and into browser-land, it will also be the same thing.

I’ve already written a lot about promises. One quick misconception about promises that’s worth covering, though, is that they don’t give the browser a chance to breathe. Just because you’re queuing up an asynchronous callback, that doesn’t mean that the browser can render, or process input, or do any of the stuff we want browsers to do.

For example, let’s say we have a function that blocks the main thread for 1 second:

function block() {
  var start = Date.now()
  while (Date.now() - start < 1000) { /* wheee */ }
}

If we were to queue up a bunch of microtasks to call this function:

for (var i = 0; i < 100; i++) {
  Promise.resolve().then(block)
}

This would block the browser for about 100 seconds. It’s basically the same as if we had done:

for (var i = 0; i < 100; i++) {
  block()
}

Microtasks execute immediately after any synchronous execution is complete. There’s no chance to fit in any work between the two. So if you think you can break up a long-running task by separating it into microtasks, then it won’t do what you think it’s doing.

setTimeout and setInterval

These two are cousins: setTimeout queues a task to run in x number of milliseconds, whereas setInterval queues a recurring task to run every x milliseconds.

The thing is… browsers don’t really respect that milliseconds thing. You see, historically, web developers have abused setTimeout. A lot. To the point where browsers have had to add mitigations for setTimeout(/* ... */, 0) to avoid locking up the browser’s main thread, because a lot of websites tended to throw around setTimeout(0) like confetti.

This is the reason that a lot of the tricks in crashmybrowser.com don’t work anymore, such as queuing up a setTimeout that calls two more setTimeouts, which call two more setTimeouts, etc. I covered a few of these mitigations from the Edge side of things in “Improving input responsiveness in Microsoft Edge”.

Broadly speaking, a setTimeout(0) doesn’t really run in zero milliseconds. Usually, it runs in 4. Sometimes, it may run in 16 (this is what Edge does when it’s on battery power, for instance). Sometimes it may be clamped to 1 second (e.g., when running in a background tab). These are the sorts of tricks that browsers have had to invent to prevent runaway web pages from chewing up your CPU doing useless setTimeout work.

So that said, setTimeout does allow the browser to run some work before the callback fires (unlike microtasks). But if your goal is to allow input or rendering to run before the callback, setTimeout is usually not the best choice because it only incidentally allows those things to happen. Nowadays, there are better browser APIs that can hook more directly into the browser’s rendering system.

setImmediate

Before moving on to those “better browser APIs,” it’s worth mentioning this thing. setImmediate is, for lack of a better word … weird. If you look it up on caniuse.com, you’ll see that only Microsoft browsers support it. And yet it also exists in Node.js, and has lots of “polyfills” on npm. What the heck is this thing?

setImmediate was originally proposed by Microsoft to get around the problems with setTimeout described above. Basically, setTimeout had been abused, and so the thinking was that we can create a new thing to allow setImmediate(0) to actually be setImmediate(0) and not this funky “clamped to 4ms” thing. You can see some discussion about it from Jason Weber back in 2011.

Unfortunately, setImmediate was only ever adopted by IE and Edge. Part of the reason it’s still in use is that it has a sort of superpower in IE, where it allows input events like keyboard and mouseclicks to “jump the queue” and fire before the setImmediate callback is executed, whereas IE doesn’t have the same magic for setTimeout. (Edge eventually fixed this, as detailed in the previously-mentioned post.)

Also, the fact that setImmediate exists in Node means that a lot of “Node-polyfilled” code is using it in the browser without really knowing what it does. It doesn’t help that the differences between Node’s setImmediate and process.nextTick are very confusing, and even the official Node docs say the names should really be reversed. (For the purposes of this blog post though, I’m going to focus on the browser rather than Node because I’m not a Node expert.)

Bottom line: use setImmediate if you know what you’re doing and you’re trying to optimize input performance for IE. If not, then just don’t bother. (Or only use it in Node.)

requestAnimationFrame

Now we get to the most important setTimeout replacement, a timer that actually hooks into the browser’s rendering loop. By the way, if you don’t know how the browser event loops works, I strongly recommend this talk by Jake Archibald. Go watch it, I’ll wait.

Okay, now that you’re back, requestAnimationFrame basically works like this: it’s sort of like a setTimeout, except instead of waiting for some unpredictable amount of time (4 milliseconds, 16 milliseconds, 1 second, etc.), it executes before the browser’s next style/layout calculation step. Now, as Jake points out in his talk, there is a minor wrinkle in that it actually executes after this step in Safari, IE, and Edge <18, but let's ignore that for now since it's usually not an important detail.

The way I think of requestAnimationFrame is this: whenever I want to do some work that I know is going to modify the browser's style or layout – for instance, changing CSS properties or starting up an animation – I stick it in a requestAnimationFrame (abbreviated to rAF from here on out). This ensures a few things:

  1. I'm less likely to layout thrash, because all of the changes to the DOM are being queued up and coordinated.
  2. My code will naturally adapt to the performance characteristics of the browser. For instance, if it's a low-cost device that is struggling to render some DOM elements, rAF will naturally slow down from the usual 16.7ms intervals (on 60 Hertz screens) and thus it won't bog down the machine in the same way that running a lot of setTimeouts or setIntervals might.

This is why animation libraries that don't rely on CSS transitions or keyframes, such as GreenSock or React Motion, will typically make their changes in a rAF callback. If you're animating an element between opacity: 0 and opacity: 1, there's no sense in queuing up a billion callbacks to animate every possible intermediate state, including opacity: 0.0000001 and opacity: 0.9999999.

Instead, you're better off just using rAF to let the browser tell you how many frames you're able to paint during a given period of time, and calculate the "tween" for that particular frame. That way, slow devices naturally end up with a slower framerate, and faster devices end up with a faster framerate, which wouldn't necessarily be true if you used something like setTimeout, which operates independently of the browser's rendering speed.

requestIdleCallback

rAF is probably the most useful timer in the toolkit, but requestIdleCallback is worth talking about as well. The browser support isn't great, but there's a polyfill that works just fine (and it uses rAF under the hood).

In many ways rAF is similar to requestIdleCallback. (I'll abbreviate it to rIC from now on. Starting to sound like a pair of troublemakers from West Side Story, huh? "There go Rick and Raff, up to no good!")

Like rAF, rIC will naturally adapt to the browser's performance characteristics: if the device is under heavy load, rIC may be delayed. The difference is that rIC fires on the browser "idle" state, i.e. when the browser has decided it doesn't have any tasks, microtasks, or input events to process, and you're free to do some work. It also gives you a "deadline" to track how much of your budget you're using, which is a nice feature.

Dan Abramov has a good talk from JSConf Iceland 2018 where he shows how you might use rIC. In the talk, he has a webapp that calls rIC for every keyboard event while the user is typing, and then it updates the rendered state inside of the callback. This is great because a fast typist can cause many keydown/keyup events to fire very quickly, but you don't necessarily want to update the rendered state of the page for every keypress.

Another good example of this is a “remaining character count” indicator on Twitter or Mastodon. I use rIC for this in Pinafore, because I don't really care if the indicator updates for every single key that I type. If I'm typing quickly, it's better to prioritize input responsiveness so that I don't lose my sense of flow.

Screenshot of Pinafore with some text entered in the text box and a digit counter showing the number of remaining characters

In Pinafore, the little horizontal bar and the “characters remaining” indicator update as you type.

One thing I’ve noticed about rIC, though, is that it’s a little finicky in Chrome. In Firefox it seems to fire whenever I would, intuitively, think that the browser is “idle” and ready to run some code. (Same goes for the polyfill.) In mobile Chrome for Android, though, I’ve noticed that whenever I scroll with touch scrolling, it might delay rIC for several seconds even after I’m done touching the screen and the browser is doing absolutely nothing. (I suspect the issue I’m seeing is this one.)

Update: Alex Russell from the Chrome team informs me that this is a known issue and should be fixed soon!

In any case, rIC is another great tool to add to the tool chest. I tend to think of it this way: use rAF for critical rendering work, use rIC for non-critical work.

debounce and throttle

These two functions aren’t built in to the browser, but they’re so useful that they’re worth calling out on their own. If you aren’t familiar with them, there’s a good breakdown in CSS Tricks.

My standard use for debounce is inside of a resize callback. When the user is resizing their browser window, there’s no point in updating the layout for every resize callback, because it fires too frequently. Instead, you can debounce for a few hundred milliseconds, which will ensure that the callback eventually fires once the user is done fiddling with their window size.

throttle, on the other hand, is something I use much more liberally. For instance, a good use case is inside of a scroll event. Once again, it’s usually senseless to try to update the rendered state of the app for every scroll callback, because it fires too frequently (and the frequency can vary from browser to browser and from input method to input method… ugh). Using throttle normalizes this behavior, and ensures that it only fires every x number of milliseconds. You can also tweak Lodash’s throttle (or debounce) function to fire at the start of the delay, at the end, both, or neither.

In contrast, I wouldn’t use debounce for the scrolling scenario, because I don’t want the UI to only update after the user has explicitly stopped scrolling. That can get annoying, or even confusing, because the user might get frustrated and try to keep scrolling in order to update the UI state (e.g. in an infinite-scrolling list). throttle is better in this case, because it doesn’t wait for the scroll event to stop firing.

throttle is a function I use all over the place for all kinds of user input, and even for some regularly-scheduled tasks like IndexedDB cleanups. It’s extremely useful. Maybe it should just be baked into the browser some day!

Conclusion

So that’s my whirlwind tour of the various timer functions available in the browser, and how you might use them. I probably missed a few, because there are certainly some exotic ones out there (postMessage or lifecycle events, anyone?). But hopefully this at least provides a good overview of how I think about JavaScript timers on the web.

How to deal with “discourse”

It was chaotic human weather. There’d be a nice morning and then suddenly a storm would roll in.

– Jaron Lanier, describing computer message boards in the 1970s (source, p. 42)

Are you tired of the “discourse” and drama in Mastodon and the fediverse? When it happens, do you wish it would just go away?

Here’s one simple trick to stop discourse dead in its tracks:

Don’t talk about it.

Now, this may sound too glib and oversimplified, so to put it in other words:

When discourse is happening, just don’t talk about it.

That’s it. That’s the way you solve discourse. It’s really as easy as that.

Discourse is a reflection of the innate human desire to not only look at a car crash, but to slow down and gawk at it, causing traffic to grind to a halt so that everyone else says, “Well, I may as well see what the fuss is about.” The more you talk about it, the more you feed it.

So just don’t. Don’t write hot takes on it, don’t make jokes about it, don’t comment on how you’re tired of it, don’t try to calm everybody down, don’t write a big thread about how discourse is ruining the fediverse and won’t it please stop. Just don’t. Pretend like it’s not even there.

There’s a scene in a Simpsons Halloween episode where a bunch of billboard ads have come to life and are running amuck, destroying Springfield. Eventually though, Lisa realizes that the only power ads have is the power we give them, and if you “just don’t look” then they’ll keel over and die.

Simpsons animation of billboard ads wrecking buildings with subtitle "Just don't look"

The “discourse” is exactly the same. Every time you talk about it, even just to mention it offhand or make a joke about it, it encourages more people to say to themselves, “Ooh, a fight! I gotta check this out.” Then they scroll back in their timeline to try to figure out the context, and the cycle begins anew. It’s like a disease that spreads by people complaining about it.

This is why whenever discourse is happening, I just talk about something else. I might also block or mute anyone who is talking about it, because I find the endless drama boring.

Like a car crash, it’s never really interesting. It’s never something that’s going to change your life by finding out about it. It’s always the same petty squabbling you’ve seen a hundred times online.

Once the storm has passed, though, it’s safe to talk about it. You may even write a longwinded blog post about it. But while it’s happening, remember: “just don’t look, just don’t look.”

Mastodon and the challenges of abuse in a federated system

This post will probably only make sense to those deeply involved in Mastodon and the fediverse. So if that’s not your thing, or you’re not interested in issues of social media and safety online, you may want to skip this post.

I keep thinking of the Wil Wheaton fiasco as a kind of security incident that the Mastodon community needs to analyze and understand to prevent it from happening again.

Similar to this thread by CJ Silverio, I’m not thinking about this in terms of whether Wil Wheaton or his detractors were right or wrong. Rather, I’m thinking about how this incident demonstrates that a large-scale harassment attack by motivated actors is not only possible in the fediverse, but is arguably easier than in a centralized system like Twitter or Facebook, where automated tools can help moderators to catch dogpiling as it happens.

As someone who both administrates and moderates Mastodon instances, and who believes in Mastodon’s mission to make social media a more pleasant and human-centric place, this post is my attempt to define the attack vector and propose strategies to prevent it in the future.

Harassment as an attack vector

First off, it’s worth pointing out that there is probably a higher moderator-to-user ratio in the fediverse than on centralized social media like Facebook or Twitter.

According to a Motherboard report, Facebook has about 7,500 moderators for 2 billion users. This works out to roughly 1 moderator per 260,000 users.

Compared to that, a small Mastodon instance like toot.cafe has about 450 active users and one moderator, which is better than Facebook’s ratio by a factor of 500. Similarly, a large instance like mastodon.cloud (where Wil Wheaton had his account) apparently has one moderator and about 5,000 active users, which is still better than Facebook by a factor of 50. But it wasn’t enough to protect Wil Wheaton from mobbing.

The attack vector looks like this: a group of motivated harassers chooses a target somewhere in the fediverse. Every time that person posts, they immediately respond, maybe with something clever like “fuck you” or “log off.” So from the target’s point of view, every time they post something, even something innocuous like a painting or a photo of their dog, they immediately get a dozen comments saying “fuck you” or “go away” or “you’re not welcome here” or whatever. This makes it essentially impossible for them to use the social media platform.

The second part of the attack is that, when the target posts something, harassers from across the fediverse click the “report” button and send a report to their local moderators as well as the moderator of the target’s instance. This overwhelms both the local moderators and (especially) the remote moderator. In mastodon.cloud’s case, it appears the moderator got 60 reports overnight, which was so much trouble that they decided to evict Wil Wheaton from the instance rather than deal with the deluge.

Screenshot of a list of reports in the Mastodon moderation UI

A list of reports in the Mastodon moderation UI

For anyone who has actually done Mastodon moderation, this is totally understandable. The interface is good, but for something like 60 reports, even if your goal is to dismiss them on sight, it’s a lot of tedious pointing-and-clicking. There are currently no batch-operation tools in the moderator UI, and the API is incomplete, so it’s not yet possible to write third-party tools on top of it.

Comparisons to spam

These moderation difficulties also apply to spam, which, as Sarah Jeong points out, is a close cousin to harassment if not the same thing.

During a recent spambot episode in the fediverse, I personally spent hours reporting hundreds of accounts and then suspending them. Many admins like myself closed registrations as a temporary measure to prevent new spambot accounts, until email domain blocking was added to Mastodon and we were able to block the spambots in one fell swoop. (The spambots used various domains in their email addresses, but they all used same email MX domain.)

This was a good solution, but obviously it’s not ideal. If another spambot wave arrives, admins will have to coordinate yet again to block the email domain, and there’s no guarantee that the next attacker will be unsophisticated enough to use the same email domain for each account.

The moderator’s view

Back to harassment campaigns: the point is that moderators are often in the disadvantageous position of being a small number of humans, with all the standard human frailties, trying to use a moderation UI that leaves a lot to be desired.

As a moderator, I might get an email notifying me of a new report while I’m on vacation, on my phone, using a 3G connection somewhere in the countryside, and I might try to resolve the report using a tiny screen with my fumbly human fingers. Or I might get the report when I’m asleep, so I can’t even resolve it for another 8 hours.

Even in the best of conditions, resolving a report is hard. There may be a lot of context behind the report. For instance, if the harassing comment is “lol you got bofa’d in the ligma” then suddenly there’s a lot of context that the moderator has to unpack. (And in case you’re wondering, Urban Dictionary is almost useless for this kind of stuff, because the whole point of the slang and in-jokes is to ensure that the uninitiated aren’t in on the joke, so the top-voted Urban Dictionary definitions usually contain a lot of garbage.)

Screenshot of the Mastodon moderation UI

The Mastodon moderation UI

So now, as a moderator, I might be looking through a thread history and trying to figure out whether something actually constitutes harassment or not, who the reported account is, who reported it, which instance they’re on, etc.

If I choose to suspend, I have to be careful because a remote suspension is not the same thing as a local suspension: a remote suspension merely hides the remote content, whereas a local suspension permanently deletes the account and all their toots. So account moderation can feel like a high-wire act, where if you click the wrong thing, you can completely ruin someone’s Mastodon experience with no recourse. (Note though that in Mastodon 2.5.0 a confirmation dialogue was added for local suspensions, which makes it less scary.)

As a moderator working on a volunteer basis, it can also be hard to muster the willpower to respond to a report in a timely manner. Whenever I see a new report for my instance, I groan and think to myself, “Oh great, what horrible thing do I have to look at now.” Hate speech, vulgar images, potentially illegal content – this is all stuff I’d rather not deal with, especially if I’m on my phone, away from my computer, trying to enjoy my free time. If I’m at work, I may even have to switch away from my work computer and use a separate device and Internet connection, since otherwise I could get flagged by my work’s IT admin for downloading illegal or pornographic content.

In short: moderation is a stressful and thankless job, and those who do it deserve our respect and admiration.

Now take all these factors into account, and imagine that a coordinated group of harassers have dumped 60 (or more!) reports into the moderator’s lap all at once. This is such a stressful and laborious task that it’s not surprising that the admin may decide to suspend the target’s account rather than deal with the coordinated attack. Even if the moderator does decide to deal with it, a sustained harassment campaign could mean that managing the onslaught has become their full-time job.

A harassment campaign is also something like a human DDoS attack: it can flare up and reach its peak in a matter of hours or minutes, depending on how exactly the mob gets whipped up. This means that a moderator who doesn’t handle it on-the-spot may miss the entire thing. So again: a moderator going to sleep, turning off notifications, or just living their life is a liability, at least from the point of view of the harassment target.

Potential solutions

Now let’s start talking about solutions. First off, let’s see what the best-in-class defense is, given how Mastodon currently works.

Someone who wants to avoid a harassment campaign has a few different options:

  1. Use a private (locked) account
  2. Run their own single-user instance
  3. Move to an instance that uses instance whitelisting rather than blacklisting

Let’s go through each of these in turn.

Using a private (locked) account

Using a locked account makes your toots “followers-only” by default and requires approval before someone can follow you or view those toots. This prevents a large-scale harassment attack, since nobody but your approved followers can interact with you. However, it’s sort of a nuclear option, and from the perspective of a celebrity like Wil Wheaton trying to reach his audience, it may not be considered feasible.

Account locking can also be turned on and off at anytime. Unlike Twitter, though, this doesn’t affect the visibility of past posts, so an attacker could still send harassing replies to any of your previous toots, even if your account is currently locked. This means that if you’re under siege from a sudden harassment campaign that flares up and dies down over the course of a few hours, keeping your account locked during that time is not an effective strategy.

Running your own single-user instance

A harassment target could move to an instance where they are the admin, the moderator, and the only user. This gives them wide latitude to apply instance blocks across the entire instance, but those same instance blocks are already available at an individual level, so it doesn’t change much. On the other hand, it allows them to deal with reports about themselves by simply ignoring them, so it does solve the “report deluge” problem.

However, it doesn’t solve the problem of getting an onslaught of harassing replies from different accounts across the fediverse. Each harassing account will still require a block or an instance block, which are tools that are already available even if you don’t own your own instance.

Running your own instance may also require a level of technical savvy and dedication to learning the ins and outs of Mastodon (or another fediverse technology like Pleroma), which the harassment target may consider too much effort with little payoff.

Moving to a whitelisting instance

By default, a Mastodon instance federates with all other instances unless the admin explicitly applies a “domain block.” Some Mastodon instances, though, such as awoo.space, have forked the Mastodon codebase to allow for whitelisting rather than blacklisting.

This means that awoo.space doesn’t federate with other instances by default. Instead, awoo.space admins have to explicitly choose the instances that they federate with. This can limit the attack surface, since awoo.space isn’t exposed to every non-blacklisted instance in the fediverse; instead, it’s exposed only to a subset of instances that have already been vetted and considered safe to federate with.

In the face of a sudden coordinated attack, though, even a cautious instance like awoo.space probably federates with enough instances that a group of motivated actors could set up new accounts on the whitelisted instances and attack the target, potentially overwhelming the target instance’s moderators as well as the moderators of the connected instances. So whitelisting reduces the surface area but doesn’t prevent the attack.

Now, the target could both run their own single-user instance and enable whitelisting. If they were very cautious about which instances to federate with, this could prevent the bulk of the attack, but would require a lot of time investment and have similar problems to a locked account in terms of limiting the reach to their audience.

Conclusion

I don’t have any good answers yet as to how to prevent another dogpiling incident like the one that targeted Wil Wheaton. But I do have some ideas.

First off, the Mastodon project needs better tools for moderation. The current moderation UI is good but a bit clunky, and the API needs to be opened up so that third-party tools can be written on top of it. For instance, a tool could automatically find the email domains for reported spambots and block them. Or, another tool could read the contents of a reported toot, check for certain blacklisted curse words, and immediately delete the toot or silence/suspend the account.

Second off, Mastodon admins need to take the problem of moderation more seriously. Maybe having a team of moderators living in multiple time zones should just be considered the “cost of doing business” when running an instance. Like security features, it’s not a cost that pays visible dividends every single day, but in the event of a sudden coordinated attack it could make the difference between a good experience and a horrible experience.

Perhaps more instances should consider having paid moderators. mastodon.social already pays its moderation team via the main Mastodon Patreon page. Another possible model is for an independent moderator to be employed by multiple instances and get paid through their own Patreon page.

However, I think the Mastodon community also needs to acknowledge the weaknesses of the federated system in handling spam and harassment compared to a centralized system. As Sarah Jamie Lewis says in “On Emergent Centralization”:

Email is a perfect example of an ostensibly decentralized, distributed system that, in defending itself from abuse and spam, became a highly centralized system revolving around a few major oligarchical organizations. The majority of email sent […] today is likely to find itself being processed by the servers of one of these organizations.

Mastodon could eventually move in a similar direction, if the problems aren’t anticipated and headed off at the pass. The fediverse is still relatively peaceful, but right now that’s mostly a function of its size. The fediverse is just not as interesting of a target for attackers, because there aren’t that many people using it.

However, if the fediverse gets much bigger, it could became inundated by dedicated harassment, disinformation, or spambot campaigns (as Twitter and Facebook already are), and it could shift towards centralization as a defense mechanism. For instance, a centralized service might be set up to check toots for illegal content, or to verify accounts, or something similar.

To prevent this, Mastodon needs to recognize its inherent structural weaknesses and find solutions to mitigate them. If it doesn’t, then enough people might be harassed or spammed off of the platform that Mastodon will lose its credibility as a kinder, gentler social network. At that point, it would be abandoned by its responsible users, leaving only the spammers and harassers behind.

Thanks to Eugen Rochko for feedback on a draft of this blog post.

Should computers serve humans, or should humans serve computers?

The best science fiction doesn’t necessarily tell us something about the future, but it might tell us something about the present.

At its best, sci-fi finds something true about human nature or human society and then places it in a new context, where we can look at it with fresh eyes. Sci-fi helps us see ourselves more clearly.

This is a video made by Microsoft in 2011 that shows one sci-fi vision of the future:

This is a utopian vision of technology. Computers exist to make people more productive, to extend the natural capabilities of our bodies, to serve as a true “bicycle of the mind”. Computers are omnipresent, but they are at our beck and call, and they exist to serve us.

This is a video showing a different vision of the future:

 

This is a dystopian vision of technology. Computers are omnipresent, but instead of enabling us to be more productive or to grant us more leisure time, they exist to distract us, harass us, and cajole us. In this world, the goal of technology is to convince us to buy more things, or to earn points in a useless game, or to send us on odd jobs the computer chose for us.

A similar vision of the future comes from Audrey Schulman’s Theory of Bastards. The protagonist rides a self-driving car, but she can’t turn off the video advertisements because her implant is six months out of date, and so the commands she barks at the car fail with an “unknown” error.

She blames herself for failing to upgrade her implant, in the way you might chide yourself for forgetting to see the dentist.

As the car arrives, she pays for the trip. Then she notes:

“At least in terms of payment, the manufacturers made sure there was never any difficulty with version differences. It was only the actual applications that gradually became impossible to control.”

Between the utopian and dystopian, which vision of the future seems more likely to you? Which vision seems more true to how we currently live with technology, in the form of our smartphones and social media apps?

I know which one seems more likely to me, and it gives me the willies.

The core question we technologists should be asking ourselves is: do we want to live in a world where computers serve humans, or where humans serve computers?

Or to put it another way: do we want to live in a world where the users of technology are in control of their devices? Or do we want to live in a world where the owners of technology use it as yet another means of control over those without the resources, the knowledge, or the privilege to fight back?

Are we building technology for a world of masters, or a world of slaves?

Introducing Pinafore for Mastodon

Today I’m happy to announce a project I’ve been quietly working on for some time: Pinafore. Pinafore is an alternative web client for Mastodon, which looks like this:

Screenshot of Pinafore home page

Here are some of its features:

  • Speed. Pinafore is built on Svelte, meaning it’s faster and lighter-weight[1] than most web apps.
  • Simplicity. Single-column layout, easy-to-read text, and large images.
  • Multi-account support. Log in to multiple instances and set a custom theme for each one.
  • Works offline. Recently-viewed timelines are fully browsable offline.
  • PWA. Pinafore is a Progressive Web App, so you can add it to your phone’s home screen and it will work like a native app.
  • Private. All communication is private between your browser and your instance. No ads or third-party trackers.

Pinafore is still beta quality, but I’m releasing it now to get early feedback. Of course it’s also open-source, so feel free to browse the source code.

In the rest of this post, I want to share a bit about the motivation behind Pinafore, as well as some technical details about how it works.

If you don’t care about technical details, you can skip to pinafore.social or read the user guide.

The need for speed

I love the Mastodon web app, and I’ve even contributed code to it. It’s a PWA, it’s responsive, and it works well across multiple devices. But eventually, I felt like I could make something interesting by rewriting the frontend from scratch. I had a few main goals.

First off, I wanted the UI to be fast even on low-end laptops or phones. For Pinafore, my litmus test was whether it could work well on a Nexus 5 (released in 2013).

Having set the bar that high, I made some hard choices to squeeze out better performance:

  • For the framework, I chose Sapper and Svelte because they offer state-of-the-art performance, essentially compiling to vanilla JavaScript.
  • To be resilient on slow connections, or Lie-Fi, or when offline altogether, Pinafore stores data locally in IndexedDB.
  • To use less memory, Pinafore keeps only a fraction of its UI state in memory (most is stored in IndexedDB), and it uses a fully virtual list to reduce the number of DOM nodes.

Other design decisions that impacted performance:

I also chose to only support modern browsers – the latest versions of Chrome, Edge, Firefox, and Safari. Because of this, Pinafore is able to directly ship modern JavaScript instead of using something like Babel to compile down to a more bloated ES5 format. It also loads a minimum of polyfills, and only for those browsers that need them.

Privacy is key

Thanks to the magic of CORS, Pinafore is an almost purely client-side web app[2]. When you use the Pinafore website, your browser communicates directly with your instance’s public API, just like a native app would. The only job of the pinafore.social server is to serve up HTML, CSS, and JavaScript.

This not only makes the implementation simpler: it also guarantees privacy. You don’t have to trust Pinafore to keep your data safe, because it never handles it in the first place! All user data is stored in your browser, and logging out of your instance simply deletes it.

And even if you don’t trust the Pinafore server, it’s an open-source project, so you can always run it locally. Like the Mastodon project itself, I gave it an AGPL license, so you can host it yourself as long as you make the modified source code available.

Q & A

What’s with the name?

Pinafore is named after my favorite Gilbert and Sullivan play. If you’re unfamiliar, this bit from The Simpsons is a great intro.

Does it work without JavaScript?

Pinafore’s landing page works without JavaScript for SEO reasons, but the app itself requires JavaScript. Although Server-Side Rendering (SSR) is possible, it would require storing user data on Pinafore’s servers, and so I chose to avoid it.

Why are you trying to compete with Mastodon?

Pinafore doesn’t compete with Mastodon; it complements it. Mastodon has a very open API, which is what allows for the flourishing of mobile apps, command-line tools, and even web clients like halcyon.social or Pinafore itself.

One of my goals with Pinafore is to take a bit of the pressure off the Mastodon project to try to be all things to all people. There are lots of demands on Mastodon to make small UI tweaks to suit various users’ preferences, which is a major source of contention, and also partly the motivation for forks like glitch-soc.

But ideally, the way a user engages with their Mastodon instance should be up to that user. As a user, if I want a different background color or for images to be rendered differently, then why should I wait for the Mastodon maintainers or my admin to make that change? I use whatever mobile app I like, so why should the web UI be any different?

As Eugen has said, the web UI is just one application out of many. And I don’t even intend for Pinafore to replace the web UI. There are various features in that UI that I have no plans to implement, such as administration tools, moderation tools, and complex multi-column scenarios. Plus, the web UI is the landing page for each instance, and an opportunity for those instances to be creative and express themselves.

Why didn’t you implement <x feature>?

As with any project, I prioritized some features at the expense of others. Some of these decisions were based on design goals, whereas others were just to get a working beta out the door. I have a list of goals and non-goals in the project README, as well as a roadmap for basic feature parity with the Mastodon web UI.

Why didn’t you use the ActivityPub client-to-server API?

ActivityPub defines both a server-to-server and a client-to-server API, but Mastodon only supports the former. Also, Mastodon’s client-to-server API is supported by other projects like Pleroma, so for now, it’s the most practical choice.

What’s your business model?

None. I wrote Pinafore for fun, out of love for the Mastodon project.

How can I chip in?

I’m a privileged white dude living in a developed country who works for a large tech company. I don’t need any donations. Please donate to Eugen instead so he can continue making Mastodon better!

Thanks!

If you’ve read this far, give Pinafore a try and tell me what you think.

Footnotes

1. Measuring the size of the JavaScript payload after gzip when loading the home feed on a desktop browser, I recorded 333KB for Pinafore, 1.01MB for mastodon.social, and 2.25MB for twitter.com.

2. For the purpose of readable URLs, some minor routing logic is done on the server-side. For instance, account IDs, status IDs, instance names, and hashtags may be sent to the server as part of the URL. But on modern browsers, this will only occur if you explicitly navigate to a page with that URL and the Service Worker hasn’t already been activated, or you hard-refresh. In the vast majority of cases, the Service Worker should handle these URLs, and thus even this light metadata is not sent to the server.

Smaller Lodash bundles with Webpack and Babel

One of the benefits of working with smart people is that you can learn a lot from them through osmosis. As luck would have it, a recent move placed my office next to John-David Dalton‘s, with the perk being that he occasionally wanders into my office to talk about cool stuff he’s working on, like Lodash and ES modules in Node.

Recently we chatted about Lodash and the various plugins for making its bundle size smaller, such as lodash-webpack-plugin and babel-plugin-lodash. I admitted that I had used both projects but only had a fuzzy notion of what they actually did, or why you’d want to use one or the other. Fortunately J.D. set me straight, and so I thought it’d be a good opportunity to take what I’ve learned and turn it into a short blog post.

TL;DR

Use the import times from 'lodash/times' format over import { times } from 'lodash' wherever possible. If you do, then you don’t need the babel-plugin-lodash. Update: or use lodash-es instead.

Be very careful when using lodash-webpack-plugin to check that you’re not omitting any features you actually need, or stuff can break in production.

Avoid Lodash chaining (e.g. _(array).map(...).filter(...).take(...)), since there’s currently no way to reduce its size.

babel-plugin-lodash

The first thing to understand about Lodash is that there are multiple ways you can use the same method, but some of them are more expensive than others:

import { times } from 'lodash'   // 68.81kB  :(
import times from 'lodash/times' //  2.08kB! :)

times(3, () => console.log('whee'))

You can see the difference using something like webpack-bundle-analyzer. Here’s the first version:

Screenshot of lodash.js taking up almost the entire bundle size

Using the import { times } from 'lodash' idiom, it turns out that lodash.js is so big that you can’t even see our tiny index.js! Lodash takes up a full parsed size of 68.81kB. (In the bundle analyzer, hover your mouse over the module to see the size.)

Now here’s the second version (using import times from 'lodash/times'):

Screenshot showing many smaller Lodash modules not taking up so much space

In the second screenshot, Lodash’s total size has shrunk down to 2.08kB. Now we can finally see our index.js!

However, some people prefer the second syntax to the first, especially since it can get more terse the more you import.

Consider:

import { map, filter, times, noop } from 'lodash'

compared to:

import map from 'lodash/map'
import filter from 'lodash/filter'
import times from 'lodash/times'
import noop from 'lodash/noop'

What the babel-plugin-lodash proposes is to automatically rewrite your Lodash imports to use the second pattern rather than the first. So it would rewrite

import { times } from 'lodash'

as

import times from 'lodash/times'

One takeway from this is that, if you’re already using the import times from 'lodash/times' idiom, then you don’t need babel-plugin-lodash.

Update: apparently if you use the lodash-es package, then you also don’t need the Babel plugin. It may also have better tree-shaking outputs in Webpack due to setting "sideEffects": false in package.json, which the main lodash package does not do.

lodash-webpack-plugin

What lodash-webpack-plugin does is a bit more complicated. Whereas babel-plugin-lodash focuses on the syntax in your own code, lodash-webpack-plugin changes how Lodash works under the hood to make it smaller.

The reason this cuts down your bundle size is that it turns out there are a lot of edge cases and niche functionality that Lodash provides, and if you’re not using those features, they just take up unnecessary space. There’s a full list in the README, but let’s walk through some examples.

Iteratee shorthands

What in the heck is an “iteratee shorthand”? Well, let’s say you want to map() an Array of Objects like so:

import map from 'lodash/map'
map([{id: 'foo'}, {id: 'bar'}], obj => obj.id) // ['foo', 'bar']

In this case, Lodash allows you to use a shorthand:

import map from 'lodash/map'
map([{id: 'foo'}, {id: 'bar'}], 'id') // ['foo', 'bar']

This shorthand syntax is nice to save a few characters, but unfortunately it requires Lodash to use more code under the hood. So lodash-webpack-plugin can just remove this functionality.

For example, let’s say I use the full arrow function instead of the shorthand. Without lodash-webpack-plugin, we get:

Screenshot showing multiple lodash modules under .map

In this case, Lodash takes up 18.59kB total.

Now let’s add lodash-webpack-plugin:

Screenshot of lodash with a very small map.js dependency

And now Lodash is down to 117 bytes! That’s quite the savings.

Collection methods

Another example is “collection methods” for Objects. This means being able to use standard Array methods like forEach() and map() on an Object, in which case Lodash gives you a callback with both the key and the value:

import forEach from 'lodash/forEach'

forEach({foo: 'bar', baz: 'quux'}, (value, key) => {
  console.log(key, value)
  // prints 'foo bar' then 'baz quux'
})

This is handy, but once again it has a cost. Let’s say we’re only using forEach for Arrays:

import forEach from 'lodash/forEach'

forEach(['foo', 'bar'], obj => {
  console.log(obj) // prints 'foo' then 'bar
})

In this case, Lodash will take up a total of 5.06kB:

Screenshot showing Lodash forEach() taking up quite a few modules

Whereas once we add in lodash-webpack-plugin, Lodash trims down to a svelte 108 bytes:

Screenshot showing a very small Lodash forEach.js module

Chaining

Another common Lodash feature is chaining, which exposes functionality like this:

import _ from 'lodash'
const array = ['1', '2', '3', '4', '5', '6', '7', '8', '9', '10']
console.log(_(array)
  .map(i => parseInt(i, 10))
  .filter(i => i % 2 === 1)
  .take(5)
  .value()
) // prints '[ 1, 3, 5, 7, 9 ]'

Unfortunately there is currently no good way to reduce the size required for chaining. So you’re better off importing the Lodash functions individually:

import map from 'lodash/map'
import filter from 'lodash/filter'
import take from 'lodash/take'
const array = ['1', '2', '3', '4', '5', '6', '7', '8', '9', '10']

console.log(
  take(
    filter(
      map(array, i => parseInt(i, 10)),
    i => i % 2 === 1),
  5)
) // prints '[ 1, 3, 5, 7, 9 ]'

Using the lodash-webpack-plugin with the chaining option enabled, the first example takes up the full 68.81kB:

Screenshot showing large lodash.js dependency

This makes sense, since we’re still importing all of Lodash for the chaining to work.

Whereas the second example with chaining disabled gives us only 590 bytes:

Screenshot showing a handful of small Lodash modules

The second piece of code is a bit harder to read than the first, but it’s certainly a big savings in file size! Luckily J.D. tells me there may be some work in progress on a plugin that could rewrite the second syntax to look more like the first (similar to babel-plugin-lodash).

Edit: it was brought to my attention in the comments that this functionality should be coming soon to babel-plugin-lodash!

Gotchas

Saving bundle size is great, but lodash-webpack-plugin comes with some caveats. By default, all of these features – shorthands for the iteratee shorthands, collections for the Object collection methods, and others – are disabled by default. Furthermore, they may break or even silently fail if you try to use them when they’re disabled.

This means that if you only use lodash-webpack-plugin in production, you may be in for a rude surprise when you test something in development mode and then find it’s broken in production. In my previous examples, if you use the iteratee shorthand:

map([{id: 'foo'}, {id: 'bar'}], 'id') // ['foo', 'bar']

And if you don’t enable shorthands in lodash-webpack-plugin, then this will actually throw a runtime error:

map.js:16 Uncaught TypeError: iteratee is not a function

In the case of the Object collection methods, it’s more insidious. If you use:

forEach({foo: 'bar', baz: 'quux'}, (value, key) => {
  console.log(key, value)
})

And if you don’t enable collections in lodash-webpack-plugin, then the forEach() method will silently fail. This can lead to some very hard-to-uncover bugs!

Conclusion

The babel-plugin-lodash and lodash-webpack-plugin packages are great. They’re an easy way to reduce your bundle size by a significant amount and with minimal effort.

The lodash-webpack-plugin is particularly useful, since it actually changes how Lodash operates under the hood and can remove functionality that almost nobody uses. Support for edge cases like sparse arrays (guards) and typed arrays (exotics) is unlikely to be something you’ll need.

While the lodash-webpack-plugin is extremely useful, though, it also has some footguns. If you’re only enabling it for production builds, you may be surprised when something works in development but then fails in production. It might also be hard to add to a large existing project, since you’ll have to meticulously audit all your uses of Lodash.

So be sure to carefully read the documentation before installing the lodash-webpack-plugin. And if you’re not sure if you need a certain feature, then you may be better off enabling that feature (or disabling the plugin entirely) and just take the ~20kB hit.

Note: if you’d like to experiment with this yourself, I put these examples into a small GitHub repo. If you uncomment various bits of code in src/index.js, and enable or disable the Babel and Webpack plugins in .babelrc and webpack.config.js, then you can play around with these examples yourself.

Decentralized identity and decentralized social networks

I’d like to tell you a story about Bob. Bob is a fairly ordinary, upstanding citizen. Bob also has a lot of hobbies.

Bob is a good father, so one of his hobbies is to coach his son’s little-league team. Bob is careful to enforce a certain set of rules during the games and at the after-game pizza parties. If one of the kids uses a curse word or bullies another kid, Bob is expected to intervene and apply the appropriate discipline.

Bob is also a Christian. When he’s in church on Sundays, there’s another set of rules, both implicit and explicit, that Bob is expected to abide by. For instance, it’s okay for Bob to confide in other churchgoers about his momentary lapses of faith, or about his struggles to understand certain Bible passages. But if Bob started quoting Richard Dawkins or loudly preaching atheism, he’d probably create a very awkward scene, and may even get kicked out of church.

Bob also happens to be a vegetarian, and he attends a monthly vegetarian meetup. Within this group, there’s an entirely different set of rules and norms at play. Bob is careful not to talk too much about his favorite recipes involving cheese, eggs, or honey, because he knows that there’s a sizable minority of vegans in the group who may be offended. It would also be completely unacceptable to talk about a juicy steak dinner, even though this topic of conversation may be perfectly acceptable within the church or the little-league team.

Bob also has a set of old college buddies that he occasionally meets up with at the local bar. Here, once again, an entirely different set of norms apply. Raunchy jokes and curse words are not only allowed – they’re encouraged. Open debate about religion is tolerated. Bob may even be able to let his vegetarian guard down and talk about a delicious steak dinner he ate in a moment of weakness.

One Bob out of many

Bob intuitively understands these different norms and contexts, and he effortlessly glides from one to the other. It’s as if there’s a switch in his brain that activates as soon as he walks through the church doors or into the bar.

Furthermore, nobody accuses Bob of being dishonest or duplicitous for acting this way. In fact, everything described above is such a fundamental, everyday part of the human experience that it’s downright boring.

Now Bob goes online. Suddenly, every social network is telling him that he should have exactly one identity, speak in one voice, and abide by one set of rules. Mark Zuckerberg says, “Having two identities for yourself is an example of a lack of integrity.” OKCupid says, “We want you […] to go by who you are, and not be hidden beneath another layer of mystique.” Eric Schmidt says, “If you have something that you don’t want anyone to know, maybe you shouldn’t be doing it in the first place.”

Bob is apparently expected to use his real name, and use one account, and present a single public face for every possible context and social situation.

Intuitively, Bob knows this is bullshit. We all know it’s bullshit. But in the online world, we’ve just learned to put up with it.

Identity on social networks

Now let’s step away from Bob for a moment and talk about how the rest of us deal with this problem.

One of the common coping mechanisms is to fracture ourselves into different silos. We use Slack to talk to our coworkers, Discord to chat with our gamer buddies, LinkedIn for professional talk, Twitter for talking about the news, Facebook for talking with our family, and so on. Folks who follow this strategy may use a completely different voice in each platform and may not even reveal their real names.

With decentralized social networks, though, the situation gets more interesting. On platforms like Mastodon, Pleroma, GNU Social, postActiv, and others, you sign up for a particular “instance” representing a self-contained community. This community may have its own rules, its own culture, and even its own emojis and theme color.

However, each instance isn’t walled off from the outside world. Instead, it has tendrils that can reach into any other community it may be connected to. It’s less like the isolated silos of Facebook, Twitter, and Slack, and more like a cluster of small towns with some well-traveled roads between them.

Some folks look at Mastodon as a mere replacement for Twitter. Maybe for them it’s Twitter for lefties, or Twitter for anime artists, or Twitter for a nationalist agenda. It’s really none of these things, though, and I think importantly it has the potential to address one of the biggest problems with online identity: context collapse.

Context collapse

“Context collapse” was first coined by danah boyd, and a good description of it can be found in a blog post by Michael Wesch.

The basic idea is this: when human beings converse in person, we use a wide variety of unwritten rules to govern the acceptable boundaries of the conversation. We pick up on subtle nonverbal cues such as someone’s posture, their hand gestures, and their degree of eye contact to choose the right “register” for the conversation. We might even switch between different dialects of the same language, depending on who we’re talking to (linguists call this “code-switching”).

All of this happens automatically and intuitively, and it’s a valuable tool for avoiding ambiguities and misunderstandings. There are entire subfields of linguistics that study how humans communicate this way, such as pragmatics and sociolinguistics.

Online, we have none of this context. Staring into the webcam or into the textbox on a social media site, we are simultaneously addressing everyone and no one, for now and for all time. Factor in character limits, upload limits, and just the limits of human attention, and this is a ripe environment for misunderstandings. Sarcasm, facetiousness, irony, playful ribbing between friends – all of it can be lost on your audience if they don’t have the proper context to guide them.

Here are some of the symptoms of context collapse that you may have experienced:

  • jokes are misunderstood and taken at face value
  • in-jokes between friends are perceived as harassment by outsiders
  • you accidentally offend someone when no offense was intended
  • something you say is taken out of context and used for dogpiling
  • you feel like you have to censor yourself online
  • you agonize over every character and punctuation mark to avoid misinterpretation

All of these situations can be frustrating or even harmful to your mental health. Consider Justine Sacco’s poorly-received joke that cost her her job and brought her a lot of mental anguish.

Fracturing ourselves into siloed social networks, in its own ham-handed way, offers a solution to this problem. Instead of just hoping that our readers will pick up on the context, we rely on the context granted by the social network itself. Discord is for gamers, LinkedIn is for professionals, Slack is for coworkers, etc.

But on decentralized social networks, we may have a more elegant solution to this problem, and one that doesn’t require locking up our identities into various proprietary silos.

Solving context collapse on decentralized social media

The notion that you should use a single identity online is, I believe, a holdover from the centralized social media sites. Their goal is to get you to reveal as much information about yourself as possible (to sell it to advertisers), so of course they would discourage you from having multiple accounts or from concealing your real name. But that doesn’t mean decentralized social networks need to be the same.

Instead of treating your identity “on Mastodon” or “on the fediverse” as a single entity, what if you had multiple identities on multiple instances, and you treated them as distinct? What might that look like?

I figured this out myself over the past year or so, as I largely split my online identity on Mastodon into two accounts: @nolan@mastodon.social and @nolan@toot.cafe.

The tone of the two accounts is completely different. @nolan@mastodon.social makes silly jokes and mostly writes in all lowercase. @nolan@toot.cafe talks about software, programming, and his day job, and tends to use proper punctuation. (It’s more like the voice of this blog.)

The reason for this split is partly historical. @nolan@mastodon.social tends to speak only in jokes because it was my first Mastodon account, and when I signed up I didn’t reveal my full name or tie it back to my real-world identity. Instead, I just tried to have fun, making as many silly jokes as I could and seeing what landed and what didn’t. I’d say I did fairly well, since at one point I had the most-favorited Mastodon post of all time and got quoted twice in this article on Mastodon.

Screenshot of Mastodon post saying "mom: hey son I joined this new Mastodon thing me: oh shit mom, I coulda helped you find a server, which one did you choose? mom: well I liked the privacy policy on satanic.bikerladi.es but then communist.blaze.party had the shortest ping latency so"

When I set up my own instance, though, things started to get complicated. Now I had an admin account, @nolan@toot.cafe, and I needed to talk about serious admin stuff: when was the server going down for maintenance, what was our privacy policy, what was our moderation policy, etc. So for that account, I switched to my professional voice so that folks could understand that I wasn’t joking or being sarcastic.

But I still had @nolan@mastodon.social for the silly stuff. And the more I used it, the more I found that I liked the split. People who followed me on @nolan@mastodon.social didn’t necessarily care about Mastodon admin topics (memory usage, systemd, Ruby, etc.) – maybe they only followed me for the fun stuff. Likewise, people who followed me on @nolan@toot.cafe maybe just wanted to keep up-to-date on Mastodon admin and development (especially as I started contributing to the Mastodon codebase itself), and didn’t care for the jokes.

Keeping my identities separate thus served a few purposes:

  • I could have fun with people who didn’t know or care about tech topics (e.g. my wife, who loves my jokes but finds tech boring).
  • Nobody had to wonder when I was being sarcastic and when I was being serious.
  • People who followed me for tech stuff didn’t have to put up with my jokes if they didn’t like my sense of humor.
  • People who liked both my jokes and my tech talk could still follow me on both accounts.

This process wasn’t without its hurdles, though. At one point I was using fairly similar avatars for each account:

Screenshot of two Mastodon avatars, one with a subtle coffee icon and one without

My original Mastodon account avatars. Could you tell the difference between the two?

Eventually, though, I got tired of people not picking up on the sarcasm in my joke account. So I switched to an avatar that could only be interpreted as something silly:

Picture of a Mastodon avatar that looks like Ogmo from the Jumper game but handrawn, a silly face with bug eyes

My new, unambiguously “zany” Mastodon avatar.

Taking this avatar seriously would be like arguing with the “We Rate Dogs” account on Twitter. The new avatar makes the intent of the account much clearer.

Am I being duplicitous? No, I link between the two accounts on my profile pages, so everyone can figure out that both accounts are me.

Is it hard to juggle two different accounts? No, I use separate browser tabs, and since toot.cafe has its own theme color, it’s easy for me to remember which site I’m on.

Screenshot of Mastodon toot saying "tfw I have to switch from my joke account to my serious account to boost a toot, to make it clear I am not boosting ironically"

Is it hard for others to know which Nolan to talk to? Well, sort of. When my wife wants to post something like “@nolan said to me today…” she tends to use my @nolan@mastodon.social account because she has more fun interacting with that account than with my serious one. But other than that, I haven’t really run into any problems with this system.

Previously, I was also running a French-language account at @nolan@mastodon.xyz, but I found this a bit hard to manage. I didn’t have a network of French-speaking friends I was regularly talking to, and most of the francophones on Mastodon can speak English anyway. Also, managing three social media accounts was just a bit too much of a time investment for me.

Instance policies and identity

Right now I have a simple two-account system, and my choice of instance for each account is fairly arbitrary. (Although toot.cafe is somewhat tech- and programming-themed, so talking about computery stuff there feels very natural.) However, you could imagine tailoring an account to its home instance, based on the instance’s theme or moderation policies.

Going back to the Bob example, let’s imagine that Bob sets up four instances:

  1. An instance for his son’s little-league team, which is closed off from most of the fediverse via whitelisting and has very strict moderation policies to ensure it stays kid-friendly. All of the parents have moderator accounts.
  2. An instance for his church group. The moderation policies reflect Christian values, and although you can talk openly about your faith, it’s advised to use Content Warnings for controversial topics.
  3. An instance for his vegetarian meetup. You’re encouraged to take pictures of your food, but pictures of meat dishes are strictly off-limits. Vegetarian (non-vegan) food photos are okay, but should be hidden behind a “sensitive” tag.
  4. A free-for-all instance for his drinking buddies. Anything goes, say whatever racy or off-color joke pops into your head, but be aware of the consequences – such as the fact that other instances might not want to federate with you. You might also want to use a pseudonym here instead of your real name.

Bob could create a separate account on all four instances, and he might speak in a very different voice on each of them. If he’s an admin or a moderator, he may even enforce very different policies, and he might choose different instances to block or silence. In fact, one of his instances may even block the other! Via whitelisting, the kid-friendly one certainly blocks the drinking-buddies instance.

Bob’s not doing anything wrong here. He’s not a hypocrite. He’s not being deceitful. He’s just taking exactly the same logic that we use in the real world, and applying it to the online world.

Conclusion

It’s unreasonable to expect people to speak in the same voice in every social setting offline, so it’s equally unreasonable to ask them to do it online.

In the world of centralized social networks, users have responded to “real name policies” and “please use one account” by fracturing themselves into different proprietary silos. On decentralized social networks, we can continue fracturing ourselves based on instances, but these disparate identities are allowed to comingle a bit, thanks to the magic of federation.

I don’t expect everyone to use the same techniques I use, such as having a joke account and a serious account. For some people, that’s just too much of an investment in social media, and it’s too hard to juggle more than one account. But I think it’s a partial solution to the problem of context collapse, and although it’s a bit of extra effort, it can pay dividends in the form of fewer misunderstandings, fewer ambiguities, and less confusion for your readers.