Create a gist now

Instantly share code, notes, and snippets.

What would you like to do?
The Pursuance System: Status

Components: LeapChat and Ensue

The first publicly-released version of the software that makes up the Pursuance System will have 2 major features/components: chat, and task management.

These features are split into 2 separate, independently-valuable apps (that is, independently of each other as well as independently of the Pursuance System), namely:

  1. LeapChat -- end-to-end encrypted chat in the browser (which we've already launched; see, and

  2. Ensue -- end-to-end encrypted task management optimized for large groups of volunteers.

These apps' React components will be combined into a separate app, "Pursue", to create the front end of the Pursuance System.

The Interplay Between Chat and Task Management

Each pursuance will have many associated tasks. Each task will have its own chat room for discussing the details of what should be done, how to achieve that tasks, etc.

There will also (almost certainly) be a pursuance-wide chat room.

One way chat and task management will directly tie together: whenever someone creates a new task, a message will be sent into the pursuance-wide chat saying that that new task has been created, and some information about it. And the task creator's client will likely send out messages/notifications to the people who have all the skills required by said task, asking if they want to do it.

Unique Features

Here's what differentiates Ensue, which again is Pursuance's task management feature:

Task/Participant Auto-pairing

When you have a non-trivial number of people participating in a pursuance, they're not going to know each other's skill sets, and therefore won't know who they should assign a task that they think someone should complete, or that they personally need done as a sub-task of whatever they are working on.

Other task management systems do not scale in the ways we need them to.

In Pursuance, when a new task is created and the skills necessary to complete it are specified (by tag), participants within that task's pursuance who have all of the requisite skills will be notified and asked if they'd like to be the assignee. (Users will add their skills to their respective profiles so that this pairing can occur.)

Automatic task reassignment

Volunteers are flaky. Someone will often volunteer for a task, or otherwise have a task assigned to them, and not do it.

When a task's assignee hasn't made recent progress, Pursuance will either ask the task's creator or reviewer if they want to ask its assignee for a status update, or Pursuance could automatically, periodically ask for said updates from assignees without first asking the reviewer if these messages should be sent out. But the interesting part is: an unresponsive or otherwise seemingly not-working-on-the-task assignee can be given, say, 24 hours (or a dynamic amount of time depending on the "velocity" of the pursuance, which we can measure by tracking changes in the task phases) to respond or to make progress or do something, after which, if nothing is done, our software can automatically reassign this task to, say, the last person who logged in who has all of the skills required by the task, or to the person with the most karma points with all the requisite skills, or to the person who invited the current assignee to the pursuance in the first place, or some other auto-calculable variant.

...and in writing this, I just realized that the tasks's reviewer, not just assignee, could be auto-reassigned in the same fashion if a task is finished but the reviewer doesn't mark it as done for some period of time.

End-to-end encryption

For private pursuances, tasks will be encrypted, in which case the server will not be able to see the title, description, deliverables, etc of a task in unencrypted form, just its relation to other tasks, who it's assigned to, who its reviewer is, and its phase/how close it is to being completed.

The crypto library we are currently using is miniLock, which has undergone a thorough security audit by the venerable Cure53. miniLock enables us to deterministically generate a passphrase from (1) a username or email address and (2) a passphrase. From the user's perspective, they will sign into Pursuance as they would sign into any other website or app (other than us requiring a stronger password), but in this case we are generating a keypair for that user, which JavaScript running in their browser (and, later, their native app) uses to encrypt and decrypt content.

Each private pursuance is associated with a unique passphrase that is used to generate a unique keypair using miniLock. That passphrase is generated in the browser/on the device of the user who created that pursuance. When a user is invited to a private pursuance, the invite includes a copy of this passphrase.

Tech Stack

Pursuance is all React on the frontend and Go + Postgres + PostgREST on the backend. (Adding TypeScript to the React code would be nice to do at some point, though I'm not sure when.)

The strategy: write React code once, publicly launch a web version of the Pursuance System by October 2017 (after a lot of prototyping and private testing), make a bunch of improvements based on user feedback, then reuse 80% of that code to build a React Native version for Android and iOS, and also a native desktop version packaged with Electron.

Especially Useful Contributions

Any ideas that you, dear reader, have for making task management great for large numbers of volunteers that don't know each other would be especially useful to this project.

I think we really need to be able to: (1) represent task dependencies, and (2) say in-app that you're blocked and what's blocking you (so the person in charge of the blocking task can be automatically notified).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment