Twidere mention workaround #5552
Conversation
| end | ||
| status.text = status.text.gsub(Account::MENTION_RE) do |match| | ||
| begin | ||
| mentioned_account = resolve_remote_account_service.call($1) |
There was a problem hiding this comment.
Codeclimate complains about $1, but I'm not sure there is a better way to do that in Ruby, at least I have not found one reading the documentation for gsub.
There was a problem hiding this comment.
what's wrong with resolve_remote_account_service.call(match.first.to_s)?
There was a problem hiding this comment.
match is the full matched string, not a list of groups :/
ClearlyClaire
force-pushed
the
twidere-mention-workaround
branch
from
e478d51
to
963878c
Compare
|
|
||
| mentioned_account.mentions.where(status: status).first_or_create(status: status) | ||
| mentioned_account.domain.nil? ? "@#{mentioned_account.username}" : "@#{mentioned_account.username}@#{mentioned_account.domain}" |
There was a problem hiding this comment.
this line should just be "@#{mentioned_account.acct}"
| end | ||
|
|
||
| status.save! |
There was a problem hiding this comment.
at this point have we already delivered the message to subscribers? I don't know if we're allowed to re-write the message here then—we'd have to pull this code somewhere else.
There was a problem hiding this comment.
No we haven't, this is right before delivering it.
There was a problem hiding this comment.
How do we know that though? I don't know if this is the right thing to do from a code organization perspective. adding a transaction might create a nested transactions error, for example.
There was a problem hiding this comment.
I understand your concern, and I share it to some extent. However, the serialized status sent over both the WebUI and remote servers through OStatus and ActivityPub already depends on this function, as the serialization depends on the mentioned_account.mentions created by this function.
TL;DR: I understand the concern, but it's not a new one
|
I'm not sure merging this change is a good idea. While in theory processing webfinger aliases is a useful thing to be doing when @mentioning users, this really needs to be fixed upstream as well—there's no guarantee that users with web_domain != local_domain will have webfinger aliases correctly set up. And without the bug driving this pull request i'm not sure the additional complexity doesn't outweigh the benefits of inclusion. |
ClearlyClaire
force-pushed
the
twidere-mention-workaround
branch
from
e9d1508
to
03a6c5e
Compare
|
@nightpool I fixed the issues you pointed out. I somewhat agree with you, although I also see it as a consistency fix for the following behavior: Mastodon resolves the account, records a “mention” relationship and notify the remote user, but the serialized toot does not contain the html-rendered mention, which breaks further interaction as the WebUI does not pick it up on reply |
Tootdon and Twidere construct @user@domain handles from mentions in toots based solely on the mention text and account URI's domain without performing any webfinger call or retrieving account info from the Mastodon server. As a result, when a remote user has WEB_DOMAIN ≠ LOCAL_DOMAIN, Twidere and Tootdon will construct the mention as @user@WEB_DOMAIN. Now, this will usually resolve to the correct account (since the recommended configuration is to have WEB_DOMAIN perform webfinger redirections to LOCAL_DOMAIN) when processing mentions, but won't do so when displaying them (as it does not go through the whole account resolution at that time). This change rewrites mentions to the resolved account, so that displaying the mentions will work.
Indeed, substitutions with the previous regexp would erroneously eat any preceding whitespace, which would lead to concatenated mentions in the previous commit. Note that users will “lose” up to one character space per mention for their toots, as that regexp is also used to remove the domain-part of mentioned users for character counting purposes, and it also erroneously removed the preceding character if it was a space.
ClearlyClaire
force-pushed
the
twidere-mention-workaround
branch
from
03a6c5e
to
1519335
Compare
|
Rebased on latest master, so it doesn't include the first commit anymore. |
* Work around Twidere and Tootdon bug Tootdon and Twidere construct @user@domain handles from mentions in toots based solely on the mention text and account URI's domain without performing any webfinger call or retrieving account info from the Mastodon server. As a result, when a remote user has WEB_DOMAIN ≠ LOCAL_DOMAIN, Twidere and Tootdon will construct the mention as @user@WEB_DOMAIN. Now, this will usually resolve to the correct account (since the recommended configuration is to have WEB_DOMAIN perform webfinger redirections to LOCAL_DOMAIN) when processing mentions, but won't do so when displaying them (as it does not go through the whole account resolution at that time). This change rewrites mentions to the resolved account, so that displaying the mentions will work. * Use lookbehind instead of non-capturing group in MENTION_RE Indeed, substitutions with the previous regexp would erroneously eat any preceding whitespace, which would lead to concatenated mentions in the previous commit. Note that users will “lose” up to one character space per mention for their toots, as that regexp is also used to remove the domain-part of mentioned users for character counting purposes, and it also erroneously removed the preceding character if it was a space.
This pull request works around a bug in both Twidere (TwidereProject/Twidere-Android#1001) and Tootdon.
Tootdon and Twidere construct
@user@domainhandles from mentions in toots basedsolely on the mention text and account URI's domain without performing any
webfinger call or retrieving account info from the Mastodon server.
As a result, when a remote user has
WEB_DOMAIN≠LOCAL_DOMAIN, Twidere andTootdon will construct the mention as
@user@WEB_DOMAIN. Now, this will usuallyresolve to the correct account (since the recommended configuration is to have
WEB_DOMAINperform webfinger redirections toLOCAL_DOMAIN) when processingmentions, but won't do so when displaying them (as it does not go through the
whole account resolution at that time).
While this is essentially a workaround for a bug in other software, it's a simple workaround whereas fixing Twidere would be more involved. In addition, it also fixes some inconsistency in Mastodon: it is somewhat dubious for Mastodon to manage to resolve the account in one place (
ProcessMentionsService) and fail in another (status serialization).Lastly, this PR depends on #5539 but that could be changed.