acct is wrongly including subdomain for certain servers (like m.webtoo.ls)

[patak-dev]

@userquin @danielroe, I'm creating an issue to dump what I see so far as I'm a bit confused. I thought this would be an easy regression but it looks like the code evolved quite a bit with this bug present. It is causing many issues in the app currently, and it looks like it may be a regression introduced in several steps in the past month (or even more).

For a server like https://m.webtoo.ls, acct handles should look like patak@webtoo.ls without the subdomain. This is because we configure the server to use the domain as the handle.

If you hover in the timeline avatars, everything works well (even for your own avatar). The account.acct will correctly be patak@webtoo.ls and clicking on it will lead to /m.webtoo.ls/@patak.

But if you hover on the Account Switcher or Picker on the bottom right, then the acct will be patak@m.webtoo.ls. Even for other accounts or in other servers, the subdomain is also there. Clicking on it will lead you to /m.webtoo.ls/@patak@m.webtoo.ls because it can't remove the server and if you share this route, the social preview will not work. Switching users has other issues that I think are related to the same.

What is even more problematic is that the acct is also wrong in both local storage and in IndexedDB.

For some reason, we are getting a good value for acct in the timeline. It looks like status.account.acct is correct. But the way we get the user account given an id may be wrong, maybe masto.js should give us a proper acct and it isn't and this is why we end up with code like this that is wrong because we should be ignoring the subdomain for the server (but I think we can't know at this point).

I'm a little bit puzzled here, I hope it is a regression. IIRC, all this was working at one point. But checking the code, we now have 5-6 utils where we are adding the @{server} at the end and all of these should be removed IIUC. Maybe I'm missing something? We may need to rework the local storage and IndexedDB once this is solved for everyone in servers like webtoo.ls.

[stackblitz[bot]]

Start a new pull request in StackBlitz Codeflow.

[userquin]

I Will try to review 2 modules and the usage of account extraction functions, It seems a call to the wrong function from sfc.

[userquin]

The logic is on cache.ts and users.ts composables, I'll check history in cache.ts, it should remove the server suffix on sign-in from users.ts (IIRC the Last function to cache the account, there is a slice)

[patak-dev]

I think that this is something that needs to be fixed in masto.js, or even in Mastodon?

status.account.acct is patak@webtoo.ls

But if you call

const accountFromId = await client.v1.accounts.fetch(status.account.id)

when you are logged in, then you end up with

accountFromId.acct being patak

And there is no information in accountFromId that can be used to know that it should be patak@webtoo.ls instead of patak@m.webtoo.ls. The url field gives you the server info but you don't have info about the need to drop the subdomain.

I would expect that the account will give us this info. But maybe it isn't needed if we get this info when the user is signing in. And we then store both the server and the server-in-handle that needs to be used to construct the acct. In localStorage, IndexDB, we need to store this info. Maybe I missed some of the evolution of the user and server handling, are we already storing the server and the server-in-handle for each user? Also, what should be the name of server-in-handle (webtoo.ls instead of m.webtoo.ls)?

[userquin]

@patak-dev this is the exact problem, I updated all account pages and some logic trying to solve it (check my Last commit on cache.ts module history), maybe we have a regression in some sfc. So, the problem is only on account main page?

[patak-dev]

I don't know if I understand the question. Currently visible bugs I see:

1. I have 6 accounts, two servers with this issue: m.webtoo.ls, m.codeflow.club. When logged into patak, if I hover in the picker, they all have the acct wrong

This is because all of them have the wrong acct used as key and in the field of the account info in localStorage and IndexedDB.

2. If you click on your own account, your profile is shown with the wrong URL (it has this wrong acct in the URL)

3. when you switch users, there are errors in the console in a lot of scenarios. Sometimes it works though. I suspect these may be related to this same issue.

The issue isn't in SFCs, this can't be solved when showing the acct. What is wrong is the acct we are generating when the acct is of the form username instead of username@server-in-handle. We are generating patak@m.webtoo.ls when it should be patak@webtoo.ls.

I think we are missing this info here. We don't only need server that IIUC it is m.webtoo.ls, we also need a serverInHandle that should be webtoo.ls. And I hope we get info when signing in to be able to store this info so we can later use it.

[userquin]

There is no solution for this, we only have the account data and we don't have enough information to know if it is WEB_DOMAIN (webtoo.ls) or LOCAL_DOMAIN (m.webtoo.ls).

We have uri only on instances where we are logged in (those instances are deleted once sign-out and there are no more accounts on same server).

If the server account is the default one there is no problem, since that is what we do right now, but for external accounts, for example with WEB_DOMAIN=aaa.org and LOCAL_DOMAIN=m.aaa.org, we do not have enough information: https://docs.joinmastodon.org/entities/Account/#acct (I'll need to check what domain is included in acct)

Mastodon should include both domains in the account info.

WEB_DOMAIN is an optional environment variable allowing to install Mastodon on one domain, while having the users’ handles on a different domain, e.g. addressing users as @alice@example.com but accessing Mastodon on mastodon.example.com. This may be useful if your domain name is already used for a different website but you still want to use it as a Mastodon identifier because it looks better or shorter. As with LOCAL_DOMAIN, WEB_DOMAIN cannot be safely changed once set, as this will confuse remote servers that knew of your previous settings and may break communication with them or make it unreliable. As the issues lie with remote servers’ understanding of your accounts, re-installing Mastodon from scratch will not fix the issue. Therefore, please be extremely cautious when setting up LOCAL_DOMAIN and WEB_DOMAIN.

[userquin]

we can use fetchV1Instance (uri) and fetchV2Instance (domain) to get that info:

• V2: https://docs.joinmastodon.org/entities/Instance/#domain

[userquin]

V1 and V2 responses for m.webtools.ls, maybe we can add another LRU cache and store the info on client:

[danielroe]

I think the solution/issue is that we only get a response without server when the account is on the server that is replying to us. And we only directly query servers that we actually have logged into or have an account on (and we have already stored their information in local storage). So we should be able to figure this out from the information we already have available to us. Will happily take a look later if @userquin doesn't beat me to it.