Recent activities

@deadsuperhero@spark.box464.social we developed a PWA that does a decent job imo, re. native apps, we will have some cool news soon-ish :)
@spark464@spark.box464.social

@ele@spark.box464.social @spark464@spark.box464.social @mayel @box464@mastodon.social @admin@spark.box464.social

right, we need to properly integrate the edit workflow in our current composer, instead of using a dialog... will open an issue! thx!

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.