Idea for federation implementation: Make subs virtual ActivityPub users


#1

I got this idea a couple of weeks ago:

Make the subs “virtual users” with special rights.

Let’s use an “at-hash” (@#) convention for denoting subs, for illustration purposes only.

So let’s say user “@animefan111@myanime.social” (made up names) wants to create a sub dedicated to “DragonGoal”, a (made-up) superpower martial arts football anime.

So he sents a request to the administrator, and user “@#dragongoal@myanime.social” is created. @#dragongoal is a bot, obviously, but handled by the server.

So in the database, @#dragongoal has @animefan111 in its “moderators” list, and also as the top mod… somehow.

All posts must be addressed to @#dragongoal only. User @#dragongoal has a set of rules. For example, if the sub has only approved submitters, only users FOLLOWED BY @#dragongoal can submit. Messages sent to @#dragongoal are ignored.

Users are banned via standard Mastodon-like user blocking: If a user, say, “@trollz” is blocked by @#dragongoal, his posts are ignored.

Now, when a post is accepted, the SUB, in this case @#dragongoal, copies the post text and publishes it “in the poster’s name”. But by making the SUB and not the USER as the originator of the messages, replies are sent to the sub, so it’s much more manageable. In the same way, users subscribed to the sub wouldn’t see all the replies, they’d only see the sub’s posts.

Subscriptions are managed by simply following the sub. If the sub is closed to subscriptions, its user is simply blocking followers and they have to be approved manually. What the sub does is messaging the moderators (in private) with a notification. Only the moderators could see it, because it’s a “private message”.

Replies to a post must also have a header, or mention @#dragongoal as the first body of the reply, and the software must first try to message @#dragongoal to verify that the user is not banned. Also, if the user replying-to is blocking the sender, the message should also be blocked. (Note that muting and blocking isn’t the same - you could mute a user but the conversation would go on)

The user would also send a message to @#dragongoal like in IRC format, to change the visibility of the post (if implemented or allowed) or to delete it:

@#dragongoal /setpostvisibility postID private

And user @#dragongoal would only obey the command if set by the posting user or by the moderators, or an admin.

To ban a user, the mods send a special message to @#dragongoal with a command, like @#subname /ban user time reason

Example: @#dragongoal /ban @trollz@badserver.social forever “no trolls allowed in here”. Of course, that’s part of the API, the UI would be a window dialog or something.

Conclusion: By making subs a special kind of ActivityPub users (with their own inbox and outbox), the ActivityPub implementation handles the low-level details of message handling, and federation is taken care of in posts, comments and moderation.

This turns the forums into a layer that goes on top of ActivityPub, possibly simplifying development and allowing for third-party implementations of the forums. (But we’d need to write an API for how the forums are handled).

ADDENDUM: If we want to go one step further, we could make @[email protected] another bot using similar mechanisms:

For example, making a sub would require to send a local message: @!admin /makesub “dragongoal” owner @animefan111

Or @!admin /addadmin @prismo

And so on. (@!admin would only listen to local administrators)


Thoughts?


#2

Hey there Rick!

Thank you for this extended description. You know what? It’s gonna be implemented exactly like that :slight_smile: We’re following the gnusocial convention in here and each group is basically an AP actor you can follow and interact with.

Moderators/admins of group are other actors/users with special permissions to change group details and settings + eventually take care of the private messages inbox of the group (it’s not planned but who know what future brings).

Everything is gonna be handled via the Prismo UI so the commands stuff you described is not necessary i think.

The last thing to consider is how to mark the groups - you proposed a hash-bang notation which is pretty interesting approach (and probably mastodon-or-anything-compatible) but gnusocial is a pioneer in that matter and they used a bang notation [email protected] so i’m for it. On the other hand, as far as i know, Mastodon author said one day he don’t like the bang notation so mastodon will not use it probably (if ever). I think it deserves a separate topic with contributions of all the other AP developers as it’s not a standard yet and it would be cool to came up with something together.


#3

Sweet! You just got me hyped now.