Jonas Schäfer March 2021 Update: Safety and Responsibility

At the beginning of March 2021, the first room was removed from the listing. In the surrounding events, new features have become desirable which have partially been implemented or put up for public discussion.

This post gives a bit of background on the situation, the new features and other things I would personally like to see in the ecosystem.


What is is a search engine for public chat rooms (channels) in the Jabber instant messaging network. I deployed it in mid-2018 and have been maintaining it ever since. It works by asking all servers it knows about for public rooms, puts them in an index and allows users to search them by keyword.

March 2nd, 2021

On March 2nd, 2021, was taken offline. This was after a user in the XMPP Operators group chat reported a room which allegedly allowed specific illegal content without any moderation. As I was threatened in the course of events to be held liable for that -- it was a rather heated and miscommunicative discussion -- I disabled the service without further notice.

The original reporter and I then were able to have a respectful discussion behind the scenes and managed to come to an agreement. I also was handed necessary evidence (which I was able to validate) which was sufficient for me to remove the room from the listing.

With that sorted out, the service came back online.

The 2021-03 Update

Room Blocklisting

This feature only exists behind the scenes, but it is a crucial tool for me, as the operator of the service. It allows me to add individual addresses to a list which will never and under no circumstances be contacted.

While I previously had this on the domain level to exclude domains where the owners had contacted me to not be queried, this implementation is different:

  1. Internally, it works on a different layer. The room (or domain) will stay excluded even if the complete room database is lost or rebuilt, because it is now part of the service configuration.

  2. The check is made earlier in the system and more efficiently, saving resources and defending against possible attacks from blocklisted domains or rooms.

    The second point is important as previously, the blocklisting was a service to the domain owner. Now we have to treat the blocklisted entities as an adversary and need to be more cautious.

Listing Policy

To make it clearer which content is tolerated on the listing and which is not, a listing policy has been formulated and made available in the Terms of Service section of the service.

This is not set in stone yet. I anticipate that I have to amend it to handle specific cases where it doesn’t quite fit exactly what I’m looking for yet. Yet, it is a start to give users some guidance about what to (not) expect.


In the interaction on March 2nd, 2021, it became clear that this service lacks an approachable point of contact for such issues. This is why now gained a dedicated Report a Room page.

While currently this page only ties together links to the Listing policy and the contact information already present on the website, having it in the navigational footer sends a message: it makes it clear that I am interested in getting such reports and keeping the listing healthy.

Clean up

In January 2021, someone approached me to point out to me that the username used by the crawler in the past (christopher.muclumbus) was offensive. That... Makes sense. I kind of was aware that the pun was not of the best taste when I originally started the project. I did not anticipate it to grow that much and the legacy stuck with it.

Being a technical detail, changing it had some implications, which is why it took over a month to sort out correctly. Now the crawler bot uses a neutral (and much more descriptive) name:

In addition, the use of white/blacklist in the public facing websites (there are some technical details in the backend which are harder to change) as well as the use of master as a branch name has been rectified. We now use allowlist, blocklist and main, respectively.

Future Work

To make the service more useful for use cases where specific content is (not) desired, I proposed an XMPP protocol extension which allows to transport labels which describe the content: XEP-0456: Content Rating Labels.

While how this will be used or transported by is not fully fleshed out yet, I anticipate that this can be used to provide safer and/or more fine grained search results.