Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multi-account feed #61

Open
ShadowJonathan opened this issue Jun 25, 2023 · 4 comments
Open

Multi-account feed #61

ShadowJonathan opened this issue Jun 25, 2023 · 4 comments
Labels
enhancement New feature or request
Milestone

Comments

@ShadowJonathan
Copy link
Contributor

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 ShadowJonathan added the enhancement New feature or request label Jun 25, 2023
@Sjmarf
Copy link
Contributor

Sjmarf commented Jun 28, 2023

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.

@BrooklynMan
Copy link
Contributor

BrooklynMan commented Jun 28, 2023

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.

@ShadowJonathan ShadowJonathan transferred this issue from mlemgroup/mormaer-mlem Jul 3, 2023
@EricBAndrews EricBAndrews modified the milestones: v1.3, v2.0 Mar 20, 2024
@EricBAndrews
Copy link
Member

EricBAndrews commented Mar 20, 2024

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.

@Sjmarf
Copy link
Contributor

Sjmarf commented Mar 20, 2024

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.

@EricBAndrews EricBAndrews mentioned this issue May 27, 2024
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: Holding Pattern
Development

No branches or pull requests

4 participants