While going through the development plan of Plato today, we defined a set of requirements that we need to resolve somehow. We’re hoping to find a solution that fits, but it’s possible that we have over-specified our way into a dead-end.
Very short brief
Plato is the umbrella term for a package of software to steward grassroots organized places and events. It’s a package that we will offer as a bundle that comes with a tried and tested methodology, but all the different components of Plato can also be run on their own. Some of the software of Plato is custom built from scratch while other parts are slightly modified or extended versions of available open-source software.
Plato Dreams helps an organization come up with, refine and prioritize between projects to work on and fund. It is similar to an internal Kickstarter, but where projects are tied to a collective fund that resources are distributed from by the org members. Dreams has a GraphQL API.
Plato Realities helps an organization keep track of who is responsible for what, what the dependencies between responsibilities are, and how these responsibilities are carried out. It has a GraphQL API.
Discourse is the preferred discussion platform for Plato. When Dreams is paired with Discourse, each Dream has a Discourse thread that serves the comment section to Dreams through the Discourse API. When not paired with Discourse, Dreams has its own native comment system. Discourse has a REST-API.
Edgeryders OpenEthnographer and Graphryder are used in Plato when paired with the Edgeryders flavor of Discourse, to enable ethnography of a community conversation.
Plato Discourse plugin is planned to allow a user to label a thread on Discourse as belonging to a specific Dream or Reality by selecting from a list of options relevant to the organizations and events the user has access to.
Pretix, an open-source ticket platform, can be paired with Dreams to issue tickets to community events. Having a ticket on Pretix to an event on Dreams allows a user to participate in project creation and participatory budgeting. Pretix can be extended with plugins. Pretix has a REST-API.
We are building Plato in 2020-2021 and testing it at Blivande and Frihamnstorget. We will run at least two festivals at Frihamnstorget using Plato during this time – one in the fall of 2020 if the situation allows for it, and one in the spring of 2021.
In 2021 we (SenseStack/Edgeryders) aim to sell Plato to clients who manage places, organize festivals, want to try participatory conferences, or need innovative ways for community engagement.
Requirements and preferences
We want Dreams, Realities, and Discourse to be separately deployable and still be useful
We want to enable a single sign-on to Dreams, Realities, and Discourse.
We want to control which organizations a user belongs to on Dreams and Realities from a single place.
We want to have access to the Edgeryders ethnography software on Discourse
We want the Blivande Edgeryders forum to host the first iteration of Plato for Blivande
We prefer the SSO integration to Dreams and Realities to be based on a protocol like OAuth2 that makes it likely to work with potential future client SSO requirements.
We want user bios, avatars, and contact details to be set in Discourse when Plato is deployed with Discourse, and that information could then be displayed on Dreams and Realities.
We want to give a user access rights to the right Dreams event automatically when a ticket is issued to that user through Pretix.
We want the Pretix ticket issuing flow to involve a step (through a Pretix plugin) where a user either logs in with their existing SSO account or signs up for an account through a single step.
We would like the confirmation e-mail for a new account registered through the Plato Pretix to be contextual, for example welcoming a user to the Festival community on the Blivande forum.
We want our chosen solutions to be scalable with Dreams, Realties, Discourse and Pretix deployed for production where new organizations can be added at a manageable cost.
Coming up with a solution
Alternative 1: Using Discourse as the SSO provider
Our first go-to solution was to use Discourse as the SSO provider and id-provider. This would look something like this:
Problem 1: Non-standard solution
To the best of my understanding, there is a recommended way for how to use Discourse as an SSO provider. However, it looks a bit hacky and very specific to Discourse. This is contrary to one of our preferences:
- We prefer the SSO integration to Dreams and Realities to be based on a protocol like OAuth2 that makes it likely to work with potential future client SSO requirements.
Problem 2: Org membership
How would we define belonging to an organization on Edgeryders communities? When a user logs in with their SSO enabled account to Dreams and Realities, we need to be able to pass information from the SSO provider on which organizations the user is a member of. One way to do this could be through defining groups on Edgeryders Communities, but I don’t know if that would work as expected.
Problem 3: Confusing registration process
A user who just wants to participate in an event and buys a ticket to that event will get confused by getting a confirmation email from “Edgeryders Communities”. Seeing that I’m just getting people at Blivande used to Edgeryders, it’s a bit much to ask from someone at the community entry-level.
Would it be possible to somehow keep track of where a registration originated from and send a confirmation email accordingly? Would it also be possible to automate bringing the user to the right sub-forum without having them need to click the right icon?
What comes to mind is a Discourse plugin where any number of custom parameter strings are paired with confirmation email massages and target URLs to continue to after email verification. Perhaps there are other, better solutions.
Alternative 2: Logging in with a third-party SSO
Another alternative that might work would be to add a stand-alone id and SSO provider like Keycloak to the Plato stack. However, since we want to use the Edgeryders fora for Plato, we would need to allow for a third-party SSO provider to act as an OAuth2 provider for Edgeryders Communities.
This solves all problems above but introduces new problems.
That would look something like this:
Problem 1: No idea if viable for Edgeryders Communities
I have no idea if this would work or if it would cause all kinds of problems.
Problem 2: Introduces an extra piece of software with marginal benefits
Adding another identity provider does not seem as elegant. However, using a dedicated id-provider also gives us access to standard auth protocols and a more powerful way to handle user permissions in a central place.