Fediverse – XMPP Bridge for administrators

Introduction: what is an administrator?

If you haven't already, please start by reading the user guide to get familiar with the main functionalities. Link: here

This guide is for administrators of the Bridge; a so-called “administrator” is a standard user with special privileges which allow you further control over the Bridge operations and global moderation actions.

It is a different role than the server administrator, who has full control over the bots and the system backend installation and operations. In practise, it could be the same person behind, but it doesn't have to be. The server administrator role is not described here but is presented with the source code on the project's page.

The server administrator is also the one who grants the administrator role to one or several accounts (both #XMPP and/or #Fediverse), who can be on any instance. It is optional but recommended to assign at least one administrator for Fediverse and one for XMPP; in order to receive reports by users, it is mandatory to have at least one XMPP administrator (of whom the first one will receive such reports if configured).

As said, administrators can act as normal users. Let's focus now on the additional commands they have. This list of commands can be queried using !ahelp

Privacy considerations

Before that, a word about privacy.

Fediverse does not support end-to-end encryption (E2EE). Therefore, it makes no sense to try and implement E2EE from XMPP, so all messages are sent and received in clear text. It doesn't mean they are publicly visible and in fact they are not: but they are simply protected by access control rights, just as direct messages in Mastodon are, as an example.

As for any bridge which acts as a proxy to send and receive messages, this has the following implications:

• Your XMPP and your Fediverse instance administrators can read your messages (as with any other non-encrypted message).
• The Bridge server administrator, who also controls the bots, can read your messages (until they are deleted automatically after 30 days).
• The Mastodon instance administrator hosting the first bot, and the XMPP instance administrator hosting the second bot, can read your messages. It could be the same person as for the previous line, but it doesn't have to be.

In our case on GayFR, the Bridge server administrator, the gayfr.social Mastodon administrator and the gayfr.live XMPP administrator are the same admin.

But in a scenario where Bridge administrators are none of the above, they will not have access to messages contents nor metadata.

So again, introducing a bridge means inserting a person-in-the-middle able to intercept and read all your messages. You need to trust that person, or better still, you are encouraged to run your own instance of the Bridge on your server.

Final word: ActivityPub and the Fediverse do not provide any means for E2EE nor effective privacy. If that is what you are seeking, you should use other tools (XMPP alone does, though, using OMEMO if your client application supports it).

Bridge status

You can enable globally the sending / receiving of messages using the command !start and you can disable it using !stop

You can open new registrations to the Bridge using the command !open and you can close registrations altogether using !close

Either way, the other operations of the Bridge will all remain available, and you can query the current status for both parameters with the command !status which will also tell you if the Bridge is set to greenlist mode (see below).

Finally, you can get a list of all active users (non-revoked accounts) and their application origin using the command !alistu

Moderation capabilities

Protection against abuse is a major feature of this Bridge. Standard users already have the following features available to them, as a reminder:

• Fediverse users have to register voluntarily first, before they can send or receive any message (opt-in). If they don't, they will never receive anything from the Bridge.
• All users can unregister at any time and if they want to be sure not to receive anything from the bots, just block them as you would any other account.
• Personal blocklist can be managed by each user to block any Fediverse or XMPP user, the commands are !block, !unblock and !listblock as presented on the user help page.
• Finally, any abuse can be reported directly to the Bridge administrator using the command !report which will be sent to the first XMPP admin.

Also, during registration, elementary checks are done to try and filter out possible spammers or to respect privacy choices: no bot nor group accounts, no #NoBot nor #NoBridge hashtag in profile, minimum publicly visible activity during the last month.

In addition, the Bridge administrator can perform global moderation actions which we shall describe below.

Global accounts moderation

You can globally block an account (or a list of accounts) using the command !ablock, which will in effect also unregister the account(s) if it(they) are already registered and prevent it(them) from registering again.

You can cancel this using the command !aunblock (which will not, however, register the corresponding accounts, if necessary they will have to apply by themselves again).

The list of globally blocked accounts is available using the command !alistb

Global domain moderation

You can manage list of domains to either redlist (all accounts using that domain name are forbidden) or greenlist accounts. For the latter, there are two different ways of working:

• If the Bridge is set to greenlist mode (by the server administrator): only the accounts which belong to that domain name are authorized to register.
• If not: accounts which belong to the greenlist will skip the activity check minimum requirement during registration.

Redlist has a higher priority than greenlist, in other words, a domain which appears in both will be redlisted. Also, blocked accounts wil remain blocked even if in a greenlisted domain.

Domain names must be exact: there is no hierarchy and subdomains must also be blocked if that is your wish.

You can globally block a domain (or a list of domains) using the command !addred, which will in effect also unregister all corresponding accounts if they are already registered and prevent them from registering again. You can cancel this using the command !delred, and list all with !listred

The commands !addgreen, delgreen and !listgreen will do the same for the greenlist, with the following differences: adding a domain to the greenlist will do nothing more, but if (and only if) the Bridge is set to greenlist mode, removing it will unregister all corresponding accounts if they are already registered and prevent them from registering again.

Finally: if a domain is blocked by the bot server (Mastodon or XMPP), it will obviously not be able to use the Bridge at all as it won't be able to contact the bots.

Deployment scenarios

To conclude, the Bridge offers many tools for moderation and protection against abuse, and is flexible in how you can manage your users.

Consider the following scenarios:

• You want your Bridge open to all? Just use the standard settings and manage blocklists, redlists and greenlists, this is the setting we use on our Bridge.
• You want your Bridge open to a limited community? Ask the Bridge server administrator to set it to greenlist mode and define your greenlist.
• You want your Bridge to serve only your local users? Do as previously and keep the greenlist empty (local bot domains are always allowed).

Installing your own XMPP/AP Bridge

You are encouraged to install your own Bridge, for privacy and scalability reasons, in the spirit of federation. The project's home page will be published shortly.

Use for Good, not for Evil. And enjoy!