Bonfire

The story of Bonfire's visual identity

2021-05-21T00:00:00Z

Everyone carries a history of contamination, purity is not an option.

This short statement by Anna Tsing in Mushroom at the end of the world encompasses a lot of the visions and needs that inspired our work on Bonfire.

We are building this piece of software for us and for the diverse communities we care about, so we strive for diversity and flexibility in every aspect of the Bonfire codebase.

We want each Bonfire instance to be autonomous and unique in its own particular way, while having a shared purpose with the other bonfires:

To create safe environments for users to inhabit and create their own culture together, while remaining in control of their personal data and experience, and being able to communicate with the fediverse at their own pace and on their own terms.

It was no surprise that words like contamination, burn, revolution, rebirth, bottom up, diverse, autonomous, nature and ecosystem were among the most used during our brainstorming about Bonfire's visual identity.

We wanted our visual identity to reflect such ideas without obfuscating itself under an overly sanitised and minimalist design. We enjoy navigating through complexity, without the burning desire to be in control of everything, and wanted to avoid the flat, metallo-plastic, stark, silicon valley style that has dominated the web in recent years.

Other than a social network, Bonfire is a playground and experimentation platform, we are learning how to take care of it and take care of ourselves - building in the open so that Bonfire can become an ecosystem open to many other peers.

We had the pleasure to work with Rocco Lombardi, a talented artist living somewhere near the Bolognese Apennines, who guided us and turned our wishes into meaningful visual representations of the project.

We asked Rocco to work on our visual identity primarly because of the style and subjects of his artwork. Forests and trees that emerge by scratching the light away from black paper, animals that fight capitalism, all sort of organics - wild and lived entities contaminate his drawings and we wanted that world to contaminate our software as well.

"Squirrels on the air" - Illustration by Rocco Lombardi - Link

The end result is very much in tune with our expectations, and we hope you like it too.

As we're progressing toward a first release of our software, we are happy to have added this important step and we thank Rocco to have joined us on this journey. :-)

First steps toward federated project coordination

2021-07-14T00:00:00Z

tl;dr #

In March 2021, the Bonfire project was awarded a "Next Generation Search & Discovery" grant from NLNet Foundation, and since then the team has been working on a series of Bonfire extensions to help create the next generation of federated software.

This is the first of a series of posts discussing the development process, work coordination strategies and the challenges we are currently facing.

One of the funded milestones led us to build a project coordination app as a bonfire extension and flavour.

But wait: why are you building another project coordination app? #

Our coordination tool shares a lot of functionality with most to-do apps out there - you can create lists, add tasks to lists, commit to complete work, set a due date, and so on...

So how is this different?

1) We want to federate coordination between many people, groups and organisations on different instances #

On top of the usual features like writing posts, following users and browsing feeds, a Bonfire instance using the coordination extension will make it possible to create lists and tasks. Users can then favourite, boost, comment, flag and adjust the visibility settings (or in the case of a Bonfire instance, choose the boundaries and circles their lists and tasks are published to).

As soon as users start publishing tasks, a new type of activity appears in the feeds like below:

Users can interact with such activities by assigning a task to themselves, searching for tasks that fit with their skills or interests, or following a task to be notified about future discussions or progress.

Users from any instance can thus start planning together: sofware projects, events, creative collaborations, peer production, etc - without having to leave the app and with the same account they already use.

A user can decide to create a private list to share with specific people, or open it to all users of their instance or beyond. At every point the user will be able to control both the visibility (who can see todos or comments), as well as the permissions and roles for each list and task (who can add/edit/comment/vote/assign/etc).

2) We needed it #

We are always seeking to improve the coordination between contributors and the various projects linked to Bonfire. We aim to iterate on the design and build a p2p coordination system that we are happy to work with and would welcome other non-hierarchical and cooperative-minded groups to join us in designing and building these tools together.

3) Interoperability #

Powered by ValueFlows #

We are building upon a well designed and tested vocabulary to bring p2p coordination to a whole new level. In short, ValueFlows does for economic activities what ActivityStreams (the main vocabulary of the ActivityPub-powered fediverse) does for social activities. Using these standard vocabularies means that every feature and user interaction can federate not only with other Bonfire instances, but also with instances of other software which implement them.

Lists (which can represent projects or milestones within a larger project) can include dependencies from other lists, as well as tracking work, but also resources, shared inventories and needs (this ties in to our work around mutual aid, which will be the topic of a future blog post).

Users can have discussions around a task, as well as record different kinds of economic activities to keep track of physical or digital resources. They can also simply log the amount of hours or the outputs (eg. git commits) of their work on a specific task.

Furthermore, it will be possible to define formulas (aka value equations) to help calculate the distribution of value generated by a project to all of its participants, based on their recorded contributions and previous agreements.

So what looks on the surface like another to-do list app, is actually a small UI layer (the bonfire_ui_coordination extension, with only 1110 lines of code) on top of larger and more general economic extensions which are poised to be used for many different kinds of applications. These are bonfire_ui_valueflows (which currently has over 2500 lines of reusable UI components) and bonfire_valueflows (sitting at a whopping 16150 lines of database and API schemas and logic), and many more...

ForgeFed #

Besides ValueFlows, we plan to participate in the ForgeFed effort.

ForgeFed is an upcoming federation protocol for enabling interoperability between version control services. It is built as an extension to the ActivityPub protocol, allowing users of any ForgeFed-compliant service to interact with the repositories hosted on other instances.
The goal of the project is to support all of the major activities connected to project management, including bug reports, merge requests and notifications across instances.

Given that we are coordinating our development using this tool, it makes sense to connect the dots between issue reporting and work coordination, code contributions (version control and merge requests) and economic contributions (along with the related value calculations). We hope to implement ForgeFed functionality to do more of this and interoperate with other tools in the near future.

Join us! #

Would you be interested in trying alpha-stage software and participate in its design and creation process? These tools are still missing some important features, several of which we've committed to build as part of other milestones, and we greatly appreciate your input about how to design and build it futher according to your needs. Please get in touch.

Let a thousand bonfires bloom

2021-07-20T00:00:00Z

tl;dr #

This is the second of a series of posts discussing the development process, work coordination strategies and the challenges we are currently facing.

The first post was about creating a coordination tool..

The second funded milestone was about creating themeable User Interface modules.

Why building themeable apps ? #

Dopamine and attention manipulation are not inherent properties of a social network. They can be replaced by healthier behaviours and other ways of connecting humans and exploring collective intelligence.

It is time to reconsider questions like:

What should appear in my feed?
Are number of likes and followers important to me?
What do I want to be notified about?
How do we want to take decisions within our community?
Does the UX reflects our identity and priorities?

Of course the Bonfire team have opinions about all of this. But we think our opinions are valid mostly for ourselves, and we do not want to impose our views upon others. There is a diversity of valid answers worth exploring.

Social networking plays a critical role in our lives, and everyone should be able to decide how to define their online identities and how to interact with others, without an app imposing the boundaries of their experience in one way or another.

How we're building it #

A Bonfire app (or flavour) is basically a set of configurations that describes how a bunch of extensions should plug and play together.

Extensions can include new sections in an existing page (e.g. a widget that shows one's most used hashtags on a user's profile page), whole new pages (e.g. a map page that shows me where my friends are located). They can use existing data from any extension (aggregating, transforming and filtering it to create meaningful and new information for the user), or new sets of information stored in the database.

Imagine installing an identity extension that enables every user to define how to represent themselves online with fined-grained controls.

Or installing the ValueFlows extension, which can give the instance economic superpowers: users can now record the production or transfer of any kind of physical or non-tangible resource, keep track of inventories, assign tasks, record work done, and reward the community based on a set of parameters previously defined.

Each community may need the ValueFlows extension for very different purposes. One instance may only need a shared todo list, and the whole economic network idea might be overwhelming for them. A mutual aid network on the other hand, may be looking to define and keep track of different types of economic resources and activities within their community, and would need a more detailed dashboard and set of pages, widgets and relationships between the data produced to deal with such level of complexity.

That's how modularity really makes a difference: the ValueFlows extension does not impose a user experience or user interface. Based on each specific use case, users can pick (or create) a compatible UI extension that better fits their exact needs. Using the ValueFlows example, it means that so far we have more than 4 extensions: with data schemas and application logic in bonfire_valueflows, reusable/customisable UI components in bonfire_ui_valueflows, todo/coordination UI in bonfire_ui_coordination, mutual aid UI in bonfire_breadpub...

Federation will be a mess #

Yes, and it will be fun!

Each instance will likely have to deal with different and sometime unknown data types that will come through federation from users of other instances.

Imagine an extension for book lovers, used to catalog, recommend, and review books. It will likely have a specific way to represent such activities in feeds with a set of actions to perform over them (add to reading list, review, reply...).

Other instances may not have that extension installed, so they will have to decide how to handle unknown activities, if and how display them (this is because on the "fediverse", users from different instances running different software can all follow each other).

An instance (or individual user) could choose to display the unknown activities, using a preview widget contributed by the authors of the book lovers extension (and added to a shared Bonfire extension used by all instance, such as bonfire_social), or deal with unknown activities using a default component which shows only the main information (such as a title, summary and link) formatted in a standard way, or just not displaying extra activities in feeds.

That's quite a new usability challenge, which seems inevitable when dealing with the fediverse and open networks in general, and one we are embracing as a way of welcoming and encouraging diversity and plurality - rather than hiding them away for the sake of "clean UX".

A UI toolbox for customizable social network apps

2021-07-23T00:00:00Z

Bonfire:UI:Social is an extension that includes the main User Interfaces (both assembled pages and single components) required to have a fully working federated social network app.

The UI:Social extension is meant to be used by extensions like Bonfire:Social and Bonfire:Me, which both provide logic for the UI to work with, and define the routes and top-level views which in turn embed UI:Social components.

UI:Social also provides components used by other extensions including: Bonfire:Common, Bonfire:Search, Bonfire:Tag, Bonfire:Boundaries.

Stack #

So far, Bonfire UI extensions are built with the PETALS stack (note that is not a requirement), which means:

We're currently in the middle of a refactor to convert all components and templates from LiveView to Surface, which is a server-side rendering component library (built on top of Phoenix and LiveView) that inherits a lot of design patterns from popular JS framework like Vue.js and React, while being almost JavaScript-free compared to common SPAs.

Scaffolding #

The relevant folders are:

Components: Surface stateless and stateful components.
Layout: Main app templates, they include guest, logged or specific view templates (eg. the setting layout)
Views: The main pages that are rendered when navigating to a specific route
Test: All the unit tests for the specific module.

Other resources #

A blog post that introduces the concept of themeable bonfire apps

Notes on the first neapolitan meeting

2021-10-14T00:00:00Z

The image above is a photo taken at the ex-asilo filangeri, one of the Neapolitan urban commons.
It is a neapolitan way of saying which means: "every head is a court". This article is the first of a set of posts about an hopeful fruitful interaction with a group of neapolitan activists interested in experimenting with bonfire.

As we’re approaching a new phase in which bonfire is not anymore a chimera among few devs, but it’s starting to come together as a nice tool, some of us are anxious to make raids in the analogic world and spread the big news: bonfire exists!

Today I visited Naples for the first time after the beginning of the pandemic. I met some friends and discussed about how bonfire could be useful to their communities and practices and how communities and practices can be useful to bonfire.

There’s many reasons I always thought at Naples as the first place to discuss a possible bonfire adoption, all of them rotate around a single yet powerful concept: contamination.
In my experience as a developer, contamination is one of the most feared and therefore dismissed aspect when building a software. Speaking of bonfire, being able to respond and adapt to contamination is its core value proposition. Needless to say, Naples is the shangri-la of contaminations and I am lucky enough to have friends who navigate this ocean of contaminations and contradictions in a superb way.
When I cite Naples i'm referring to participants of the urban commons network. Activists that most of the time cross different places, communities and initiatives. In front of the oldest restaurant of Via dei Decumani, we started wondering about the possibility of lighting a few bonfires in Naples.

Below a list of not exhaustive topics we brainstormed during the day:

There is a general tension to restore practices after the pandemic
It's hard for a community already used to communicate/work with a specific software (even if closed source or whatever) to shift to a different one. It's a lot about changing habits, and picking new habits requires trust, energy, time, mental effort...
For some users, dealing with huge and complex apps is an overwhelming experience - sometime they just need a little app that solves a functional/pressing issue, leaving everything else aside.
Sometime community members have difficulties using even the most trivial/hegemonic/widespread apps like whatsapp, facebook or google drive - or they feel repulsion for the digital world at scale, how could it be possible to not exclude them from the community flow of discussions / coordinations / decisions that takes place online ?
Different participants have different priorities and needs about how to be part and be involved with each community and such differences are reflected in the tools they are up to adopt and how they want to use them.
Nonetheless it sounds to be a good historic moment for the neapolitan network to bring back the discussion about adopting a platform for the urban commons network.
Speaking of using bonfire for coordinating work and productions - there's an on-going, crucial even if sometime stale conversation that gravitate around income, activism, distribution of value and commons goods.
Is it possible to envision and approach a software as a common good itself rather than a mere service/product?
What would it mean for a software to be a common good?
In which ways a community can take care of a software?
What would imply for a software to be a common good from the governance perspective?
How bonfire can foster co-design and community-driven development?

Suggestions for next extensions #

Current bonfire extensions: Social, Kanban and Offers/Needs - even if still under development - caught the eye because in a way or another they answered current needs of different communities.
Nonetheless during our conversations two new extensions were cited several times as worth to note.

Federated calendar #

It's hard to coordinate initiatives among different communities and organize events that do not cross existing ones. At today, this requires lot of chats and schedule changes at last moment. Having a federated calendar would allow activists to have a general view across everything that's happening within the network. This would greatly enhance the activities planning and coordination.
The calendar should span across different levels: it would allow users to view all the activities planned in the wider network and zoom in/out to specific area/communities, as well as filter for specific topics or date range. We didn't investigate further how such federated calendar should work, but it's all good food for thoughts.

Federated governance #

How to take decisions and how to implement a governance system that reflect the community vision was also briefly touched during the brainstorming session. At present some experimentations were made using Framavox and loomio - mostly as a sentiment analysis tool when discussing new proposals.

Where to go next #

During our chats we didn't pretend to answer any of the questions that arose - neither It was the scope of this post. We agreed to meet again in a couple of weeks - bringing more minds to the table - and keep the discussion going as well as start playing with bonfire.

Announcing the Zappa project

2021-12-26T00:00:00Z

We are pleased to announce that Bonfire has been awarded a grant from the Culture of Solidarity Fund to support cross-border cultural initiatives of solidarity in times of uncertainty and "infodemic".

The grant will be used to release a beta version of Bonfire Social and to develop Zappa – a custom bonfire extension to empower communities with a dedicated tool to deal with the coronavirus "infodemic" and online misinformation in general.

The Zappa extension #

Zappa will be powered by user communities' assessments of content (links, news, videos, pictures) to develop common practices and patterns to fight misinformation.

These assessments will then be used to train experimental artificial intelligence engines.

The user ratings (along with optional input from AI predictions) will generate decentralised "Zappa scores" which may help users classify and act upon content based on each community’s methodology and preferences.

We didn't go much further in outlining how Zappa might work, for the time being preferring to stay with ambiguity as much as possible, because while we have some ideas, we want to co-design it together with interested communities and we welcome you to join the discussion and participate.

How to participate in the Zappa project? #

We will keep track of our work and deliverables in our milestones, which includes running sessions to come up with user stories that will guide development.
Feedback and open discussions will take place on the Zappa topic on the SocialHub forum (we may create more topics when needed)
You are welcome to join the Bonfire chat and engage with the team

As always, we will report progress and news here on the blog, so stay tuned!

Countering misinformation in federated social networks, an introduction to the Zappa project

2022-02-08T00:00:00Z

This post was originally published on Doug Belshaw's Open Thinkering blog

One thing I’ve learned from spending all of my adult life online and being involved in lots of innovation projects is that you can have the best bookmarking system in the world, but it means nothing if you don’t do something with the stuff you’ve bookmarked. Usually, for me, that means turning what I’ve filed away into some kind of blog post. It’s basically the reason Thought Shrapnel exists.

Last week I started some new work with the Bonfire team called the Zappa project. Bonfire is a fork of CommonsPub, the underlying codebase for MoodleNet.

Self-host your online community and shape your experience at the most granular level: add and remove features, change behaviours and appearance, tune, swap or turn off algorithms. You are in total control.

Bonfire is modular, with different extensions allowing communities to customise their own social network. The focus of Zappa is shaped by a grant from the Culture of Solidarity Fund.

The grant will be used to release a beta version of Bonfire Social and to develop Zappa – a custom bonfire extension to empower communities with a dedicated tool to deal with the coronavirus “infodemic” and online misinformation in general.

The announcement blog post talks of “experimental artificial intelligence engines” and “Zappa scores” which may be longer-term goals, while my job is to talk to people with real-world needs right now. As I’ve learned from being involved in quite a few innovation projects over the last 20 years, there’s a sweet spot between what’s useful, theoretically sound, and technically achievable.

Last week, I met with Ivan to try and do some definition of user groups and the initial scope of the project. It’s easy to think that the possible target audience is ‘everyone’ but it’s of much more value to think about who the Zappa project is likely to be useful for in the near future.

Priority areas for stakeholders, user groups, and themes
The above Whimsical board shows:

a list of people we can/should speak to (we’ve spoken with two orgs so far)
themes of which we should be aware/cognisant
groups of people we should talk with

The latter two lists are prioritised based on our current thinking and, as you can see, it’s biased towards action, towards those who don’t have merely an academic interest in the Zappa project, but who have some skin in the anti-misinformation game.

A note in passing: many people use ‘misinformation’ and ‘disinformation’ as near-synonyms of one another. But, even in common usage, it’s clear that they have an important difference in meaning.

We’d say, for example, that someone was ‘misinformed’, in which case their lack of having the correct information wouldn’t necessarily be their fault. On the other hand, we might talk about state actors waging a ‘disinformation’ campaign, which very much would be intentional, and probably focused on creating a mixture of fear, uncertainty, and/or doubt.

The line between misinformation and disinformation can be blurry, but it’s probably helpful to conceptualise what we’re doing in the terms of the grant: to help “empower communities with a dedicated tool to deal with the coronavirus ‘infodemic’ and online misinformation in general”.

One of the resources that I’ve found particularly helpful (and which I wish I’d seen before presenting on Truth, Lies & Digital Fluency a couple of years ago) is Fake news. It’s complicated. Its author, Claire Wardle from First Draft, lays out 7 Types of Mis- and Disinformation on a spectrum from ‘satire or parody’ (which some wouldn’t even conceptualise as misinformation) through ‘fabricated content’ (which most people would definitely consider disinformation).

Some of the differences between these types can be quite nuanced, and so I found the Misinformation Matrix in the post really useful for looking at the reasons for the misinformation being published in the first place. These range from sloppy journalistic practices, through to flat-out propaganda.

What the user research we’re doing at the moment is focused upon is what types of misinformation human rights organisations, scientists, and other front-line orgs are suffering from, how and where these are manifested, and what they’ve tried to do about it.

So far, we’ve discovered that countering misinformation can be a huge time suck for people who are often volunteering for charities, non-profits, or loosely-organised groups. It seems that some areas of the world seem to suffer more than others, and particular platforms are currently doing worse than others. All of them could, of course, could do much better.

We’re still gathering people and organisations for this project. So if, based on the above, you know someone who you think it might help us to talk to, then please get in touch! You can leave a comment below, or get in contact via email.

Some interesting findings from user research for the Zappa project (so far!)

2022-02-18T00:00:00Z

This post was originally published on Doug Belshaw's Open Thinkering blog

One of the things about working openly is, fairly obviously, sharing your work as you go. This can be difficult for many reasons, not least because of the human tendency toward narrative, to completed stories with start, middle, and end.

The value of resisting this tendency and sitting in ambiguity for a while is that allows for slow hunches to form and serendipitous connections to be made. So it is with user research I’m doing as part of the Zappa project for the Bonfire team. We need time to talk to lots of different types of people who meet our criteria, and to spend some time reflecting on what they’ve told us.

As I wrote in my previous post about the project, we’d identified some of the following:

a list of people we can/should speak with
themes of which we should be aware/cognisant
groups of people we should talk with

Inevitably, since this initial work, we’ve come up with some obvious gaps in the people we should speak to (UX designers!). The people we’ve spoken with have recommended other people to contact as well as avenues of enquiry to follow. This is such an interesting topic that we need to be careful that the project doesn’t grow legs and run away with us…

10 interesting things people have told us so far #

We haven’t started synthesising any of what our user research participants have said so far, but as we’re around halfway through the process of conducting interviews, I thought it might be worth sharing 10 interesting things they’ve told us. These are not any any particular order.

Countering misinformation is time-consuming — to fact-check articles takes time and by the time the result is published the majority of the people who were going to read it have done so anyway.
Chat apps — public social networks are blamed for not dealing with mis/disinformation but some of the most problematic stuff is being shared via messaging services such as WhatsApp and Telegram.
Difference between human and bot accounts — it’s possible to reason with a human being but impossible to do with a bot account.
Metaphor of adblock list — a way of reducing the burden of moderation on administrators and moderators* of a federated social network instance by creating a more systematised version of something like the #Fediblock hashtag.
Subscribing to moderator(s) — delegating moderation explicitly to another user, perhaps by automatically blocking/muting whatever they do.
Different categories of approaches — for example, reputational solutions that deal with trusted parties, technical solutions that prove something hasn’t been tampered with, and process-based solutions which make transparent the context in which the content was created and transmitted.
Visualising connections — visualising the social graph could make it easier to spot outlier accounts which may be less trusted than those that lots of your other contacts are connected to.
Fact-checking platforms can be problematic — they promote an assumption that there is a single ‘Truth’ and one version of events. They can be useful in some instances but also be used to present a distorted view of the world.
Frictionless design — by ‘decomplexifying’ the design of user interfaces we hide the system behind the tool and the trade-offs that have been made in creating it.
Disappearing content — content that no longer exists can be a problem for derivative works / articles / posts that reference and rely on it to make valid claims.

It’s been fascinating to see the different ways that people have approached our conversations, whether from a technical, design, political, scientific, or philosophical perspective (or, indeed, all five!)

Next steps #

We’ve still got some people to talk with next week, but we are always looking to ensure a diverse range of user research participants with a decent geographical spread. As such, we could do with some help identifying people located in Asia (yes, the whole continent!) who might be interested in talking about their experiences, as well as people from minority and historically under-represented backgrounds in tech.

In addition, we could also do with talking with people who have suffered from mis/disinformation, any admins or moderators of federated social network instances, and UX designers who have a particular interest in mis/disinformation. You can get in touch via the comments below or at: hello@dynamicskillset.com

First version of report published sharing findings from Zappa project user research

2022-03-05T00:00:00Z

This post was originally published on Doug Belshaw's Open Thinkering blog

Over the last month, I’ve been working with the Bonfire team to perform some initial user research on the Zappa project. The aim of the project, funded by a grant from the Culture of Solidarity Fund, is to empower communities with a dedicated tool to deal with the coronavirus “infodemic” and online misinformation in general.

We ended up speaking with 11 individuals and organisations, and have synthesised our initial user research into the first version of a report which is now available.

📄 Click here to access the report

Notes on our first usability testing round

2022-05-21T00:00:00Z

On May 10th we published a toot asking for volunteers to dive into our upcoming beta of Bonfire Social, by participating in some usability testing sessions. It was such a great opportunity to see how a diverse range of people interacted and used our platform, what they found easy and familiar and what instead felt weird, clunky or buggy.

We ended up with a valuable list of suggestions, feature proposals, bugs and some appreciations for the work done so far :-)

A huge thanks to @dougbelshaw, @django, @edumerco, @asteroidrainfall, @bea for their time, feedback and sharp observations <3.

Participants #

This first round included 5 testers (we picked this number based on this NNG article about usability testing). Though small, the group was diverse enough in terms of background, interests and geography. It included educators, activists and developers, among which some were already well versed with the fediverse, while others discovered it recently.

They all were interested in using Bonfire via servers operated by and for themselves, their family or their local community. Some of them were even keen to set up and maintain an instance.

Main takeaways #

We ended up creating an ad-hoc beta-testing tag on our issue tracker to keep track of the bugs and feedback that came out of the sessions.

Among all the amazing input we received, we found some that were shared by the majority of testers:

It should be more obvious to know how to tailor and extend your instance to go beyond the standard microblogging use case.
Trending topics are a great way to discover the network. They play an important role in how users search, find, avoid, or subscribe to certain topics and people.
The text input for writing a post is too small to go beyond microblogging. It does not encourage deeper and structured conversations. We should definitively provide an option for distraction-free writing.
It would be awesome to have federated groups.
It would be useful to have moderation and instance rules shown on the homepage, together with other meaningful information about the instance.
It would help to have a wizard to guide new users on their first time using the platform or participating in the fediverse.
Pinning one or more posts to the top of your timeline is a simple but powerful way to customise one's profile.
It would help to have more flexibility on how users define the audience of their posts.

Final thoughts #

Beta testing is not only a great way to spot bugs, but can also be powerful in finding more inclusive and participatory ways of co-designing the platform itself.

We therefore plan to continue with iterative usability testing sessions on a monthly basis - feel free to contact us if you want to join in :)

Thanks also to the Cultural Foundation, who helped fund our work on the beta milestones.

Not Just 'Yet Another Microblog'

2022-06-18T00:00:00Z

We’re days away now from the beta release of our Bonfire federated app toolkit. So close to the launch, we thought it’d be a great opportunity to write to future beta users - especially those whose first impressions of it might be something along the lines of: wait, this looks like just another microblogging app! haven't we already got enough of those?

Well, our reasoning is that everything is social. Political activities are social. Economic activities are social. Artistic activities are social. The way we work and coordinate activities... is social. That's why at the heart of Bonfire is a set of social components that underpins what is yet to come.

Bonfire is a toolkit for assembling federated apps #

In a previous post, we wrote:

Social networking plays a critical role in our lives, and everyone should be able to decide how to define their online identities and how to interact with others, without an app imposing the boundaries of their experience in one way or another.

An app built with Bonfire is a preset configuration describing how a collection of extensions should plug and play together. And users can then add more extension to end up with an app that fits their specific needs. For example, imagine installing an extension that adds end-to-end encryption to the messaging functionality, or an extension that adds a calendar view showing any-date based information from other extensions (like the kanban app, or events federated from Mobilizon).

With this beta launch we're looking to test both the user experience of the social components of Bonfire, and also to ask for help (from the ActivityPub savvy people who are willing to set up test instances) to ensure Bonfire instances are first-class citizens of the Fediverse. By this we mean that federation works as expected with other networks such as Mastodon, Peertube, and Pixelfed.

Other apps #

We have plenty of ideas and work-in-progress for Bonfire apps within the existing team and the wider network of people and organisations around us. For example:

Kanban - federated project coordination.
Zappa - empowering communities to tackle online misinformation.
Offers & needs - a federated way for people to share offers and requests, as one of the many apps that will use ValueFlows, an open protocol for economic activities

And we'd love to see many other apps emerge, for example:

Collective decision-making - perhaps in a similar way to Ukuvota or Loomio
Federated calendar & scheduling tool - to help plan and coordinate intitiatives across different communities and timezones.

We're also excited to see ideas coming from the community, including designers or developers who may have the expertise to collaborate on making some of these ideas into reality!

Customisation #

Everything in Bonfire is customisable at one level or another, a nice example is how the whole UI is themeable, but it goes much further than that.

In general, we're getting into the habit where any hesitation or disagreement about a feature is used as an opportunity to add a user setting for it, meaning that the user is the one to decide how it should work. Developers and instance admins still hold power in setting the defaults, but ultimately it should be up to the people using Bonfire.

"Forkability" #

From the beginning, we've built Bonfire to be extremely customisable and configurable. One of the great things about Free Software is the ability to fork the project and take it in your own direction. However, a fork of a big complex app is a lot of work to maintain by one person or a small group, let alone someone who isn't very technical (or not experienced in the particular tech stack).

By separating the code in dozens of different extensions (each in their own git repository), the maintainance burden is greatly reduced. By putting data models, backend functionality and user interfaces in separate extensions, it’s easier to, for example, fork an UI extension to customise the experience (or create a completely different one) while retaining the same functionality.

Next steps #

We couldn't be more excited about the first release of Bonfire and we hope it can truly revolutionise the way online communities are formed and maintained. If you’re interested in helping us test the upcoming beta version of Bonfire, please add your email address below and we’ll get back to you very soon.

What you can expect from the Bonfire beta

2022-06-21T00:00:00Z

In a few days' time we'd like to invite you to experiment with a 'playground' instance of Bonfire, the federated social networking toolkit for communities. As we explained in the previous post, we're focusing on getting the core social functionality of Bonfire ready, and we need your help!

We're looking for people who want to play around with Bonfire and who can help spot bugs and possible improvements around the user experience. We're also looking for those who might want to set up their own Bonfire instance to help test federation.

Features and functionality #

Lots of what you'll see in the Bonfire beta will be recognisable from other social and/or federated apps: for example, navigating timelines and profiles, following users and boosting or favouriting activities. You'll be able to create posts, engage in discussions, flag or block problematic content, and pick your preferred language (with three languages available to start, we need help with translations in more languages if you can!).

There is some functionality that may be a little different with Bonfire as well. Choosing what you see in your home feed, changing the interface theme and font, switching between multiple profiles, rich text formatting in posts, setting a title for threads, and granular blocking options are a few features that may be new to beta testers. We're looking forward to seeing what you think of them!

Get involved! #

If you would like to test the user experience of Bonfire, please enter your email address below. We'll ensure you get an invite to the test instance as soon as it's ready.

Meet us at the playground: Bonfire Social beta launch

2022-06-25T00:00:00Z

Today, the Bonfire team is asking for your help with beta testing. Bonfire still needs a lot of work - be it bugs, federation, missing features, configurability and user experience - but that's the point: we decided to launch the playground at this gnarly stage with the specific intention of moving toward the 1.0 release as a community. We think the best way to rapidly improve Bonfire and its modularity is to test it and discuss it together!

By setting up a workflow within the playground instance to report issues or share feedback, both devs and non-devs alike will be able to input their ideas and co-design our 1.0 release in an open and inclusive way.

Watch the video walkthrough #

If you would like to test the user experience of Bonfire, please sign up on the instance at playground.bonfire.cafe

When you come across a bug or something that could work better/different (for example, an option within Settings to set the default boundary for all new posts), you will have the opportunity to easily share it to the Bonfire team from within the app. Simply click on the "share feedback" button after signing in to the playground instance: this will start a thread mentioning @BonfireBuilders and adding #bonfire_feedback as a hashtag. Please feel free to report anything you see which is unexpected, even if you're not sure what it 'should' be like! You can also look up existing posts tagged with #bonfire_feedback to participate in discussions started by others.

We will be monitoring and participating in these discussions with zeal! Discussions about new features and extensions will shape our open roadmap, and bugs or technical implementation discussions will be found in the issue tracker.

What is in scope for this beta? #

If you haven't yet read our updates from this week, please check out these posts where we show how Bonfire is not just another microblog, and what you can expect from the beta.

A note on federation #

Federation is a key part of Bonfire and is included by default with all fresh installs. However, please note that federation will be disabled on the playground instance. This is for three reasons:

We don't want to spam the fediverse with too many test posts or meta discussions.
The playground instance isn't meant to be your main home on the Fediverse. We want to encourage decentralisation in this regard.
We need more testing and tweaking to ensure federation works as expected with all the federated apps out there.

Having said that, we also want to test and improve the federation functionality, so if you've got the ability to set up your own instance of Bonfire, we would very much appreciate it! Please check out the docs and get in touch.

Upcoming events #

In addition to discussions on the Bonfire playground instance, we're planning:

Ask us anything sessions - opportunities to ask the Bonfire team any questions you might have.
Install parties - peer support for people looking to set up and test their own Bonfire instances.
Build parties - peer support for builders looking to set up a development environment, along with some pair programming sessions.

Sign up for updates below if you want to be notified of any of these. Of course, we're also reachable by @ mentioning the @BonfireBuilders account within the Bonfire playground instance, or sending an email.

Beta launch FAQ #

Do I need any technical skills to get involved in the beta testing?
If you would like to test Bonfire as a user rather than as an administrator then the skills required are the same as for any social network. However, if you would like to install your own instance, you will need to be familiar with the command line and general knowledge on operating a web server (configuring DNS, etc).
If I want to be involved, how much time do I need to set aside for beta testing?
We would appreciate any and all help with beta testing. You may be able to spend 15 minutes looking around and sharing your thoughts on anything that doesn't work as expected. You might be able to experiment with the Bonfire playground over a number of days or weeks, and give us more in-depth feedback. Whatever works for you, works for us. After all, given enough eyeballs, all bugs are shallow!
What happens if I come across inappropriate content while involved in user testing?
As part of the sign-up process, all users will be asked to agree to a Code of Conduct. The Bonfire team has spent time and effort in crafting this document, and expect it to be followed in all spaces operated by us. Of course, feedback on improving future versions of the code of conduct is welcome. Please follow the guildelines for reporting issues should you come across anything which contravenes the Code of Conduct.

Our general FAQ section can be found on the Bonfire website.

If you would like to keep informed about what's happening in and around the Bonfire ecosystem, please follow us on the fediverse and/or enter your email below to subscribe to occasional updates.

Introducing circles and boundaries

2022-07-19T00:00:00Z

How will our online experiences be different once we take back control over exactly who should see, interact with, and even collaborate on our content and activities at the most granular level?

With our last update to the beta of Bonfire, we wanted to release the initial functionality to experiment with this question, and embark on a quest to find some answers and pose many more crucial questions together with our community.

Within bonfire, you now have the possibility to define circles and boundaries: a way to privately group some of your contacts and then grant them permissions to interact with you and each piece of content you share at the most granular level.

Boundaries go beyond the typical permissions on social media (i.e. who can see your content) and include a long list of verbs in order to represent all kinds of meaningful interactions and collaboration that should be possible on a real social network.

People don’t fit in binary boxes labeled “follower” or “friend”. Circles and boundaries are a way to empower us to come up with our own groupings and sets of permissions.

But this is really just the beginning: boundaries are a core feature in bonfire that many other extensions and features will rely on. The same functionality will soon be used to introduce custom roles, going beyond catch-all titles like "instance admin" and "moderator" with the possibility for communities to define a multitude of roles that fit with how they want to distribute power and responsibility.

How can circles and boundaries allow more flexible governance models in online communities? How can they empower new forms of peer coordination? How can we create user experiences where every user has total control without feeling overwhelmed?

If you are interested in taking part in this journey, start by joining our campground instance!

Bonfire presentation @ PrivacyWeek

2022-10-01T00:00:00Z

In September we have been invited to present bonfire at the Italian PrivacyWeek. We joined Francesco Macchia and Filippo Delle Bianca in a speech titled: "Does it exist an alternative and a future for social media?"

Below you can see the bonfire presentation translated in English:

Thanks to Francesco Macchia for the invitation :)

How to use boundaries, circles and roles

2023-05-30T00:00:00Z

Bonfire's circles and boundaries system is a powerful tool with which you can create custom groups of contacts and grant them specific permissions to interact with you and your content. They can help you take control of your online presence and ensure that your data is shared only with the people you want.

It may help to start by defining some general concepts:

Boundaries are limits that you set for yourself or others to define what you're comfortable with.

These limits can be physical, like curtains or doors; digital, like sharing settings on social media; in writing, like codes of conduct; emotional, like feeling comfortable to take time for self-care; or mental, like choosing what you pay attention to. In Bonfire, boundaries can help limit the type of interactions that others may have with you or things you post.

Boundaries are important because they help you protect yourself, maintain your autonomy, and communicate your needs and expectations clearly.

Circles are a tool that can be used to establish relationships. They are representations of multifaceted relationships that you have with people in your life. Circles can help you understand the different levels of intimacy and trust that you have with different people, as well the different contexts or topics which are relevant to particular relationships, and can help build stronger, healthier relationships.

In Bonfire, you can define circles based on your unique style of relationships and interests. For example, you might create a circle for your colleagues, which can help you keep track of work-related content and collaborate with them more efficiently. You could also have a locals circle, with which you may share and discover local events, news, and recommendations. You might also create a comrades circle, to stay connected with fellow activists and organise around shared goals. Finally, you could create a happy hour circle, to coordinate social gatherings with local friends or colleagues, and the crew for your inner circle. With circles, you have the flexibility to manage your relationships and social activities in a way that makes sense for you.

Using circles #

When you share content on Bonfire, you can simply choose to share it with specific circles instead of sharing it publicly.

Navigate to your settings page.
Click on the "Circles" section on the left sidebar.
Click on the "New Circle" button located at the top-right corner of the page.
Enter a name for the circle in the modal and click "Create."
Once you've created your circle, you can start adding people to it by typing their names or usernames in the input. The search input will provide autocomplete suggestions as you type.

Now you can use that circle when making a post:

Click "Compose" in the sidebar
Click the boundary menu which by default says "Public"
Click "Custom"
Click the box which says "Select one or more circles or people"
Select the circle you created
Now next to the circle that appears in the list you can select what role you want that circle to have with regards to your post. The default is "Participate" which means they can read, boost and reply to it.
Click "Done" and you can now write and publish your post

You can also save time by defining boundaries in your settings to reuse the same selection of circles and permissions when posting and avoid having to select multiple circles and give them a role every time, which we'll cover in the next section.

That's it! With these steps, you can create and add people to circles in Bonfire and use them to share content with specific groups of people.

Using boundaries #

Boundaries takes things the next level by enabling you to combine one or more circles and then grant specific roles to each circle. For example, you might create a "Fitness" boundary and grant the "Participate" role to your gym buddies, allowing them to interact with your fitness-related content, while granting the "Interact" role to your family and friends, who can view and react to your posts but not comment on them.

Navigate to your settings page.
Click on the "Boundaries" section on the left sidebar.
Click on the "New boundary" button located at the top-right corner of the page.
Enter a name for the new boundary (e.g., "Fitness") and click on create.
On the newly created boundary page, start typing the name of a circle you want to add to the boundary (or an individual user, though it's recommended to use circles to group users who you want to assign the same role to). The search input will provide autocomplete suggestions as you type.
Click on the desired circle or user to add them to the boundary.
Next to the name, click on the "Role" dropdown menu and select the appropriate role (e.g., "Interact" if you want them to be able to read/like/boost your activities or "Cannot participate" if you don't want them to be able to reply).
Repeat steps 5-7 for each user/circle you want to add to the boundary.

Now you can use that boundary when making a post:

Click "Compose" in the sidebar
Click the boundary menu which by default says "Public"
Select the boundary you created
You can now write and publish your post

What are roles? #

Roles in Bonfire are a way to assign a set of permissions to users or circles, allowing them to perform specific actions.

Roles play a crucial role in defining the scope of engagement and participation for users. By assigning roles, you can establish specific permissions and restrictions, ensuring that users or circles have appropriate levels of access and abilities based on their relationship with you or the purpose of the boundary or nature of the content on which they're applied.

Here are some preset roles and their associated actions:

Read: can discover the content in lists (like feeds) and read it; request permission for another verb (e.g., request to follow).
Interact: can read, plus like an object (and notify the author); follow a user or thread; boost an object (and notify the author); pin something to highlight it.
Participate: can interact, plus reply to an activity or post; mention a user or object (and notify them); send a message.
Contribute: can participate, plus create a post or other object; tag a user or object or publish in a topic.
Caretaker: can perform all of the above actions and more, including actions like deletion.

There are also negative roles, indicating actions which you specifically do not want to allow a particular circle or user to do, such as:

Cannot Read: not discoverable in lists or readable, and also can't interact or participate.
Cannot Interact: cannot perform any actions related to interaction, including liking, following, boosting, and pinning, and also can't participate.
Cannot Participate: cannot perform any actions related to participation, including replying, mentioning, and sending messages.

Negative permissions always take precedence over positive or undefined permissions. For example, let's say you share something and allow all your followers to read and reply to it. However, if you assign the Cannot Participate role to your Likely to troll circle, the people in that circle will be able to read the content but will not be able to reply to it. In other words, the negative permission restricts the permissions they would otherwise have.

It's important to note that these negative roles do not grant any additional permissions. Assigning the Cannot Participate role to someone who wouldn't otherwise be able to read the content does not mean they will now have the ability to do so. Negative roles simply limit or override any permissions defined elsewhere, ensuring that the specified actions are explicitly restricted.

By using boundaries, circles, and roles in Bonfire, you can take control of your online presence and ensure that your content is shared only with the people you want. So why not give it a try and see how it can help you connect with your contacts in a more meaningful way?

Dev Diary: Implementing federated groups in Bonfire

2023-06-08T00:00:00Z

As part of our commitment to empower communities with tools to foster coordination, meaningful communications and a greater sense of caring and belonging, we are thrilled to announce the development of federated groups in Bonfire. In this blog post, we'll delve into the work in progress of implementing the core features of groups and explore the potential benefits this feature can bring to the whole fediverse.

Group development is made possible by the NLnet Entrust Grant. The grant will let us research and develop an intial set of features to create and manage groups, as well as federate them with other platforms, such as Guppe, Mobilizon, Lemmy, and Mastodon.

The Power of Groups #

With groups users can create context-specific and cross-instances spaces, define their own rules and governance, to better organize their participation across the fediverse. Key features of groups in Bonfire so far include:

Creation & Discovery #

Bonfire users will have the ability to create their own groups, specifying the group's purpose, rules, and other settings. Each group will have a unique username, based on the instance where it was created (e.g., @climatenews@zomia.zone), and will be discoverable (depending on its privacy settings) across the whole fediverse to enable users to find and join groups aligned with their interests, ensuring that everyone can find or build their communities on the fediverse.

Boundaries & Privacy #

Group caretakers will have granular control over privacy settings, allowing them to determine whether a group is open, visible, or private. This flexibility ensures that users can participate in groups that suit their comfort levels and maintain control over their personal data. Private groups will only show their activities to members, while open or visible groups allow anyone to read group contents, and members can add posts or participate in conversations.

Roles & Moderation #

Group caretakers will also have the ability to define custom roles and assign to certain members, thus simplifying and decentralising the management and moderation of groups. Members who are granted a relevant role may see and address flagged activities, invite other users, edit the group appearance and details, create and edit roles, or publish announcements, etc.

When a user flags an activity or a member of the group, the group moderators are the first to be notified. This helps distribute the moderation workload and reduces the burden on instance moderators. If a flagged user breaks not only the group rules but also those of their respective instances, group moderators have the option to escalate the case to instance moderators, to help maintain a healthy and respectful environment across the fediverse.

To ensure the best possible user experience, we intend to launch an initial version on groups to be tested within our playground instance. This will enable us to gather valuable feedback from our community and engage in collaborative discussions to refine and enhance the platform as we progress.

In an upcoming post, we will delve into more details, including our ideas for federating groups and the technical challenges we're facing. Stay tuned 😎

Empowering Bonfire users with advanced roles & permissions

2023-06-15T00:00:00Z

Greetings, Bonfire Community!

We are happy to announce that the next Bonfire release will introduce the capacity to define and assign custom roles. This feature, far from being limited to instance administrators, will also be available to individual users and to group caretakers (as part of our groups extension which is currently in development).

The addition of custom roles will empower users define a set of permissions to grant to other users or circles. This paves the way for a more nuanced and personalised way to define interaction within and across communities.

Now instance admins and group caretakers will be able to define and assign custom roles to other members, to distribute responsibilities among broader groups of trusted users, fostering a more diverse and inclusive governance structure within each community.

Imagine a group caretaker creating a custom role named "Mediator". This role could allow certain members to review and act upon flagged content. The Mediators would be notified of flags, and start a dialogue with the author of the flagged post or the person who flagged it, remove the content from the group and/or block a member if necessary, or escalate the issue to instance moderators when further action is waranted.

Moreover, other users could be granted the "Gatekeeper" role, making them responsible for creating invites, managing join requests or manually adding and removing users from the group.

Custom roles aim to alleviate the workload and emotional burden traditionally associated with admin roles. By distributing power among the users, we aspire to foster healthier governance and cultivate more participative and empowered communities.

Outside of group and instance governance, individual users will also benefit from roles by being able to define exactly how other users can or cannot interact with them and their contents, by using custom roles when defining their circles and boundaries or when making a post.

This is just the beginning for custom roles, we plan to refine and enhance this feature based on your feedback and ideas and our iterative design process. As we progress toward the release of Bonfire 1.0, our goal is to make custom roles a robust and integral part of our platform.

Therefore, we wholeheartedly encourage you to share your experiences and feedback with us. Your insights are invaluable in helping us shape and perfect this feature.

Group development is made possible by the NLnet Entrust Grant. The grant will let us research and develop an intial set of features to create and manage groups, as well as federate them with other platforms, such as Guppe, Mobilizon, Lemmy, and Mastodon

Could you help us with user research?

2023-06-28T00:00:00Z

As we approach v1.0 of Bonfire, we’re looking for volunteers to help us with some user research. We’re particularly interested in hearing from a diverse range of people who may be interested in using Bonfire in a personal or professional capacity .

You do not need any particular technical knowledge, skills, or prior experience of Bonfire. The user research interviews will be carried out in English by Dynamic Skillset .

If you are interested in helping us out, please complete the form. Thanks in advance!

As much as we value and appreciate the effort to participate in our user research, we are unable to offer compensation to the participants at this time. If you have any further questions or concerns, please don't hesitate to reach out to us. Thank you!

Making things intuitive is complex! Or, what we discovered via user testing

2023-07-19T00:00:00Z

The Bonfire team is committed to creating a federated app toolkit that is intuitive, user-friendly, and meets the diverse needs of our community. A key part of how people interact with Bonfire is the composer — the space where users craft their post and decide who can see and interact with it. To ensure this is as effective and easy to use as possible, we recently conducted user research to gather feedback and insights.

The User Research Process #

Our user research involved in-depth sessions with a diverse range of participants. These 45-minute sessions included a mix of questions and prototype testing, using screen-sharing and a prototype created with Figma. Our participants spanned a variety of locations, backgrounds, technical proficiency, and amounts of previous exposure to Bonfire, providing us with a wealth of perspectives and insights.

What we found out #

The feedback we received was invaluable in highlighting areas for improvement. Many users found the concepts and/or UX of boundaries, circles and roles confusing, particularly the ‘caretaker’ role and the way you could deny or combine permissions. There was a desire for greater clarity in the include/exclude sections, about understanding the details of each specific role, and for the ability to edit boundaries after posting.

Interestingly, we found a surprising uniformity in user behaviour, with all participants choosing the same initial workflow in the prototype, though participants each suggested several different ways to improve the composer feature.

Our response #

As a team, we've taken this feedback on board and have been discussing the best ways to iterate based on the insights and sugestions shared by participants.

Next steps #

We're now in the process of implementing changes based on the feedback received. In a couple of months, we plan to conduct further user research to assess the impact of these changes and gather more user insights. We encourage members of the Bonfire community to get involved in this process by providing feedback and participating in future user research. You can do this by discussing this post on the Fediverse and mentioning @bonfire@bonfire.cafe

Users who want to provide further feedbacks to the bonfire team can go through the composer on our campground instance, and report any suggestion using the #bonfire_feedback hashtags.

Conclusion #

This user research process has been extremely helpful in refining the composer and improving the overall user experience on Bonfire. We're grateful to all the participants for their valuable feedback and to our community for their ongoing support. We look forward to sharing updates on our progress and continuing to work together to make Bonfire the best it can be.

(Thanks to Doug Belshaw of Dynamic Skillset who volunteered his time to run this user research for us and provide us with insights.)

Bonfire 0.9.6

2023-08-09T00:00:00Z

We're thrilled to announce the release of Bonfire version 0.9.6! This latest update brings a host of improvements and new features aimed at enhancing usability and providing more control over the content you engage with. Here's what's new:

Expanded Messaging and Thread Views #

We've successfully completed the messaging milestone, now users can seamlessly see all their direct messages or send a message to one or more people.

Threads (for both messages and regular posts) can now be viewed in both nested and flat layout, providing a more comprehensive or streamlined way to navigate conversations.

Sorting options on threads now include chronological views, sorting by replies, boosts, likes, and more, allowing users to tailor their view according to preference.

Enhanced Feeds #

Sorting options have been expanded on feeds, offering chronological, reply, boost, and like-based sorting.

Users can also filter feeds based on time frames such as Today, Week, Month, Year, and All Time, giving more refined control over content discovery, at the same time offering alternatives to the addictive infinite scrolling pattern.

Rich Text Editor and Composer Improvements #

The addition of a rich text editor in our composer enables markdown use with a WYSIWYG interface.

The composer can also now be stretched and expanded, enhancing focus and ease of use, especially when writing longer posts.

Refined Boundaries #

We've started integrating the valuable insights gained from our user testing interviews into the boundary system, enhancing the overall user experience.

This update simplifies the process of defining custom permissions and includes a convenient option to preview the resulting boundaries, allowing for more intuitive and flexible control.

And more! #

Plus, we've tweaked and fixed many more things to make the Bonfire experience smoother and more intuitive.
We encourage everyone to explore these new features and continue to provide feedback as we work towards our next milestone. Your insights drive our progress, and we look forward to growing together with the Bonfire community.

Explore Bonfire 0.9.6 now

The Road to Bonfire 1.0

2023-09-14T00:00:00Z

We've spent the past two years building, iterating, experimenting, and refactoring the Bonfire codebase — to explore our assumptions, co-design with our community, and stretch the limits of social networking, all while having fun!

We are now excited to announce that we're shifting toward a new phase. Over the next three months, our primary goal will be to make Bonfire as reliable and interoperable as possible, until we are able to release Bonfire 1.0 - a version we'll be confident in recommending for setting up instances that federate with the broader fediverse.

Feature freeze #

To focus our efforts on releasing Bonfire 1.0, we're temporarily pausing the development of new features. This strategic decision allows us to concentrate fully on the essential aspects that need attention.

To-do list #

Our key areas of focus include:

Consolidating Federation: We're committed to fine-tuning and optimizing our federated features while rigorously testing interoperability with as many fediverse platforms as possible.
Automated Testing: We'll continue adding automated tests (which automatically check that each feature of the code or user interface works as expected) and fixing existing ones.
Bug Fixes: Identifying and resolving any bugs is of course a top priority to deliver a seamless and fast user experience.

We'll also keep going with ongoing efforts as time permits, such as:

Enhancing User Experiences and Design Patterns: Streamlining the user interface and design elements to make for a more intuitive Bonfire experience.
Documentation: We're committed to providing comprehensive documentation to guide both users and developers through Bonfire's features.

How you can help #

We extend an open invitation to all users and developers to join us during this pivotal phase. Your feedback, which has been invaluable thus far, remains crucial for the continued improvement of Bonfire. Whether it's reporting bugs, helping with documentation or interoperability testing, or even contributing code, every effort matters.

Together, let's make Bonfire 1.0 a milestone release that raises the bar for decentralised and customisable social networking. It's only working together that we can empower communities and build a platform that truly serves our diverse needs.

Thank you all, for your ongoing support and enthusiasm!

We'd also like to extend a shoutout to the NLnet Foundation for their continued backing during this critical phase.

Safer social networking - Bonfire's recent experiment with Prosocial Design Patterns

2024-01-26T00:00:00Z

Introduction #

As we gear up for the release of Bonfire Classic 1.0 – which includes not just the software but also extensive documentation and tutorials for people to customise and extend functionality in-depth – we're testing the framework's modularity. Our goal is to understand the workflow involved in planning, designing, implementing, and shipping a Bonfire extension from scratch. Our first experiment involved implementing a design pattern from the Prosocial Design Network, a community dedicated to pioneering safer social networks.

The results were quite encouraging. We were able to prototype the researched pattern, package it as a distinct Bonfire extension, and integrate it with the Bonfire codebase, all within a matter of hours. This not only demonstrates the power of Bonfire's modularity but also aims to initiate closer collaboration with researchers, activists, and organisations that are committed to designing and fostering safer digital spaces.

Through Bonfire, we can challenge the limitations of current digital platforms, which are often constrained by dark patterns, closed and centralised (not just in terms of interoperability but also in terms of design choices) and/or profit-driven. By partnering with communities, foundations, and anyone whose mission is to truly improve our digital tools and environments, and leveraging the open and interoperable nature of the Fediverse, Bonfire can significantly reduce development time, making it easier to experiment with alternative patterns and foster a more collaborative and open experimentation on building better digital spaces in such crucial times.

Experiment overview #

We chose to implement a feature allowing moderators to add content labels to posts, following a design pattern documented by the Prosocial Design Network: label misleading content; add links to reliable, related content.

This pattern aims to reduce the spread of misinformation by adding context to potentially misleading posts, by displaying accurate information and sources alongside them.

In the following example, a user has published a misleading post.

Our development process began with the creation of necessary user interface (UI) components. The first was simply adding a button in the dropdown menu next to every activity on Bonfire to allow moderators to add a label to a post.

Moderators can then select a label in a modal. As outlined in the design pattern, we provided three default options: Stay informed, Get the latest, and Misleading, though instance admins or moderators could add their own labels as well. Additionally, a text box is available for adding broader context, and up to three links can be included to offer reliable sources.

Once published, these notes become visible underneath the post for all instance users or visitors, and a preview is included for each of the reference links.

Once the UI components were built, along with the necessary backend functionality, it was just a matter of adding the new extension into the desired Bonfire flavour.

Results and insights #

We are extremely pleased with the outcomes of our experiment and the opportunity to benefit from the design patterns and research conducted by organizations like NewPublic, Integrity Institute, Open Future, and the Prosocial Design Network and others.

While implementing the design pattern, we encountered several thought-provoking questions, such as:

How can users suggest notes and reference links to moderators?
How can users contribute feedback to those added by moderators?
How can different moderators collaborate effectively on creating or improving these notes?
What steps should be taken if a note or reference links are found to be inaccurate or misleading?
Initially, only moderators can add labels. Should we leverage Bonfire's custom roles to enable specific users review and label content, easing the load on instance moderators?
How can labels be used in a federated environment? At the moment moderators are tied to specific instances, at least until groups are introduced. Should we extend this feature to enable federated content labelling teams, so users (or entire instance) could subscribe to several trusted teams?

Although we have potential answers to these questions, we believe it would be much more beneficial to open up the discussion and start a feedback loop where research, experimentation, and community feedback are all incorporated into both the documented design pattern and our implementation of it. This would provide a more comprehensive and holistic approach to building and evolving such features.

It is worth noting that mitigating misinformation has been a crucial topic for the Bonfire team, and we have conducted research that informed the design and development of custom roles, boundaries, and circles - features that lie at the core of Bonfire's architecture.

However, there is still some work to be done before we can include this feature in our campground instance and testing it live with our community. Key among these tasks is the ability for moderators to edit or remove a content label and to adding a dedicated page for moderators where all labelled content is listed and can be reviewed, as listed in the relevant issue.

Potential for collaboration #

This experiment showcases Bonfire's extensibility and highlights its potential as a collaborative toolkit for organizations aiming to improve our digital environments and discourse. The modularity and ease of use of Bonfire make it an ideal playground for testing and implementing innovative design patterns in the open.

We are eager to explore partnerships that can leverage Bonfire’s capabilities, furthering our collective quest of creating safer, more engaging, and enjoyable federated digital spaces.

Comments #

Please join the discussion on the fediverse if you have thoughts or suggestions, and get in touch if you'd like to collaborate.

Open source meets open science - announcing the Open Science Network initiative

2024-02-27T00:00:00Z

The scientific method must be liberated. In an era marked by misinformation, mass surveillance and political propaganda, corporate monopolies and platforms hinder scientific innovation and knowledge sharing. Scientists, researchers, academics and their affiliated organisations must have control over the tools and medium they use to publish, review, share, study and discuss their work.

Today, we’re excited to present the Open Science Network initiative, a first step towards open and federated digital spaces designed to push the boundaries of open science and scholarly communication. You can read more about it on the official website.

What is an open science ‘digital space’ #

A digital space is an online place where people gather and interact with one another. Some digital spaces are home to only one community, while others are platforms that host multiple communities. The organisation or individuals who set up and maintain the digital space control the user experience and the governance of that space.

An ‘open science digital space’ includes a set of bespoke features and UX paired with a community dedicated to fostering open science practices. This means the space is intentionally designed to support the sharing of scientific knowledge, collaboration, and transparency in scientific research, promoting open reviews and production of scientific knowledge.

Our journey so far #

The idea of building a federated tool for sharing research on the social web started with Nibö, a science communication collective, wanting to build a social tool for academics and researchers. Nibö contacted the Bonfire team with innovative ideas on how a federated digital space specifically designed for scientific communities could benefit open science – promoting better practices and knowledge sharing for both scientists and users, and moving beyond the conventional use of social media as a mere content broadcasting tool. They wondered if such a federated digital space could be built atop Bonfire's modular and extensible architecture.

Since this initial collaboration, we've outlined a preliminary set of features, primarily catering to Nibö’s community while also considering the broader needs of the open science community.

We soon discovered that the fediverse is an incredibly fertile ground for discussions on open science, where open science advocates, activists, researchers and communities have been increasingly gathering to share knowledge, collaborate or simply discuss how to foster open science practices.

Driven by aligned visions and needs, together with Björn Brembs (author of Replacing Academic Journals and Mastodon over Mammon: towards publicly owned scholarly knowledge), Ulrike Hahn (a coordinator of SciBeh, an initiative that has been thinking about new digital infrastructure for science, including online workshops) and Nibö, we started the open science network. Its mission is to co-design, develop, study, iterate and disseminate tools to improve open science practices on federated digital spaces.

The Open Science Network has been shaped by many contributions and ideas and benefited immensely from discussions over the fediverse.
With such an amount of grey matter in place, the next logical step was to validate the feasibility of these ideas and how they would play in a federated network.

The open science extension prototype #

We decided to start by tackling a (technically) low-hanging fruit to demonstrate the benefits of co-designing digital spaces with communities bottom-up and the feasibility of adding tailored features in Bonfire without messing with the rest of the codebase. We introduced a custom preview feature for posts containing links to papers or publications.

This widget not only displays the paper's title and abstract (like standard link previews in other social networks) but also details the publication journal, co-authors, topics, publication date, and relevant links such as the DOI and the PDF when available - - with data automatically fetched from various open repositories. This feature enriches the context provided by linked papers, enhancing users' understanding of the publication. The prototype was shared across the fediverse, receiving a wave of feedback and encouraging reactions.

Based on that enthusiastic response, we ventured further to develop other features requested including:

ORCID single sign-on #

Researchers can sign in to their open science digital space using either their email and password or their ORCID credentials. This integration simplifies the login process and ensures that users can have a trusted provider to log into their digital space.

Automatic import of publications using ORCID credentials #

Linking a user's ORCID profile also enables the automatic import of their publications, using the ORCID API, which are then showcased on a dedicated "publications" tab within their profiles. This feature not only highlights the researcher's work but also facilitates easy access to their scientific contributions - evolving their social profile into a professional one.

Publications feed #

A new "publications" feed aggregates all papers fetched via users’ ORCID profiles or added via post links, so users can discover publications of other members of their digital space, including those from followed users on remote instances. This fosters a wide-ranging view of scientific contributions within a digital space federated network.

Conduct a discussion around a publication #

Beyond reading publications, users can start discussing them with authors and amongst themselves. This means going beyond content distribution and fostering academic discourse and open collaboration, enriching scientific cooperation within the community and beyond.

All the code is open source and available for anyone to pick up and try out or extend. We published a new Open Science extension for Bonfire that includes code for most of the features requested (other bits live in different extensions as they are transversal to different use cases, such as federated groups and topics).

We did enough work to confidently say....

We can develop an open science extension that academics and scientists can include in their Bonfire instances - we hope it can nurture and promote a novel paradigm of scientific practices.

Next steps #

We have now launched the Open Science Network website to try gathering together more communities, organisations and researchers to co-design features and support the project.

Moving forward, our plans include refining the current features in collaboration with scientific communities, moving from prototypes to reliable and tested features and incorporating additional ones if necessary.

We will iteratively test the open science digital space with pilots to ensure that new communities can set up their own digital space with confidence.

How to contribute #

If you wish to propose a new feature or refine an existing one, please open an issue.
To join the network or participate as a pilot community, contact us at team@openscience.network
If you're interested in contributing through coding, design, facilitation, social media, or other tasks, please get in touch at team@openscience.network
We won’t take private capital or venture funds, but we do need more resources to onboard additional collaborators to partner with pilot projects to test and iterate features. We would greatly appreciate support for our work through donations or grants. Please reach out to us at team@openscience.network or donate directly via our Open Collective account.
Please spread the word about these initiatives to broaden their impact.

Bonfire Expeditions - Collaborating to Release Version 1.0

2024-06-11T00:00:00Z

Releasing the stable 1.0 version of the Bonfire federated social network requires collaboration with the communities, hackers, tinkerers, and sysadmins who plan to use it.

That's why we're thrilled to announce Bonfire Expeditions - a series of co-design initiatives aimed at refining and polishing various aspects of the project. These expeditions will ensure that all the moving parts of Bonfire work together seamlessly, making the project safe and enjoyable for both communities and developers.

Each Bonfire Expedition will focus on one of the following areas:

Surveying: Developer Experience, Onboarding and Documentation
Camp: Instance Configuration and Tools
Care: Safety and Moderation Features and UX
Party: Installation and Admin

Surveying Expedition: Enhancing Developer Onboarding #

Challenge: Bonfire's modularity and architecture can be intimidating, and the current documentation is insufficient to properly guide developers.

Objective: Streamline the developer experience for setting up the Bonfire dev environment, manage and create new extensions.

How to Participate:

We are looking for 5 Elixir developers to begin with
Each developer will have a 1-hour pairing session with the Bonfire team
During the session, the participant will go through the setup of the bonfire developer environment and the creation of a Hello World extension.
Developers will vocalize their thoughts, doubts, and suggestions throughout the process
The Bonfire team will provide support and help overcome any obstacles when necessary

After each session, the Bonfire team will:

Compile all feedback and insights
Incorporate feedback into the codebase and documentation
Refine the onboarding experience for the next session

Compensation:

Participating developers can request compensation of €50 for their time on the project’s OpenCollective

If you're an Elixir developer who's passionate about the potential of federated social networks and wants to contribute to shaping the future of Bonfire, join us on this expedition! Send a mail to team@bonfire.cafe to participate in the Surveying Expedition, and we'll reach out with all the necessary details.

Together, we can make Bonfire's 1.0 release a truly landmark moment. Let's embark on this journey and build something extraordinary, one expedition at a time!

Bonfire Expeditions - Camp! A bounty programme

2024-08-07T00:00:00Z

🎉 Welcome to the Bonfire Bounty Programme #

Bonfire is an open source framework written in Elixir that enables communities to create their own federated digital space. These spaces can range from simple group chats to complex infrastructures for municipalities, and everything in between.

The Bonfire Bounty Programme offers monetary compensation for tackling specific challenges.

This initiative aims to inspire developers to learn the stack and framework and to create Bonfire extensions, while helping to close some issues along the way.

🏴‍☠️ Camp! expedition #

We've started a series of expeditions to increase developers contributions and get help to reach our v1.0 release.

The first expedition: Surveying, is currently ongoing and focuses on improving docs and dev onboarding by doing 1-to-1 sessions with developers.
Our second expedition: Camp! includes a series of bounties for developers to help us with current technical blockers.

The Camp! expedition will target a specific set of bounties that is currently preventing Bonfire to be used and adopted more widely and it is focused on the features in the Bonfire Classic flavour. All submissions are evaluated based on the quality of the code, performance and documentation.

Bounties #

Open bounties #

Improve DB query performance €1,000 + half of donations to the dedicated Open Collective
Improve feed rendering performance €1,000 + half of donations to the dedicated Open Collective

Upcoming bounties #

Validate OpenID Connect and OAuth (client and server) implementation
Refactor and unify feed logic

🫶 Collaborative approach to bounties #

We want to experiment with a bounty system designed to foster collaboration rather than competition. We aim to:

Organically grow the number of developers contributing to Bonfire.
Make Bonfire a go-to framework for experimentation, both for people new to Elixir or even to coding and for seasoned developers, with clear design patterns and a robust documentation.

We encourage developers to work openly by:

Digging into the problem and sharing insights or potential solutions in each dedicated bounty issue.
Collaborating with others developers to improve the overall quality of solutions.

Additionally, the Bonfire Team will organize recorded sessions to discuss each issue, navigate the relevant code, address blocking issues, tests, and provide pertinent information to ensure developers can effectively work on the bounty.

💰 Compensation #

Primary bounty #

One developer will receive the full bounty amount for the selected solution, plus half of donations to the dedicated Open Collective.

Each submission (likely to consist of pull requests on multiple Bonfire repositories) will be tested and benchmarked on the playground instance.

To be selected, the contribution must demonstrate a deep understanding of the core problem, and solve it effectively and efficiently. Alongside the technical correctness, it should also be submitted with a clean code, clear explanations and a complete documentation.

Additional compensation #

We have allocated a separate fund to reward valuable contributions beyond the winning solution. Depending on available funding, 2 or more developers per bounty can receive €200 each for the following:

Significant code contribution: You created pull request(s) that while not satisfying all the criteria or fully solving the bounty, inspired and helped other developers to do so. Also valid if you commented on issues or pull requests with additional code to improve other developers’ solutions.
Meaningful support: You supported other developers in solving the bounty by clarifying issues, reviewing code, running tests and benchmarks, suggesting solutions or improvements, writing documentation, or explaining concepts that helped.

We acknowledge that the funding allocated does not reflect the labour and time that's likely to be involved. To hopefully increase the compensation, we're asking for help from the community: half of the donations collected through each respective Open Collective page will be go to the primary bounty and the other half will be distributed to people who make meaningful contributions, as a way to recognize and encourage broader participation and share responsibility for the project's sustainability with the broader community.

💻 How to participate #

Requisites #

Ensure you have read our Code of Conduct and these guidelines to know what you will expect by participating to our bounty programme. Then read through the bounty details and requirements carefully.

Work on the challenge #

Use the provided resources and fork the relevant git repositories to work on. If you have any questions during your work, feel free to comment directly on the bounty issue and we will be happy to assist you.

Submission #

Once you have started your work (or at any stage you prefer, though we recommend working in the open), create a draft pull request with your code. You can then ask for feedback and iterate on the same pull request until ready to submit.

Discussion and compensation #

The Bonfire team will review and discuss submitted pull requests and merge the one that satisfies all requirements most effectively, and proceed with awarding the bounty (please note that payment may take up to a month).

At the same time, besides the awarded developer, we will optionally compensate other contributors with 200€ each, based on their effort, support, and impact in helping to close the bounty.

ℹ️ Support #

For questions on a specific bounty, comment on the dedicated issue
Matrix channels for realtime chat: General & Technical
Forum for technical discussions: Elixir Forum
Email for private questions: team@bonfire.cafe

Building Bonfire Native Apps with LiveView Native

2024-09-27T00:00:00Z

Introduction #

Welcome to the first post of our development diary for the Bonfire native app. In this series, we'll journey together through the entire process of designing and publishing Bonfire on the Apple App Store using LiveView Native (LVN), an experimental framework that enables developers to build native applications using Elixir.

We're focusing on iOS first because the current LVN release targets the Apple ecosystem (iOS and macOS, but also watches, TV, and vision pro), with Android support coming next. At the time of writing, LVN is at version 0.3, so some approaches and solutions will evolve over time. We aim to provide the most accurate and up-to-date information but encourage readers to check the docs for details and contribute their knowledge along the way.

Why LiveView Native and Elixir #

LiveView Native is an exciting new framework developed by DockYard that extends Phoenix LiveView to native platforms, enabling real-time, interactive native applications with a unified codebase. As they mentions in the announcement:

"Because we are leveraging the LiveView programming model, if you already have a LiveView application built you already have 75% of the work done to build a LiveView Native application. State management and event handling are shared between target destinations."

This approach is a perfect match for an open-source project like Bonfire. By building upon existing code and staying within the Elixir ecosystem, we can invest more time in strengthening our codebase without needing a traditional client-server API or splitting efforts across different languages, while still using each platform's unique native UI framework to deliver a state-of-the-art user experience (e.g. using SwiftUI and Android Jetpack for the native UI in shared components and views, alongside the HTML/CSS already used in the web app).

Through this dev diary, we aim to open up our development process and share our challenges and progress with the wider Elixir community. We'll share code, lessons learned, and materials starting from the very first mock-ups, inviting the community to jump in, provide feedback, and ask questions along the way.

We also plan to experiment with existing Figma plugins to convert designs to code (SwiftUI) and later attempt to convert that code into LVN's Elixir syntax. There will be a lot of trial and error, especially since we don't have prior experience with SwiftUI, but that's part of the experiment.

The journey begins: designing initial mock-ups with Figma #

Using Figma, we've created initial mockups that lay the groundwork for Bonfire's user interface and experience. While these mock-ups are still in the early stages, they represent our vision for the app's basic look and feel. We won't include all of Bonfire's functionalities in the first release of the native app; instead, we'll adopt an incremental approach. We'll publish a basic app that lets users perform essential social networking features, then expand its complexity and give more control to users as we become more confident using the LVN framework and as it becomes more stable.

Setting up the Figma environment #

Apple recently published the iOS and iPadOS 18 UI Kit for Figma—a set of components and assets, including variables and Apple's color palette, to use in our Figma mockups. This is essential for properly designing iOS mockups following Apple's design guidelines.

Before creating our first mockup, we also downloaded the latest SF fonts and symbols from the Apple Developer website to use them across all views and components. We also downloaded the Figma desktop app to benefit from local fonts installed on our machines.

With the standard iOS assets, icons, and fonts in place, we've created our first view using the iPhone 14 & 15 Pro frame as a reference.

Before building our mock-ups, we found it helpful to define layout grids. Layout grids help maintain order and structure, ensuring all elements are well-aligned and proportionate by defining both row and column configurations.

Columns: A common grid column configuration for iPhone is 6 columns with a 16px gutter and margin. Set the columns to "Stretch" to automatically adapt to different screen sizes.
Rows: We set the count to "Auto," type to "Top," height to 44 (the standard touch target size in iOS), and offset to 54 (to start the grid just below the status bar) with a gutter of 16 points.

This configuration results in a view like this:

Bonfire's basic views #

In our initial design, we've defined the following basic app views:

Main timeline
Profile
Search
Notifications
Discussion
Compose form

There's nothing too fancy; we've mostly used standard iOS assets where possible and Apple's color palette and typography for all the custom components we've created.

We've added a Components page listing all the component instances, which we clone to include in our views. We detach components from the main instance when custom edits are needed.

We're striving to keep things clean and maintain our Figma files in an organized and well-structured manner. We can't promise adherence to all best practices, as our experience with Figma is quite limited. However, we've loved using the auto layout feature to create more structured components, and we highly recommend building components using auto layout—it may seem daunting at first, but it's very easy to work with once you delve into it.

In the next post, we'll expand on these mockups, adding more details and including interactive flows, additional screens, and animations.

Access the Figma document here: Bonfire iOS App Mockups

By clicking the link, you can view the current designs, leave comments directly on the mockups, and provide suggestions to design a better Bonfire native app. Your feedback is invaluable, whether it's about aesthetics, user experience, or features you'd like to see.

What's next? #

In the upcoming posts, we'll dive into:

Enhancing the mock-ups: Adding user flows, interactive components and animations, and more detailed screens - eventually publishing the Bonfire design library in Figma for anyone to use and build upon.
Translating designs to SwiftUI: Once we're satisfied with the design, we'll start converting them into SwiftUI code, discussing challenges and learnings along the way.
Exploring LiveView Native: Attempting to port SwiftUI code to LVN, including the hurdles and triumphs of using an evolving pre-1.0 framework to implement a federated social network's moving parts and design patterns.
Putting AI to work: Experimenting with LLMs to automate parts of the translation from SwiftUI to LVN.
Publishing on the Apple App Store: Documenting the process and requirements to publish the app.

Join the journey #

Beyond sharing our experience, we aim for Bonfire to become a place where both beginner and experienced developers can learn, build, experiment, and collaborate using the Elixir programming language to design open and federated social networks. We invite developers to dive into the framework, provide feedback, ask questions, and help push the boundaries of federated and open-source digital spaces.

Here's how you can get involved:

Feedback and suggestions: Follow us on the Fediverse and join our discussions on the Elixir Forum, #Bonfire room in Elixir Slack or our Matrix space to stay updated.
Collaborate: If you're interested in contributing code or ideas, you can have a look at our "good first issues" or check out our open bounties.

Prototyping Our First Native Components with LiveView Native

2024-10-03T00:00:00Z

Read part one: Building Bonfire Native Apps with LiveView Native

With our initial mockups complete, we were eager to start coding in LiveView Native (LVN). There are two primary ways to debug an iOS app: using Xcode or LVN Go. LVN Go is an application available on macOS, iPad, and iPhone that allows you to test a LiveView Native app directly on a device by pointing it to the Phoenix server URL.

We chose to use Xcode because we need to build custom SwiftUI views in the future for our specific use case.

For reference, I'm using Xcode beta with the iPhone 16 simulator running iOS 18 on macOS Sequoia, and live_view_native_swiftui version 0.3.0.
iOS 17 should work fine as well; however, I experienced some SwiftUI errors with older versions.

I followed the tutorial from the DockYard blog post to set up a basic LiveView Native app.

Adding LVN is quite straightforward, though there are still some tweaks that need to be done manually, such as editing the dev.exs file. Nonetheless, the experience is already pretty smooth!

To debug my app, I needed to run the project on Xcode. Fortunately, the basic code to set up the SwiftUI app and connect to the Phoenix server is automatically generated when running the mix lvn.setup.gen task.

I just had to open the project by running:

open native/swiftui/Counter.xcodeproj

Xcode begins fetching dependencies and may trigger some errors. Enabling permissions for plugins used by LiveView Native, as outlined in the official guide, solves all of them.

At this point, I was ready to build and run the app on the iPhone simulator.

Understanding SwiftUI and LVN #

One of the challenges I encountered was wrapping my head around the SwiftUI way of building interfaces and then translating that back to LVN. I found myself frequently switching between the SwiftUI documentation and the LiveView Native SwiftUI syntax conversion guide.

Other resources I found useful were the LVN CookBook (a collection of useful design patterns) and the Lax GitHub repository (a minimal Slack clone built with LVN).

Leveraging AI and Community Support #

There were some parts I still need to understand better, but using AI tools like Claude 3.5 sonnet and GPT-4o often helped in navigating component design in SwiftUI and translating SwiftUI code into LVN. When I wasn't able to do it on my own, the LiveView Native slack community was very supportive.

Prototyping Components #

At this point, I just wanted to get a feel of how to build native components in LVN, before starting to build the main pages of the app. I ended up prototyping a few components that are trasversal to the main views of the Bonfire iOS app, such as the Dropdown Menu and the Modal.

LVN includes the SwiftUI default Menu component:

<Menu> 
  <Text template={:label}>Edit Actions</Text> 
  <Group template={:content}> 
    <Button phx-click="arrange">Arrange</Button> 
    <Button phx-click="update">Update</Button> 
    <Button phx-click="remove">Remove</Button> 
  </Group> 
</Menu>

The unfamiliar bit for me here was the template prop on both Text and Group.

In SwiftUI, the Menu struct requires both a label and content parameter, which are closures returning the views to be displayed in the menu component:

struct Menu<Label, Content> where Label: View, Content: View

In LVN, when a SwiftUI struct or modifier expects a closure or a content view (like content, label, footer, etc.), we use the template attribute to link a child view to that modifier's parameter.

I further customized the menu by including icons next to each menu item and adding a divider to separate different groups of content. The final component looks like this:

<Menu>
  <HStack template={:label} style="tint(.black)">
    <Text style="font(.body);">Following</Text>
    <Image systemName="chevron.down.circle.fill" style="padding(.leading, 2);"/>
  </HStack>
  <Group template={:content}>
    <Button><Label systemImage="house">Home</Label></Button>
    <Button><Label systemImage="eye">Following</Label></Button>
    <Button><Label systemImage="person.2">Local</Label></Button>
    <Button><Label systemImage="globe">Remote</Label></Button>
    <Divider/>
    <Button phx-click="show_filters"><Label systemImage="line.3.horizontal.decrease.circle">Filters</Label></Button>
  </Group>
</Menu>

LiveView Native includes a default modal among other components in the core_components file. It is a simple VStack with a sheet modifier. The sheet modifier accepts an isPresented value to toggle visibility, a :content view, and an onDismiss callback. The code looks like this:

def modal(assigns) do
  ~LVN"""
  <VStack
    id={@id}
    :if={@show}
    style='sheet(isPresented: attr("presented"), content: :content)'
    presented={@show}
    phx-change={@on_cancel}
  >
    <VStack template="content">
      <%= render_slot(@inner_block) %>
    </VStack>
  </VStack>
  """
end

I wanted to further refine the modal by tweaking its size, including a drag indicator, and changing the background.
Specifically, I wanted to:

Make the modal initially occupy half the size of the screen.
Include a drag indicator.
Allow it to expand or dismiss completely.
Replace the default background color with a translucent one.

The final result looks like this:

(It's not easy to notice the translucent effect due to the flat background color behind the modal.)

To achieve this result, I included a few custom classes in the VStack's :content template.

Note: It took me some time, along with assistance from the LVN team, to realize that the classes should be applied not to the main sheet component, but to the child VStack with the :content template. This is a key detail from the SwiftUI API.

<VStack class="detents:medium:large ultrathinmaterial dragindicator:visible" template={:content}>

Classes are an alternative way to add modifiers. They can combine multiple modifiers to create easy-to-use and standard components, and they can be chained together—much like Tailwind CSS.

Defining Custom Classes #

In my app.swiftui.ex file, I've defined the classes used above:


~SHEET"""
"dragindicator:" <> do
  presentationDragIndicator(.{props})
end

"ultrathinmaterial" do
  presentationBackground(.ultraThinMaterial)
end
"""

def class("detents:" <> props) do
  [start, end] = String.split(props, ":")
  ~RULES"""
    presentationDetents([.{start}, .{end}])
  """
end

And that's it!

What's Next? #

In the next entry, we will start defining the views for the main pages outlined in our mockups, build the main components for each of them, and navigate between pages using the TabView component and links.

Stay tuned!

Understanding Navigation in LiveView Native

2024-10-08T00:00:00Z

Read part one: Building Bonfire Native Apps with LiveView Native
Read part two: Prototyping Our First Native Components with LiveView Native

Note: This entry may evolve over time as the LiveView Native team pushes improvements and releases major versions of the libraries. Please bear with us as we test and implement the main navigation patterns in our upcoming Bonfire native app! Also, this article reflects our current understanding of SwiftUI and LiveView Native; we would love to get feedback and improve any parts that are not accurate!

Thanks to the LiveView Native team for their feedback and support! 🔥

In our previous article, we experimented with building some simple UI components that we'll be using across the Bonfire app, and at the same time, we've developed some initial confidence in writing LiveView Native (LVN) code.

Today, we'll go through the implementation of the main navigation patterns needed to traverse our app's sections and views.

In SwiftUI, there are three main ways to navigate an app:

Tab Bar
Navigation Bar
Links

The destination can be a different section in the same view, a different page, a sheet (modal), or an external view.

In LiveView Native, all the routing and navigation happens within the NavigationStack view, which is included by default in the root.swiftui.leex and wraps all the views defined in the router.ex module.

The LVN documentation is a great starting point to learn more about how navigation works:

The TabView #

The TabView is a default SwiftUI component fixed at the bottom of a view. It consists of up to five navigation items (icons only or icons with text—although text is usually recommended if you're showing a maximum of three buttons) and is used for top-level navigation between major sections of a single view.

In SwiftUI, the TabView is defined as:

TabView: A view that switches between multiple child views using interactive user interface elements.

To include a TabView in LVN, we need to use the default <TabView> component.

The Lax repository provides a couple of custom components to implement a TabView in an elegant and simple way—we copy-pasted them into our app in no time 🥸️️️️️️ !

attr :rest, :global, include: ~w(phx-change selection)
slot :inner_block, required: true

def tab_bar(assigns) do
~LVN"""
  <TabView {@rest}>
    <%= render_slot(@inner_block) %>
  </TabView>
"""
end

attr :tag, :any, required: true
attr :name, :string, required: true
attr :icon_system_name, :string, required: true
slot :inner_block, required: true

def tab(assigns) do
	~LVN"""
	<Group tag={@tag} style="tabItem(:tab);">
	  <Image template={:tab} systemName={@icon_system_name} />
	  <Text template={:tab}><%= @name %></Text>
	  <%= render_slot(@inner_block) %>
	</Group>
	"""
end

Then we just had to import them into our view like this:

<VStack>
  <.tab_bar phx-change="swiftui_tab_selection" selection={@swiftui_tab}>
    <.tab tag={:home} name="" icon_system_name="square.stack">
      <Text>Home</Text>
    </.tab>

	<.tab tag={:notifications} name="" icon_system_name="bell">
		<Text>Notifications</Text>
	</.tab>
	
	<.tab tag={:search} name="" icon_system_name="magnifyingglass">
		<Text>Search</Text>
	</.tab>
	
	<.tab tag={:direct_messages} name="" icon_system_name="tray">
		<Text>DMs</Text>
	</.tab>
	
	<.tab tag={:profile} name="" icon_system_name="person.crop.circle">
		<Text>Profile</Text>
	</.tab>
</.tab_bar>
</VStack>

And this is the result:

Note: Currently, you can include only functional components as slots within each <.tab>. It is not possible to include sub-LiveViews—this may evolve with future releases of the LiveView Native Core library.

The TabView is mostly this; it resembles the standard <Tabs> web design pattern: it lets the user navigate different content of the same page, highlighting the currently active <Tab> component.

We found the toolbar navigation trickier to implement, probably because of the various user experiences and customizations we required.

Note: We highly recommend the article How to Create Toolbar in SwiftUI to learn more about the different types of actions and properties you can leverage to build the toolbar.

In our case, our main issue consisted of having to switch between three different types of toolbars based upon the current active page.

As mentioned earlier, the <TabView> component only accepts functional components as slots for each <Tab>. Additionally, we can only define a single <Toolbar> for each view.

This means that based on the active tab, we need to programmatically change the toolbar structure to customize it according to the needs of the rendered component.

As far as we know, the current version of LVN doesn't include all the Optimistic UI features that are built into LiveView—or maybe it's just us doing something weird—but we are experiencing a few minor bugs when trying to programmatically edit the toolbar when props change.

To add a basic toolbar, which includes only the navigation title, all you need is to include this code in your main view:

<VStack style={"navigationTitle(:title);"}>
	<Text template={:title}>Home</Text>
</VStack>

This will add the standard iOS navigation title at the top of your view like:

From there, we can go further and add buttons at the top left and right, add the search bar, add an extra dropdown menu next to the title, change the position of the title, or edit the background.

We will need to apply all of the above in order to build toolbars like these:

iOS Toolbar provides ways for adding items and buttons on both the left and right. This is done by adding a ToolbarItem (or ToolbarItemGroup if you need to wrap more actions in the same component) and specifying a placement attribute. In order to add a ToolbarItem/ToolbarItemGroup in our toolbar, we need to specify it by including the toolbar modifier in our parent VStack: toolbar(content: :toolbar)

Our code now looks like:

<VStack 
	style={[
	  "navigationTitle(:title)",
	  "toolbar(content: :toolbar)"
	  ]}>
	<Text template={:title}>Home</Text>
</VStack>

This change alone is not enough though; we need to actually add the items we want to render.

<VStack 
	style={[
	  "navigationTitle(:title)",
	  "toolbar(content: :toolbar)"
	  ]}>
	<Text template={:title}>Home</Text>
	<ToolbarItemGroup template="toolbar" placement="navigationBarTrailing">
	  <Button>
		<.icon name="plus" />
	  </Button>	
	. <Button>
		<.icon name="gear" />
	  </Button>
	</ToolbarItemGroup>
	<ToolbarItem template="toolbar" placement="navigation">
		<.icon name="person.crop.circle" />
	</ToolbarItem>
</VStack>

The navigationBarTrailing placement allows us to show the actions on the right side of the toolbar; using navigation places them on the left side.

The toolbar now looks like:

Getting better....

But we don't want the title that big, and we want to center it in the middle of the toolbar.

We have two possibilities:

Using navigationBarTitleDisplayMode(.inline): This moves the title to the center of the toolbar and reduces the font size at the same time.
Using a ToolbarItem with placement="principal": Insert a <Text> into it with the page title.

If we use the latter option, we should remove the <Text template={:title}>Home</Text> from the template.

Here's the updated code:

<VStack 
	style={[
	  "navigationTitle(:title)",
	  "toolbar(content: :toolbar)",
	  "navigationBarTitleDisplayMode(.inline)"
	  ]}>
	<Text template={:title}>Home</Text>
	<ToolbarItemGroup template="toolbar" placement="navigationBarTrailing">
	  <Button>
		<.icon name="plus" />
	  </Button>	
	. <Button>
		<.icon name="gear" />
	  </Button>
	</ToolbarItemGroup>
	<ToolbarItem template="toolbar" placement="navigation">
		<.icon name="person.crop.circle" />
	</ToolbarItem>
</VStack>

et voilà...

The missing piece for our first toolbar, which we can implement using the toolbarTitleMenu modifier, is adding a dropdown menu next to the title:

<VStack 
	style={[
	  "navigationTitle(:title)",
	  "toolbar(content: :toolbar)",
	  "navigationBarTitleDisplayMode(.inline)"
	  ]}>
	<Text template={:title}>Home</Text>
	<ToolbarItemGroup template="toolbar" placement="navigationBarTrailing">
	  <Button>
		<.icon name="plus" />
	  </Button>	
	. <Button>
		<.icon name="gear" />
	  </Button>
	</ToolbarItemGroup>
	<ToolbarItem template="toolbar" placement="navigation">
		<.icon name="person.crop.circle" />
	</ToolbarItem>
	<VStack template="content">
		<.button><Label systemImage="house">Home</Label></.button>
		<.button><Label systemImage="eye">Following</Label></.button>
		<.button><Label systemImage="person.2">Local</Label></.button>
		<.button><Label systemImage="globe">Remote</Label></.button>
		<Divider/>
		<.button phx-click="show_filters"><Label systemImage="line.3.horizontal.decrease.circle">Filters</Label></.button>
	</VStack>
</VStack>

And here's how it looks:

When the Search tab is active, we want to remove the title from the toolbar and display a button that redirects the user to the search page. Meanwhile, the rest of the page shows trending search results or other default content. This is a common pattern we observed in several social network apps like the Mastodon iOS app, IceCubes (an alternative Mastodon iOS client), and X (btw are you still relying on X as your main social presence? If so, you may want to consider moving your main presence over the fediverse, it's a way less toxic environment and not owned by a megalomaniac idiot 🔥️️️️️️).

The code to build the Search Toolbar is as follows:

<VStack
  style={[
	"navigationTitle(:title)",
	"toolbar(content: :toolbar)",
	"navigationBarTitleDisplayMode(.inline)"
  ]}>
	<ToolbarItem template="toolbar" placement="principal">
		<Button phx-click="go_to_search" style={[
			"frame(maxWidth: .infinity)",
			"controlSize(.small)",
			"foregroundStyle(.gray)",
			"buttonStyle(.bordered)"]}>
			<HStack style="frame(maxWidth: .infinity)">
				<.icon name="magnifyingglass" />
				<Text>Search</Text>
			</HStack>
		</Button>
	</ToolbarItem>
	<ToolbarItemGroup template="toolbar" placement="navigationBarTrailing">
		<Button><.icon name="gear" /></Button>
	</ToolbarItemGroup>
	<ToolbarItem template="toolbar" placement="navigation">
		<.icon name="person.crop.circle" />
	</ToolbarItem>
	<VStack template="content">
		<.button><Label systemImage="house">Home</Label></.button>
		<.button><Label systemImage="eye">Following</Label></.button>
		<.button><Label systemImage="person.2">Local</Label></.button>
		<.button><Label systemImage="globe">Remote</Label></.button>
		<Divider/>
		<.button phx-click="show_filters">
			<Label systemImage="line.3.horizontal.decrease.circle">Filters</Label>
		</.button>
	</VStack>
</VStack>

Resulting in:

Since each tab has different buttons and items to display on the toolbar, and we can only include one toolbar per view, we needed a way to programmatically edit the toolbar based on the active tab.

We ended up defining a Header component, using slots for the different sections.

Here is the final code:

attr :style, :any
attr :show_search, :boolean, default: false
attr :page_title, :string, default: ""
slot :toolbar_trailing
slot :navigation_menu
slot :header_menu

def main_header(assigns) do
~LVN"""
  <VStack style={@style}>
	<%= if @show_search do %>
	  <ToolbarItem template="toolbar" placement="principal">
		<Button phx-click="go_to_search" 
		  style={[
		  "frame(maxWidth: .infinity)",
		  "controlSize(.small)",
		  "foregroundStyle(.gray)",
		  "buttonStyle(.bordered)"]}>
			<HStack style="frame(maxWidth: .infinity)">
			  <.icon name="magnifyingglass" />
			  <Text>Search</Text>
		    </HStack>
		</Button>
	  </ToolbarItem>
	<% else %>
	  <Text template="title"> <%= @page_title %></Text>
	<% end %>
	<ToolbarItemGroup template="toolbar" placement="navigationBarTrailing">
	  <%= render_slot(@toolbar_trailing) %>
	</ToolbarItemGroup>
	<ToolbarItemGroup template="toolbar" placement="navigation">
	  <%= render_slot(@navigation_menu) %>
	</ToolbarItemGroup>
	<VStack template="content">
	  <%= render_slot(@header_menu) %>
	</VStack>
</VStack>
"""
end

This is more Elixir than SwiftUI! 😊

In our home_live.ex, we already have a handle_event function responsible for updating the swiftui_tab value based on the tab bar's phx-change="swiftui_tab_selection" event.

We added more logic to render different components in the header slots based on the active tab.

The remaining task was to define the correct modifiers to apply to the toolbar struct. We experienced some issues while trying to update the modifiers array directly in the template or even in the handle_params function.

For example, doing something like this did not seem to work:

<VStack
	style={[
	~s[toolbar(content: :toolbar)],
	~s[navigationTitle(:title)],
	~s[navigationBarTitleDisplayMode(.inline)],
	~s[toolbarBackground(.visible, for: .navigationBar)],
	~s[toolbarBackground(.ultraThinMaterial, for: .navigationBar)]
	] ++ if @show_header_menu, do: [~s[toolbarTitleMenu(content: :content)]], else: []}>

Even though the props were correctly added to the modifiers array. (Brian Carderella pointed out that these small issues will likely be resolved when the LiveView Native core library refactor is completed 🎉)

We achieved our goal by wrapping the style in two different classes and conditionally switching between them based on the props.

We've added these two classes:

def class("main_header") do
~RULES"""
	toolbar(content: :toolbar)
	navigationTitle(:title)
	toolbarTitleMenu(content: :content)
	navigationBarTitleDisplayMode(.inline)
	toolbarBackgroundVisibility(.visible, for: .navigationBar)
	toolbarBackground(.ultraThinMaterial, for: .navigationBar)
"""
end

def class("simple_header") do
~RULES"""
	toolbar(content: :toolbar)
	navigationTitle(:title)
	navigationBarTitleDisplayMode(.inline)
"""
end

And finally, in our home_live.swiftui.neex

<.main_header 
  page_title={@page_title} 
  show_search={@show_search}
  style={if @show_header_menu, do: "main_header", else: "simple_header"}
  <:toolbar_trailing>
	<%= case @toolbar_trailing do %>
		<% :home_toolbar_trailing -> %>
		  <.home_toolbar_trailing />
		<% :notifications_toolbar_trailing -> %>
		  <.notifications_toolbar_trailing />
		<% :search_toolbar_trailing -> %>
		  <.search_toolbar_trailing />
		<% :profile_toolbar_trailing -> %>
		  <.profile_toolbar_trailing />
		<% :direct_messages_toolbar_trailing -> %>
		  <.direct_messages_toolbar_trailing />
		<% _ -> %>
    <% end %>
  </:toolbar_trailing>
  <:navigation_menu>
	<%= case @navigation_menu do %>
		<% :profile_navigation_menu -> %>
			<VStack></VStack>
		<% _ -> %>
			<.navigation_menu />
	<% end %>
  </:navigation_menu>
  <:header_menu>
	<%= case @header_menu do %>
	  <% :home_header_menu -> %>
		<.home_header_menu />
	  <% :notifications_header_menu -> %>
		<.notifications_header_menu />
	  <% :search_header_menu -> %>
	  <% _ -> %>
	<% end %>
  </:header_menu>
</.main_header>

This is what the result looks like:

We can optimize the code by using a single class and concatenating dynamic props, something along the lines of:

def class("main_header:" <> props) do

~RULES"""
  ...
"""
end

Additionally, we can use push_patch to remember the current tab when navigating back to previous page from the Search view. We also need to iron our understanding about how SwiftUI handles the navigation stack.

We'll continue this work in the next article, where we'll clean up the code and make it more robust. We'll also try to include some transition effects to change the header content when scrolling down the profile page.

From the next article, all the code will be pushed to our GitHub, making it easier for contributors to read and navigate the code.

Introducing Mosaic - Partner with the Bonfire Team to Create Your Own Federated Digital Space

2024-10-17T00:00:00Z

We’re excited to introduce Mosaic, a new initiative from the Bonfire team that empowers organisations by creating fully customised, federated digital spaces—built just for them.

What is Mosaic? #

Mosaic is a unique service where the Bonfire team collaborates with you to co-design and build a bespoke online presence that serves as a hybrid between a traditional website and a social networking platform—going well beyond merely sharing pictures or short posts. Depending on your specific needs, we will incorporate, build, or customise Bonfire extensions to facilitate all kinds of information sharing, community building, and collaboration.

With Mosaic, we build a bespoke software application that you can choose to self-host, ensuring you’re not locked into a monthly subscription with per-user costs and have complete control over your digital space.

You can visit the Mosaic website for more details, or the Bonfire website for information about the software project that makes Mosaic possible.

Why does it matter? #

Great question! In short, the way we work has changed dramatically, and our tools need to keep up. Here’s our perspective…

Yesterday, we used to work in companies. Today, we thrive in networks. #

In today’s landscape, an organisation’s success hinges not only on internal efficiency but also on how effectively it can communicate and flourish within a broader network of relationships, partnerships, and collaborations. The challenge? Most platforms were designed for what’s hopefully a bygone era—one dominated by rigid hierarchies and a focus on profit over inclusivity and cooperation, often overlooking the importance of externalities.

Enter Mosaic—a fresh approach to meet today’s needs. In a networked environment, the flow of information between teams, partners, and different layers of collaborators is a key factor for success. Seamless communication uncovers opportunities, fosters partnerships, and drives innovation. It’s no longer about working in isolation; it’s about thriving through connection. Today’s working world blurs the lines between internal staff and the public, encompassing a vibrant community of team members, collaborators, early adopters, advisors, partners, advocates, ambassadors, community members, followers, and more.

Unfortunately, most platforms just aren’t designed for this. They are stuck in the past, limiting what organisations can achieve. That’s where Mosaic is ready to ignite change. Together, we can co-create the tools necessary to thrive in a networked world—flexible, federated, and designed to help communities, organisations, collectives, and consortia collaborate and grow in meaningful, unexpected, and interconnected ways.

Why should you care about the fediverse? #

The fediverse is a growing network of independent yet interconnected digital spaces, which can empower organisations in ways Big Tech cannot. It enables you to own your data, control your algorithms, and connect directly with your community—without the unpredictability of profit-driven platforms.

Unlike proprietary apps like Instagram and Twitter, the fediverse prioritises trust and safety. Organisations can build meaningful connections, collaborate freely, and maintain control over their tools and online spaces. Thanks to standardised protocols like ActivityPub, users can easily export their data and migrate between instances, ensuring you’re never locked in.

In the fediverse, you have options. You can join a vast network with millions of users or create an island network focused on your community's needs. Whether you integrate into the global network or build your own archipelago, the fediverse offers a refreshing alternative to the dystopic enshitification of Big Tech.

Build once, benefit for ever #

Bonfire’s framework is open source under the AGPL 3.0 license, ensuring that any extension or fork remains open and available to all. This has two important benefits:

Every solution built for one organisation is available for anyone to use, improve, or adapt. Whether you’re building a community space, knowledge-sharing platform, or anything else, the tools we create together will contribute to the commons and benefit the broader ecosystem. As organisations work with us, they are not only solving their own challenges but also contributing to the success of others in the fediverse.
Everyone benefits from contributions made by others, so you can incorporate any new features and improvements. This creates a virtuous cycle of innovation and collaboration. We hope this approach encourages like-minded organisations to cooperate, co-design and co-fund features, and work together for collective impact.

With Mosaic, you’re not just solving your own problems—you’re investing in an ecosystem where everyone wins. You’re helping build a digital commons that empowers both your organisation and others to thrive in an increasingly networked world.

A real-world example #

Our first Mosaic project is a great example of the possibilities it offers: an independent cinema archive needed a platform where visitors could explore their extensive film catalog and related information, while community members could contribute to further enrich the archive. With Mosaic, we’re building a federated digital space where members can for example add annotations to specific sections of videos, and visitors can search the collection, follow topics, watch films, and engage with community activities. This transforms it from a static archive into a living, evolving space where users actively contribute to preserving independent cinema, enriching the collection over time.

All annotations and posts will be federated via the ActivityPub protocol, meaning users on platforms like Mastodon can discover and engage with the archive. And by building a Bonfire extension that integrates with the open-source software already used for film metadata and video hosting , we’re extending their toolset with social functionality tailored to their needs—without requiring them to switch platforms or manually copy information. This project exemplifies how Mosaic empowers organisations to build collaborative, networked digital spaces that foster community and go far beyond simple microblogging.

Ready to build with us? #

If Mosaic sounds like a solution worth exploring—or if you’re unsure and want to discuss your options—we’d love to chat! Let’s schedule a call to discuss your specific needs and explore how we can collaborate to create the ideal federated digital space for your community or organisation.

Our team is balancing core development of the Bonfire framework alongside Mosaic projects, so availability is limited. Reach out soon to secure a spot, and let’s start building something amazing together!

🐌 Slow Software for a Burning World 🔥

2025-04-20T00:00:00Z

A reflection on Bonfire’s journey to 1.0 and an open invitation to shape what comes next. #

As we approach the release of Bonfire 1.0, this isn’t your typical launch announcement. Instead, it’s a moment to reflect on how we’ve built Bonfire, a roadmap of values, methods, and intentions – and an invitation to define what comes next.

You can follow Bonfire on the fediverse for updates on the release, including highlights of unique features we’ll share over the next few days.

In a world of “move fast and break things,” we’ve chosen a different tempo — one rooted in care, deep listening, and collective stewardship. Slow software means building for long-term resilience and meaningful participation, rather than chasing novelty, speed, or scale.

🏦 Profit over people: at what cost? #

The Silicon Valley model delivers quick but unaccountable decisions. Rules are one-sided, power is hoarded, and systems operate behind closed doors. The casualties are many:

Trust: Algorithms bred to addict or manipulate rather than to inform or empower.
Consent: Secrecy quietly eroding autonomy. Invisible hands reshaping our lives without consent.
Community: Platforms optimising for engagement, making division and hatred profitable.
Attention: Human focus becomes data—extracted like oil to fuel the surveillance economy.
Labour: Care work like content moderation rendered invisible, workers treated as expendable.
Environment: Scale trumping sustainability at every turn.

As power concentrates, democracy withers and authoritarianism thrives. Algorithms tuned for "engagement" amplify fear, outrage, and division—because that’s what keeps us clicking. In the end, the tools meant to connect us are weaponized to divide us.

We've witnessed the damage when tech scales without care. What could we build instead?

🐌 Caracol: a different outlook #

Bonfire draws inspiration from the caracol (snail), a Zapatista symbol of slow, collective movement. The caracol is a spiral, with no top or center—only a shared heart. It stands for governance from the edges, listening before action, autonomy over hierarchy, and the conviction that how we build matters more than what we build.

These aren't lofty ideals—they're the backbone of Bonfire's design: a system built for flexibility, diversity, and overlapping needs. You don’t just use Bonfire—you shape it. It’s not one tool; it’s a terrain. A toolkit. Imagine digital spaces growing organically, communities determining how they connect, and tools that can be picked up, transformed, or set aside as needed. The caracol reminds us: meaningful progress comes from how we move, who we move with, and what kind of world we forge together.

✊ Governance: foundations of Bonfire #

The way we build is part of what we create. Inspired by sociocracy—a method of collaborative governance based on circles, consent, and distributed authority, and by Bookchin’s municipal confederations, the Zapatistas, and Rojava, governance in Bonfire runs deep:

Everything is modular—down to the core: All features are provided by separate extensions, meaning the “core app” contains no code but just configuration. There also isn’t a single core; instead, there exists different “flavours” of Bonfire: sets of config and extensions adapted to various use cases or communities.
Communities govern “flavours”: Bonfire's modularity serves a political purpose—inviting communities to discuss, configure, and collectively govern every aspect of their experience.
Shining a light on the power of defaults: Whenever a choice about how something should work in Bonfire is unclear, we make it configurable. Code establishes an initial default, but flavours can override it, communities can set instance-wide settings, and individuals make final decisions in their own account or profiles.
Custom roles: Moving beyond binary admin/user hierarchies, communities and individuals define and assign roles with precisely calibrated permissions—distributing power and responsibility to match their unique contexts.
Circles and boundaries: Creating flexible "circles" (like "colleagues" or "book club") and "boundaries" (granular permission sets) to control exactly who can see, interact with, or collaborate on anything—putting people in charge of their online relationships.
Tools that prioritise real people and relationships over speed and simplicity. We make no assumptions about the “average” user, social needs are complex and overlapping, there are no no one-size-fits-all solutions. We center needs often marginalized or overlooked—making them foundational so everyone benefits from greater flexibility and control.

🛡️ Guarding the commons #

Values alone aren’t enough—many well-intentioned projects eventually drift, burn out, or sell out. Bonfire is federated at every level—protocol, code, and governance—so its purpose and values can’t be quietly eroded or easily overturned. This technical and political design aims to resist capture, prevent enshittification, and safeguard community autonomy for the long term.

Here's how Bonfire can resist capture:

AGPL licensing: All code is AGPL, ensuring all modifications remain open and accessible, preventing capture by Big Tech or cloud services.
Multi-layered modularity and forkability: Everything is an extension—identity, moderation, groups. People can fork just an extension or a flavour–which encourages forking by lowering the maintainance effort.
Community-governed flavours: Communities decide what's included and how it evolves.
Zero VC funding or ads: Bonfire will remain free of venture capital and advertisement. No dark patterns. No pivoting away from responsibility or ethics.

We're also experimenting with:

Sociocratic circles: Self-organizing groups stewarding specific extensions or flavours, making decisions by consent. We're expanding this approach, creating pathways for communities to shape and protect their own digital spaces.
New models for participatory funding and resource allocation.

The commons survive only when they can regrow anywhere. We design for resilience, adaptability, and collective stewardship.

🌐 Federation: autonomy through connection #

Bonfire federates (i.e., interconnects with other independent platforms) with Mastodon and the wider fediverse, but federation is more than a technical protocol — it embodies our commitment to autonomy and collaboration:

Each community governs itself while connecting with others, maintaining distinct cultures, rules, and practices.
Federation isn't for scaling one model, but for interconnecting many. No central power dictates decisions—only connected, independent nodes working in concert.
Offboarding and freedom to migrate: Users should never be locked into platforms by their data or social connections.

We're building many interconnected worlds, not one massive platform.

Bonfire is a commons–a place to gather, co-create, and build networks that last–beyond products to be sold or services that use, abuse, or extract from you.

Bonfire’s values, goals, and processes are shaped by the people and communities who choose to participate. As a starting point, we uphold principles rooted in care, consent, and collective stewardship.

Whether you're a community organiser, activist, builder or simply curious, join us:

Join the conversation: Take part in our public discussion spaces. Share your experiences, needs, and questions.
Help shape governance: Participate in forming circles to govern specific extensions or Bonfire flavours, and share responsibility, decide by consent, and ensure Bonfire evolves with real community needs.
Propose features or co-design new extensions: Bring your ideas for how Bonfire can serve new purposes, or create new "flavours" and tools.
Contribute feedback: Help us spot issues, propose adaptations, or challenge assumptions so Bonfire can serve more people, more justly.
Help shape the culture: Share learnings from your own communities, organize workshops, or experiment with governance models.

Built for the long haul. By people, for people.

🏕️ Campground: a living laboratory #

Our test instance, the campground, is open as a local-only space for co-design and experimentation. Here, you can:

Experience what digital spaces built on consent, care, and mutual aid feel like.
Collaborate to co-design and test features — making Bonfire safer, more resilient, accessible, and truly centered on people and communities.

This isn’t a product launch—we’re not looking for users but for active participants: people and groups who want to shape, critique, and experiment together — whether that’s on the campground, through their own Bonfire instances, or by joining others to co-create new digital spaces.

✨ Let’s build what lasts, together #

If these ideas resonate, we invite you to reflect, dialogue, reach out, and co-create. Bonfire lives as a conversation in motion, beyond its code. The world needs many interconnected spaces built on care, autonomy, and collective power — not yet another app chasing scale.

We hope these principles can ignite new approaches to digital community-building. The future is ours to build — intentionally, collectively, and with care. Join us in shaping what comes next.

This post was written by the Bonfire maintainers' circle and shaped by feedback from the advisory circle. Join the conversation on Matrix, comment on this post on the fediverse or on the campground, or email us at team@bonfire.cafe.

Credit for the art goes to Tomás, a Zapatista artist in a community near San Cristobal.

Announcing the Bonfire Social 1.0 Release Candidate

2025-06-04T00:00:00Z

After a long stretch of co-design, development, and reflection (see Slow Software for a Burning World), we’re excited to share the Bonfire Social 1.0 Release Candidate — a version ready for real-world testing and feedback before the official 1.0 release.

We invite communities to install their own instances, explore the features, and help identify any remaining bugs or usability issues. Reach us at @bonfire@bonfire.cafe or through our issue tracker. Your input will help ensure Bonfire Social 1.0 is stable, accessible, and genuinely community-ready.

While Bonfire isn’t just another federated social app — it’s a modular framework for building digital spaces governed by communities – Bonfire Social is the first "flavour" of Bonfire to reach 1.0, and is a starting point for communities who want a space of their own, that's locally governed and fully customizable, yet connected to the wider fediverse. It’s ideal for people who value self-determination and meaningful connection, balancing local autonomy with global conversation.

A flavour is a pre-configured bundle of Bonfire extensions that defines which features are included, how they behave, and what defaults are in place. Each flavour can have its own governance group, extensions, roadmap, and priorities. Besides Bonfire Social, other flavours like Bonfire Community and Open Science are already in development, and any community can create their own.

Many features in Bonfire Social will feel familiar: feeds, profiles, following users, sharing posts, flagging or blocking content. Others might be new: rich-text posts, feed customization, nested discussions, multiple profiles per user, and fine-grained access control.

Let’s explore some of the key features:

Key features in this release #

Custom feeds #

Bonfire puts users in charge of what they see. Instead of relying on hidden algorithms, you can easily create your own custom feeds using a simple interface—no coding required. Filter and sort content by type, circle, date, engagement level, source instance, and more to surface what matters most to you.

Save presets and choose which ones to see in your sidebar and in what order.

Circles #

A circle is simply a list of people. Bonfire includes default circles like “local users” or “people I follow”, and you can define your own, e.g. "friends", "mutual aid crew" or "monster movie fans."

Circles are private by default but can be shared with others.

Boundaries #

Boundaries help you control who can see and interact with your content. E.g. you can share a post with several circles but only allow replies from a specific circle, or make a post public but invisible to specific people.

Nested discussions #

Bonfire supports threaded conversations, where replies can branch into focused sub-threads without losing context. It’s ideal for deep discussions, collaborative work, or simply following a conversation’s collective train of thought. This structure is especially useful in communities that value dialogue over noise — where replies build on one another rather than compete for attention.

Themes and customization #

Bonfire ships with 16 colourful themes — but you can go further. Design your own colors, fonts, and layout styles. Do you prefer a sleek minimalist space or want to recreate the GeoCities era? Go for it.

Multiple users profiles #

In Bonfire, accounts and profiles are separate. One account can create multiple independent profiles, each with its own followers, content, and settings.

Shared profiles can also be managed by multiple accounts — ideal for collectives, publications, or project teams.

Additional features #

Install Bonfire (as a Progressive Web App) on mobile devices.
Import community-curated blocklists to ease moderation.
Migrate your data and connections across instances and platforms.
Custom roles and permissions to distribute admin powers
Custom emoji support
Direct messages and private group discussions, with the same nested threads and discussion features as regular posts
Full-text search across posts, discussions, and profiles (users can opt out from being indexed)
Federates with Mastodon, Peertube, Mobilizon, and many more
Extensions can be enabled or disabled by admins and by users — for example, you can disable likes or boosts if they don’t suit your needs

You can find more details on Bonfire Social on our website or have a play on the demo instance.

What’s not included #

These features are not part of Bonfire Social 1.0:

Mastodon API compatibility
Content labeling (needs co-design and interoperability work)
Emoji reactions (needs better federation)
Groups and topics (coming in Bonfire Community flavour)
Federated coordination tools (coming in Bonfire Coordination flavour)
Many other feature ideas (add your own!)

Getting started #

Install Bonfire Social or try our demo instance
Report bugs: mention @bonfire@bonfire.cafe or open an issue
Need managed hosting?
Want to collaborate on a custom flavour?

What’s next? #

The release of Bonfire Social 1.0 will mark both an ending and a beginning. After building a foundation for federated community infrastructure — no more one-size-fits-all platforms, we’ll focus on:

Improvements based on community feedback
Co-designing other extensions and flavours with communities (e.g. Open Science Network)
Ensuring sustainability for maintainers and contributors
Expanding our moderation tools in collaboration with Erin Kissane, Jaz, and the IFTAS moderator community

Your feedback, ideas, and use cases will shape what comes next. Let’s build it — together.

You can comment on this post on the fediverse.

Long-form content in Bonfire: Part 1

2025-06-27T00:00:00Z

Inspired by @evan@cosocial.ca 's recent article on advancing long-form text in the social web, we've taken the leap and developed our first prototype for publishing and reading articles on Bonfire, based on the FEP-b2b8 draft specification.

Beyond microblogging #

From day one, we've designed Bonfire to break free from the constraints of microblogging-centric social networks. We've already experimented with extensions for coordinating tasks, exchanging resources, and more. As we work on Bonfire Social 1.0, adding article support felt like a natural evolution of this vision.

Working based on a FEP (fediverse enhancement proposal) that provided both design guidelines and technical specifications was refreshing and showed how co-design and shared standards can be our strongest ally for pushing the fediverse forward.

One feed, many content types #

Adding articles marks a small but significant step towards realising the vision of the open social web: a digital space where you can receive, read and interact with diverse content types from a single place, rather than juggling multiple platforms, accounts, and notification streams.

With Bonfire, articles from writefreely, ghosts, wordpress and any other federated platforms that implement the FEP-b2b8, now appear seamlessly in your feed alongside other content from your network. You can:

- Preview articles in the feed

- Read the full article and nested comments without loading an external site (just like the good old days of RSS readers)

- React or reply to the article or other comments

This UX improvement offers a glimpse of what becomes possible as more platforms and software embrace the fediverse.

But why stop there? #

Thanks to our modular feed builder, we've added an "Articles" feed preset. This dedicated timeline displays only long-form content, with sorting options for most liked, most replied, and more.

It's like having a decentralised blogging platform and feed reader integrated in your social network.

Speaking of feed readers, we've also added RSS and Atom feeds so you can subscribe to Bonfire feeds (including articles and/or microposts) via your favourite feed reader app as well.

And yes, you can also write articles directly in Bonfire! While the authoring experience is still rough around the edges (we're actively improving the UX), we're pleased with this initial prototype (which includes a simple rich text editor using markdown, and the option to add a title and cover image). In fact, this very article was written and published through Bonfire.

What's Next? #

As we refine the implementation, ideas are already flowing:

- Personal blog pages: Do users want an optional dedicated blog section on their profile, maybe with tabs to easily switch between notes, articles, or other content types?

- Instance curation: Could instance moderators pin and showcase their best articles on the homepage?

- Enhanced authoring: Should we create specialized UIs for properly writing and managing blog posts?

- Email subscriptions: Non-fediverse users could subscribe via email to federated blogs?

The possibilities are endless, but we believe long-form content features should be shaped by actual community needs and designed collaboratively in the open, building upon FEP-b2b8 through real-world usage and experimentation.

Join the experiment #

This is just the beginning. You can experience writing and reading articles on Bonfire today at our campground instance or by setting up your own Bonfire instance.

If your community is interested in test-driving or co-designing long-form content features, we’d love to collaborate.

To build a fully integrated, community-shaped publishing experience — and continue improving Bonfire in many other areas — we’re actively seeking support. You can back Bonfire on OpenCollective or get in touch to help shape the future of federated publishing.

---

What would you like to see in federated long-form content? Join the conversation and help us build the open social web together!

🔥 Bonfire Social 1.0 RC2

2025-07-08T00:00:00Z

We’re pleased to announce Bonfire Social 1.0 Release Candidate 2! This update is all about refining and polishing the experience, fixing bugs, and making Bonfire more enjoyable and reliable for everyone. These improvements come directly from your feedback, bug reports, and real-world testing.

Of course, we couldn’t help ourselves and also snuck in some exciting new features—like long-form article publishing and more feeds customisations, plus plenty of interface refinements for both desktop and mobile.

A huge thank you to everyone who has set up a Bonfire instance, or joined the campground (our local-only testing space) to try out the app. Your suggestions and bug reports have been invaluable as we approach version 1.0. Please keep testing, sharing feedback, and helping us shape the future of federated social spaces!

✨ What’s new and improved? #

Long-form publishing: Going beyond beyond short posts to read and write in-depth articles, ideal for essays, announcements, or detailed content. Article feeds are now available for RSS readers.
Smarter feeds: New feed options for events, books, and articles help you discover what matters to you most. You can now also filter out your own activities from your feeds when desired.
Multi-profiles overview: A new navigation menu can display all your profiles with notification indicators, allowing quick profile switching.
Private by default: New Bonfire instances start as invite-only, giving admins control over membership from day one.
Interface improvements: We've refined the user experience, enhanced notifications and ensured posts display properly across mobile devices.
More reliable: Tons of fixes for authentication, media uploads, mentions, moderation, and other core features.

Additional improvements include:

Better translation and localization workflow
Smoother OAuth/OpenID login and SSO support
Updated documentation and guides for admins and contributors
Enhanced S3 integration for uploads
Lots of small bug fixes on comment threads, messaging, settings, and more

For a comprehensive list of changes, see the full changelog.

🎪 Community contributions and other initiatives #

We hosted our first install party using coop-cloud, with all participants who followed along successfully deploying their own Bonfire instances.
Seperately, ozoned from Fireside Fedi livestreamed their installation attempt, surfacing valuable setup challenges. This highlighted the need to simplify Docker deployment and improve documentation. Contributors are welcome to help make this easier!
Sciety deployed a Bonfire instance as part of their pre-print review project.
@spark464@spark.box464.social published an article on how to add a weather widget in Bonfire.

🌍 Localisation: Bonfire in your language! #

Bonfire Social is built to be diverse and welcoming, which means making it accessible in as many languages as possible. Thanks to our amazing translators, Bonfire is now available in several languages.

🏅 Top translated languages #

- Portuguese (Brazil): 100% translated & reviewed 🎉

- French: 98.9% translated, 69.4% reviewed

- Italian: 96.7% translated, 54% reviewed

- German: 98% translated

- Spanish: 57% translated

- Vietnamese: 20.9% translated, 11.1% reviewed

- ...and several more, including Catalan, Cantonese and Taiwanese.

Want to help Bonfire speak your language? Please join us and make a difference for communities worldwide!

🤝 Help needed #

As we push toward 1.0, we're facing some specific challenges where community support and contributions would make a real difference:

DevOps expertise: We need help streamlining the Docker installation process to make Bonfire more accessible to new users. If you have experience with containerisation and deployment workflows, your contributions would be invaluable.
Elixir developers: Join us in improving Bonfire's stability and performance. We're focused on eliminating bugs and enhancing the core extensions' reliability.
Financial support: As a small team of two working full-time on Bonfire, we need community support to sustain development. You can contribute through our Open Collective page.
Federation testing: We're seeking users willing to set up Bonfire instances and try out federation and interoperability with other fediverse platforms. Your real-world testing helps ensure Bonfire works seamlessly across the fediverse.
Translation: Please join us or share this with your multilingual friends!

These are our most pressing needs as we approach 1.0. If you can help with any of these areas, please get in touch via the fediverse, Matrix chat, or GitHub. Every contribution, big or small, helps make Bonfire better for everyone.

🙏 Thank you! #

A heartfelt thank you to everyone who has contributed translations and reviews. You are lighting up Bonfire for people everywhere! Here are some of our awesome translators:

Gilles Dutilh, Ahmad Dakhlallah, Lamparina Coletivo, alan ptm, Antonio Irre, Zulfikar A, CDN, cranio_is_thinking, Steven Bond, Diego KehrleSousa, Vrlo Vazno, Ed, Andrei Guliaikin, Hendra Wahyu T, Hippie Gschpängschtli, House of Olivier EU, Ivan Minutillo, Juan García, Lapineige, Pascal Schmid, Martin Frost, Duy, Mayel de Borniol, Sovversivo Anonimo, Peter Kvillegård, Poesty Li, Sergio Guidoux, Vaclovas lntas, Williams Melgar, and many more!

We really appreciate your work! 💜

And a massive thank you to everyone who contributed code, ideas, testing, translations, and support—including @spark464@spark.box464.social , @tommi@pan.rent, @lechindianer@sueden.social , @fishinthecalculator@bonfire.fishinthecalculator.me , @dumpsterqueer@gts.superseriousbusiness.org , @ozoned@social.ozoned.net.

Thanks to those that are taking time to test drive Bonfire on our demo instance and provide feedback, such as @LiquidParasyte, @Rincewind, @youronlyone, @coyote...

Thanks to @nlnet@social.nlnet.nl for supporting the Bonfire development, all our Open Collective donors and our amazing community as a whole.

Bonfire is a collaborative project, and we’re grateful to build it with you .

---

Ready to try Bonfire 1.0 RC2?

- Get started

- Try our demo instance

- Provide feedback

- Chat with us on the fediverse: @Bonfire@bonfire.cafe

- Chat with us on Matrix

Let’s light up the fediverse together! 🚀

Connect your existing tools to the fediverse with Mosaic

2025-07-15T00:00:00Z

Your organisation's favorite apps, now with superpowers.

We all navigate a constellation of specialized tools daily. Organisations depend on CRMs, project management platforms, and financial systems. Communities coordinate through forums, chat and event platforms, and resource-sharing databases. Individuals track their lives across fitness apps, reading lists, streaming services, knowledge management tools and more.

Each app serves its purpose, but they each create isolated silos where valuable activities, insights, and connections remain trapped behind separate logins and walled gardens.

What if you could keep using the tools built for your needs while opening them to your community or the broader fediverse according to your specific rules and boundaries?

🧰 Bridge your tools to the open web #

Through our Mosaic initiative, leveraging the Bonfire modular framework, we offer like-minded organizations and communities the opportunity to build custom extensions that connect their homegrown or third-party applications to the fediverse. These bridges:

Import data from your existing tools
Transform it into rich ActivityPub activities for federation
Enable meaningful, two-way interactions
Respect your privacy boundaries and governance needs

The result? Your isolated tools become part of a connected, collaborative ecosystem.

Real-world examples: your tools, federated #

Project management meets community feedback #

Imagine your team uses a kanban board to manage development sprints. With a custom Bonfire extension, we could connect the service's API and monitor specific triggers like completed tasks, cards tagged with #feedback, or comments added.

When triggered, the extension would create ActivityPub objects with rich metadata: task description, relevant links, and progress context. Your fediverse followers would receive these as native posts they can react to, boost, and comment on. Their feedback would flow back through the extension as comments on the original card.

You would control the boundaries granularly, e.g. public for open source projects, followers-only for beta features, restricted to your instance for internal work, or anything in between. The two-way sync would ensure your project management tool remains the single source of truth while your community becomes an active participant in the development process.

Community resources go network-wide #

Your mutual aid network could maintain a resource spreadsheet or database tracking offers, needs, and availability. Our extension would poll for new entries or status changes (by connecting to an API, listening to webhooks, or even directly reading the database or spreadsheet itself), converting them into structured ActivityPub objects with standardised properties for location and resource type taxonomy tags, and custom properties for quantity and urgency.

When someone marks "10 wool blankets available" or "urgent: need baby formula," it would federate as a rich post that other instances can parse intelligently. Neighboring mutual aid groups would see these in dedicated feeds or maps, filtered by resource type or geographic proximity.

The extension could handle resource matching across networks, suggesting possible connections between needs and offers while respecting each network's autonomy.

Events that travel beyond platform borders #

Your organisation's calendar contains everything from public conferences to internal meetings. The extension would connect via calendar APIs (CalDAV, Google Calendar API, etc.) and intelligently parse event metadata: detecting whether events are public, extracting registration links, and identifying capacity limits.

Public events would become rich ActivityPub Event objects that federated platforms can display natively—Mobilizon and Bonfire instances would show them in event listings, Mastodon users would see them as interactive posts. RSVPs would flow back through via ActivityPub federation, updating your attendee count in real-time.

The extension could handle timezone conversions, recurring events, and last-minute changes. When you update event details, it would send an update to ensure all federated copies stay synchronised.

The possibilities are endless #

Imagine federating your collaborative playlists to spark music discovery across communities. Or sharing fitness milestones that inspire distributed workout challenges. Or creating transparent financial reporting that builds trust with your supporter network.

Ready to give your tools superpowers? #

The examples above showcase just a glimpse of what's possible when we bridge isolated tools to the fediverse. While these specific integrations are just ideas, they represent the transformative potential of Bonfire, and we're ready to build them with you.

Mosaic is a unique service where the Bonfire team works with you to co-design and build custom extensions entirely shaped around your community's needs.

Mosaic is perfect for you if:

You're frustrated by data trapped in isolated platforms
Your community wants to participate more but faces too many barriers
You believe in transparency and collaborative approaches
You're ready to pioneer new models of digital cooperation

What we offer:

Custom extension development tailored to your specific tools and workflows
Full control over privacy boundaries and federation rules
Ongoing support as your needs evolve
The opportunity to be among the first to explore federated tool integration

Let's start a conversation.

Whether you want to federate your project management, open up your resource database, or imagine entirely new possibilities, we're here to build it with you. Your use case could become the next example inspiring others to break down their digital silos.

Book a call with us or contact us at team@bonfire.cafe.

Exploring a Bonfire Geosocial Extension

2025-07-23T00:00:00Z

Overview #

This issue explores implementing a basic geosocial extension for Bonfire that enables location-based social interactions without the privacy concerns, gamification and corporate overhead of foursquare.

Relevant resources #

Use cases and proposed implementation approach: hedgedoc.socialweb.coop/kUPv...
Geosocial task force github.com/swicg/geosocial (Issues are particularly relevant)
Small client for checking in places socialwebfoundation.org/2025...

Mockups #

Create new activities in the composer #

Currently, our composer only supports notes and articles. To enable check-ins/check-outs, we need:

Activity type selector: Dropdown next to user avatar in composer
Dynamic fields: Show relevant inputs based on selected activity type
For check-ins/travel/check-outs: Autocomplete location input

Here our standard component, but with a dropdown element next the user avatar to select the activity to publish

The dropdown shows the activity type available, based on the active extensions

Once the user chooses the activity, the composer includes the needed extra field, in this case for check-in it only adds a autocomplete input for selecting the location.

(I added a dropdown next to checkin for switching between checkin - travel - checkout, maybe it's better to show all the 3 options inline?)

The place page #

Places should be first-class AP actor.

This transforms places from simple geotags into active participants in the federated web, allowing physical spaces to build communities and curate their digital presence.

This means also that a place should be managed by one or more user.

In the following mockups we envisioned a very basic place page: on the right sidebar there is the About widget, with some extra fields that can be included in the place settings such as: name, address, phone number, email, opening hours, plus some aggregated data if needed, like the amount of check-in in last day/weel/month etc.

The page would have different tabs based on what's most relevant for the place and the extensions enabled, here the check-in feed

and the events feed

We already have most of the building block ready for implementing this, at least for this basic version (eg. focusing only on "public" spaces, not including the event extension, focus on check-in/check-out functionalities).

Location Pages for Non-Actor Places #

For locations from places.pub (or similar services) that aren't yet ActivityPub actors, we can create aggregation pages that function like more structured location-specific hashtag pages. Users can follow these locations and explore all related activities in one place.

See all the check-in that belong to a specific location #

See the map with all the other locations nearby #

See all the media published in that location #

Next steps

Add a Map view mockup (we do already have one in the bonfire_geolocate extension) to navigate all the places in a interactive way
Add more geosocial activity preview to see how they appear in other feeds
Feedback on proposed UX flow

Bonfire Social 1.0rc3

2025-10-02T00:00:00Z

Bonfire’s latest release puts data portability (moving and taking your data with you) and anti-enshittification (avoiding manipulative platform tricks) front and center. Whether you’re moving from/to another fediverse app or between Bonfire instances, you can now bring along your posts, bookmarks, block lists, circles — and of course, your followers.

This release also includes consent-based quoting, new dashboards for migration and federation status, improvements for using Bonfire on mobile, a smoother interface for boundaries, and new guides to help you get started.

We encourage all instance operators to upgrade and explore these new capabilities. Your feedback on this release candidate will help us refine these features before the stable release.

Here are more details on some of these...

Import your old posts when moving instances #

You can now bring your posts (and optionally their replies) with you when moving to Bonfire from another instance. Imported posts keep their original dates and links, and are added to your timeline in the right order, so your history looks complete. Replies and threads are preserved, as are like/boost counts. This works by automatically "boosting" your old posts (but without flooding people's feeds or notifications with old activities).

Bonfire now supports consent-based quoting, introduced through the new ActivityPub extension FEP-044f. With this first iteration released alongside Mastodon’s, it marks an important step toward making quoting work smoothly — and respectfully — across the fediverse.

With Bonfire, you can now:

Use boundaries to define who can quote your post, who must request first, or who cannot request at all.
Quote — or request consent to quote — someone else’s post.
Give or withdraw consent at any time.

Other data portability improvements #

Instance migration is now more robust. In addition to follows, blocks, and posts, you can now export and import circles/lists, bookmarks, likes, and boosts.

A dedicated dashboard helps you follow the progress of data imports and migrations, so you always know what's happening with your data.

Federation status dashboard #

Similarly, you can now easily track your outgoing and incoming federated activities with a new dashboard, making it simpler to monitor federation health and troubleshoot issues.

RSS/Atom feeds #

Access your data beyond the fediverse: Subscribe to Bonfire feeds via your preferred RSS/Atom client. You can subscribe to specific users or to a feed of your choice, including bookmarks, likes, etc, all available as RSS.

Boundary UI & usability improvements: #

Boundaries (who can see or interact with your posts) are now easier to use. For example, you can share a post publicly but limit who can reply or quote it. Bonfire’s boundaries now also connect with GoToSocial’s interaction controls and Mastodon's quote authorisations, making them more interoperable across the fediverse. We also drafted a guide about how you can start using circles and boundaries (feedback welcome!)

Mobile web app improvements #

The progressive web app experience has been refined with UI and UX enhancements that make Bonfire feel more native on mobile devices. Whether you're installing Bonfire to your home screen or using it directly in your mobile browser, the interface now responds more smoothly and adapts better to different screen sizes.

Single sign-on #

Bonfire supports OpenID Connect and OAuth2 authentication, allowing instance administrators to configure their preferred identity providers for login and signup. We've tested integration with GitHub, ORCID, Zenodo, and more, making it easier for communities to align authentication with their existing workflows and trust networks.

Each instance can define which providers to enable and whether to allow new signups through SSO, giving administrators flexibility in how their communities access Bonfire. Bonfire can also act as an SSO provider itself, so other applications can authenticate users through your instance.

Federation interoperability guide #

Published interoperability docs to ensure compatibility with other ActivityPub software.

User guides #

New guides and documentation help you get started and make the most of Bonfire's features, whether you're new to the fediverse or exploring advanced capabilities like boundaries and circles. This is a work in progress, so feedback on how things would be better explained or what's missing would be very helpful!

These guides are designed to help you understand, use, and configure Bonfire.

Core Concepts #

Using Bonfire #

Data & Identity Portability #

Advanced guides #

For a full list of changes, you can read the changelog.

What's next #

We're eager to dive deeper with you and gather feedback during the next FediForum on Oct 7-8th, where we'll paricipate in a session along with our friends from the NewsMast Foundation.
In November, we'll be presenting at SFSCON in Bolzano, Italy. We'd love to connect and hang out with those of you who'll be there, if you're planning to attend, please reach out!
Beyond Bonfire Social, we're also working on the Open Science Network flavour, which is shaping up to address critical needs in academic and research communities.

Support the project #

Building truly autonomous digital spaces requires community and solidarity.

If Bonfire’s vision speaks to you, there are many ways to help. Financial support via Open Collective helps us dedicate time to maintenance rather than just features. But contributions aren’t only financial — testing this release candidate, translating the interface, reporting bugs, or spreading the word are equally valuable. Every action strengthens the commons we’re building together.

Anti-enshittification is a collective effort to create digital commons that serves people, not platforms.

Bonfire Social 1.0 is here, back the community‑funded roadmap

2025-11-07T00:00:00Z

Today we're releasing Bonfire Social 1.0: a federated community‑first social network and the modular toolkit that powers it: a framework for building apps on the open social web beyond microblogging. We're pairing the launch with a crowdfund so communities drive what we build next.

If you believe the social web should be open and portable - where your profiles, relationships and data move with you, where governance lives with communities, and where you can build beyond microblogging for community organising, mutual aid, and collective decisionmaking, this is your moment to help.

Please back the campaign, share it, and invite others to make this "last migration" from closed platforms to open, interoperable networks.

Visit the campaign page for more details

Quick links

Thank you for helping build a safer and community‑centred social web, slowly, autonomously, together.

Matters of care - why maintenance comes first

2025-11-12T00:00:00Z

It was not an easy choice to focus our crowdfunding campaign on care and maintenance as the condition sine qua non to consider it successful.

Some may dismiss a maintenance‑focused campaign as unambitious or uninteresting, if they don't see the stretch goals beyond it. Others may just not be hooked on backing a project that cares (pun intended) so much about maintenance, as Erin Kissane beautifully put it in her recent essay:

Bonfire also, to my absolute delight, foregrounds maintenance—the thing no institutional funder ever wants to help with, because the incentives are for the innovative and new, not the stable and thriving

Care work is unsexy. It doesn’t open wallets or drive clicks. So why put care as the foundation, and how does it shape what and how we build?

First, let's clarify what "care" means to us. We go by the definition elaborated by Joan Tronto and Berenice Fisher in Toward a feminist theory of caring, discovered while reading the PirateCare syllabus several years ago, shared with us by our friend Maddalena Fragnito:

In the most general sense, care is a species activity that includes everything we do to maintain, continue and repair our world so that we may live in it as well as possible. That world includes our bodies, ourselves and our environment, all of which we seek to interweave in a complex, life-sustaining web.

Almost all open source software goes through that, because care is first of all about nurturing relationships:

To care about something, or for somebody, is inevitably to create relation. Caring is more than an affective-ethical state: it involves material engagement in labours to sustain interdependent worlds, labours that are often associated with exploitation and domination.

- Maria Puig de La Bellacasa, 2012. Nothing comes without its world: Thinking with care

Valuing unglamorous labour #

Maintaining, continuing and repairing are care work. They’re foundational to any open‑source project. Maintenance is the unglamorous work that keeps people safe, tools usable, and the commons alive.

Day to day, that looks like fixing bugs and security issues, keeping things reliable and performant, documenting how to use and deploy, adding settings people ask for, translating the interface, and making it accessible on slow connections and phones. It’s unglamorous, often invisible, but it’s what builds reliability, equity, and trust.

But caring in open‑source software is also about maintaining relationship and communication: documentation and guides, replying to questions, and being accountable to the community that is using or wants to use your tools: community support; managing translations and localisation; troubleshooting; moderation for project spaces; attending calls and events; onboarding help... did we say troubleshooting?

Mutual aid over burnout #

However, care isn’t just outwards facing, it's how we hold eachother up. If life intervenes (with illness, caregiving, burnout, financial stress, etc.) we don't apply pressure; we offer solidarity. As much as possible, the rest of us stretch so others don't have to vanish or push through pain. We redistribute tasks, slow a release, pool funds, and amplify their other work. People first, with tempo and budgets set by real lives. That's how the commons stays alive: not just through resilient code but through resilient relationships.

This relational care extends in collaborations with people involved in flavours such as the Open Science Network, family and friends, and allied communities or projects. It takes a village to keep the commons alive and healthy beyond any "core team".

How care shapes the system #

We also apply care at the root of our technical and governance infrastructure. We want our software to be community‑driven in terms of what features are prioritised, which are excluded, how features are designed, how defaults are decided, and how communities should not be bottlenecked by previous decisions about how things are supposed to work for them.

We believe in many interconnected worlds, not one platform. Communities should set their own rules and still connect. That’s why we create everything as remixable building blocks and release code under the open source AGPL licence and refuse ads or VC incentives that drive enshittification.

In short, we prioritise care over novelty and speed. We listen first, do user research, and design for consent and harm reduction. Ethics and real needs guide what we build and how we ship.

Tools for organising and care #

We've now released the Bonfire Social flavour and are actively working on the Open Science Network, in cooperation with a group of scientists and researchers.

Once we have care covered, we'll feel ready to commit to building exciting and critical features together with an awesome list of communities and partners, to transform how social networks can empower communities for the better: free from billionaires, VCs, and benevolent dictators.

The crowdfunding stretch goals include tools such as for groups, events, collective decision‑making, cross‑instance moderation tooling, mutual aid networks, living memory archives, etc., to move beyond social media (broadcasting content to an audience) and extend the social graph to community organising, blurring the lines between local communities and digital spaces.

Infrastructure for the long haul #

With the Co‑op Hosting stretch goal (in cooperation with Co-op Cloud) we want to build a network of care to offer an infrastructure that is accessible and trustworthy to non‑technical communities across the whole software lifecycle, providing sustainability for all partners and teams involved. Shared sustainability means funding infrastructure, ongoing maintenance and contributor care, not just new features.

Back the care work #

Our crowdfunding campaign is radically ambitious specifically because we put care as the precondition to research and development.

At the time of writing we’re 74% of the way towards the care and maintenance goal. Please help us cross the last mile to our first goal.

If you can't contribute funds, please share the campaign on different channels, introduce us to people who could help (such as journalists or pilot communities) or contribute feedback or translations, all equally part of building (and maintaining!) the commons together.

Gifting with Integrity: Federated Digital Spaces for Mutual Aid Networks

2025-11-15T00:00:00Z

Meet Adrian and Lee, two of the people helping shape Bonfire's future. They are gifting group administrators who've been on the frontlines of the Buy Nothing movement, building community, fostering generosity, and fighting against Facebook's enshittification every step of the way.

They're co-designing the Mutual Aid Networks stretch goal with us, bringing years of lived experience into Bonfire's development.

In this video and in Adrian's writeup below they share their story, why this matters, and why we're building it together.

Support our crowdfunding campaign to make community-owned gifting infrastructure a reality.

The Gifting Movement #

I am an administrator of a gifting group, formerly known as “Buy Nothing” on the formerly tolerable “facebook”. We’re looking for a new home.

Buy Nothing was a grassroots movement that had millions of participants in thousands of groups across the world. In my suburb, 1 in 5 people are members of our local chapter’s facebook group, which exists for the sole purpose of either giving things away, or asking for things, from your neighbours. The movement has now forked into both a privately owned (somewhat buggy) app and a rebel alliance of facebook groups called “Gifting with Integrity” and other names.

Buy Nothing’s global success could be attributed to the context in which it was started, its thoughtful principles and its careful coordination. Facebook’s universal adoption and its built-in groups functionality made it technically easy to set up one of these communities and have the posts appear in people’s news feeds. People were already checking these, which made it a low barrier to entry. Buy Nothing groups emphasised that meeting new people; helping each other, being kind and respectful in the process; were all part of the goal. That was a new experience for many facebook users, who are used to the wild west of facebook Marketplace interactions. Facebook doesn’t really facilitate kindness and respect out of the box but the founders of Buy Nothing worked hard to build a kind-of open-source administrative control to circumvent facebook’s default of engineering for conflict.

A Movement's Secret Sauce #

The movement tapped into the unmistakable joy that comes from giving and sharing as well as the security we feel from getting our needs met by our community. It tapped into the longing for real, human connection that was coming from our increasing addiction to being online.

The group administrators are responsible for bringing the movement's principles from theory into action. Every group administrator who set up a Buy Nothing group was asked to complete the Buy Nothing training linked above. This included introducing ideas like: what is a gift economy; understanding the benefits of diversity; understanding the issues with consumerism, prejudice, privilege; and all the practicalities of starting a group. Group administrators were connected in regional and global chat groups, enabling them to solve problems together, share expertise and evolve new ideas to be incorporated into the training material. The result was the most progressive induction I had partaken in up to that moment.
Having a clear educational pathway makes it possible to replicate the successful elements of a group in new instances. The initial learning load is not a barrier to entry, but instead resonates with the people who have noticed the same issues it solves. They see it as a meaningful call to action which they are willing to put their energy behind. The power and privilege of administrating a group is given freely to anyone willing to endure this rewarding rite of passage.

Group administrators promote their group through their real-life social networks. Since they have such a good understanding of the movement’s principles, these are relayed with enthusiasm and passion. This gets passed through friends and friends-of-friends like a wave. The enthusiasm and passion exchanged is just not comparable to receiving a link from a stranger. If people know and trust the admins, this trust is also transferred into the group they create. This becomes an essential part of setting and propagating the culture. Everyone in the group is connected to everyone else, friends, family or neighbours and this affects how we interact with each other: with accountability and consideration (not like many other spaces of the internet, which are more like people who have crossed international borders to go on a bender without repercussions.)

Mutual Aid Movements v Capitalism #

As facebook has increasingly needed to deliver higher revenue to justify its share price, the quality of our news feeds has been in freefall, consisting mostly of paid content, devoid of truth and morality. Now it feels like our local gifting groups are being held hostage along with the other interest groups and communities. They all came to facebook because that's where the people were. Now the only reason people go on facebook is because that's where the groups are.

There have been a lot of attempts to make apps that take the gifting phenomenon out of facebook. None though seem to have achieved the cohesive, world spanning momentum of the original Buy Nothing groups. In the official Buy Nothing app, “Community Builders” (aka “Administrators”) are now considered optional extras, so anyone can start using the app in any area, at any time, regardless of whether someone has committed themselves to grow and nurture the movement there. The result is that people have an experience of turning up to a party with no one else there, one at a time. I guess Buy Nothing failed to replicate the success of Buy Nothing. Like many other tech startups, they might have thought it made business sense to engineer away the need for administrators, to reduce a perceived problem of work hours. But in doing so, they ignored the dynamics of a social movement: who’s going to promote the group now? Who’s going to take responsibility for the group’s direction? Who’s going to provide the feedback and new ideas? Sure they might keep trying to make AI grow a conscience and moderate every conversation in the world at once, but we love being moderators and we love our oceans at their current temperatures, so why introduce new problems for useless solutions?

Mutual Aid Unleashed #

Innovation should be targeted at real problems. The way existing commercial online marketplaces are set up, there is little consideration for the economy of movement. At any point in time, any person might decide they want something from literally anywhere and the result is traffic (and emissions). We also have a problem of people feeling the need to be glued to their phones in case they miss out on something. To address this in our groups we encourage people to wait a while before choosing who will receive their gift. If we had control of the underlying software, we could design our gifting platform to first expose gifts to nearby neighbours and increase the radius over time. This would introduce a natural delay in the likelihood of a gift being allocated, and help in strengthening nearby neighbourhood connections (reversing feelings of isolation). It would also reduce transport emissions by prioritising these localised interactions, while saving more distant interactions for more niche objects.

We can also be conscious about how our online communities affect our culture, which means we can decide together which of our expectations we want to keep and which don’t serve us well anymore. Should I expect, as people in my city do, that every 6 months, I can generate a pile of rubbish that is too big to go in my 240L bin (which I also expect to be emptied every week?) Should I expect that the council will take it, squash it and bury it? Should I expect that the only way this stuff is going to get recycled is by people driving around rummaging through the rubbish? Should I expect someone else to recover and repair our broken stuff? Should I expect there is a lower class to do this for me and that they should show gratitude for this honour? Or should I try to demonstrate that when I buy something, its existence is my responsibility, including when it is no longer useful to me. Are there things I just shouldn’t buy? Are there things that shouldn't be for sale in the first place?

When we have determined what our community’s principles or “rules” are, finding out about them shouldn’t be the same experience as encountering a big tech’s “terms of service”: large blocks of complicated text, cut off by a scroll bar, making room for a big “Agree” button that will make it all go away. These are designed for minimal engagement and minimal understanding to obfuscate rules that benefit one large company. Moderators and group administrators need to establish, learn, evolve and propagate community culture and if this is enhanced in our technology design, we will be rewarded with a safe, progressive and popular movement.

The cultural change that we are talking about amounts to a large reduction of material waste and a great improvement in mental health outcomes for our community. Had the costs otherwise fallen upon our state bodies, they would be exponentially greater than the cost of investing in development of open source software which can be deployed across many regions with similar issues to solve. Investing in community hosting collectives, is a far more economic proposition than corporate subscription solutions which not only cover running costs but investors' completely insatiable greed.

We are driven by a desire to see less unnecessary consumption, less trash, less traffic and less isolation. We want to see less misinformation and less of the corruption, suffering and inequality it enables. We want more input and more community connections. We see easy ways to influence all of these things by letting communities partake in designing and running their own communications platforms.

We want to connect with other gifting groups around the country and around the world about how they’re addressing similar issues. We want to collaborate with the local council and government bodies who see value in backing these community-led and community-owned initiatives. We’d love to hear from members of gifting communities about their thoughts on social media and how our groups should evolve in the future. We want to work with local, progressive tech people who are passionate about sustainable, community hosting and software. Let’s connect and build this together.

If you are part of a mutual aid or gifting community, get in touch with us to work together on the mutual aid stretch goal. Support our crowdfunding campaign to make community-owned gifting infrastructure a reality.

What is Bonfire? Plural by design

2025-11-27T00:00:00Z

Bonfire is difficult to pin down with a single definition, and that's a feature, not a bug. The project's very structure is about enabling a tapestry of social spaces, all built with shared building blocks but diverging in flavour, practice, and purpose. In this post we embrace the project's plurality and explore the many ways people around the web describe and understand Bonfire.

1. Familiar yet different: not (just) another Mastodon #

Many pin Bonfire as “Mastodon-adjacent”, but see both a family resemblance and a revolution brewing:

"Bonfire Social seems to be a Mastodon alternative?"^14

"Mastodon sets out to create a single optimized interface for a short form social network. Bonfire sets out to let you create different interfaces that match what your unique community needs..."^1

Or, as another puts it:

"Bonfire, the swiss knife fused with a dremel of the fediverse"^15

2. Bonfire as a toolkit or framework for building community platforms #

A recurring theme is that Bonfire is fundamentally not just a social platform, but an extensible toolkit or framework:

"Bonfire is a framework to put together different configurable communities or social networks based on ActivityPub. ... Bonfire sets out to let you create different interfaces that match what your unique community needs through extensions."^1

"It's modular. Devs can create plug-ins to add features. For example, you can run different 'apps,' including social (Mastodon-like), community (Forum-like)... hoping devs can pick and choose feature sets they want to build unique platforms. Like fediverse legos."^2

"Both a platform like mastodon, and a toolkit for internet community software..."^3

Or as one commenter quips:

"Beneath the surface, there’s a bigger story ... rather than simply being a social platform, it’s also a development framework."^4

3. Flavours and extensions: customisation and plurality by design #

What makes Bonfire unique is the flavour and extension model, which means each instance could feel totally different:

"In Bonfire, Extensions are first-class citizens... ranging from the federation library to data access controls to mutual aid tools ... pick and choose which ones to use, then bundle them together into a single app experience. Bonfire calls these experiences Flavors..."^4

"Each flavor is a preconfigured bundle ... When a community opts to run a particular 'flavor,' it gets to govern the app as it sees fit, adding its own extensions and determining its own roadmap for product changes. This puts the social software back under users’ control..."^5

One commenter likens Bonfire to "a social networking-focused Nextcloud,"^6 while another compares it to "getting all your friends together for a big barn-raising, and then each of you gets to customize and decorate your own interior unit. The foundation is prepared for you and all the timber and roofing supplies are available."^7

Or succinctly:

"Fediverse platform built for customization and extension as a one sentence explanation."^8

4. Commons and cooperative ethos, not just software #

Bonfire’s modularity isn’t just technical, but philosophical:

"Bonfire is building a modular toolkit for communities with the decentralised, commons patterns at heart..."^9

"kind of a framework to build fediverse apps… putting a lot is emphasis on community and cooperative aspects."^21

"The team describes Bonfire as open, community-first infrastructure, and their design is explicitly for communities rather than individual people." Bonfire is "a 'third path' between blockchain’s emphasis on individual sovereignty and Big Tech’s centralisation, one that centers collective care and community autonomy."^10

Bonfire’s own flavor offerings, like the Open Science Network, are co-designed with stakeholders:

"Each feature is being co-designed with organisations bringing domain expertise, from Princeton HCI’s research on collective governance to Co-op Cloud’s work on community hosting infrastructure."^10

5. Granular boundaries & empowerment of communities and individuals #

Many point out this signature capability: fine-tuned privacy and boundaries.

"...with a unique feature of boundaries, your posts can be shared to specific people within your 'circles'."^2

"On peut gérer avec précision qui peut voir/intéragir avec les messages avec un système de cercles."^11

Other features noted include:

Custom feeds
Multiple independent profiles per user
Portability & content migration tools
"Group-based visibility and feeds with Circles and extremely granular controls for who can see, reply to, and otherwise interact with posts using Boundaries."^12

6. Diverse use cases & flavours in practice #

Far from being “just another Mastodon,” Bonfire’s architecture enables specialized communities and use cases:

"An example of what you can do with the blocks: Bonfire’s Open Science community project ... was co-designed with working scholars to build something that served them, specifically. ... It’s designed to integrate scholarly data..."^12

It’s also being tried out for:

"experimenting with #Bonfire as a platform for Buddhist monasteries."^13

And for those seeking sanctuary from Facebook groups:

"Would it be an alternative place to put facebook groups? There are fb groups doing important things like Buy Nothing Project, food sharing etc.... I'm really looking forward to community-built and community-hosted alternatives."^7

7. Bonfire's potential and the challenge of defining it #

If there's a through-line, it's excitement and a sense that Bonfire eludes easy description:

"I've been very hyped for Bonfire for quite some time..."^11

"This is...starting to feel like an endgame platform for me."^16

"Bonfire is really cool. And this kind of stuff is absolutely the future of the Fediverse..."^20

"I really need to make some time to play with @bonfire . I love the idea of it but the practicalities are confusing the f out of me..."^17

"I do wish they could get a little better at communicating what exactly their project is though, it took a hot minute, reading, and also asking folks on lemmy to try and figure out kinda-sorta-vaguely what they’re building..."^3

"I wish them the best, but I think they really need to work on their sales pitch. It's hard to tell what it is."^18

8. Yet-to-be-defined: blank space for new flavours #

What is Bonfire? An evolving answer. There are “empty slots” for flavours, use cases, approaches, and communities not yet imagined or built:

"Open Science Network is a 'network', kind of like Mastodon. It is built with Bonfire... You can also create other custom 'networks' using Bonfire? ... All of them speak ActivityPub, so you can follow individual accounts from Mastodon?... Perhaps a different tack... What if you could create your own Mastodon server, but instead brand it with your organization's identity? What if it had additional easily customizable features like [fill in] to tailor your social media network to the needs of your organization?... That's Bonfire."^19

Ask not what Bonfire is, ask what it could be, in your hands.

Want to join us in building the future of Bonfire? Support and share the crowdfunding campaign to join install parties, workshops, co-design sessions, and more!

Support the crowdfunding

Why Community Matters: Groups as the Next Step for the Fediverse

2025-12-05T00:00:00Z

Good news everyone! The maintenance goal of our crowdfunding campaign is 100% funded. Huge thanks to everyone who supported us! Our focus now moves to the first stretch goal: €25k to co‑design federated groups together with communities.

Whether you are an old‑school tweeter or have moved to the fediverse, you know the status quo: follow people, read your home feed, boost, reply, and maybe gather followers, post thoughts or links and receive random replies. That can be great for conversation and discovery, but the moment you try to organise something together, like an event, project, reading circle or local initiative, you feel the limits of a feed built around individuals.

Shouting at the mythical "global town square" may be fine for chatter but it’s lousy for organising. When you need specific people to see, act, and follow through, you need a group. So your community's calls to action aren't at the mercy of algorithms or noisy feeds.

Federated groups in Bonfire will be spaces where communities gather to organise, care, and coordinate across the fediverse. They'll live next to your personal feed, but each group having a specific purpose: a study circle, a lab team, an activist collective, a local mutual aid crew, a project team. Inside you’ll find posts, conversations, calendars, shared resources, and more. Crucially, groups will be portable and interoperable (see FAQ), so communities can grow and thrive without lock‑in.

How this compares with groups on existing platforms #

Millions of people rely on Facebook groups and other Big Tech platforms to connect and communicate, but enshitification and overnight, top‑down changes keep communities locked in and powerless.

Bonfire’s federated groups restore agency: a shared home to gather and organise without the traps. Communities own their spaces, set visibility and membership on their terms, and members can join and participate from anywhere, without platform or server lock‑in.

See the FAQ) for details about portability, interop, or how groups compare to forums and “threadiverse” apps.

What groups bring to the table #

Imagine a repair cafe with a calendar, community documents like code of conduct and how‑tos, a shared resource list, and discussions that carry on between meetups so planning and organising keep moving. Or a research collective that shares articles, schedules peer sessions, and keeps notes in one place. Or an activist movement that coordinates across servers without forcing everyone to “move” to a single app.

Groups make these everyday needs feel natural, not improvised. They sit alongside your main feed, giving communities a home where real collaboration happens rather than getting lost in the noise.

Pilot communities and real use cases #

Federated groups are not just a concept. We are co‑designing them with communities who have lived these needs and who will help design how they should work in practice. Partners like Princeton HCI and pilot communities make the use cases concrete. They help us design groups that work for real people, not simplistic features designed for the lowest common denominator.

Gifting groups #

Gifting communities (such as BuyNothing groups on Facebook) show how everyday care can flourish when neighbors build trust and simply offer, request, and match what's needed. Group admins like Adrian and Lee from Gifting with Integrity explain how in such groups:

"enthusiasm and passion gets passed through friends and friends-of-friends like a wave [and] is just not comparable to receiving a link from a stranger. If people know and trust the admins, this trust is also transferred into the group they create. This becomes an essential part of setting and propagating the culture. Everyone in the group is connected to everyone else, friends, family or neighbours and this affects how we interact with each other: with accountability and consideration (not like many other spaces of the internet, which are more like people who have crossed international borders to go on a bender without repercussions)..."

Having run large local groups and watched Facebook’s enshitification increasingly degrade their experience, they now want to rebuild autonomous spaces. In Bonfire, gifting groups will rebuild trust, share offers and needs, and design location‑aware features that prioritise nearby neighbors, so generosity moves sustainably through neighborhoods.

Mutual Aid Networks #

From everyday support to emergencies, mutual aid such as HUMANs coordinate people, information, food, rides, spaces, schedules, funds, and other resources locally. Today, much of this lives inside closed platforms, spreadsheets, or siloed tools that are hard to search and share.

Federated groups can provide mutual aid networks a portable home across the fediverse, with location‑aware activities, resource lists, and simple matching mechanisms that prioritise local or urgent needs.

Knowledge Commons & Open Science Network #

Knowledge Commons is a network for researchers and knowledge creators across disciplines, where they can discover open‑access scholarship and teaching materials, share work in the repository, and make interdisciplinary connections. Communities building on Bonfire's Open Science Network flavour, such as Sciety also curate and discuss preprints, reviews, and scholarship across institutions. Until now, these groups typically live inside single sites where membership and conversations are siloed, and participation can be cumbersome.

With federated groups, research and knowledge‑sharing collectives can span institutions and disciplines, keeping conversations, documents, and events portable so coordination doesn’t break when people, servers, or platforms change.

Civic coordination #

As Jon Pincus, member of the Washington Privacy Organizers said:

"Group functionality comes up in almost every single conversation I have with organizers and activists about their needs. Microblogging is great for getting the word out about actions and other kinds of public communications, but isn't useful for other important scenarios like discussing priorities and tactics or working in cross-organization coalitions."

Activist groups and civic technologists have worked on participatory processes and community coordination for years, and need portable spaces that cross organisational boundaries, with clear roles, shared context, and the ability to keep discussions and decisions visible over time.

What's next #

We’ve prototyped the core groups functionality; next we’ll build the tools communities need, co‑designing the UX with partner communities, learning from pilots and iterating in the open, to ensure groups federate across Bonfire instances and compatible fediverse apps.

Our north star is maximum compatibility: we’ll align with standards and collaborate across the ecosystem, while keeping usability and real workflows front and centre so people and groups can safely interconnect across servers and platforms. For details on portability and interop, see the FAQ).

We need your help #

If this resonates, please back the groups stretch goal so we can deliver federated groups, bring your community into the co‑design process or join as a pilot group, and share the campaign with your networks.

Support the crowdfunding

Together we can give communities durable homes that cross server boundaries while staying open and portable, without trading away autonomy for convenience, so communities can organise, document, and coordinate in spaces they control. Let’s build the tools communities deserve, and let's make them community‑owned from the start.

FAQ (Frequently Asked Questions) #

Will this work with Mastodon? #

To begin with, Mastodon users should be able to interact with federated groups at a basic level. Group posts and replies will appear as standard activities to Mastodon users, and they'll be able to follow and @‑mention groups. Some specific features may not be supported in Mastodon and will appear as links back to the group’s home server.

What about old‑fashioned forums? #

Forums are excellent for structured, long‑form discussion. Threads nest neatly, topics stay organised, and communities build rich archives over time. They’re also often self‑hosted, governed and moderated by their community rather than at the whims of a Big Tech platform. But classic forums are typically isolated on a single site. You need to create a new account for each one and remember check for updates regularly (or endure noisy email notifications). If you move on, you lose the network, content, and reputation you built there, as forums rarely interconnect with each other or the wider social web.

Groups in Bonfire are inspired by the best of forums (community-run with clear topics and findable archives) while being portable and interconnected across the fediverse from the start. A group is not only a set of threads; it also has rules (who can find it and join, who can post or participate, who can see what's posted, and codes of conduct and moderation processes), a list of members and moderators, and content such as events, shared resources, and other lightweight workflows living in one context, so organising feels natural. You have a single identity on your home server from which you can join and participate in groups on any server, rather than being stuck on a single site.

We should note that Discourse modernised the forum experience with cleaner UX and solid organisational tools and has an experimental federation plugin to enable forums to exchange some activity. NodeBB is a similarly modern forum app that has implemented federation and integrates with the fediverse. These are important steps we support and want to interconnect with.

How this compares to the "threadiverse"? #

Reddit and the federated platforms it inspired (such as Lemmy, PieFed, and Mbin) are great for topic‑based discussion. Bonfire groups overlap with some of those ideas and aim to be compatible with the threadiverse, but with experience is more focused on collaboration than just topical threads and votes. Think less “top tech news of the day” or “comment storm on a hot post” and more “a space where an idea or project unfolds over time.” You can plan a meetup, share notes, link documents, and keep decisions visible.

A key detail for longer discussions: Bonfire supports deeply nested threaded conversations with a design inspired by those apps. When a topic branches in different directions, replies can split into focused sub‑threads, making it easier to follow each path without losing the larger context. Long conversations become more readable, and side topics can mature without derailing the main thread.

What do you mean by portable and interoperable groups? #

Portable: Your identity stays on your home server, but you can join groups anywhere. Groups can move hosts and take their membership and existing content with them.

Interoperable: A group on one server can talk to people and groups using other apps or servers. Posts, replies, events, and updates travel across the network without forcing everyone onto the same platform. And because groups sit inside the wider fediverse, a conversation can bridge to Mastodon, threadiverse apps, federated forums, or any other ActivityPub platforms without losing the group’s home or history.

What standards will this use? #

We build on ActivityPub and ActivityStreams 2.0. For group‑specific behaviour, we'll use and contribute to Fediverse Enhancement Proposals (FEPs) and participate in the SWICG working group.

We will endeavour to avoid fragmentation between different implementations:

Participate in shared standards work (FEPs, SWICG, etc)
Publish an interoperability guide and docs
Provide reference JSON examples and test fixtures
Prefer the most compatible common behaviours; add clearly defined extensions that degrade gracefully

How do moderation and safety work across instances? #

All the familiar moderation tools are available: report, block, or (de)federate at the server group, or individual level. Groups also will have their own moderation team which can for example remove/hide posts, which federates to other servers to reduce duplicated labour.

Bonfire 1.0.1: Building Momentum

2026-01-16T00:00:00Z

We're back with Bonfire 1.0.1, an update focused on making your social web experience livelier, more connected, and truly yours.

Now is a good time to update your instance or discover Bonfire firsthand at campground.bonfire.cafe.

We’ve moved our main presence from indieweb.social to bonfire.cafe! Be sure to follow us at @bonfire@bonfire.cafe. Our deep thanks go to indieweb.social for being a warm and welcoming home as we found our footing in the fediverse.
Our old account will continue boosting posts from bonfire.cafe, so you won't miss anything during the transition.

What the new release includes #

New features #

Follow hashtags: Discover and join conversations that matter to you, bringing relevant posts into your feed without needing to follow specific people. (Note: You'll see tagged posts known to your instance, for example, if someone on your server follows the author or boosted the post.)
Scheduled posts: Plan ahead and have your posts published at just the right moment for your community.
Language & translation: Choose your preferred language(s), set a language for your posts, and translate content from other languages. (Translation currently works in some Chromium-based browsers, using a local translation engine. Support for other browsers, using LibreTranslate or DeepL, is coming soon.)
Replies in feeds: Choose what to display above a reply in your feeds: the direct parent post being replied to, the original post that started the thread, or just a label indicating that it is a reply. Set your preference in settings.
Polls (work in progress): Ask questions and gather input from your community. You can now view and vote on remote polls, creating them locally is coming soon.
Mastodon-compatible API (work in progress): This will make it possible to interact with Bonfire through dozens of fediverse clients available on mobile and desktop. We're gradually adding support for more parts of the API and will be testing it with different third-party clients (please report any issues if you test it with your favourite app!).
ActivityPub client-to-server (C2S) API (work in progress): Opening new possibilities for how you can interact with fediverse through third-party apps.
Widgets: Configure your homepage to display widgets highlighting what interests you most, rather than being dropped straight into a feed of activities. Head to "configure your dashboard" in settings to choose your widgets and switch between a composable widget layout or the standard "my following" feed. Reorder them by dragging and dropping directly on the dashboard (tip: you can also do that with navigation menu items on the left or widgets on the right of most screens).

Widgets #

Currently available widgets include:

Trending links: Discover the latest news and what's generating conversation across your instance.
Recent articles: Discover long-form content and blog posts from across your network.
Suggested profiles: Instance admins can curate recommendations to help newcomers find interesting people to follow.

We’d love your feedback on which widgets you’d find most useful. Let us know what you’d like to see on your dashboard. What would make Bonfire feel even more like home?

Performance #

Prioritised federation queues: We now prioritise the processing of mentions and DMs over regular posts, so direct conversations arrive without delay.
Database improvements: Added more indexes and improved queries for snappier responses.
Server-to-server federation: Various optimisations for smoother communication between instances.

UI and UX enhancements #

We've put work into smoothing out the interface and improving design patterns across the app: small touches that add up to a better experience.

Bug fixes #

This release squashes bugs around federation behaviour, threading, user interface, composer states, and more. See the full changelog for the complete list.

Update your instance or try Bonfire at campground.bonfire.cafe

Crowdfunding update #

As you may know, we ran a crowdfunding campaign in December. We raised €32,467, surpassing our primary goal of €30,000 for maintenance.

We’re deeply grateful to everyone who chipped in, your support genuinely moved us. Seeing so many people rally behind Bonfire, all through grassroots word-of-mouth, was both encouraging and humbling. We're energised by seeing this vision of a more caring, community-based social web resonate so widely. Thank you for believing in what we’re building, together.

We're now working on fulfilling rewards, so if you backed the campaign, you'll hear from us soon!

And if you didn't get a chance to pledge in December, or want to help us level up, you're in luck: the campaign is now open for a limited time for late pledges for anyone who wants to boost our progress toward the first stretch goal of €25,000 for federated groups (for a total of €55,000), which are a foundational feature to empower communities across the fediverse and make Bonfire even stronger for community organising and collaboration.

Read our blog post about why groups matter as the next step for the fediverse and contribute to building groups in Bonfire.

Support the crowdfunding

What's next #

We’re already hard at work on the next release. We’re excited to make it even easier to organise, share, and stay safe together, with expanded API compatibility to open Bonfire to more third-party apps, along with poll creation, new widgets, and the usual bug hunting and interoperability improvements.

We've also started work on end-to-end encrypted messaging as part of the Social Web Foundation's project to bring interoperable secure messaging to the fediverse, a meaningful step toward private, secure communication on the open social web. We'll be testing this over the next few months and releasing it when a secure and interoperable implementation is ready.

Support the crowdfunding

From the community #

Ozoned recorded a video walk-through of setting up a Bonfire instance from scratch, a great resource if you're thinking about self-hosting. Thanks for your contribution, Ozoned!

Meanwhile, The Fulcrum wrote a thoughtful article exploring Bonfire and its potential. We're eager to see how they'll experiment with the framework and what emerges from their work.

We're also working with Newsmast Foundation to setup a Bonfire server for an existing community, stay tuned!

Have you made something with Bonfire or written about it? We'd love to hear from you and feature community projects in future updates.

See you at FOSDEM? #

On January 30th and February 1st, the Bonfire team will be at FOSDEM, a free software event in Brussels that brings together more than 8000 people every year. We're running two sessions: one in the Social Web track titled Building Modular, Consentful, and Federated Social Networks and another in the Decentralised Communication track: Modular Communication Tools on the Open Social Web.

We’ll also have some exciting announcements about new collaborations and projects, stay tuned!

Besides the talks, we’re eager to catch up with friends old and new from across the open source and fediverse communities. If you’re attending, we hope you’ll find us and say hi! We’d love to connect, answer your questions, and share ideas, whether you’re a hacker, organiser, or just curious about the fediverse.

Thank you for making Bonfire what it is. Every message, suggestion, and act of cooperation moves us closer to a more caring fediverse. Can’t wait to see what we grow together!

Support the crowdfunding

Bonfire 1.0.2: Shaping Your Space

2026-03-17T00:00:00Z

We just released Bonfire 1.0.2, an update focused on giving you a more stable and reliable experience.

Now is a good time to update your instance or discover Bonfire firsthand at campground.bonfire.cafe.

We're also heads-down working with several communities who are setting up their own Bonfire servers. Plus updates on end to end encryption and federated groups. More below.

What's new in Bonfire 1.0.2 #

Keyword filtering #

You can now filter out posts containing specific words, phrases, or hashtags. Useful for tuning out topics you'd rather not see. Instance admins can set filters that apply across the whole instance, and per-user filtering is coming in a future release.

Translate posts with one click #

A translate button now appears under posts, making it easy to read content written in other languages. Translation works in Chrome using built-in local translation system; for other browsers instance admins or individual users can also set up LibreTranslate or DeepL APIs, configurable in translation extension settings.

Feed markers #

Your place in the feed is now saved when you navigate away, so you can pick up exactly where you left off, without scrolling back through posts you've already seen.

New dashboard widgets #

Weather, instance stats, and user summary are now available for your customisable dashboard. Bonfire's homepage is moving toward a widget-based layout that goes well beyond the classic microblogging feed, to become a space you can genuinely shape around what matters to you.

Currently available widgets include:

Highlighted posts: Pinned or featured content from your community
Weather: Local conditions at a glance
Instance info: An overview of your instance's key defaults: federation behaviour, open vs invite-only registration, and known servers
User summary: Surfaces your account info and highlights safety defaults at a glance, including discoverability and search indexing settings
Recent articles: Discover long-form content and blog posts from across your network.
Suggested profiles: Instance admins can curate recommendations to help newcomers find interesting people to follow.

We'd love your feedback on what kind of widgets you'd find most useful. What would make Bonfire feel even more like home?

Better mobile experience and keyboard shortcuts #

The composer is smoother on mobile, and you can now press Cmd+Enter (or Ctrl+Enter on Windows/Linux) to publish a post without reaching for the button. Keyboard shortcuts for opening the composer (n) and minimising it (-) are also available.

Stronger federation #

We added support for RFC 9421 HTTP Message Signatures, a newer and more robust standard for verifying messages between instances. This improves trust across the fediverse by making it harder to spoof messages between servers, and was added in collaboration with the broader ActivityPub community (big thanks to Hong Minhee from Fedify!)

Bug fixes #

This release squashes a long list of bugs around federation behaviour, threading, user interface, polls, content warnings, and more. See the full changelog for the complete list.

Update your instance or try Bonfire at campground.bonfire.cafe

Ongoing projects #

Several communities are actively working toward launching their own Bonfire instances, and we're supporting them through setup, co-design, and customisation:

Jacobin DE chose Bonfire as their community space for readers and contributors, putting community-governed infrastructure in the hands of Germany's most prominent independent left media outlets, tightly connected with their publication. In collaboration with Newsmast Foundation for the mobile app and Klasse & Methode for hosting.
Totnes Pulse: a local app for Totnes, a pioneering transition town in Devon, UK, experimenting with Bonfire as local social infrastructure for community events and discussions. In collaboration with Newsmast Foundation for mobile apps and Lauti for events publishing.
Bida and nobigtech.social: An Italian collective and fediverse pioneer, they've set up a bonfire instance for their community with the goal of codesigning together new features focused for collectives and grassroots organisations.
University of Warwick's Centre for Interdisciplinary Methodologies: A higher education institution joining in co-designing and piloting Bonfire's Open Science Network for academic community building and open knowledge exchange.
Princeton University's Human-Computer Interaction: Collaborating on protocol-based UX research into community-governed social platforms, with a project to help communities better define and communicate their governance structure and rules, like "nutrition labels" for online communities.
Federated groups are taking shape. Proper groups are a critical missing piece of the fediverse, and although the crowdfunding stretch goal for groups didn't quite reach its target, our collaboration with Jacobin DE (and potentially other communities down the line) is giving us the momentum to push forward. We're currently working together to co-design and improve the UX of our groups prototypes. In parallel, we're collaborating with other ActivityPub developers through the Groups task force of the W3C Social Web Incubator Community Group to ensure federated groups will be interoperable across the fediverse. If your community would benefit from federated groups and you'd like to help co-design and co-fund this work, please get in touch, the more communities involved, the better the result!
We're also making progress on end-to-end encrypted messaging as part of the project initiated by the Social Web Foundation to bring interoperable secure messaging using the MLS standard to the fediverse. We'll be testing this over the coming months and will release it when a secure and interoperable implementation is ready.

Crowdfunding update #

Thanks again to everyone who backed us, your contributions will go a long way in making Bonfire more usable and stable for everyone!

We're now preparing to fulfil rewards. If you selected a physical reward (printed or screenprinted artwork), please make sure to check your shipping address on Indiegogo so we can get it to you. You'll hear from us soon either way.

Thank you #

Every message, bug report, translation, and contribution moves us closer to the fediverse we want to inhabit. Thank you for being part of it. We can't wait to see what we grow together.

Bonfire 1.0.3: Stability, Clarity, and Federated Publishing

2026-05-15T00:00:00Z

Since the 1.0 release of Bonfire Social, we've been heads-down listening to our our pilot communities, beta testers, and co-design partners. Version 1.0.3 is the result: a release focused on stability and polish, which fixes a wide range of bugs and brings meaningful usability improvements, especially around feeds, boundaries, and more advanced features. It also ships a set of new capabilities born from our ongoing collaboration with Jacobin DE.

Stability first #

This release addresses dozens of issues reported by communities actively using Bonfire day to day. The progressive web app experience is smoother on mobile. Federation is more reliable. Many reported bugs have been fixed and UX improvements have made based on community feedback: tooltips, focus states, icon labels, layout glitches, and accessibility issues across the board.

Making power feel approachable #

This release gave particular design attention to one of Bonfire's most powerful (and sometimes daunting) areas: boundaries and post permissions.

Those features are an example of where Bonfire's depth and breadth of options can feel overwhelming at first: a lot of choices, many possible combinations, and real user empowerment that deserves to be surfaced carefully.

We've been working on a layered design pattern that we're calling calm empowerment:

a handful of simple defaults that cover most users;
a middle layer of curated overrides for people who want some control without being overwhelmed by all possible options;
finally, a full advanced matrix of options behind an explicit "expand" gesture for power users.

For boundaries, this means the screen now leads with the presets (Public, Local, Mentions, Follows), followed by a small set of controls for the most common adjustments: "allow replies?", "allow quote posts?", each of which works across all relevant audience circles at once, without requiring you to understand the full permission matrix. All options are still available, but exposed only after a conscious choice, for the cases that genuinely need it.

Feed filtering is next on the list, as something we can simplify while retaining all its power. More broadly, calm empowerment is becoming a guiding pattern across Bonfire extensions. We're experimenting with it for two upcoming beta features: group creation, where simple defaults get you started but the full range of visibility and membership controls is there when you need it; and poll creation, where the surface is as simple as single or multiple choice, but opens up into proposal phases, consensus building, ranked choice voting, and more.

The goal is simplicity by default, while being endlessly configurable for those who want it, without making anyone feel like they have to decipher or fight the interface. We're working on applying this pattern consistently across Bonfire, and plan to write more about the thinking behind it: both as a design reference and as a broader conversation about what it means to feel genuinely empowered by a social network rather than managed by one.

New dashboard widgets #

The dashboard (what you see when signing in, instead of being thrown straight into a feed) is now significantly more useful. New configurable widgets focus on community building and participation:

Spotlight: posts pinned by instance moderators surfaced prominently for all members
Getting started: an onboarding widget to help new users find their feet
Polls closing soon: keeps active decisions visible at a glance
Top discussions: the 3 most-replied local posts from the last few days, for a pulse on what's alive in your community

Federated discussions, anywhere on the web #

Paste a script into any web page (a blog article, a portfolio, a recipe, a funding proposal, a research draft) and it instantly gets a federated comment thread tied to that URL. The page becomes a post on your Bonfire profile, and people can respond from anywhere on the fediverse, and even from Bluesky and the ATmosphere thanks to bridging via BridgyFed.

Bonfire-powered comments embedded on your web page means nested discussion threads that are boostable, upvotable, and most importantly, federated. Readers can engage from within the webpage, and the conversation also lives on the linked Bonfire instance, where it can be moderated like any other content and followed or replied to from across the fediverse.

We're continuing to refine the embeddable comments widget over the coming weeks as part of our collaboration with Jacobin DE. More soon.

Community publishing with Ghost #

Working with Jacobin DE also pushed forward a set of features we're genuinely excited about for any community that publishes content alongside social interaction: a deep integration between Bonfire and Ghost, the open source publishing platform.

We demoed what this looks like in practice at FediForum: watch the recording here.

Single sign-on. Members sign in on Ghost and Bonfire using the same email address, and move between the two without friction.

Gated login and membership sync. Ghost membership tiers sync directly with Bonfire circles and groups. New members land in the right spaces automatically. If a user tries to sign in but isn't yet a member on Ghost, they receive a registration link.

Article import. Ghost articles are imported into Bonfire automatically, attached to the author's profile and placed in the relevant groups and topics, with full content, images, and captions included, ready to be discussed across the fediverse. Visibility is set automatically based on the Ghost tier (public, members-only, or paid), so each piece reaches the right audience without manual intervention.

But doesn't Ghost already federate? Ghost has built-in federation, and WordPress has a plugin for it, broadcasting articles into the fediverse and pulling replies back as comments. That's a great start. But Jacobin's needs pushed us further: a structured community space where your content is an invitation for people to go from audience to participants, with groups, topics, polls, moderation and governance tools, etc. So each tool focuses on what it does best.

This isn't a Jacobin-specific feature set, it's a reusable foundation for any publisher or community who wants a fully-integrated federated social space, whether that's a newsletter, a media outlet, or a membership organisation. Publishers like The Verge and 404 Media, the New York Times, and others are all exploring deeper social integration into their articles.

If you're running Ghost and thinking about where your community conversation should live, we'd love to talk. The same approach could be extended to other publishing tools: WordPress, Drupal, or whatever your community already uses.

More broadly, this reflects something we care about in how Bonfire relates to other tools: we're not trying to replace your CMS, your event platform, or your preferred workflow. Bonfire can publish articles natively, but if Ghost already meets your publishing needs, or you organise events with another tool, the goal is integration: bringing the federated social layer to where people already are, rather than asking them to start over. The same thinking is behind our LAUTI integration for events. Keep the tools that work, and connect them to the open social web.

tags.pub integration #

Bonfire now can integrate with tags.pub, making it easier to use hashtags to discover and participate in conversations across different servers. Thanks to Papiris and Ozoned for the testing and feedback that made this happen.

First translation complete #

Thanks to the Jacobin DE team, Bonfire now has a complete German translation. If your community is German-speaking, it's a good time to give Bonfire a try.

Contributions to other languages are always welcome, join the effort to contribute to an existing language or start a new one.

Also in this release #

Modular community rules (the first step in bringing research and co-design with Princeton HCI students and researchers into Bonfire), per-user and per-instance keyword filtering, smarter nested thread sorting that surfaces the most active discussion branches, and the usual round of performance improvements and dependency updates.

Read the full changelog for details.

Get involved. If you're running a Bonfire instance, now is a good time to upgrade. If you've been curious about Bonfire for your community or organisation, get in touch, we'd love to hear what you're building.

— Ivan & Mayel

Bonfire

The story of Bonfire's visual identity

First steps toward federated project coordination

tl;dr #

But wait: why are you building another project coordination app? #

1) We want to federate coordination between many people, groups and organisations on different instances #

2) We needed it #

3) Interoperability #

Powered by ValueFlows #

ForgeFed #

Join us! #

Let a thousand bonfires bloom

tl;dr #

Why building themeable apps ? #

How we're building it #

Federation will be a mess #

A UI toolbox for customizable social network apps

Stack #

Scaffolding #

Other resources #

Notes on the first neapolitan meeting

Suggestions for next extensions #

Federated calendar #

Federated governance #

Where to go next #

Announcing the Zappa project

The Zappa extension #

How to participate in the Zappa project? #

Countering misinformation in federated social networks, an introduction to the Zappa project

Some interesting findings from user research for the Zappa project (so far!)

10 interesting things people have told us so far #

Next steps #

First version of report published sharing findings from Zappa project user research

Notes on our first usability testing round

Participants #

Main takeaways #

Final thoughts #

Not Just 'Yet Another Microblog'

Bonfire is a toolkit for assembling federated apps #

Other apps #

Customisation #

"Forkability" #

Next steps #

What you can expect from the Bonfire beta

Features and functionality #

Get involved! #

Meet us at the playground: Bonfire Social beta launch

Watch the video walkthrough #

Sign up to the Bonfire playground #

What is in scope for this beta? #

A note on federation #

Upcoming events #

Beta launch FAQ #

Subscribe to updates #

Introducing circles and boundaries

Bonfire presentation @ PrivacyWeek

How to use boundaries, circles and roles

Using circles #

Using boundaries #

What are roles? #

Dev Diary: Implementing federated groups in Bonfire

The Power of Groups #

Creation & Discovery #

Boundaries & Privacy #

Roles & Moderation #

Empowering Bonfire users with advanced roles & permissions

Could you help us with user research?

Making things intuitive is complex! Or, what we discovered via user testing

The User Research Process #

What we found out #

Our response #

Next steps #

Conclusion #

Bonfire 0.9.6

Expanded Messaging and Thread Views #

Enhanced Feeds #

Rich Text Editor and Composer Improvements #

Refined Boundaries #

And more! #

The Road to Bonfire 1.0