Mastodon: Support "twitter lists"

[guidob]

When this platform gets traction it will be really useful to be able to group users in different "lists". In general timelines are too verbose.

And to be able to continue where you left off later.

[ghost]

Thoughts on this subject:

a) Where are lists stored, server-side or client-side?
server-side, pro: no need to enter lists multiple times when you use different apps or PCs
server-side, con: extra burden on servers (arbitrary number of arbitrary-length lists for every user 😲)
client-side: inverse of the above, but also con: it might be hard for the web client to store large lists in cookies (IANAP, so please CMIIW)

b) Once lists are implemented (either side), functionality can be added to

• toot a list
  don't put @'s in front of usernames to avoid notifying them every time they're listed
  put the list under a CW to avoid cluttering timelines
  split a list over multiple toots if it's too long to fit in one
• add the usernames from a toot to a list
  optionally create a new list before adding the usernames
  client needs to recognize un-@'ed usernames for the sharing of lists through toots to work
  for convenience, client should probably also recognize lists split over multiple toots
• follow the users in a list
• mute the users in a list
• block the users in a list
• split the listed users from your home timeline into a new column (à la Tweetdeck)
  see also #351, #1419

These don't need additional server support, but makers of different apps should agree on a common format for sharing lists.

Easily sharing lists between users through toots will help mitigate the current discoverability problem.

[jerome-tgl]

I'd like to point out one major benefit of lists: they allow users to "privately follow" people without publicly disclosing their interests (e.g politics, religion, sexuality...).

[algernon]

An idea I've been playing with, to solve the same issue, but differently, is to apply filtering on the client side. That is, the server would have the same timeline it has now, and the client would sort it into lists, based on arbitrary rules - which could even be some custom JS running in the browser for each incoming message. The filters would tag statuses, and the client would display them as lists, or in any other way it finds appropriate.

The server could store the rules, as a blob, so that they would be available for every client that supports this.

This way, the server doesn't have to maintain lists, or even care about how to add content there. The user would have much more freedom too, because they'd have more options than manually adding people one by one to any number of lists. I could have a "list" that has a few people, and all statuses that contain a phrase, or a tag, or are part of a context which is already part of this group. This way, if I have someone on a list, any replies to their toots will also get to the list (assuming the replies somehow appear on my timeline too).

In other words, I'd push this into the clients, because that's more practical, more flexible, and easier to do too.

The downside of this is that one will need to follow others to have their statuses appear on the lists - there is no private follow. Not sure if this is a good or a bad thing.

As for sharing lists: one would share filtering rules, instead of lists. For ease of use, the most simple rules (filtering by username) could be made easier to share by explicitly exposing that in the UI.

[pointlessone]

@algernon. You’ve just basically invented IMAP Sieve. Might as well reuse syntax and functionality.

[algernon]

Yes, Sieve is where I got the inspiration from, except this'd run filters on the client side. My first thought was to allow arbitrary JavaScript functions (gets the status/notification as input, returns a list of tags), for maximum flexibility. But this would only work for clients that can support running JS.

[pointlessone]

I would argue that both Sieve and JS are suboptimal from UX point of view. Not all users can write code for what Twitter and others can achieve with a simple UI. Moreover, it’s hard to share code. On top of that while Sieve is code at least it’s not Turing-complete, JS can do arbitrary things including leaking your private toots, stealing your credentials, posting as if it was you, mining crypto currency, or really anything.

It’s a powerful solution, but I’m convinced it’s wrong on many levels.

[algernon]

JS - and code - if exposed on the UI is wrong, indeed. It's wrong for the average user who just wants to manage lists, but it is a powerful tool for the advanced user who wants complicated rules. Having JS at the lowest level, and building a limited set of exposable features on top of it would benefit both those who just want lists (they'd have an UI that acts like that, where you can export / import lists), and those who want to do more complicated things.

Yes, it can be abused, but that's a price I'd be willing to live with for the power it'd give me.

(For the record, the client I'm working on, will have JS functions under the hood, with a list-like UI built on top of it. You'll be able to take control of the full power of JS if you host the client on your own, and use the list-like UI otherwise.)

[mkosler]

+1 for this functionality. Lists are great for aggregating similar accounts together, like game development or political news.

Questions and suggestions for the feature:

• __Server versus client?:__ I use both the web app and a mobile app and would like to be able to share my lists across all my apps.
• __Public, subscribeable lists?:__ I don't think this is a good idea. The pros are publicly curated lists that users can jump into without having to do the work themselves. This is great for things like keeping up with political news or following a sports team without having to track down "the good accounts" yourself - like an obscure Supreme Court reporter or the local sports talk radio account. There are a lot of cons related to harassment, however. Trolls often use lists to coordinate harassment. One person adds a user a public list, and then other trolls subscribe to that list and harass those users in the list. It also allows for easy bootstrapping for a troll. If they get banned, then all they need to do is create a new account and subscribe to the list and they barely missed a step. Twitter tries to get around this by notifying a user if they are added to a public list, but even then, users are burdened with more self-policing. Is this "Women in gamedev" list on the up-and-up, or is it more nefarious? Even if it is on the up-and-up, trolls can still use it to track their victims, which means now the list creator needs to police their lists, and the rabbit hole keeps going... All in all, I think the bad outweighs the good on public lists.
• __Add accounts to lists without following them?:__ I don't like the idea of not knowing if someone is tracking me. Sure, they can "track" me in the Local and Federated Timelines, but that's a morass to filter through. You would also likely need to notify an account they have been added to a list, and provide the account a way to prevent that from happening, whether per list or altogether. You'd also need to put in rules for not allowing a blocked account from adding your account to a list, prevent private accounts from being added to any lists or only being added to lists by people they already allowed to follow them, etc. I think a lot of edge cases can be fixed by only allowing followed accounts to be added to lists.
• __Accounts in list appearing in Home Timeline?:__ This falls out from the bullet point just above. If you have to follow an account in order to add it to a list, then you'll get that account's toots in multiple places at once. This isn't a huge problem on mobile apps, because you likely are only viewing a single timeline at a time, but on the web app, you'll see the toot all over the place (home timeline, local timeline, all lists that account belongs to, maybe even if your notifications). Currently, this already happens with the Local and Federated Timelines, so the easy answer could be to maintain the status quo. But, there could be something like a column priority. Something like Lists > Home > Local > Federated, i.e. if an account appears in a visible list, then it appears in that column only, otherwise it appears in Home if visible, etc.

[pointlessone]

My 2¢.

• Server versus client? Definitely server. It'd be extremely tedious to set up lists on all my clients: web, desktop, phone, tablet. And if I get a new device recreating all lists from scratch sounds like an exercise in tedium.
• Public, subscribeable lists? Yes, please. It's harder to discover new account to follow in Fediverse: no fediverse-wide hashtags, no full text search. Thematic lists are fantastic. I don't have a solution for harassment problem. Maybe banning lists the way one can ban a user would help?
• Add accounts to lists without following them? Probably not. ActivityPub has a concept of an _actor_. Users are actors. Actors have inboxes and outboxes, and following (collection of other actors this one is subscribed to). This seem like a natural way of representing a list. The only problem (which probably is not) I see is identification of lists. Like, @[email protected]/my-precious-list. I don't know if that plays nicely with ActivityPub. I haven't read it closely.
• Accounts in list appearing in Home Timeline? Please, no. Taking into account previous point it seems natural that a toot would only appear in timelines that are subscribed to a specific user. I would also suggest that hiding a toot from other timelines because it was _seen_ first elsewhere is not good. Presence/absence of a toot may affect overall context. Also "first seen elsewhere" makes toot presence non-deterministic. Moreover, it requires implementation of the "seen" concept which is completely absent from Mastodon at the moment.