From Wobbly Wiki
Jump to: navigation, search

Note: there are currently no plans to build Wobbly on top of XMPP. This article is kept here for posterity.

XMPP came about in the early 2000s, and so the core protocol is geared towards a pre-mobile world. It was written for users who were either online in front of a desktop computer, or offline and thus could not be reached. However, there are extensions that make it usable on mobile clients.

XMPP extensions are called XEPs (XMPP Extension Protocol). These enable things like multi-user chat rooms (XEP-0045), downloading old messages from the server (XEP-0313), or uploading images (XEP-0363). There's even an extension for WhatApp- or Signal-like encryption called OMEMO.

There's an XEP to create more mobile-friendly, WhatsApp-like groups. It's called XEP-0369: Mediated Information eXchange but the protocol is still in-progress and not production-ready.

Using XMPP for Wobbly has several benefits:

  • Easy federation. If we want to, we can allow anyone to set up a server while still being able to communicate with all other Wobbly users. This means that there's no single point of failure.
  • Existing encryption protocols makes it (relatively) easy to enable end-to-end (E2E) encryption. Note that while it's easier, E2E still has many tradeoffs.
  • There's a lot of software for XMPP servers out there. Popular ones include ejabberd and Prosody.
  • We can do many of the fancy Wobbly-specific things we want with existing extensions. For example, voting could be implemented using Data Forms (XEO-0004) as suggested in this StackOverflow question.
  • If we stick purely to existing, well-supported extensions, then users could technically access Wobbly groups through any XMPP client they like that supports all the client-side features. For simplicity we might not want to advertise this, though :)

That being said, we also have to be aware of the downsides of this architecture.

  • XMPP multi-user chatrooms (MUCs) have strict hierarchical requirements. There must be an owner of each room who has complete control over it. If we create a dummy account/bot to be the owner of all rooms, then end-to-end encryption won't do us much good (since control of the room will lie with us anyway).
  • Putting metadata on MUCs (e.g. which groups are super- or sub-nodes) isn't straightforward.
  • New developers have to be familiar with XMPP and how it works. It's a pretty common standard, but some devs may be more familiar with standard REST frameworks.
  • Push notifications aren't standardized for XMPP servers. Other projects have solved this problem in their own ways, e.g. Fixing the XMPP Push Problem or MucSub. The point is that we don't get it out-of-the-box for free.
  • It's difficult to implement highly custom features since they'll require a custom XMPP extension. For example, we can easily make groups password-protected or be invite-only, but it would be hard to implement something like groups where you have to apply and members vote on whether or not to grant access.

End-to-end Encryption

With a federated architecture like XMPP, end-to-end encryption becomes increasingly important. Otherwise, a malicious actor could set up a server like `totally-a-real-union-and-not-the-government-i-swear.com` and snoop on the communication of all its users. Note that even with E2E encryption, server admins can still see metadata about its users like IP addresses and message from/to fields and timestamps. See this article for more criticism of the information that XMPP server admins have access to (but also see this rebuttal -- Google-translated).

Here are some tradeoffs of using E2E encryption in the context of XMPP:

  • If we set up voting using XEP-004 Data Forms, then it means that any poll is only available to the current members of a group -- and not any members that join later while the poll is open (I think. I'd be happy to talk through this with someone).
    • Similarly, old messages won't be available to new members. I think this might actually be preferable for Wobbly.
  • XMPP Multi-User Chatrooms (MUCs) have a very hierarchical power structure that we may not want -- there is one owner, then moderators, then regular members, then visitors (who can only read, not write, messages). One way to get around this hierarchy is to have a chatbot as the owner of all groups, but then we lose out on the benefits of E2E encryption since the chatbot (and thus the server) will be able to see all messages.
    • We may be able to remove all the owner privileges through server settings, but I need to verify this.