The problem with the problems with hashtags

16 years after their invention, is it time for a change?

I published my thoughts on Bluesky’s proposals for how the decentralized network might tackle hashtags about a month ago. Days later, Threads launched (notably without hashtags, an omission I dutifully pointed out to Mark Zuckerberg).

Gradually I discovered that people on Threads tended to be skeptical-to-hostile towards hashtags, likely due to hashtag abuse on Instagram.

As I’ve come to understand it, here’s how hashtags went awry:

Hashtags are a kind of temporary autonomous zone — a disposable, digital context from which people came and went to coordinate around a specific event or moment — often connected through IRL experiences. Indeed, back when social media was smaller and more intimate, tracking events called BarCamps was the hashtag’s original use case.

But that was a simpler time.

As the popularity of social media grew, platforms established new aggregated contexts like search and trending topics to help people explore everything going on. These spaces relied on algorithms to sort through and rank vast swathes of data. Since algorithms are just math, marketers (and spammers) figured out how to make their content look more appealing to the algos. Spamming hashtags proved one reliable method, since algos couldn’t easily discern appropriate from parasitic hashtags.

What worked for our Twitter town square didn’t work when it became Times Square.

Skip to the end for six ideas to improve hashtags on platforms like Mastodon.

Eugen Rochko responded to this post to clarify that only hashtags preceded by a new line will be moved to the hashtag bar, nullifying the specifics of the #OldManMessina example below. Additionally, Vince Aggrippino comment was not accurate. I’ve made adjustments accordingly.

The hashtag turns 16 in two weeks — and for the most part, hashtag creation hasn’t changed: you type a # character immediately followed by a word or phrase without spaces; you publish, and any added hashtags are turned into links.

Simple. Optional. Unobtrusive. Sufficiently dumb.

Eugen Rochko, Mastodon’s founder and lead developer, just pushed out a big change to how hashtags work on Mastodon that — as the upstream software provider in a growing network of decentralized social hubs, may have significant downstream impact on the humble hashtag.

Soon, Mastodon “toots” will start to look more like Tumblr posts, inspired by a proposal from Matt Birchler. This change would also represent an example in the wild of Paul Frazee’s proposal for Bluesky to “visually separate the tags”):

With this change, hashtags that appear at the end of a post will be slurped out and spat into a dedicated “hashtag bar” below the post. Seven hashtags will be visible by default, with any overflow hidden behind a tap or click:

Rochko’s justification for this change presumedly is meant to address feedback he’s received from the community (but doesn’t cite):

People will often put all of the hashtags relevant to the post at the end of the post, but it looks spammy. Others avoid using hashtags this way because it looks spammy, and therefore lose out on discoverability.

Considering the solution he proposes, I assume he infers that when hashtags clump at the end of a post, the author isn’t intending for them to be read as content, but instead used as metadata. They happen to be visible because there’s no dedicated field for them.

The second problem flows from the first: because people want to avoid the appearance of spamminess, they avoid using hashtags. Since their posts then lack useful keywords, their content ends up with less reach because it’s less likely to appear in trending topics or search results. This sucks for authors who otherwise want their content to pollinate the federated feeds of hashtagged content traversing the Mastoverse.

Rochko’s solution is to leave hashtag creation alone, but to slough off trailing hashtags into the “hashtag bar”, so they’ll appear visually distinct from the main content and either ignored (e.g. hidden in the UI) or glossed over (e.g. by screen readers).

But not everyone uses hashtags in the same way.

Rochko inference (made on behalf of all Mastodon users) leads to imposing a singular design on everyone, possibly resulting in frustration and tears, and not necessarily more or better hashtag metadata.

As Vince Aggrippino posits points out, this may actually lead to increased hashtag abuse:

Author’s note: it turns out that the ActivityPub, Mastodon’s underlying protocol, allows tags to be added to posts without requiring that they be presented to the post’s audience. Rochko’s change will cause these hidden tags to be surfaced for the first time. Overflow tags contained within the body of a post may still be rendered in the hashtag bar, hidden by default.

I do understand and appreciate Rochko’s approach given the incrementalist constraints he’s imposed on himself, this change is a misguided compromise. Other, creator-first approaches would be better, and cut a path towards better overall outcomes.

Should form triumph over function?

Hashtags were designed to pass the “drunk test” — that is, if the creator (me) has had a few drinks (say, at an event like SXSW) they’ll still (hopefully) remember to add #sxsw to their posts—so they can be routed appropriately or searched for (and deleted) later. In dynamic, frenetic contexts, we need a non-fiddly means to label posts without having to futz with complex interfaces. I dunno if you’ve checked out Instagram’s composer lately, but it basically looks like this:

Not kidding (each of those lines with a > leads to a secondary interface that must also be navigated):

My hashtag design intentionally cared less for the audience, prioritizing creator experience because people, by and large, are lazy, calorie-preserving creatures. Even though our brains only represent around 2% of our total body mass, it consumes 20% of our daily energy spend. Generalizing, people want to spend as little marginal cognition using technology than with the benefits (real or perceived) they receive. Get in, get out; move on.

By capitalizing on this behavioral axiom and embracing essentialism, Twitter brought social media into the real world. Twitter’s posting UI asked a simple question (“What are you doing?”) and dispensed with all the cruft and complexity that had infected desktop publishing software.

But at 16, perhaps it’s time for the hashtag to grow up?

Rochko’s proposed design does one thing right by creators: they don’t need change what they do. They can add as many hashtags at the end of their posts and the software will “take care of it”.

But this prioritizes form over function. He says it himself: “hashtags at the end of posts look spammy”.

Hashtags were defiantly never concerned with how they looked, but how easy they were to create.

Rochko’s design will interfere with creators’ intentions — at least some of the time. And in those cases, his approach is regressive.

But as the software maker, Rochko is free to change to make this change, and in giving greater priority to how hashtags look, he has revealed hashtags to be linguistic qubits, which act as content or metadata—or both— depending on their superposition in creators’ and readers’ experiences.

So the question remains: is it possible to rebalance the interest of both, while preserving the hashtag’s ability to fulfill the role it performs?

Fixing the problem with the problem with hashtags

The problem with the problem with hashtags is that solving any of the hashtag’s problems invariably results in other problems.

Getting people to add metadata — at scale — to their posts on social media is hard. Most won’t be bothered (see above: drunk test). But at least for those who do (well intentioned and spammers alike), there’s the potential benefit of increased reach and visibility.

In comparison, ask the folks advocating for adding ALT text to images to improve accessibility. Even with dedicated interfaces for adding ALT tags on most of the major platforms, it’s still a slog, especially if you’re a prolific poster of images. So rare is voluntary contribution of this kind of content that Facebook automatically generates it on behalf of users.

And so one might ask: well, should that tactic be used for other metadata? And for hashtags in particular? Perhaps! (This is also not a new idea, but no major platform has rolled out this feature except LinkedIn).

But if we’re going to attempt to fix the problem with the problem with hashtags, then we 1) should not make things worse and 2) should not fix what isn’t broken. That leaves us with 3) support creators in adding relevant hashtags [and other metadata] more easily and 4) rewarding those who do.

Should we get those things right, then we 5) benefit everyone else in the system with clearer and more accurate metadata.

Squeezing the complexity balloon 🎈

Rochko’s change moves hashtags from the end of a post to a dedicated area below, showing the first seven tags and hiding the rest behind a click: e.g. “…and 22 more.”

Creators don’t have a choice. If they don’t want their hashtags to be hidden, I presume they’ll probably just add some text (or maybe even a period) after the last hashtag and get around the current implementation.

Over on Bluesky where hashtags aren’t implemented yet, this kind of workaround is already in play: creators pick an emoji and then create a custom feed to filter content as if they were using hashtags conventionally (e.g. the What’s Science feed filters posts with that contain the 🧪 emoji).

Perhaps only the highly motivated will attempt to circumvent Rochko’s change, but regardless, this isn’t an attempt to address the underlying incentives that lead to hashtag stuffing and abuse in the first place, nor does it do anything to curtail it. Instead, it merely squeezes complexity from one end of the balloon to the other —in the form of the “hashtag bar”.

Time for a drink? 🍸️

Move slow and make things… better?

I don’t want to have a knee-jerk reaction every time some platform decides to mess with hashtags, avoids them altogether, or attempts to tweak the recipe. I don’t intend to play hashtag gatekeeper — especially because the hashtag was intended to route around the incumbent gatekeepers!

However, when I see changes that appear to not fully consider the full spectrum of ramifications, I feel it is my duty to speak out, as the keeper of the hashtag flame, as as someone who has probably thought about hashtags longer than anyone else.

And in this case—surprise! — I don’t think Rochko’s changes go far enough!

Indeed, the proposed changes are relatively straightforward and can already be reviewed in Mastodon v4.2.0b1. That’s the essential benefit of benevolent dictatorships: when the dictator makes a decision they can cut through otherwise endless debate and just ship it.

But here I think he should go farther and better consider the problem(s) with hashtags that are worth solving and given priority.

If Threads is going to adopt ActivityPub and federate in 2024, then now is a chance for the decentralized social web community to set some intentional directions — when it comes to capturing and expressing helpful metadata that improves content routing and accessibility.

Threads hasn’t adopted hashtags yet (although Instagram chief Adam Mosseri has pledged that they will) and when they do, Mastodon’s implementation could help inform their approach. Even a fraction of Threads’s 100M users a launch will make a material impact on the fediverse, and I’d prefer that newly federated Threads users be impressed and delighted by the ease of use, thoughtfulness, and inclusivity of the design of fediverse apps compared with the product out of Menlo Park. But that means we have our work cut out for us.

And so that end, as a boy likes to dream, here’re some birthday wishes for the hashtag’s 16th year.

Six birthday wishes for the hashtag’s 16th year 🎂

1. Make automatic processing opt-on

Let’s start where we began.

My biggest complaint about Rochko’s change is that, with the stroke of his benevolent dictator’s pen, he’s changes the experience of hashtags for everyone, without having obtained their consent.

Sometimes such a drastic change is warranted —especially if people are at risk— but in this case, form pulled a fast one on function.

I thought it might take some time for me to run into a situation where this change would interfere in my content, but it took all but a day:

This example demonstrates how hashtags act as both content and metadata, and that if you only assume the latter, then you actually change the meaning of a post.

In this case, I intend to share some amusing (to me, anyway) images from Can of Soup, a new generative art app, and will use the hashtag #OldManMessina to label related images. But if the tag is moved to the end of the post, then people are likely to miss it, and won’t understand what I mean by “Starting a series…”

And so in this simple example, I can demonstrate that auto-slurping hashtags should be an opt-in choice, which should be attractive for those who go wild with their hashtags but want to spare their audience assault by visual graffiti. In fact, Rochko identified this constituency in his rationale and yet neglected them in the design of this solution… Did he reach out to any of the folks who frequently use more than 7 hashtags per post? Were they in favor of this solution? I have no idea, but it seems like he should have broadened his sampling aperture to find out?

Author’s note: Eugen Rochko responded to clarify that only hashtags preceded by a new line will be moved to the hashtag bar. The #OldManMessina tag in my post would not be moved because it does not appear on its own line at the end of the post.

Regardless — coupled with the next suggestion about earned reputation, moving to an opt-in model for this change would allow individuals to decide for themselves whether this feature improves their content, and would allow instances to decide which hashtag presentation default would work best for their community (i.e. Pixelfed might choose to default to autohiding hashtags). But there’s really no need to drive this through executive fiat.

2. Lean into reputation and verification to thwart abuse

As much as I’m about dismantling sclerotic gatekeeping regimes, I also recognize the value of durable mechanisms for earning equitable reputation, demonstrating verifiable association (e.g. to an established organization or institution), and authenticating aspects of identity.

Were a reputation system established for the fediverse (akin to Technorati Authority?), certain features could be gated at the instance level by verification or reputation. Members with low scores could use all the tags they wanted to their posts, enjoying freedom of speech without the privilege of reach.

Distributed trust networks could develop both between instances as well as third party validators (again, like Technorati of yore). This could incentivize positive contributions and penalize abuse.

I accept that this area can be rather thorny, but if we’re considering the problem with the problem with hashtags more holistically — then this addresses misaligned incentives that benefit those who spam trending topics, and the like.

3. Optimize hashtags for local instances

As Dave Grohl said, the sky is a neighborhood, and posts from members of the same Mastodon instances should be amplified as though come from the zip code.

To wit, the premise of the fediverse is to disaggregate the crazy-making context-collapsing centralization that the Web 2.0 Social wrought. Let’s Jane Jacobs this situation and reinvigorate smaller, more resilient hubs of digital sociality. Local instance hashtag usage can provide discovery and coherence between neighbors, not unlike the way Nextdoor provides social architecture at the scale of physical neighborhoods. This would restore the hashtag’s utility in uniting conversations that are timely, relevant, and pertinent to the theme or subcultures of the Mastodon instance.

Wade into the broadcast noise of global hashtag feeds if you dare, but Mastodon should promote liberal use of hashtags in local instances, and treat global feeds late night TV drivel.

Let’s give everyone the chance to experience the serendipity and usefulness that hashtags offered in the early days of the social web by making them work really well for bespoke Mastodon instances.

4. Elevate metadata creation with first class user experiences

I know I gave Instagram shit for the complexity of its New Post UI, but at least it puts everything that you might add to a post on roughly the same level of hierarchy. This might mean there’s a lot to look at, but it also means that it’d be harder to miss extended metadata like ALT info or hashtags.

Let’s provide tooling suitable to this elevated station. Make it effortless to add hashtags (with pronunciation hints for speech readers), ALT text, location information, and other tagging data to posts — and preserve its portability in any API or exported data formats.

Facebook pioneered viral friend tagging years ago — and that basic concept can be extended to near real-time contexts with hashtags. Give people tools to tag people, objects, products, hashtags, events, and more (with the necessary anti-abuse moderation filters). And then surface that information to developers, users, searchers, and others to build and remix feeds that represent their interests (as Bluesky is doing with composable moderation).

5. Crowdsourced accessibility

Authors of books benefits from libraries, but they don’t necessarily staff them. Similarly, everyone benefits from making content more accessible, but it need not only be original content creators who add accessibility hints. Don’t mishear me: I’m not exempting creators, but instead suggesting that others within a community might be willing to contribute this information, which can be approved by the original author, just as librarians do in cataloging, sorting, and maintaining references that enhance access for all.

Pre-Elon Twitter Community Notes (né Birdwatch) presented a robust, Wikipedia-style open source data approach to soliciting annotations to help contextualize public content, and a similar open model could be applied to ALT image content and hashtag pronunciations (e.g. how a speech reader should properly read #susanalbumparty).

6. In the fediverse, err on the side of creators

Mastodon gets dumped on for its steep usability curve, understandably. Designing to preserve choice and freedom is never easy, and requires compromises that freedom-denying (i.e. “centralized”) software can avoid. But defaults matter, as does informed consent, and it’s critical that Mastodon continue to improve its user experience for all comers. That is, one assumes, why Rochko made this change to hashtags in the first place.

Generally, software defaults should support maximal generativity with a sufficiently graduated learning curve. Put another way, you should be able to make cool shit with just the right amount of learning and effort.

The core loop of a product should be discoverable, enjoyable, and fun to learn. Then, as mastery develops, more powerful and complex functionality should emerge in a natural cadence.

Consider search. Searching for a word or phrase on a platform like Mastodon should first source content locally and then backfill from the wider fediverse. Bonus points for taking into consideration social graph proximity and personal relevance. Savvy searchers should be able to add context filters to help them hone in on whatever they’re seeking — especially using hashtags and other kinds of metadata, language, date ranges, or content types. Twitter’s advanced search is quite robust — and would be amazing to see Mastodon replicate:

Another example is how creator’s tags are handled. As in my #OldManMessina example above, hashtags are used in inventive and idiosyncratic ways. As their use is not monolithic, Mastodon should not attempt to impose normalization where uniformity doesn’t exist!

BUT — giving creators reasonable choices over how they prefer to create tags and whether they are displayed prominently or discretely to their audience empowers them. Such an approach seems broadly aligned with Mastodon’s ethos of self-determination.

To make this more concrete, I would point to Day One’s approach — which indexes the hashtags you use inline while also offering a tagging interface that allows keeping tags out of the content completely:

As far as creator preferences go, there is no conflict: hashtag users and hashtag abolishers alike can enjoy their preferred flavor without encroaching on the other. Day One supports both harmoniously.

I’d like to see Mastodon consider this approach — leaving the decision to move hashtags out of band up to creators first, with instance owners able to set the default. Changing how hashtags work should require proactive consent, and upon roll-out, there should be an in-product notification that the option now exists.

But I see no reason to make this change unilaterally on Mastodon, or anywhere.

Not while there are bigger fish to fry that could meaningfully improve the benefits and use of hashtags. If we’re going to make changes like this, let’s be intentional. The hashtag hasn’t survived nearly 16 years — as long as Twitter did — to be messed with impulsively.