Recent activities
Bonfire
@Bonfire  ·  activity timestamp 7 days ago

⁂ Article

Connect your existing tools to the fediverse with Mosaic

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.
Bonfire
@Bonfire  ·  activity timestamp 2 weeks ago

⁂ Article

🔥 Bonfire Social 1.0 RC2

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

🌍 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! 🚀
Mayel
@mayel  ·  activity timestamp 2 weeks ago

@ozoned@social.ozoned.net Thanks for sharing! That was very useful to watch even if painful at times (mostly because I wanted to jump in with pointers but it was prerecorded :D). I took many notes of things to improve with the documentation and tooling.


Overall, the docs and tooling for deploying directly with docker (compared to those using @coopcloud@social.coop which is the recommended and simpler approach) are out of date and too complex mostly because they've been adapted from the dev ones, and we're thinking about how to offer an alternative method with only a compose file and a .env (though I'd welcome advice about how to do so in a simple way, as the just commands are mostly there to reduce the guide to a handful of steps/commands instead of having to copy paste a lot more, and they also set some variables used in the compose file to make it more flexible, but maybe that's not worth it, or there are some other ways to simplify?)


Here's some hints on the main blockers you encountered:


  • you first entered MIX_ENV=ember when you wanted FLAVOUR=ember
  • if you enter ctrl+c in iex it pauses the app so it wouldn't respond unless you unpause it (by pressing c for continue)
  • we recently closed port 4000 which now not open outside of docker's internal network by default (for security since you usually want people to connect through the web proxy in prod) and need to update the docs
  • we need to better document that it's also running a web proxy by default on ports 80/443, and point to where the caddy config is
  • at one point you were looking at docker-compose.yml instead of the release one docker-compose.release.yml
  • during of the following attempts where you tried to run dev you were still following the prod guide instead of the dev guide which uses different just commands and env vars

I'm not sure why you weren't able to connect on port 80 during the first attempt though, as the elixir app logs didn't show anything, and caddy's error log was pretty cryptic, I'd be curious what you'd see on port 4000 if you opened it in docker-compose.release.yml


@bonfire@indieweb.social
Mayel
@mayel  ·  activity timestamp 2 weeks ago

@ozoned@social.ozoned.net


ah thinking about it more, one of your viewers may have guessed the issue, saying you had to set up a domain and set the hostname. As port 80 redirects to port 443 and that one couldn't work without those.


@bonfire@indieweb.social
Mayel
@mayel  ·  activity timestamp 2 weeks ago

@ozoned@social.ozoned.net Thanks for sharing! That was very useful to watch even if painful at times (mostly because I wanted to jump in with pointers but it was prerecorded :D). I took many notes of things to improve with the documentation and tooling.


Overall, the docs and tooling for deploying directly with docker (compared to those using @coopcloud@social.coop which is the recommended and simpler approach) are out of date and too complex mostly because they've been adapted from the dev ones, and we're thinking about how to offer an alternative method with only a compose file and a .env (though I'd welcome advice about how to do so in a simple way, as the just commands are mostly there to reduce the guide to a handful of steps/commands instead of having to copy paste a lot more, and they also set some variables used in the compose file to make it more flexible, but maybe that's not worth it, or there are some other ways to simplify?)


Here's some hints on the main blockers you encountered:


  • you first entered MIX_ENV=ember when you wanted FLAVOUR=ember
  • if you enter ctrl+c in iex it pauses the app so it wouldn't respond unless you unpause it (by pressing c for continue)
  • we recently closed port 4000 which now not open outside of docker's internal network by default (for security since you usually want people to connect through the web proxy in prod) and need to update the docs
  • we need to better document that it's also running a web proxy by default on ports 80/443, and point to where the caddy config is
  • at one point you were looking at docker-compose.yml instead of the release one docker-compose.release.yml
  • during of the following attempts where you tried to run dev you were still following the prod guide instead of the dev guide which uses different just commands and env vars

I'm not sure why you weren't able to connect on port 80 during the first attempt though, as the elixir app logs didn't show anything, and caddy's error log was pretty cryptic, I'd be curious what you'd see on port 4000 if you opened it in docker-compose.release.yml


@bonfire@indieweb.social
Mayel
@mayel  ·  activity timestamp 2 weeks ago

For example, I've just improved thejust secrets command based on a suggestion from one of your viewers, so it gives you the whole block (including env names) ready to paste in your .env, for example:

SECRET_KEY_BASE=92ef8434f4d462b4384258fb4191bb69c26485dfd9cb2751b245b90163ea7416644398df3b7ec4e3f7c6482f51045823e6397377fe71e44084763e5e899fdbed705337453499c21691f49951585a3c2555866bde406e37907d55764dcfc429dc381e3a739699c67b1b58381abb956655adde875346b92c1f08a9ee9367caf632
SIGNING_SALT=5a9f16fe2d61581fb8af6d8f062aeed60752603d73f2a0cec96967448290545f56086ba935f2be2bdd9a724b8f96c0f74db5ed8b2ae601f5e3c8ca2911eaae73bad7b6c281ef7bf4da87c3339c8f764a10da3b2c1502f9bee2c36f4fc918560a7371668924b5845f59efe02875b1cfc7d83a755220695db0cb7e60686a92b3f5
ENCRYPTION_SALT=f54695f8449a5b200c27ba5cacfff650e4f3e0ded1bedf59635e320b0077291a299816eb5df13de1277637212d2abc11a3a7b327fb89f3227b7811de06904896f987adcbcf4a5760a41b497b4bee4c14d0f6cc7dd4ad5f4cdf95a010f2e2a93a88b08188bd4e56bfe1846b0a9523d96f913abd5255f1061e856e835ff9811d42
ERLANG_COOKIE=b33ebdc8897ea0ad026ab2eb2c49fb6d9d0fa7a2522d28e83c4f3289dc1cea67dc4a458de60ebf4cc0d7
POSTGRES_PASSWORD=fb1164836b3d505f4c5943248d1ef5d8161a092d4a599f1f4dd0872f9751cc28487389a9e47debe79917
MEILI_MASTER_KEY=b74b3877078c6ccb406f81b952746f9f68e3e929d4a52f63a8cd85df2c23ad86e23508c7378e034d6215

Now the question is how to do something similar if you're shipping only a docker-compose and .env?

@ozoned@social.ozoned.net @bonfire@indieweb.social @coopcloud@social.coop
Mayel
@mayel  ·  activity timestamp 2 weeks ago

@ozoned@social.ozoned.net Thanks for sharing! That was very useful to watch even if painful at times (mostly because I wanted to jump in with pointers but it was prerecorded :D). I took many notes of things to improve with the documentation and tooling.


Overall, the docs and tooling for deploying directly with docker (compared to those using @coopcloud@social.coop which is the recommended and simpler approach) are out of date and too complex mostly because they've been adapted from the dev ones, and we're thinking about how to offer an alternative method with only a compose file and a .env (though I'd welcome advice about how to do so in a simple way, as the just commands are mostly there to reduce the guide to a handful of steps/commands instead of having to copy paste a lot more, and they also set some variables used in the compose file to make it more flexible, but maybe that's not worth it, or there are some other ways to simplify?)


Here's some hints on the main blockers you encountered:


  • you first entered MIX_ENV=ember when you wanted FLAVOUR=ember
  • if you enter ctrl+c in iex it pauses the app so it wouldn't respond unless you unpause it (by pressing c for continue)
  • we recently closed port 4000 which now not open outside of docker's internal network by default (for security since you usually want people to connect through the web proxy in prod) and need to update the docs
  • we need to better document that it's also running a web proxy by default on ports 80/443, and point to where the caddy config is
  • at one point you were looking at docker-compose.yml instead of the release one docker-compose.release.yml
  • during of the following attempts where you tried to run dev you were still following the prod guide instead of the dev guide which uses different just commands and env vars

I'm not sure why you weren't able to connect on port 80 during the first attempt though, as the elixir app logs didn't show anything, and caddy's error log was pretty cryptic, I'd be curious what you'd see on port 4000 if you opened it in docker-compose.release.yml


@bonfire@indieweb.social
ivan
@ivan  ·  activity timestamp 2 weeks ago

@midzer@chaos.social @matt@oslo.town @jaz@toot.wales I am quite interested in hearing if there are features that could enhance a location-based fedi server experience...would love to build a #bonfire flavour for villages/bioregion 🏕️
Gadfly (-booq-)
@gaditb@icosahedron.website  ·  activity timestamp 3 weeks ago
@mayel I also think I disagree your takeaways from it?

Like, looking at what my hypothetical person 2 thought they were doing -- there is no need for them to assume that is a clean or perfect block, or that there is no way for it to get exposed. Most people who have used blocks in any sort of social platform know that with alt-accounts or friends, or just normal social dynamics, the person they block can find out. That capacity even with that limitation is nevertheless /enough/ for them to want it.

In this case, that still-CAN-be-revealed requires either active testing of each possible block, or very engaged social surveillance.
Which is often discussed, and which people seem to discuss and understand Bluesky's block issue as being qualitatively different than.
Mayel
@mayel  ·  activity timestamp 3 weeks ago

@gaditb@icosahedron.website oh yeah they're definitely different! maybe enough that each (or something in between, like showing what boundaries you applied to people who you give permission to) may be desired in different situations or use cases?
Gadfly (-booq-)
@gaditb@icosahedron.website  ·  activity timestamp 3 weeks ago
@mayel As a side-point, that I don't think has any safety impact and also don't REALLY have fully-theorized to a necessarily-useful level of specifics, and also haven't really run it by people as like "are my thoughts here, like, coherent? and useful?",

I have thoughts re:
"""
From your perspective, those replies disappear, and new ones won’t appear at all. Your instance silently enforces these boundaries by ignoring unwanted interactions, even if the sender’s server is unaware and still allows them to post.
"""

about the concepts of who "owns" (and can curate) the comments section of their post, from whose perspective. (It's never going to be a single person curating/moderating, but I.. think?.. people feel ownership feelings over it nevertheless.)
Mayel
@mayel  ·  activity timestamp 3 weeks ago

@gaditb@icosahedron.website yeah that's an interesting line of thinking, I think the authors of these to FEPs have been exploring that: github.com/bonfire-networks/...
Gadfly (-booq-)
@gaditb@icosahedron.website  ·  activity timestamp 3 weeks ago
@mayel How visible is the exclusion itself, though?

Like, if I send to "Hey does anybody have a place I can crash tonight?" to @group--attendees_of_this_hacker_gathering but invisible to @guy_I_dont_trust_to_be_alone_with_but_really_dont_want_to_get_into_a_public_confrontation_about_that_right_now,

is there a chance that @defender_of_that_guy_who_sees_fear_of_him_as_an_attack_on_his_character sees that block in the metadata of the post and starts flaming me about it?

This is a contrived example that I don't have specific experiences I'm translating it from,
and sometimes technical limitations or just "we don't have a better design for that yet" mean that you can't AVOID exposing that, so it's not necessarily "it Must Be Fixed if it reveals this",
just,
(a) finding what intuition might be, and checking the implemented teality against that
(b) exploring what attacks there might be, and knowing where they might be made less post-hoc surprising

e.g.:
https://old.reddit.com/r/BlueskySocial/comments/18ebrhx/blocks_being_public_is_already_leading_to/
Mayel
@mayel  ·  activity timestamp 3 weeks ago

@gaditb@icosahedron.website

I think the Bluesky example you linked to is an unfortunate illustration of what happens when we expect technical tools to cleanly solve social problems. Making a blocklist public is obviously egregious, but even private exclusions can be exposed through old-fashioned social interactions. For example, someone casually referencing a post might unintentionally reveal to someone else that they weren't included.


In Bonfire, boundaries aren’t meant to control what others do on their own instance (apart from defining who an activity is addressed to, similarly to BCC with email). They’re more about controlling what reaches you on yours. Since ActivityPub doesn’t yet support strong security features like end-to-end encryption or object capabilities, boundaries are designed as a local-first mechanism. They help shape your experience and interactions rather than enforcing strict rules across the network.


So, in your example, if someone starts harassing you, you can block them, or just silence them or the thread in question. From your perspective, those replies disappear, and new ones won’t appear at all. Your instance silently enforces these boundaries by ignoring unwanted interactions, even if the sender’s server is unaware and still allows them to post.


It’s not perfect privacy or hard enforcement but harm reduction and local autonomy in a messy, federated world...
Gadfly (-booq-)
@gaditb@icosahedron.website  ·  activity timestamp 3 weeks ago
@mayel (You can tell me to, like, look into it myself rather than asking you to explain every detail and stuff. I'm not in a situation where me having that info is relevant to my safety or supporting anyone where it is relevant to theirs. I'm just asking hopefully-useful questions, so while I like learning about how this works from this angle and am enjoying it, if my repeatedly-asking-details is not particularly enjoyable/useful to you/the project, like.)
(I'm not getting thst impression from you, but just in case/to be explicit about my conversational position rather than try to rely on tonal nuances.)
Mayel
@mayel  ·  activity timestamp 3 weeks ago

@gaditb@icosahedron.website Don't worry I'm enjoying it, keep em coming!
Mayel
@mayel  ·  activity timestamp 3 weeks ago

@gaditb@icosahedron.website Thanks for the reading materials! 😊



@evacide@hachyderm.io @sarahjamielewis@mastodon.social @sarahjeong@mastodon.social
Gadfly (-booq-)
@gaditb@icosahedron.website  ·  activity timestamp 3 weeks ago
@mayel Oh wow! I didn't even look at the specifics yet (another reason this was dashed-off and non-specific), that's great that you've already been thinking along those same lines!

The actual specific thing with Bonfire set me off on this line of thinking was:

"""
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.
"""

"Make this invisible to X, Y, Z" strikes me as something that can requires very nuanced and situation specific careful stepping around disclosure/visibility and trust. (Ranging from "none", e.g. planning a birthday party, to much higher stakes.)
Mayel
@mayel  ·  activity timestamp 3 weeks ago

@gaditb@icosahedron.website Good catch! We usually try to explain things in a more comprehensive way than in that short blurb. Specifically in this case, if something it shared publicly there can be no gurantee that they won't see it. For non-public posts there's no guarantee either (because there's no end-to-end-encryption) but there's a better chance, since we distribute it only to the actors who were given permission (in a similar way as BCC in email).