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 “@email@example.com” (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 “@#firstname.lastname@example.org” 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 @email@example.com 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)