From Wobbly Wiki
Jump to: navigation, search

This is a list of some of the existing, planned, and potential features of Wobbly and how we're thinking of them.

Minimum Viable Product

These are the core features we need for the Wobbly MVP. We will implement all these before moving to the beta (see Versioning).


The core of Wobbly is a solid group messaging system. As decided in a poll, we are starting with a forum like structure with messages organized into threads.


Workers organizing on Wobbly can create different types of polls -- perhaps starting with just single or multiple choice. This is a requirement for syndication (i.e. voting on forming or joining supernodes). In the future, we can also envision using voting to elect e.g. moderators of a group.


Some sort of moderation features to get rid of spammers, abusive group members, etc. There are two options:

  • group members vote on each moderation instance, i.e. banning a user from the group
  • group members vote for moderators

We will need to speak to users to decide on one of these options.


A key feature. Workers using Wobbly first join or create a local group. From the introduction to Wobbly:

If workers in nodes want to do things like pool funds, make shared resolutions, strike together, organise shared events, they can form a supernode. [...] The McDonald’s Princes Street node and the McDonald’s London Road node create a proposal to form a supernode called McDonald’s Edinburgh. The members of the local node vote on the proposal, and if it’s successful, a new supernode is created that the other branches of McDonald’s within Edinburgh can also join. Then, using mandated recallable delegates (or some other democratic system) to communicate, the supernode can coordinate the local nodes that constitute it, and direct the shared resources towards their chosen ends.

Delegates of this supernode can then join or form supernodes at an even higher level.


Less of a single feature than a way of thinking about the app. We aim to consider the specific security threats faced by workers and organizers, for example management breaching a group. How do we make this difficult? How do we minimize the damage if it were to happen?

End-to-end encryption

We'd like to encrypt communication over Wobbly (starting with messages) such that we have no knowledge of what Wobbly users are talking about. Voting may not be encrypted, since the server will need to know the outcome of some polls in order to create supernodes, etc.

Other ideas

Wiki-style forum posts

The IWW Cardiff branch mentioned that they really want a document store. Wobbly is not a competitor to Google Docs, but having a shared list of links to important documents would be very helpful for them. Instead of building this specifically (it seems that it may be a niche requirement) we could make pinned forum posts that anyone can edit (and with replies disabled).

Post templates

Wobbly has the potential to nudge workers to use tried and tested communication or organization strategies. One way of doing this is through post templates -- for instance, when clicking the "new post" button, users can either a) write a thread title and the first post or b) create from a template.


A federated system could be more resilient to some threats as there is no single point of failure. There are also downsides including technical complexity.