nuova casa per le galline in costruzione, per questi giorni devono accontentarsi di un bilocale...
nuova casa per le galline in costruzione, per questi giorni devono accontentarsi di un bilocale...
I've noticed that as well when I edit posts. The Bonfire Edit dialog isn't quite right. I usually just delete it and start over.
@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."
Non so bene cosa stiamo facendo ma per ora sembra piacergli....
Anna Tsing - Wonder in the midst of dread (A very recent lecture)
⁂ Article
Exploring a Bonfire Geosocial Extension
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.
Currently, our composer only supports notes and articles. To enable check-ins/check-outs, we need:
Here our standard component, but with a dropdown element next the user avatar to select the activity to publish
The dropdown shows the activity type available, based on the active extensions
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?)
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
and the events feed
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).
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.
Next steps
🤮 This is the reason why US withdraws from UNESCO today (from the official note)
"...UNESCO’s decision to admit the “State of Palestine” as a Member State is highly problematic, contrary to U.S. policy, and contributed to the proliferation of anti-Israel rhetoric within the organization."
state.gov/releases/office-of...
Looking at @bonfire I feel like it's time to setup a test instance?
@ankorage@fe.disroot.org @muppeth@fe.disroot.org sounds awesome!
"... According to Young's notes, the song was banned in Spain under Franco. according to Xavier Valiño, when Zuma was released in Spain following Franco's death, the song was listed as "Cortez, Cortez"."
https://www.youtube.com/watch?v=x-XnPXL_HMA
⁂ 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?
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:
The result? Your isolated tools become part of a connected, collaborative ecosystem.
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.
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.
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.
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.
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:
What we offer:
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.
Don't the captcha people understand that by now we're not selecting motorbikes or fire hydrants but what we think the algorithm thinks other people think they are?
in love with the new #BrandeeYounger album
@stefan@gardenstate.social edited, thanks! the link is opencollective.com/bonfire-n...
Man, this is so exciting! I've been thinking about building with Bonfire for a while now, this might be the push I need!
@sean@deadsuperhero.com great, let's conspire together 🔥
⁂ 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!
Additional improvements include:
For a comprehensive list of changes, see the full changelog.
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.
- 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!
As we push toward 1.0, we're facing some specific challenges where community support and contributions would make a real difference:
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.
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?
- Chat with us on the fediverse: @Bonfire@bonfire.cafe
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:
MIX_ENV=ember
when you wanted FLAVOUR=ember
ctrl+c in
iex it pauses the app so it wouldn't respond unless you unpause it (by pressing c for continue)docker-compose.yml
instead of the release one docker-compose.release.yml
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
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.
@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:
MIX_ENV=ember
when you wanted FLAVOUR=ember
ctrl+c in
iex it pauses the app so it wouldn't respond unless you unpause it (by pressing c for continue)docker-compose.yml
instead of the release one docker-compose.release.yml
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
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
Attempted to set up @bonfire a couple of times and didn't have success. But hopefully someone can find this valuable and/or tell me what I did wrong to help me learn as well.
https://video.firesidefedi.live/w/sXNGDdqurg59cE3syZ3svU
#peertube #vod #tech #bonfire #fedi #fediverse #it #install
@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:
MIX_ENV=ember
when you wanted FLAVOUR=ember
ctrl+c in
iex it pauses the app so it wouldn't respond unless you unpause it (by pressing c for continue)docker-compose.yml
instead of the release one docker-compose.release.yml
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
we have 3 years to create a common transnational infrastructure to defeat Elon Musk American party
@jaz also created this map-view of regional instances: https://jaz.co.uk/projects/startheresocial/shs-map/
@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 🏕️
A space for Bonfire maintainers and contributors to communicate