noticing is my way of opposing

"[...] Noticing is my way of opposing a particular modernist practice of looking towards an imagined future. Certain things get coded as possible futures and then we develop blinders so that all we can see is our trajectory towards one kind of imagined future, which isn’t actually the future but is a stereotyped dream future. And so, we stopped seeing. Noticing is trying to take those blinders off to look at the world around us, with special attention to the more-than-human world, by which I mean the human plus non-human world."

fojournal.org/interview/anna...

⁂ Article

Exploring a Bonfire Geosocial Extension

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

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


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

Image

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?)


Image

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

Image

and the events feed


Image

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

Image

See the map with all the other locations nearby

Image

See all the media published in that location


Image

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

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

⁂ 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! 🚀

@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

@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

@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

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

@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

@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 🏕️

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

@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?