There are a couple of parallel development efforts tackling the problem of hashtags. The main drawback is that while you can use them in your posts and search for them to find additional content, the reach and visibility of the hashtag is restricted to that of the instance's own visibility.

In other words, looking up a hashtag on your instance probably would not give you a complete view of the use of that hashtag worldwide.

1. @newsmast@newsmast.social channels
   • The first I'd heard of it was Newsmast's "channels". How they worked was opaque to me, but after seeing @saskia@backend.newsmast.org's presentation, I now know it is collating use of hashtags into a broader topic (e.g. #Asenal, #AFC, plus many others into "Arsenal")
2. tags.pub
   • @evan@cosocial.ca came up to me after FediMTL and asked whether I'd looked into his FOSDEM presentation about tags.pub, which aims to do something similar, although user-facing. Users can follow individual "tag" actors and they then receive all content tagged as such.
   • I will have to watch the presentation as tags.pub is headless and has no landing page! <img class="not-responsive emoji" src="https://activitypub.space/assets/plugins/nodebb-plugin-emoji/emoji/android/1f606.png?v=75a99755bb3" title="" />
3. FediBuzz Relay
   • ActivityPub.Space is following this approach, where I set up NodeBB to subscribe to a couple of relevant FediBuzz relays: #activitypub, #fedidev, #fediadmin, #fedimod and #fedimods

It's interesting to follow the convergent evolution of solutions to solve a single problem. Right now NodeBB gives you the tools to set up the FediBuzz relay connection + auto-categorization rules, but it's not exactly user-friendly for admins.

The ideal flow would be something much more high level for admins. An additional field during category creation where they can specify hashtags they'd like to follow globally. Simple, understandable, hides all the backend complexity away.

It is worth looking into additional solutions (like tags.pub or the Newsmast channels) so as to not be tied to a single provider in the backend.