Mentions of local users don't always get rendered correctly during AP delivery
Example note: https://transfem.social/notes/9xunlsv0uqtm005h
Fetching the AP representation results in the following content
:
<p><a href=\"https://plush.city/@Chel\" class=\"u-url mention\">@Chel@plush.city</a> <a href=\"https://transfem.social/@hazelnoot@transfem.social\" class=\"u-url mention\">@hazelnoot@transfem.social</a> It's sickening that this happened, and I still feel really bad for the party involved. I will say, there is a happy ending in that there were no consequences to the victim as a result. It was still extremely disrespectful and uncool.</p>
Note that the URL chosen for hazelnoot is https://transfem.social/@hazelnoot@transfem.social
, which is neither the canonical URI nor the canonical URL for the user in question. This leads software like Mastodon and Iceshrimp-JS/.NET to be unable to resolve the mention correctly, especially since Misskey (and by extension, Sharkey) now don't send the MFM representation for posts that don't carry any MFM tags not representible in HTML.
I'm fairly certain the issue is in this line: https://activitypub.software/TransFem-org/Sharkey/-/blob/f4853fb9bca1988875d1e69f60d8c3fb5ddf1bdc/packages/backend/src/core/MfmService.ts#L416
Specifically, since the user is not remote, if the mention is set as @user@localinstance.tld
(instead of just @user
), acct
will be the full user@localinstance.tld
, which then gets concatenated to https://localinstance.tld/@
. This causes the above-mentioned issue.
A fix is likely as simple as checking whether acct
ends in @localinstance.tld
, and if it does, to strip it from the variable. It should be easy to do so, as this.config.url
is already used here.
This issue also affects upstream Misskey, from what I can tell, though I don't feel like reporting it there for now, you're welcome to do so.