Thanks for the suggestion!

This is a tricky one

Fedilab-like

Doesn't follow the hig "Do not assign actions to double-clicking or right-clicking a button. Users are unlikely to discover these actions, and if they do, it will distort their expectations of other buttons."

Sengi-like

Sengi was built with that (multi-account timelines) as the goal while Tuba/Tootle was built for general use - account switching is mostly for advanced users (and even then I doubt most people would want their accounts mixing up)

I really don't see any viable way to add this.

• Sidebar? There's already one, adding another one is too much (plus it would need a tutorial on what's the difference between that and the main account switching one).
• Another button on posts? The post widget is already too cluttered/complex.
• Context menu item? It's either 4 new items (reply as, boost as, fav as, bookmark as) (too many items) or a single item (act as a different user) but that would need yet another indicator on the post widget to showcase which is the current active account for that specific one.

And that's the UX/UI portion, (I haven't looked into how Sengi does it) but you have to make network requests using the changed-to account to all visible posts from the changed-from account's timeline to see if the changed-to account can see and interact with them, for the first case. For the other two cases (per-post account switching), you'd have to either make network requests from each account when a user selects that they want to interact as another account to see which ones they can use OR allow them to pick any and just attempt to interact even if it fails (bad UX).

I don't want to sound dismissive but this would require many UI changes and network-related decisions for little to no gain / usage.

I'll leave this open for a bit for any future comments but the chances are very slim

(This is a bit long and I might have overthought it or misunderstood the original suggestion, if so feel free to specify below!)

Fedilab-like

Doesn't follow the hig "Do not assign actions to double-clicking or right-clicking a button. Users are unlikely to discover these actions, and if they do, it will distort their expectations of other buttons."

Ha, missed this part of the HIG, sorry.

Sengi-like
I really don't see any viable way to add this.

* Sidebar? There's already one, adding another one is too much (plus it would need a tutorial on what's the difference between that and the main account switching one).

I don't really see a problem with an option that would enable a left cross-account action sidebar with the accounts' avatars, but I'll let you be the judge of that.

* Another button on posts? The post widget is already too cluttered/complex.

There is also room for an additional menu button on the posts (especially if buttons span the whole width and not only the text area). This would reproduce the current standard from the Mastodon web interface, so users would probably not mind? But sure, that's a design decision so I'll let you think about it.

* Context menu item? It's either 4 new items (reply as, boost as, fav as, bookmark as) (too many items) or a single item (act as a different user) but that would need yet another indicator on the post widget to showcase which is the current active account for that specific one.

I'm not sure how you differentiate the previous item from this one, could you elaborate.

And that's the UX/UI portion, (I haven't looked into how Sengi does it) but you have to make network requests using the changed-to account to all visible posts from the changed-from account's timeline to see if the changed-to account can see and interact with them, for the first case. For the other two cases (per-post account switching), you'd have to either make network requests from each account when a user selects that they want to interact as another account to see which ones they can use OR allow them to pick any and just attempt to interact even if it fails (bad UX).

Yes, Sengi simply uses the post visibility to tell whether you should be able to interact or not but it does not actually check so there are instances where interaction may fail (e.g. if the person blocked your other account)

I don't want to sound dismissive but this would require many UI changes and network-related decisions for little to no gain / usage.

I understand.
Another possiblity could be an "open post as" option with the feature that navigating back brings you back to the initial timeline and account (that would already remove a large fraction of the inconvenience).

For the record, Tweetdeck does this by providing those special actions as part of the meatballs (…) / hamburger menu in the context of the post:

It then prompts you like this (with an overlay, but it could be a dialog), for example:

Personally, it wouldn't shock me to have those 2-3 extra actions in the meatballs menu in addition to the few existing ones, perhaps with a separator inbetween.

@nekohayo Agreed! This would be my preferred choice.

In case it is not deemed acceptable, here is a 3rd proposal:

Since the last version it now seems that there is a menu item next to the post privacy icon (top-right corner) so we could also add the following option

1. click the menu from account A and select "open in another account"
2. select desired account B
3. make the interaction
4. (important) clicking "previous" (the top-left arrow) brings you back to the post on the initial account's timeline (i.e you're back to account A)

Though that's already a lot of interactions, I feel it'd still a significant improvement over the current state.

Mastodon has also announced that they are planning to introduce quote boosts, and they are already a feature in at least Akkoma and Calckey, so maybe these 2 problems can be solved together.

on Twitter and Bluesky, the repost button opens a menu like this:

on Tumblr, the reblog button opens a dialog like this, where a comment can be optionally added and identity can be switched. I remember Twitter was A/B testing this kind of workflow a few years back, but has seemingly withdrawn from it.

this however still doesn't solve the problem for favs.

Ok so, I gave it a try on #281 (there's screenshots)

The approach I took is changing the account to act as from the menu and execute the post actions using it.

I am not sure if that's the ideal approach, the tweetdeck one is also worth looking into - showing the actions next to every account

The tumblr one involves the composer mostly which might be worth looking into in a different issue ("Posting as different a account without switching to it") and/or when a composer redesign is proposed!

I'm still not really fond of cross-account actions, before doing anything, it already requires making a search request from the changed-to account to get the post id from its instance and then everything is kind-of random (in regards of whether you can interact etc). At least the initial search request deals with whether the changed-to account can see the post.

Ok so, I gave it a try on #281 (there's screenshots)

So am I right in understanding you implemented that proposal?
In that case, does the "go back" button indeed redirect to the original account and timeline where the post was first seen?

The approach I took is changing the account to act as from the menu and execute the post actions using it.

I am not sure if that's the ideal approach, the tweetdeck one is also worth looking into - showing the actions next to every account

Yes, I would say tweetdeck implementation is the most time-saving option, but this is already a great improvement.

I'm still not really fond of cross-account actions, before doing anything, it already requires making a search request from the changed-to account to get the post id from its instance and then everything is kind-of random (in regards of whether you can interact etc). At least the initial search request deals with whether the changed-to account can see the post.

I guess with the tweetdeck version you could actually check whether the action is possible and only display the accounts that can do the requested interaction?

Anyway, thanks a lot for starting to look at this, it really makes a world of difference when using multiple accounts!

So am I right in understanding you implemented #223 (comment)?
In that case, does the "go back" button indeed redirect to the original account and timeline where the post was first seen?

Kind-of, apart from the "opening" part - it's closer to Sengi:

• You select doas (not final name) from the menu of a post (that is public or unlisted)
• Then select one of the saved accounts
• Tuba does a search request from the changed-to account
• If it fails, it won't act as the changed-to account
• If it succeeds, it will slightly change the post background color to purple and act as the changed-to account
• If you then select doas again and pick your active account, the purple background color will be removed and you will act as the active account

I guess with the tweetdeck version you could actually check whether the action is possible and only display the accounts that can do the requested interaction?

You are right, it would require doing a search request from every single account so probably not going to happen

Kind-of, apart from the "opening" part - it's closer to Sengi

* You select `doas` (not final name) from the menu of a post (that is public or unlisted)

OK, I imagine that you don't do followers-only because you don't want to make the additional search requests

* If it succeeds, it will slightly change the post background color to purple and act as the changed-to account

I'd find it more intuitive if the post went (perhaps in addition to the color change) into "thread mode", like when you normally click on a post, so that it's really obvious that you are no longer in the same context. In my opinion that would also make it easier to implement the reply as in this context.

* If you then select `doas` again and pick your active account, the purple background color will be removed and you will act as the active account

With this implementation, it's an additional two clicks to go back to the other account and you need to know it (it is not intuitive). What happens if you don't click "doas" again and resume scrolling?
To me it seems more intuitive to go to thread mode, where you have to click back (you don't need to know what you're supposed to do, there is not other option).

You are right, it would require doing a search request from every single account so probably not going to happen

OK

@GeopJr did you have time to think about the potential implementations? As you mentioned that you wanted to discuss this with some GNOME designers, I was wondering if you got the opportunity to do so.

Nope. I'm not satisfied with the current implementation nor the other suggestions so it's stuck in the backlog. I don't like that pretty much everything is left up to "it might or might not work" and it's not as easy as just "opening a thread as a different account" because there are many moving parts from custom emojis to how many poll options an instance supports or whether it can display quotes and emoji reactions.

Nope. I'm not satisfied with the current implementation nor the other suggestions so it's stuck in the backlog.

I understand.

it's not as easy as just "opening a thread as a different account" because there are many moving parts from custom emojis to how many poll options an instance supports or whether it can display quotes and emoji reactions.

I did not follow that last part, could you explain why this is an issue here, compared to the situation where I would find a post on account A, copy its link, go to account B and search for the post there?

I did not follow that last part, could you explain why this is an issue here, compared to the situation where I would find a post on account A, copy its link, go to account B and search for the post there?

1. In Tuba to get the current account, we do accounts.active which returns an InstanceAccount. An instance account is similar to a normal account but has more info (and other functions) like instance info, the instance's custom emojis and, of course, the account access token. The instance info includes the instance's config which is used by the composer (max character count, max polls, max attachments, max attachment size, supported attachment file types etc). If you were to reply to a post using another account without 'activating' it all this info won't be there or might be outdated, e.g. account A allows 1024 characters but account B allows 512 characters, composer needs to keep track of account B's limit during doas (/ cross account actions)
2. Threading gets messier when there are different backends involved. Have you seen an Akkoma quote post from a Mastodon account? It probably ends with "RE: <quote post url>", but from Akkoma instances it just shows the quoted post (like on Twitter). (Similarly for emoji reactions). If account A (mastodon) opens a thread with some quoted posts inside, you'll just see them as RE: .... but if you go back and re-open it as account B (akkoma) Tuba will display them as quote posts. Similarly, glitch-soc allows markdown in posts so posts will look different between account A and account B
3. Additionally, threading does not update the post that opened it, the other posts in the thread get added before or after it, so in combination with [2], the original post might look very different to the rest of them (if account A was mastodon and account B was akkoma, the original post will have RE: ... while the others will have quoted posts)
4. Everything that uses accounts.active would need to be refactored in a way that allows other instance accounts to be used instead
5. When you copy the link to a post in search, Tuba knows your account's limits, emojis etc, your instance knows whether you can see and interact with it as well as what's supported (quotes, markdown, reactions etc) and how to display them (should *foo* be displayed as foo, foo or *foo*? (your instance returns it to Tuba as html))

3. Additionally, threading does not update the post that opened it, the other posts in the thread get added before or after it, so in combination with [2], the original post might look very different to the rest of them (if account A was mastodon and account B was akkoma, the original post will have `RE: ...` while the others will have quoted posts)

4. Everything that uses `accounts.active` would need to be refactored in a way that allows other instance accounts to be used instead

Now I understand, thanks!