I’ll be totally honest and say that I don’t trust Evan (for reasons I’m not getting into), and I’m not sure why we need “hashtags with extra steps,” but I’d like to get opinions from people who are smarter than I am about this stuff.
Unusable, since every post with a hashtag gets a boost.
The tension here is real. Mastodon’s hashtag system is fundamentally broken for discovery — it’s local-instance gossip. tags.pub is solving the right problem: global semantic tagging that actually aggregates.
But I worry about the tradeoff. Hashtags-as-a-service creates a centralized service at the core of a decentralized network. That’s the fediverse paradox: tools that make the fediverse usable inevitably re-centralize.
I’m exploring this at Zeitgeist Experiment — building discourse mapping that respects decentralization while actually aggregating signals. The answer isn’t tags.pub or hashtags, it’s something that lives in the data layer without needing a central authority. But figuring out how to do that at scale is hard.
I think it is a useful service, because it helps small instances discover content. However, this idea is not new and another service of that kind, FediBuzz, has been operating for a long time.
So it’s actually more helpful than hashtags? Sorry, I’m not super well versed in how smaller instances work 😅
It’s not more useful than hashtags.
It’s a hashtag relay.
On the fediverse, there is no central “fire hose”, no central source of “every post from everyone”. Rather, when someone makes a post, the instance the post was created on looks at the list of people following the person making the post, and sends a copy of the content to all of those instances.
When someone boosts a post, the original post is sent to all instances that have people following the person doing the boosting.
And that’s basically it.
So if you’re on a single person instance, the only content you will see is the content created by or boosted by people you follow. No other content makes it to your instance, so your “global feed” and your “home feed” look the same.
On a big instance with lots of users, the global feed is just a master list of all of the public content that makes up all of the home feeds of the users on the instance. So the more users, the more content in the global feed.
And when you follow a hashtag, the only content you see is hashtag content that made it to the global feed. So if no one on your server follows a particular person, none of their hashtag content will make it to your instance.
Relays are a fire hose. Every instance that adds a relay sends all of its public content to the relay. And in turn, the relay sends back all public content it receives from every instance subscribed to the relay. So if you’re a single user instance, and you subscribe to a relay, your global feed will look very different to your home feed, because the relay will be sending you content from all of the instances subscribed to that relay!
tags.pub is a garden hose instead of a fire hose. It’s a way of getting filtered content from a relay, so that only content that matches the hashtags you or your admin have subscribed to make it to your instance. The other main difference between tags.pub and a typical relay is that individual users can subscribe to a tag on the tags.pub relay, and get content from it even if their instance admin hasn’t added it as a relay.
If you run a small micro-blog instance, you follow some people and maybe some communities. Tagged posts come only through these follows, so you only see a tiny portion of all tagged posts.
A hashtag relay tries to aggregate tagged posts from the whole network. By following a hashtag on such relay you can see more posts on the topic that interests you.
This is an attempt to work around the lack of support for groups in Mastodon.
Anyone who wants tags.pub to be a thing should just use the threadiverse instead.
You can ping groups in mastodon to post to them.
It’s quite easy to flip this around: forcing topical discussion through groups are just a workaround for lack of proper discovery and aggregated search…
To give you one simple example: I get a lot more useful and meaningful interactions from following #emacs on mastodon than by waiting for people to find out and post to !emacs@programming.dev. Same thing for #nfl and !nfl@nfl.community or !nfl@a.gup.pe, etc.
What even happened to group support in Mastodon? Wasn’t that promised to be nearly finished and about to be released like some years ago?
I don’t know. Last I saw was a PR languishing for years.
“Hashtags-as-a-service”? I can’t see why we’d need this. Hashtags already exist.
Thanks everyone! It makes more sense to me now.
I still have my reservations about the person who’s running it, but it seems like a good concept.
Hashtags-as-a-service isnt new thinking, but tags.pub solves a real gap Mastodon has always had — native group support was promised forever and still hasnt landed. The problem is hashtags fragment across instances. Tags.pub centralizes tag resolution so a post tagged #fediverse gets discovered the same way on lemmy.world or a small microblog. Its a pragmatic middle ground between full federation and centralization. Im skeptical itll become the standard, but its the best workaround until Mastodon actually ships groups or activitypub gains native hashtag support.
The interesting tension here is that tools like tags.pub surface content based on tags people actually use, while Mastodon’s recommendation system will be based on engagement. I wonder which one actually leads to better discovery. With Zeitgeist I’ve been thinking about this: people’s actual behavior vs what algorithms tell them to care about. Tags.pub is a middle ground.
