Some fediverse clients don't rewrite hashtag links

[snarfed]

In the fediverse, hashtags in content are like mentions: we wrap them in HTML links, and when remote instances render the post, they rewrite those links to point to the hashtag search page on their instance. Gory details in #45.

...except evidently not all clients do this. The Mastodon Android app, for example, leaves them as is: https://piaille.fr/@politipet/113664287902122111

Bridgy Fed currently points its placeholder links in content to non-existent pages, eg #foo gets linked to https://bsky.brid.gy/hashtag/foo. I don't plan to build a hashtag or search UI in Bridgy Fed's web UI, and hashtags in content do need to be linked somewhere for clients that do rewrite, so I'm not sure what to do. Maybe link to #, ie the current page?

[snarfed]

Maybe link to #, ie the current page?

Refreshed my memory a bit, and at least based on Mastodon's implementation back in March 2023, sounds like this wouldn't work. From #45 (comment) :

• Both the tag object name and content link text must start with #.
• Both the tag object and content hrefs must be non-empty, fully qualified URLs.
• They don't need to match.
• Mastodon rewrites the content href to point to the local instance's search for the hashtag.
• However, it also generates a link preview for the original content href, unless it points to the sending instance. Ie for BF, if the content href is https://fed.brid.gy/[anything], the link preview is suppressed. That's not really useful for users though, they're not going to link their hashtags on their site to BF. 😐

[Tamschi]

I think these should be redirected to hashtag searches (not text searches for the hashtag, those are different there!) on Bluesky. It's essentially what all other fediverse instances do too.

[snarfed]

Good idea! Totally makes sense, and easy to do.

[snarfed]

...not sure what we'll do for web users though. Hrm.

[snarfed]

^ Deploying a change to link Bluesky => fediverse converted hashtags to the bsky.app hashtag search page.

[Tamschi]

Hm, I think that might enable the link preview for them, though.
If that happens, I think it would be better to still have the https://bsky.brid.gy/hashtag/… URLs and HTTP-redirect to Bluesky from there.

[snarfed]

Hmm, receiving fediverse instances will generally rewrite hashtag links instead of generating previews for them, right? That's what they do now. Non-webapp clients like Mastodon Android may not do that rewriting, but afaik they also don't generate previews themselves locally...?

(In any case, I'm happy to do some work like this to smooth over these links, but only some. I have kinda limited patience for interop depending on how finicky and niche it gets. 🤷)

[snarfed]

Here's an example Bluesky => fediverse bridged post with the new hashtag URLs:

• https://bsky.app/profile/did:plc:iykhuqc3h2jlrr5uj2ylazkx/post/3ldjzcrtb5k2p
• https://mastodon.social/@[email protected]/113670825878807712 (requires mastodon.social login)

Anyone with an affected client/app, feel free to look and check that the hashtags now link to bsky.app!

[Tamschi]

Hmm, receiving fediverse instances will generally rewrite hashtag links instead of generating previews for them, right? That's what they do now. Non-webapp clients like Mastodon Android may not do that rewriting, but afaik they also don't generate previews themselves locally...?

(In any case, I'm happy to do some work like this to smooth over these links, but only some. I have kinda limited patience for interop depending on how finicky and niche it gets. 🤷)

Oh, if it works then I take it back of course 😅
It was just a hunch based on #1634 (comment).

[gerbenjacobs]

I'm a web user and I use absolute URLs to 'mysite/tags/the-tag-itself' as I have an actual page that's catching those.

Both those inline tags (from e-content) are properly shown in Mastodon and Bsky.app.

Somehow Mastodon still takes the old original URL and uses that as link preview. Also any inline tags get removed from the added (p-category) tags. I had also added "#bluesky" but it's not shown in the bottom.

[snarfed]

@gerbenjacobs ruh roh! That's not good. Odd though, I'm not seeing that link preview on eg indieweb.social, on either desktop or mobile web. Where is your screenshot from?

[popet-master]

How about https://bsky.brid.gy/hashtag/TAG simply returns a 302 and redirect to https://mastodon.social/tags/TAG ?

The #TAG links belong to the Fédi, not to Bsky. Take web clients: they point to the local instance, in the Fédi.

[snarfed]

How about https://bsky.brid.gy/hashtag/TAG simply returns a 302 and redirect to https://mastodon.social/tags/TAG ?

It's a nice idea, but it privileges mastodon.social a bit more than I'd like. bsky.app is very much the canonical Bluesky client app right now, but mastodon.social is much less the canonical fediverse instance, and fedi people often don't love seeing it enshrined as "special" like this compared to other instances.

[snarfed]

Oh, also, @gerbenjacobs, I misinterpreted your screenshot earlier, I think it's mostly doing the right/expected thing after all. #bluesky isn't shown at the bottom because it's visible in the post text, and its link in the post text is rewritten to the local fediverse instance's tag page.

I looked at it on three different instances - indieweb.social, mas.to, mastodon.social - and the last two do have the link preview you saw. Not sure why the difference there.

[popet-master]

use piaille.fr then :-) it's the biggest 🇫🇷 instance afaik, and "neutral". Maybe as a quick fix.

[gerbenjacobs]

Oh, also, @gerbenjacobs, I misinterpreted your screenshot earlier, I think it's mostly doing the right/expected thing after all. #bluesky isn't shown at the bottom because it's visible in the post text, and its link in the post text is rewritten to the local fediverse instance's tag page.

I looked at it on three different instances - indieweb.social, mas.to, mastodon.social - and the last two do have the link preview you saw. Not sure why the difference there.

Yeah, I'm not sure there's much to do.

The screenshot was from todon.nl which is running Mastodon 4.3.2. I also have my own instance running the latest GotoSocial.
The funny part (which I didn't even know) using a 'headless' client like Semaphore.social or Elk.zone will show both entries differently.

Those that are stored on todon.nl (running Mastodon) have this link preview, while those stored by GtS don't have those. GtS also doesn't do anything with hashtags and just keeps it a regular link back to my site.

And semaphore.social always uses the spoiler mechanic for that specific post with "Long post".

Bottomline: many servers and many clients do a lot of different things 🤷🏼‍♂️

[Tamschi]

How about https://bsky.brid.gy/hashtag/TAG simply returns a 302 and redirect to https://mastodon.social/tags/TAG ?

It's a nice idea, but it privileges mastodon.social a bit more than I'd like. bsky.app is very much the canonical Bluesky client app right now, but mastodon.social is much less the canonical fediverse instance, and fedi people often don't love seeing it enshrined as "special" like this compared to other instances.

I think it would be a good idea to 301 Moved Permanently-redirect https://bsky.brid.gy/hashtag/TAG URLs to https://bsky.app/hashtag/TAG searches to fix older posts, since we don't send out Updates for post transform fixes like these.

(Bluesky hashtag search pages are guest-accessible. Technically this alone would fix this issue in terms of UX, I think, though it would of course be nice to do this without the redirect.)