It’s hard to communicate bonfire in a single - effective - easy to grasp value proposition (and imho that’s not necessarily what we have to do , given we do not need to adhere to the corporate mainstream startup-ish marketing plans ), while at the same time we’re not willing to retreat upon all the narratives, scenarios, possibilities (or SF for the Donna Haraway readers) that we’ve in mind when we speak or wonder about bonfire.
In this thread I’d like to list a few of the scenarios that we care to investigate with bonfire, and how they may fit together - the intention is to eventually open a discussion about how communities and interested peers may fit into it and help shape or fork such scenarios into unexpected ones.
- Bonfire is a place your community is happy to call home.
- Bonfire is a playground for experimenters.
- Bonfire is a device to start-up communities anywhere, anytime.
1. Bonfire is a place your community is happy to call home.
Any action that involves more than one person is mediate by dialogue, therefore we decided to focus our efforts on releasing a federated social network first.
But, quoting Carl Sagan:
That’s right dear Carl, as we have no interest in simply developing yet another social network that is bound to the team preferences or market interests, but rather we want to encourage each community to shape their own instance in unique ways. Most of the effort put into the last 2 years of development - discussions - refactoring - development was to build a minimal core module, a flow to install and add/remove/fork extensions, and a set of extensions that can be installed to perform a wide range of activities and that can be easily replaced by different ones.
The long term goal is to let admins to setup, shape, install modules and configure any aspect of their own instance through a GUI, without touching a line of code (but we’re still not there and it will not be the case for our first release).
Our idea of customisation spans from:
-
Appearance
How the instance looks like, from picking a theme, or create a new one (defining which color palette, the default font and emoji sets to use) to edit or remove elements on the pages:
Which are the interactions you want to be notified about?
How do you want to be notified?
Do you want to show both the banner image together with your avatar one, do you want to hide both of them?
Do you want to show the amount of likes your posts managed to get or the amount of followers a user has?
Bonfire can be a way to experiment with dopamine/attention economy free social networks (Shoshana Zuboff - Wikipedia) and much more.
Also developers can build new frontends to explore diverse user experiences, forking the existing module or creating new ones, without the need of maintaining the whole codebase fork up-to-date. -
Language
This includes both adding new languages to enhance internationalisation, but also give the possibility to edit the terminology used within the app. You do not like being identified as a followers, or you’re not really liking a post? Terminology is an essential part for enhancing inclusivity and must be done collectively, as well as leave room for freedom of experimentation. -
Features
Extensions are basically new features that can be added to your instance. Such features can span from enabling governance activities (such as a voting module, or a whole sociocracy flow to deal with decisional processes), to economic ones (such as coordinating the work load and the resources available within a community, from planning all the activities, to track the work done and the resources produced, transferred and consumed to distribute the value generated through custom value equation formulas to all the participants Read more about valueflows here ). -
Alghoritms
Which topics do you want to highlight in your instance? which ones do you want to hide away? How do you want to deal with fake news, spam, bots, fascists? Alghoritms can be a powerful way to address todays communication issues, if they’re community-owned and developed.
With bonfire, we want to give the possibility to each instance to decide which alghoritms they want to include (if any) to shape which kind of information reaches their own audience and how - in a transparent way.
At the end, giving the possibility to collectively address such questions, posing new ones, disagree and discussing them again with your community, test the answers on the instance, and change the code together with evolving community values and priorities can be summarised as the result of most of the bonfire value propositions combined together. Something that may end up with effectively “feeling at home” when logging into your community instance.
Most of these questions open up even more questions that I am eager to discuss (therefore the other 2 points will be discussed in separated threads):
- How we can effectively coordinate bonfire development so that priorities and features are shared among different communities and teams ?
- How we can co-design features from the ground-up in the open?
- How we can reach sustainability and support grassroots initiatives at the same time?
I swear It was not my initial intentions to raise so many questions in a single thread 
