Shared/Collaborative User Lists

[extratone]

Pitch

Instance-bound (I'm assuming federation-wide implementation would be extremely difficult) shared user lists primarily associated with the creator's account. A rudimentary administrative privilege system (read-only, can add, can delete, etc.) would be ideal. Perhaps users could be offered an option to follow the list and another to follow all users in the list.

Motivation

From my perspective, lists are the most powerful curatorial tool on the social web. The common obstacle for new Mastodon users in "finding accounts to follow" would be offered a substantial remedy, I believe, in public-facing shared/collaborative user lists. A view showing basic metadata about the list (description, list of collaborators) with its own permalink might offer new users significant context.

[alexstandiford]

This would be a huge improvement, I think, especially if lists curated on an instance gets indexed as-if they were being followed.

Imagine a scenario where I am self-hosting a single-user instance of Mastodon, and I want to be able to fill my feed with relevant content. A fast way to do that would be to follow a set of pre-made lists of people, across the fediverse, who have similar interests to me. This would allow me to find, and index clusters of people on my personal server quickly.

For example, some of my personal interests include WordPress, Travel, and a digital nomad lifestyle. If I could follow curated lists that contain people who frequently talk about those things, I could have a single-user instance that automatically indexes content I'd probably like. To me, this feels a bit like I'm creating my own mini algorithm of content I'll probably like, and then I can follow/un-follow people based on the curated results.

I know that this is a significant undertaking (perhaps impossible?) but I think it would have a profound impact on how people use Mastodon in-general, and could pave the way to make Mastodon run smaller instances across more servers.

[ChrisWiegman]

Chiming in to mostly echo @alexstandiford 's sentiments. One of the issues I hear in trying to evangelize the platform is discovery and this could go a long way to helping solve that.

[jasontucker]

I agree with @alexstandiford @ChrisWiegman discovery is definitely hard when you’re on a fairly empty instance or one that’s just starting up so I think this idea would be a great one to try and implement. Some of us follow some really great people. This would be nice to make them shared into a list.

[alexstandiford]

I will mention that there is some nuance to this that should be considered beforehand. It seems like there's privacy concerns revolving around lists that should be considered here before making this a feature.

https://scholar.social/@researchfairy/109285701189842320

I don't think it's impossible to accomplish, but perhaps lists should be consensual before this feature is implemented. Maybe it's a user-level permission, where a person can force people to ask for permission before they can be added to a public list, or something like that?

This could also be taken a step further, and make it possible for a person to always have access to view all of the lists they are currently a member of, and allow them to silently remove themselves from that list at any time.

[Lukas2112]

I would not limit a "share" function to lists, but extend it to, for example, filter groups (from Mastodon version 4.0.0).

cc: @ClearlyClaire

[SheilaMAverbuch]

Can I upvote sharing lists publicly please? I am part of the children's publishing industry and it would save everyone time, facilitate discovery and smooth transition to Mastodon if I could publicly share the lists I'm building of librarians, teachers, authors and bookshop owners. People who don't want to be on lists could be 1) unaddable (if they have locked their followers but allowed me to follow them, I would not be able to add them to a list) but 2) if they are already on the list, any posts they publish that are set to public are the only ones that would be visible. Is this too to difficult to code?

[Timothyjchambers]

I will mention that there is some nuance to this that should be considered beforehand. It seems like there's privacy concerns revolving around lists that should be considered here before making this a feature.

https://scholar.social/@researchfairy/109285701189842320

I don't think it's impossible to accomplish, but perhaps lists should be consensual before this feature is implemented. Maybe it's a user-level permission, where a person can force people to ask for permission before they can be added to a public list, or something like that?

This could also be taken a step further, and make it possible for a person to always have access to view all of the lists they are currently a member of, and allow them to silently remove themselves from that list at any time.

You could let each user have a setting in their account with a radio button "allow me on public mastodon lists?" And if they opt out, then they can only be added to private lists.

[Timothyjchambers]

Many, many people from the Twitter migration are now having to do this same sharing of list features and signing up to be added to lists via web apps or public spreadsheets. This feature clearly hits a need and could be so much more gracefully done this way.

[alexstandiford]

You could let each user have a setting in their account with a radio button "allow me on public mastodon lists?"

It would be nice if you could even say "let me choose which lists I'm added to" or something like that, as well.

So you could either:

• automatically be added to any public list
• require approval to be added to a public list
• block all public list requests

Then, it would be nice to also have access to a list of all public lists you've been added to, so you can go back and remove yourself should you change your mind later.

I think this creates a good opt-mechanism for people who don't want to be added to lists, or perhaps they're sensitive to what list they're added to and want to ensure they don't get thrown on some list being made by a bad actor. This also covers circumstances in which a person gets added and they later decide they don't want to be on it. This would allow people to leave when someone makes an inocous list, adding people to it, then changing the name or something disparaging.

The only other improvement I could see is setting up notifications, so that when someone updates a list's name, the people on that list get notified.

Related conversation in this thread: https://fosstodon.org/@alexstandiford/109348269566641747

[fezzik02]

what if there was a nomination process:

• list user "nominates" a user to a list
• the server target but not the username of this nomination is mapped to a UUID for the list
• the full request is sent to the target server and entered into a nomination lifecycle on the target
• the target server will help the target user through the lifecycle of the nomination, and record results
• when retrieving a list from the list owner server, a list of servers which have received nominations and a UUID is tendered
• the client can then query the nominee's servers for lists of users who have accepted matching nominations
• a user can fetch their list of list nominations from their local server at will and CRUD as necessary

so at the end of the day, the list is a list of servers with possible members, and each server has a map of users to consented lists (and of course various nomination lifecycle events).

this prevents the remote server being able to leak nominees that have yet to consent - I think.

[alexstandiford]

what if there was a nomination process:

* list user "nominates" a user to a list

* the server target _but not the username_ of this nomination is mapped to a UUID for the list

* the full request is sent to the target server and entered into a nomination lifecycle on the target

* the target server will help the target user through the lifecycle of the nomination, and record results

* when retrieving a list from the list owner server, a list of servers which have received nominations and a UUID is tendered

* the client can then query the nominee's servers for lists of users who have accepted matching nominations

* a user can fetch their list of list nominations from their local server at will and CRUD as necessary

so at the end of the day, the list is a list of servers with possible members, and each server has a map of users to consented lists (and of course various nomination lifecycle events).

this prevents the remote server being able to leak nominees that have yet to consent - I think.

A nice bonus of this - it would probably make it possible for instances to index the people on this feed (not sure if it would be in other scenarios). Again, this would be really useful in cases where a person is running a private self-hosted instance and want to ensure they can connect with people relevant to their interests without following thousands of people manually.

[fezzik02]

instances to index the people on this feed

depending on which side, yes. I know it's not easy to police client behavior, but I think the expectation would be that the map of list members to list ID would only exist on the instance of the list member other than short-term caches on remote servers.

this helps protects the list member's ability to revoke membership.

[lisardggY]

I think public lists - and the ability to insta-follow a public list - can be a very powerful use-case for new users onboarding. We know that one of the main hurdles of onboarding to Mastodon is the anxiety of choose an instance - it's not clear how meaningful the choice of server would be, and how hard it would be to switch. If the choice of instance gives you one axis of discovery, a public curated list for a given topic, organization or community (e.g "web devs in London", "alumni of school X", etc) can give you an additional axis of discovery. Suddenly the instance you've chosen isn't the only community you're subscribed to.

[lisardggY]

In fact, this can lead into a more complicated feature - a list/feed comprising a combination of users and hashtags. Let's say I have a list of "SF and Fantasy fans in Israel" (one of my communities). This feed, by itself, doesn't guarantee to be related to SF&F, just that it's comprised of people in that community. But a combination of three features - curated public lists, hashtags and post visibility - can create a powerful tool: a list is combined with hashtag, say #sff. Anyone following it will see the posts from people on the list, but only ones that are tagged with #sff. This gives us a curated feed organized by people and topic. I can not only follow fellow SF&F lovers in Israel, I can get a view of their posts on that topic.

This can then be extended even further by adding a new post visibility level - "list only". These posts will now not show up in public timelines but also not in home feeds, but only in list feeds. If "Direct"-visibility labels are a way to emulate private messages on top of the activity stream, then "List" (or "community") visibility labels allow you to post only to a list-community.

Hashtags started on Twitter, way back when, as an attempt to create IRC-like channels, with the client automatically filtering hashtagged tweets from the main feed and showing them only in dedicated "room" channels. Twitter recently started implementing that with their Communities. This can be done on the #fediverse by adding these features.

[zesty]

The main friction for me is that I have to follow every member of a list. This means that if I use lists to manage multiple interest areas—as opposed to creating multiple accounts—my home feed becomes unusable. Seems like adding unfollowed users to a list would be a prerequisite for sharing lists, unless there's going to be a notion of a Sharable List parallel to a Regular List, or forcing the follow of all list members.

off topic, but related: adding hashtags to a list

[naught101]

Partial solution to @zesty's comment: #6982 - add accounts to list without following them

[maphouse]

public lists please :)

[eloquence]

I see an entry "Lists" on https://joinmastodon.org/roadmap under "Planned" as AND-9. Is that intended to describe a shared list feature similar to this issue?

[alexstandiford]

I see an entry "Lists" on https://joinmastodon.org/roadmap under "Planned" as AND-9. Is that intended to describe a shared list feature similar to this issue?

I'm not on the team for that, but looking at the rest of the list I think that's specific to the android app. I think "AND" is a prefix for the app.

My guess is general support for lists is slated for the app.

[shafik]

Adding my voice here, this was one of the most useful features of twitter for me was the ability to create a C++ twitter list and share it and grow it over time. This is a feature I very much miss as I try to use twitter less and less.

This allowed C++ twitter to collaborate and ignore the rest of the noise in a very easy way.

I feel like this would make the C++ community way more cohesive. I think that applies to all other communities but I can only speak personally for my main community.