[Friendica] Navigation to hashtags / profiles doesn't work?

[kr428]

Using Tusky for talking to Friendica, it seems both hashtags (#) and accounts (@ mentions) are somehow "mixed up": They appear as links in the app but they don't toggle profile or hashtag view in the app (as they do while using Mastodon) but apparently are full HTTP URIs pointing to (profiles) the user profile URL on its home instance or (hashtags) an URL to search the particular friendica instance for these hashtags. Sample:

In this case, for my instance, clicking on "photo" will get me to https://instance/search?tag=photo . Is there some way in Tusky to work around this? Seems it's a Friendica specialty yet still it would be cool to have this work well. :)

---

• Tusky Version: 19.x Test

• Android Version: Samsung M51

• Android Device: Android 12

• Mastodon instance (if applicable): Friendica loma.ml

• [x ] I searched or browsed the repo’s other issues to ensure this is not a duplicate.

[connyduck]

That is because friendica does not include the # and @ in the link which Tusky uses to detect if it is a hashtag/mention or a standard link.

[kr428]

Is there any way (or motivation) to work around this on Tuskys end? Or should it be modified by Friendica then?

[connyduck]

I'd like Tusky to be compatible with Friendica and i could fix it in Tusky but having the #/@ not part of the link is really weird and I think it would be better if it was fixed on Friendicas side. Can we get a Friendica dev to comment on this?

[kr428]

Ok, thanks. Created a corresponding issue with Friendica, hope someone will be able to look into this and provide some feedback here.

[MrPetovan]

Hi @connyduck , this is an accurate analysis, we intentionally do not include the #/@ (and !) characters inside the mention link, I assume for aesthetics purposes. This means we have to convert inbound mentions to our format, and convert outbound mentions to the expected target platform format.

We could switch the Friendica API from one format to another but it would be a backward-breaking change so I'm not very comfortable with the idea. Do you mind chiming in @annando ?

[connyduck]

Ok so let's fix it on Tuskys side then. If anyone wants to take this over, feel free to do so, I don't know when I will have time for it.

[annando]

@MrPetovan Question is if there are other systems that expect a different behaviour. AFAIK we have got a separate mode for our BBCode for API posts.

[MrPetovan]

Yes, but we don’t discriminate by client, so if we switch for API posts, it would also affect Twidere, Friendiqa, etc…

[kr428]

For the tests at least of Mastodon clients with Friendica I did, it seems most of them behave just the way tusky does here, maybe except for recent fedilab that also seems to take care of that by itself...

[annando]

We can add this behind some config variable, so that this can be tested until we are sure that it can be used per default.

[MrPetovan]

Can you test with all the Mastodon-compatible clients?

[kr428]

Can you test with all the Mastodon-compatible clients?

Can offer testing for tusky, fedilab, andstatus, tooot, fedi, twidere (x) and subway tooter if needed; these are the ones I'm aware of. However I don't have an instance of my own so which one should I connect to test that against?

[MrPetovan]

Thanks for the offer, now someone™️ has to create this config switch to enable tests on the develop branch.

[kr428]

Seems fixed in Friendica dev, meanwhile with the recent Tusky Test build against released Friendica this has become somewhat worse:

[connyduck]

Ok this is hilarious @Tak

[Tak]

Yeah, this is kind of a pathological case 😬

[kr428]

Apparently that's how it currently works in Friendica - hashtags and profiles generally seem to be full links to the actual instance - so it might be required, in this case, to strip off the actual links and only use the link text if it starts with # or @?

[annando]

It would be best, if Tusky had a look for the rel="tag" in the link to detect that this is a tag.

[kr428]

It would be best, if Tusky had a look for the rel="tag" in the link to detect that this is a tag.

Is there something similar for profiles too? Not really sure how the data looks in the message, here.

[Tak]

Apparently that's how it currently works in Friendica - hashtags and profiles generally seem to be full links to the actual instance - so it might be required, in this case, to strip off the actual links and only use the link text if it starts with # or @?

…but that's the problem - the link text doesn't start with # in this case

[kr428]

Apparently that's how it currently works in Friendica - hashtags and profiles generally seem to be full links to the actual instance - so it might be required, in this case, to strip off the actual links and only use the link text if it starts with # or @?

…but that's the problem - the link text doesn't start with # in this case

Ah ok, wasn't aware of that. In this case, maybe go for @annando s recommendation and really evaluate the rel - attribute here? Seems the most robust approach I'd say.

[MrPetovan]

No, our hashtag links are #<a>text</a> by convention.

[kr428]

@MrPetovan Maybe slightly off: Is this something covered by activitypub standard in some way? Also, wondering how this has been fixed or addressed in the Friendica change linked above? Will this particular problem cease to exist once Friendica instances have moved to the next release...? Reading the code / changes, I'm unsure...

[Tak]

The new link domain advertisement behavior should also be fixed by the new behavior in friendica/friendica#12122 - if somebody has a link to a post on a server with the changes, I'm happy to verify

[kr428]

(If that stuff works for both profiles and hashtags in the coming Friendica version, I'd close this off as fixed. Would be good to know that, though. 🙂️)

[kr428]

As most of the Friendica instances seem still on 2022-10, I assume this won't see a tusky-side fix anymore for release 20...? At the moment, this setup isn't really fun... 😉

[kr428]

Seems closed/fixed on Friendica 2022-12 instances. Closing this.