The standard practice seems to be to link a hashtag in a post to a specific server’s search interface. However, this is not applicable in all circumstances.
Is there a 3rd party, decentralized, independent tag search? Or in this case is it better just to not link it to anything?
Hi @gabek,
I haven’t seen a good third-party search for hashtags (or anything else) across the Fediverse.
There may be utility in directing the user to search results from some OAuth’d account though I generally prefer on such a click to be shown content of a similar media type to what I’m viewing.
The basic case probably works for any service… That of showing content on the local instance which used the same tag.
Stepping back for a moment however I’m tempted to ask about the problem being solved with hashtags and if other solutions like categories, groups, stickers or emojis might apply.
-David
Like most questions, the answer to your question about “why” is “Because Mastodon has them and now it’s expected even though it’s not a standard”.
I am not sure about this, so maybe someone can correct, but it seems to me that the search results on a hashtag doesn’t provide me with a complete overview of all occurences across all the (whitelisted) instances. Maybe the search result depends on who on other instances are being followed by the members on my instance?
We’ve had internet sh*tfights over this. As a service which has federated with other providers - including commercial providers, some services get very upset if you “steal” their hashtags and point them at your own site. And we have every right to get upset if somebody “steals” them from us.
So point them at your own site and don’t rewrite any hashtag links that point to another site. If somebody comes up with a global fediverse hashtag search - feel free to offer it as a service in addition to not stealing hashtags. I probably will not use a global fediverse hashtag search because it doesn’t scale; and if it does it needs monetisation and therein lies a slippery slope back to centralised services; because that’s basically what it is.
A number of projects (including mine) offer the ability to “follow hashtags”. You only follow the hashtags which already arrive at your site. Many have suggested ways of subscribing to hashtags from other sites, but it’s basically a poor man’s groups. Just use groups. Because as soon as these hashtags become popular, they will get hijacked for spam. At least a group has an owner that can kick people out. It’s a lot harder to kick people out of a hashtag.
Diaspora built their network on shared hashtags - it was the only practical discovery mechanism they had; and it led to centralisation, because following hashtags provides fewer results on smaller sites and it tends to drive people to the largest sites. So it’s the slippery slope problem. Again we offer them as a service, so you might think I’m being a hypocrite; but we acknowledge their limits and their tendency to push people to large sites. It’s just another tool in our chest full of useful tools. We also have groups. We’ve found most people prefer groups and when both are available, they don’t rely on hashtag following (which would drive them to large sites), but just use it as another tool and aren’t necessarily disappointed if they’re on a small site and don’t get a lot of followed hashtag content. If followed hashtags are all they’ve got, they get hopping mad that they can’t see every matching hashtag in the network and start looking for centralised solutions to this perceived problem.
Sorry for rambling, but it’s a diverse topic with a lot of implications.
Addendum: In Hubzillla we provided a “community tagging” feature. Originally this was designed so that people could tag nudity with n-s-f-w if the post creator “forgot”. But as a side effect, it let somebody (with permission to do so) add their own tag to somebody else’s post. Let’s say I create a post and tag it with #homebrew. If you click the tag you’ll only find tags I’ve posted on the subject because I’ve got a single user site. But one of my friends might have an instance of thousands of members who use that tag. So they can add a #homebrew tag to my post that links to their own site and tens of thousands of posts on the topic. It’s a complicated feature to implement because of the privacy aspects but it has worked well and I’m mentioning it because I haven’t seen anything like it anywhere else in the fediverse.
Very informative, as always, thanks! Sorry for my crappy understanding of things, but I don’t fully grasp the ‘stealing’ part.
Suppose (describing concept, not technical) I am a fedizen on a small site that federates with 10 other instances. I and maybe a few other members start to follow #activitypub hashtag. As a result the server starts to maintain a search index for us. It indexes local hashtag occurrences. And it starts listening for any occurrence in the 10 instances it federates with. My hashtag timeline will show all of that, and when I reply to a search result I jump on a conversation that may have started remotely. But that’s just federation, nothing is stolen.
Is this how it currently works? Or do we get a smaller subset, because from remote instances only hashtag matches from followed accounts are added to the index?
The permission aspect is critical. A while back it was suggested to have hashtag editing on posts in the context of Indymedia, but unless you’re really careful about permissions and identity it would rapidly turn into an abuse or spam mechanism.
Stealing hashtags is also something we encountered federating with Diaspora. If I created a post with a hashtag (for instance #homebrew) linked to posts on my site with that tag, it wouldn’t federate. They processed the markdown, found the ‘#’ character and added a url element - even though it already had one. This broke the posts/comments because it created a nested url in the markdown. We had to remove the link and just send the raw hashtag as typed. There Diaspora would receive it and create a link to posts on their site which used that hashtag. This was one of those D* protocol quirks. At the time we provided some level of API federation with Facebook and Twitter, and we had to do the same for posts we relayed from those networks. I reckon Zuck and Jack would be calling lawyers if they saw a post that originated from their network whose hashtags were linked to a Diaspora pod and not to their own network.
Currently we scan posts to the publicInbox (including those from folks we have no relationship with) and if there’s a match to one of our followed tags, we copy it to our own timeline. That post could have a link to a hashtag search on another site, but it will also appear in a hashtag search on our site; because the search itself is based on the hashtag - regardless of where the link in the post points.