Bonfire Offers Framework for Next-Gen Fediverse Platforms

Building Blocks for Tomorrow's Platforms

Bonfire is inching ever closer towards a 1.0 release of its social offering, which is a landmark development for the project. But beneath the surface, there’s a bigger story going on: rather than simply being a social platform, it’s also a development framework.


As a project, Bonfire has been in development for a long time, taking on different shapes and forms throughout the years. It first emerged as CommonsPub, in an effort to bring ActivityPub federation to MoodleNet. After a long refactor and refocus, Bonfire seems to be hitting its stride.

“We want to be the foundation for the next generation of Fediverse apps,” Mayel says. When I ask what he meant by that, he elaborates.

From Bonfire’s “Safer Social Networking” article. The team wrote an extension for moderators to add Community Notes in response to misleading information. It’s a fascinating case study of how the platform can be extended.

“We designed Bonfire in a way that it is easy for users to extend, and add new functionality. Just earlier today, we wanted to add a new feature, and were able to add it in, in just under a few hours of work.”

Foundational Layers

I want to take a moment to peel back the layers of Bonfire, because I think they really set it apart from other platforms. The vision for the project is incredibly unique: “we have all the pieces you need, all you have to do is assemble it.”

Extensions

In Bonfire, Extensions are first-class citizens. The project’s developers have gone to great lengths to segment out features in such a way that they’re all modular, and work together as components.

In Bonfire extensions are not reserved for bonus features contributed by third parties (as is typically the case for many platforms), but every piece of the core software is packaged in an extension so it can easily be forked or swapped out for another extension with a different design or value proposition.

There are over 75 different extensions available on the project site, ranging from the federation library to data access controls to mutual aid tools. There’s a lot of foundational stuff here, and an enterprising developer could do a lot with it.

Flavors

With so many extensions available, Bonfire offers developers the chance to pick and choose which ones to use, then bundle them together into a single app experience. Bonfire calls these experiences Flavors, and each one can be dramatically unique from the next, despite sharing 99% of the same underlying code.

The prospect is really interesting, and sounds similar to how a Linux distribution is used to ship a collection of software. Does this mean that Flavors are basically Bonfire distributions?

Circles, Boundaries & Roles

Access control and user permissions are huge concepts in Bonfire, intended to be applied to everything that’s hooked into the core platform.

There are three complementary concepts at work here: Users have Circles that are assigned Roles, and what those Roles can do is defined by Boundaries.

Circles

A circle is a pretty simple idea: it’s a group of your contacts, possibly bunched together by their relationship to you or one another. A circle could contain family members, co-workers, or colleagues.

Circles are pretty similar to how Aspects worked in Diaspora, or Collections work in Friendica: when you post, you can decide which circle can explicitly see or do something.

Roles

Roles can be thought of a set of permissions for interacting with a given resource. These can be one-off, such as not letting people reply to a Public announcement, but they can also be bundled together to account for how different groups of people should interact with the same post.

A demonstration of how roles can be assigned in federated groups. Source: Bonfire.

Boundaries

Bonfire defines boundaries as “limits you set for yourself and others to define what you’re comfortable with”. Within the platform, a Bonfire user can assign roles to a circle. In fact, they can be set ahead of time as a preset.

For example, maybe I have a circle called “Colleagues”, who are assigned a “Work Friends” role. I’ve decided that anyone with that role can participate in any posts I make about my work, whereas anyone outside of that circle wouldn’t even see it in their timelines.

I can think of two benefits for this: one, it can help me laser-focus certain kinds of posts to the people most likely to be interested in it, and two, it can let me privately put something out to specific followers, and hide it from everybody else. This could be particularly useful with private group interactions, where a bunch of people in one workplace might have their own locked-down Bonfire group.

What’s Next?

The future for the project is incredibly promising. Bonfire is currently running a pilot program for the Open Science community, and is running a Community pilot program with Radio Free Fedi as a partner.

The project is also interested in collaborating with cooperative hosting networks to offer people cheap and easily accessible infrastructure to spin up Bonfire instances on. The logic in doing this is to reduce friction for prospective users, allowing them to join in immediately. Bonfire has submitted a proposal, with Co-Op Cloud and Bridge Seat Cooperative signing on.

Bonfire intends to ship a 1.0 release of Bonfire Classic relatively soon, and is doing a lot of heavy lifting in making sure every part works as intended. It’s an amazing project, and we can’t wait to see what comes of it. Expect to see an in-depth review shortly after the launch!

Sean Tilley

Sean Tilley has been a part of the federated social web for over 15+ years, starting with his experiences with Identi.ca back in 2008. Sean was involved with the Diaspora project as a Community Manager from 2011 to 2013, and helped the project move to a self-governed model. Since then, Sean has continued to study, discuss, and document the evolution of the space and the new platforms that have risen within it.

3 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button