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.