Discussion
Public Interest Social Networks
Bonfire is built by communities, for communities. Rooted in autonomy, mutual care, and collective power. Co-create your tools, reclaim your data, and resist manipulation by shaping your own federated digital spaces.
Previously at @bonfire@indieweb.social
This is a chance to poke at the process, challenge assumptions, and have an open conversation. Bring your curiosity, hard questions, and ideas about co-design, funding, burnout, moderation, and the messy realities of open-source work.
Let’s dig into how fediverse apps get built, maintained, and shaped by their communities.
See you there! 🔗 https://fediforum.org
Join us at #FediForum today — an unconference about the ActivityPub ecosystem. We’ll be doing a live demo and proposing a session:
Behind the Bonfire: building a fediverse app in public
Curious how a fediverse app actually gets made? We’ll share the journey to Bonfire 1.0, talk about deployment, governance, and what building in public really looks like — the good, the hard, and the weird.
1/2
About 12 hours until the start of FediForum June 2025!
Join us for three half-days of sessions on all aspects of the Open Social Web, better forms of social media, open social protocols and more!
While mostly an unconference, we also have innovative software demos and amazing keynotes!
Registration is still open! And you can join right from your living room or office! https://fediforum.org
we have an icon in several formats, but a simplified one that scales well to smaller sizes may be useful as well: https://bonfirenetworks.org/presskit/
As mentioned in the issue, we could extend the API but then each client would have to specifically implement the additions. There's a risk of duplicating types added by other apps in incompatible ways unless there's something like FEPs or RFCs for the API schema?
> you mention this would be a limited window onto Bonfire, is that just because you only implemented a proof-of-concept so far, or is it because Bonfire would have features that the existing clients wouldn't support (yet)?
It's because of features not available in the Masto API schema (like boundaries/circles) but also since Bonfire is extensible and some extensions implement new object/activity types beyond the note/post...
We did implement a partial Mastodon REST API as a proof-of-concept (attached are some screenshots of a Bonfire feed displayed in different clients). Of course that would come with several limitations, like when displaying activity/objects/metadata not supported by the API and client, or with features not available such as the option to select custom boundaries/circles when posting...
Install bonfire.cafe
Get the full app experience
