Rewrite of Dreams for multi-tenancy and wider adoption

Dreams has been used by The Borderland and other burns since 2016. It has enabled the participants to co-create the events by allowing any participant to create an idea (a dream) of something they want to do, set a budget, and then letting all participants decide what to fund collectively with tokens representing a part of their membership fee.

Dreams is a prime example of technology coming out of the participatory culture and something that has good potential for wider adoption and usage. But adopting this platform and process for your own event requires a lot of specific technical know-how, as a single deploy can only handle a single event, meaning that you need to set up and deploy your own version of Dreams to use it for your own event.

Rewriting Dreams to allow multiple organisations and events to use the same instance would lower the barrier for it to be used by not only more and smaller burns that do not have the resources to set up and run its own deploy, but also opening up the possibility to use it for other types of events and gatherings and in other networks.

Building a Minimum Viable Product (MVP) of a multi-tenant Dreams
I’ve talked with @hugi about leading the development of an MVP funded by Participio, using a similar tech stack as Realities, another Participio project (with the biggest difference being using a more traditional database here):

  • UI: React, Next.js, Apollo Client
  • API: GraphQL server using Node.js, Express and Apollo, with a Postgres database

Goals of MVP

  • allow multiple organisations and events on the same instance
  • make it possible for a smaller event to adopt the Dreams process without needing any technical know-how (admin of event might need to do some non-technical manual work, like giving out tokens to the correct members)

MVP user stories

  • to be determined

Future development possibilities but outside of MVP scope

  • integrate with OpenCollective to use it as the financial backend, to handle the money part and expense reimbursements, reducing a lot of manual and tedious work that takes place today
  • build support for custom integrations per organization, like Keycloak (used by Borderland for single sign on), Loomio, ticketing, etc

Why a rewrite?

  • Tech debt and developer happiness. The current platform is built in Ruby on Rails, and has developed some tech debt over the years. I was part of the Participio Dreams hack in March, and the general feeling I sensed among the developers was that it was a pretty cumbersome to work with. Small changes taking a long time to implement. While an experienced Rails developer would have no trouble being very productive in Rails I think it becomes increasingly hard to find people wanting to work on this tech stack, myself included…

  • Another factor is the benefit of using a similar tech stack as Realities (which is also, arguably, a more modern and popular tech stack) and making it easy for developers to switch seamlessly between them. Using GraphQL there are some neat things you can do in stitching two schemas together, reducing the data barriers between the platforms.

Open questions

  • Name. Is this a Dreams 2.0 or something else?
  • What other use cases beyond burns can you see for the Dreams process?

Feedback welcome! :slightly_smiling_face:


Yes! I’m excited about this. Dreams is indeed quite cumbersome and frustrating to work with these days. Remember also that the original Dreams architecture was never built for multi tenancy or even for the social functions we built into it in 2019. It seems like it might be time to take what we have learned and rebuild it with all of our lessons learned. I’m very happy that you’re picking this up!

Financially, I will use the rest of the money in the Participio fund for this development. It will be managed in an OpenCollective organization which will also be possible to donate to through crowd-funding to extend those resources. I will be the owner of that org, but @gustav will call the shots on who gets paid for what, as the do-ocratic leader of the new Dreams.

@jakobskote has some ideas about how it might be used in cities, and I’ve also had ideas along those lines. @nadia and I have also spoken about idea for using Dreams for the Edgeryders “festival” and event format.


Such things are always sad to read for developers and maintainers. I’d love to continue working with Ruby and/or Ruby on Rails and wish you that the chosen stack will lead to a more maintainable solution. At least PostgreSQL will not be a moving target :slight_smile:

I mentioned the project today in a chat of people from which is a conference/festival/gathering - probably close to the current use case.

DreamTeam :wink: ?


Thank you for pointing this out! :heart: I’m very much spouting out my personal technology preference as some sort of truth, sorry about that. I don’t know if I have to point it out but the original Dreams platform is awesome, no matter my very biased tech stack preferences, and the people that built it deserves a lot of credit. There will be a lot of shameless copying and stealing of ideas, as we are essentially building a multi-tenant clone.

I hope this project can be seen as some kind spiritual offshoot of the original Dreams platform, with the goal of taking its magic to more places than before, without necessarily trying to be a successor or replacement. If you would like to use the Dreams process and know some Ruby/Rails, the original platform should be the way to go still.

As for PostgreSQL, it actually might be the most moving target here :sweat_smile: , as the idea has been to stick close to the stack of Realities, except for its graph database which seemed overkill for the use case here.

Very cool! I think these types of gatherings/conferences would be great to have in the indented audience for this :slightly_smiling_face:

1 Like

Things are starting to take shape! Here is the repository on GitHub:

The proposed tech stack is put in place (with the slight tweak of using MongoDB instead of Postgres, more info in the tech stack issue) with a GraphQL schema currently encompassing users, memberships, events, dreams.

Everything on master is deployed here:, individual events are on subdomains:, and while there is not too much to see in terms of a frontend right now you can interact directly with the graphql API here:

Next step is adding authentication and after that getting a basic UI going, to create event, create dream, display dreams etc (here is a GitHub issue with user stories for the MVP).

1 Like

Great news! :slight_smile:

It would be good if the schema is consistent with Realities when possible and relevant, for example having the same nomenclature for a Person, user etc. Just a minor thing, but makes it easier once we want to link them together.

Makes sense!