A down-side…

One side-effect of having the ability to share subscribed lists is that you don’t have to actually subscribe. The list itself will be viewed as a single subscriber, even if 10 people are using that list. I assume multi-reddit had this same general issue. And, of course, “All” works that same way.

So some communities may feel like their subscriber count is low compared to “users/week”- which Lemmy does go out of way to show both… so It’s kind of covered by the “users/week” which IIRC - counts posts and comments as active users. Not sure if voting in a community counts as activity…

Some random notes:

1. featured on/off allows switching of list. Useful for some kind of music rotations / etc.
2. featured on/off also gives history of changes if desired, or just edit
3. Only fully-qualified community names, including domain name

!finneganswake@bulletintree.com and

!multipass@bulletintree.com

I created a posting about the privacy concern of sharing community list openly: https://lemmy.ml/post/3663416

Worth a mention…

One thing that MultiReddit has on Reddit… is a way to specify on the URL which communities you want blended. Example, 2 subreddits in one URL: https://old.reddit.com/r/BlackPeopleTwitter+WhitePeopleTwitter/

I’m currently not including that ability in the scope of the design. As there are multiple front-end apps for Lemmy in active use and expanding the development scope is not what I’m looking to do ;)

MultiReddit was widely introduced in 2013, a decade ago. But Reddit already supported blending multiple communities OTHER than the Join/subscribe/member list…

It’s the idea of sharing the lists with others more deliberately that was what was new in 2013.

With Lemmy, I think there is more need than ever to discover communities and explore. There has been an explosion of instances and communities, finding the quality ones is where a good Multi editor group comes in…

I think some people don’t look at this as a pretty straight-forward topic: right now Lemmy has only one Playlist for what you want, and it requires you to log-in to even use that Playlist. Having the ability to change Playlist is pretty core to any multi-media tool.

Even if the design solves the “multiple people can edit the list” problem, there are many issues within Lemmy right now that do not make it robust. Right now, there is no way to re-home a community when the home instance goes down. That would still impact MultiPass - because the edits to the PlayList/CommunityList would still have to be federated/replicated to all other instances by the home instance the community was first crated on.

If anything, this project serves to highlight some of the longer-term needs of Lemmy’s core programming.

Progress today…

1. I hacked two new parameters into the post/list API for lemmy_server. after_when=number, where number is ms since Unix Epoc. This puts a filter on the post listing to do published > that timestamp. The second parameter is multipass_creator_id=number, where number is the Lemmy person id of a local user. This allows you to borrow another local user’s subscribed list, and is utilized when _type=Subscribed on the post listing.

2. I created a PostgreSQL FUNCTION that can parse Lemmy markdown and produce an array of all community names found within the text.

3. I created a PostgreSQL SELECT statement that finds communities marked moderator-only posting and scans for the featured post in there community, then sends the body of the posting to the community name search mentioned in step 2 above.

4. I experimented with creating negative person id in the lemmy person database table. They seem perfectly fine and do not interfere with the sequence of new users signing up (and I assume federation incoming person entries).

It’s a bit convoluted… but basically to create a “multipass list”, you create a new community which you mark as moderators-only allowed to post. Then you create a post in that community, feature it (pin it / sticky it) to the top… and edit the body of that post with a list of communities you want to be part of the list.

This leverages federation… because a community can appoint multiple owners by adding moderators. And any moderator on any instance can un-feature a post and feature a new-post, changing out the list. The posts will get federated too, sending the list to other instances.

There are still some steps missing:

1. the creation of negative person rows in the database would need to be accepted by the core Lemmy developers as a technique. It gets around needing to add any new database tables and change any of the existing code in Lemmy. Because this fake-person will be used to create a community subscribe list.

2. The community subscribe list for the fake-person hasn’t been coded yet. I will probably do it in pure PostgreSQL FUNCTION so I don’t have to mess with Lemmy’s Rust code.

3. The sharing of ALL user’s community subscribe list has some potential privacy objections. I encourage Lemmy users to not make this a privacy issue - that your subscribed community list be any kind of “secret”. But if it does end up being a concern that people don’t want that exposed… we could limit it to negative person id numbers, only the fake-person created by the code would be allowed to be used as “shared” subscribe lists.

4. Using PostgreSQL FUNCTION keeps me from having to modify the Rust lemmy_server code, but I still need a way to initiate the rebuild of the community list for the multipass-communities. To do this efficiently, probably have to add to the scheduled jobs that the Rust code runs in lemmy_server - maybe every 15 minutes. In theory an existing TRIGGER could be enhanced to try and do this… but probably better to keep it on something less-common like community editing/update.

Some general down-sides of this design:

1. It clutters up the person table with one fake-person per multipass community list. These person will not be moderators, they will not be creating any posts, they won’t have a login (local user table), they will not be creating any comments or any messages of any kind. They just exist so there is a person to associate subscribe lists with (In theory it could also be used to create shared block-lists of community, but that would require more API parameters for post/list to be added).

2. It clutters of communities. A big point of the design is that they get shared between instances. It might confuse people. So some naming convention for these communities such as zzz_games would probably make some sense. But ultimately, I think more development needs to be done with Lemmy to enhance the community/list API and front-end for lemmy-ui (and other apps) to better sort, filter, and organize the communities list. And a new attribute could be added to community like “moderator only posting” that distinguishes it as a multipass-community.

3. I haven’t bothered with the “listing comments” instead of posts, I honestly never use that feature of Lemmy except for debugging.

This is the best design I could come up with that requires the LEAST amount of Rust programming changes. The core Rust programming change is to add one new parameter, multipass_creator_id=number to pick which of these multi-community lists you want for listing posts.

I went with this option because I felt it could be implemented pretty easily, I could see people wanting a more whole separate API, database tables, and even federation replication logic to share between instances. It’s actually the federation sharing that I found to be the most difficult problem to take on, which was why I choose to make a community the central means of transporting the list data. It’s be a much bigger project to do it ‘proper’ with a whole set of multi-community API.

Now I could turn this whole problem on it’s head and propose a new Lemmy to Lemmy JSON data transport. Define some tables and conventions for blobs of JSON data to be shared between instances. PostgreSQL functions can parse JSON and work with it too. It could be as simple as having an API client and requiring operators to run an app to poll it… this could have future uses such as backfill replication.

Federation is very message oriented, not a general purpose means to transport data… from what I’ve seen so far. But I could see things develop where people want to use Lemmy as kind of a data-replication and sharking platform for things related to the central purpose.

Locking posts is another replicated attribute… mod-only post community, featured post, locked post…

Wait, we could use an obscure language! That gets replicated. A community set to a combination of languages?

Big Picture

Even if the server-side doesn’t accept the desired changes… this convention could be done by front-end apps and smartphone apps. If we can figure out a way to flag communities so they know to read the top post in that community and process the list of community names in it…

{{multipass:all_games@bulletintree.com}}

Submit to Lemmy a new language choice, “multipass”?