mlem icon indicating copy to clipboard operation
mlem copied to clipboard

Multi-account feed

Open ShadowJonathan opened this issue 2 years ago • 4 comments

Taking a look at the current defeds across Lemmy, I think that it's worth considering to look at "multi-account feeds", something that is able to stitch together feeds from multiple accounts, to allow someone to not have to "strategically position" their account across multiple servers, but just sign up for them, sub to communities, and be able to view and interact with them in some way or another.

Something to consider;

  • We should make it more clear, from this feed view, with which account the user is currently interacting with with the post, when they'd open it.
  • We have to have a conflict resolution algorithm when a user tries to add subs to the same community from different accounts, to resolve "which account" is going to interact with that community, from that feed.

ShadowJonathan avatar Jun 25 '23 13:06 ShadowJonathan

If a post in the multi-account feed is available from more that one account, the user should be able to change which account they are interacting with from within the comment-writing menu.

Maybe the user could set a default account to use for each community, too.

Sjmarf avatar Jun 28 '23 06:06 Sjmarf

from a UX perspective, this would be a disaster trying to explain to the user what feed a post is from, what actions are from what account, and how they apply to which feed. Users are already confounded by the current experience of using a single account across instances. this concept would make their heads explode-- creating a sensible interface UX that could easily make transversing multiple instance feeds with multiple accounts might not be possible.

one of the best things about the app is that it's simple and easy to use while being powerful where it counts (or it will be). overloading it with every feature we can imagine will negate all of that and Mlem would become complicated and overwhelming. That's no good.

BrooklynMan avatar Jun 28 '23 06:06 BrooklynMan

I'm not going to remove BrooklynMan's comment because I believe in preserving thread history, but I think it can be safely ignored.

This should be pretty easy to set up with 2.0, at least on the rendering side, using the better instance handling + generic multi-trackers.

Account selector in the comment editor is a nice straightforward solution to handling which account to submit replies from. Handling other interactions shouldn't be too complicated--one idea would be to allow users to set a 'priority list' when creating a multi-instance feed and have interactions be performed from the highest-priority account with access to the post. Actions such as blocking a post or user should presumably be executed from all accounts.

Somewhat more complex is handling saved state, though we could perhaps handle that with a matching "saved from all accounts" feed.

Read state is also a little tricky, but that can be handled by just submitting it on all accounts--we won't have to worry about spamming the API, since it's n calls client-side but only 1 per server.

We should also probably display a warning at setup that this will dramatically increase the amount of data being fetched, and maybe add the option to only enable multi-instance feeds when on wifi for users with limited cellular data.

EricBAndrews avatar Mar 20 '24 00:03 EricBAndrews

This feature would certainly be highly valuable to a lot of users. I don't think it'll be too confusing, since it would be an opt-in feature and not enabled by default. Multi-accounts is something that we could build the architecture for in 2.0, but I think we should keep the feature hidden or "experimental" for the time being. There are a lot of cases (subscriptions, voting, saving, read state) where we needed to build well-thought-out solutions, and taking the time to cover all of those could delay the 2.0 release. I'd be happy marking it as "experimental" and making the feed read-only for the time being. We've already got some major features planned for 2.0 (Guest Mode, actual state-faking everywhere, post searching, keeping place when switching accounts, maybe an inbox revamp), so I don't think we need to have multi-accounts for it to still be an important update.


What will the UX look like for setting up a multi-feed?

Maybe we could let a user add "multi-accounts" in the Accounts setting page. They could give a name to each multi-account, and choose which of their accounts are included. The user would also be able to add guest accounts to the multi-account in this system. The user could switch in and out of the multi-account easily via the quick switcher.

Encapsulating the "multi-feed" idea in the form of a distinct "account" as described above, rather than as a feed, allows us to utilise multi-account features outside of just the feeds. Some examples of where this would be useful:

  • The search tab could query all instances that compose the multi-account, and combine their results. This allows the user to quickly access a defederated community without having to switch accounts.
  • The "View post" button in the modlog could find which child of the multi-account is authorised to access the post, and display the post using that child account's API client.

How would we display the subscription list in this setup? We could have two settings for the way they are displayed:

  • Mix subscriptions in together, displaying the avatar(s) (of some other identifier) of the accounts that are subscribed to each community next to the community
  • Add a bubble-picker to the subscription list that lets the user switch between the lists for each account.

We could also have a "sync subscriptions" setting for the multi-feed (off by default, and with a warning attached to it) that attempts to keep all of the subscriptions the same across accounts where possible.

Sjmarf avatar Mar 20 '24 11:03 Sjmarf