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?
Tending to @bonfire@bonfire.cafe 🔥
@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=emberwhen you wantedFLAVOUR=ember - if you enter
ctrl+c iniex 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.ymlinstead of the release onedocker-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
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:
- you first entered
MIX_ENV=emberwhen you wantedFLAVOUR=ember - if you enter
ctrl+c iniex 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.ymlinstead of the release onedocker-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
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:
- you first entered
MIX_ENV=emberwhen you wantedFLAVOUR=ember - if you enter
ctrl+c iniex 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.ymlinstead of the release onedocker-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
Mayel
boosted
Mayel
boosted
Are you still on #Spotify?
Spotify’s CEO Daniel Ek has raised €600M for his new startup, which is developing AI TECH FOR WAR. Ek still owns 9% of Spotify, but has 37% voting control. His net worth went from $2.5B to $10B in the last two years alone, on the back of paying musicians a pittance in royalties.
And don’t forget:
• Spotify spent $250M of your subscription dollars to invite Joe Rogan to spew his disinformation on their platform.
• They’re still trying to embrace and extinguish Podcasts.
• They’re developing in-house, AI-generated “music” so users will play them (royalty-free) instead of music created by humans (who demand royalty).
And now, he’s using his wealth, created by your subscriptions, to fund tech that will use AI to literally murder humans in war.
Stop funding him. Quit Spotify now.
#QuitSpotify #music #ai#militaryTech #techbro
“Spotify’s CEO invests $1 billion into an AI military start-up — and musicians are fuming”
Mayel
boosted
"Men who sell machines that mimic people want us to become people who mimic machines. They want techno feudal subjects who will believe and do what they’re told. We, as people, are being strategically simplified. This is a fascist process."
https://organizingmythoughts.org/some-thoughts-on-techno-fascism-from-socialism-2025/
Mayel
boosted
Well, it’s official: I have been released from my employer and I am now looking for new employment.
I am an Elixir and Ruby on Rails software engineer with a penchant for learning new languages and technologies quickly. I am a keen problem solver and an excellent communicator. I am passionate about building tools with open source software for the good of mankind. I also have a background in electronics and RF mesh networking.
I prefer remote, but would be open to a hybrid position in the Fort Worth, Texas area.
Mayel
boosted
Bonfire's progressive web app is getting cool 🤟
@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?
@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.)
@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/...
@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/
@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...
@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.)
(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.)
@gaditb@icosahedron.website Don't worry I'm enjoying it, keep em coming!
@mayel (After a certain level of depth to this conversation I hit the wall of being a Fake Geek Girl™ who hasn't actually read @sarahjamielewis 's Queer Privacy or more than a chapter or two of @sarahjeong 's Internet Of Garbage or looked deeply into the work and critiques that @evacide has done over the years or ... .)
@gaditb@icosahedron.website Thanks for the reading materials! 😊
@evacide@hachyderm.io @sarahjamielewis@mastodon.social @sarahjeong@mastodon.social
@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.)
@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).
A bit of a longer post to hopefully come (but I AM bad at Task, and currently behind on many things) but I think there's a widespread antipattern in UI presentation of calling a functionality (especially safety functionality) what the user WANTS rather than what it DOES.
I think this is especially... not "dangerous" exactly, but more impactful -- in federated/distributed networks, where there isn't a Single Platform/Owner able to play god with the single database (and with a stronger ability to pretend to play god with every user's endpoint).
Iike, "Delete Message", e.g. I think should be called "REQUEST Delete" -- it relies fundamentally on a basic minimal level of politeness from instances (federated) or individual endpoints (E2E chat).
A lot of these are "request"s, but it gets more obviously complicated when you add it in explicitly.
Like, "block user" -> "request block user".
Who are we Requesting things of? That is, who are we trusting? And who hears of this request?
@gaditb@icosahedron.website great point! This is what's currently shown when you delete a post in Bonfire, I guess we could make it clearer that this:
- deletes it on your local instance
- sends a deletion request to other instances (and to which ones?)
Mayel
boosted
⁂ Article
Long-form content in Bonfire: Part 1
Inspired by @evan@cosocial.ca 's recent article on advancing long-form text in the social web, we've taken the leap and developed our first prototype for publishing and reading articles on Bonfire, based on the FEP-b2b8 draft specification.
Beyond microblogging
From day one, we've designed Bonfire to break free from the constraints of microblogging-centric social networks. We've already experimented with extensions for coordinating tasks, exchanging resources, and more. As we work on Bonfire Social 1.0, adding article support felt like a natural evolution of this vision.
Working based on a FEP (fediverse enhancement proposal) that provided both design guidelines and technical specifications was refreshing and showed how co-design and shared standards can be our strongest ally for pushing the fediverse forward.
One feed, many content types
Adding articles marks a small but significant step towards realising the vision of the open social web: a digital space where you can receive, read and interact with diverse content types from a single place, rather than juggling multiple platforms, accounts, and notification streams.
With Bonfire, articles from writefreely, ghosts, wordpress and any other federated platforms that implement the FEP-b2b8, now appear seamlessly in your feed alongside other content from your network. You can:
- Preview articles in the feed
- Read the full article and nested comments without loading an external site (just like the good old days of RSS readers)
- React or reply to the article or other comments
This UX improvement offers a glimpse of what becomes possible as more platforms and software embrace the fediverse.
But why stop there?
Thanks to our modular feed builder, we've added an "Articles" feed preset. This dedicated timeline displays only long-form content, with sorting options for most liked, most replied, and more.
It's like having a decentralised blogging platform and feed reader integrated in your social network.
Speaking of feed readers, we've also added RSS and Atom feeds so you can subscribe to Bonfire feeds (including articles and/or microposts) via your favourite feed reader app as well.
And yes, you can also write articles directly in Bonfire! While the authoring experience is still rough around the edges (we're actively improving the UX), we're pleased with this initial prototype (which includes a simple rich text editor using markdown, and the option to add a title and cover image). In fact, this very article was written and published through Bonfire.
What's Next?
As we refine the implementation, ideas are already flowing:
- Personal blog pages: Do users want an optional dedicated blog section on their profile, maybe with tabs to easily switch between notes, articles, or other content types?
- Instance curation: Could instance moderators pin and showcase their best articles on the homepage?
- Enhanced authoring: Should we create specialized UIs for properly writing and managing blog posts?
- Email subscriptions: Non-fediverse users could subscribe via email to federated blogs?
The possibilities are endless, but we believe long-form content features should be shaped by actual community needs and designed collaboratively in the open, building upon FEP-b2b8 through real-world usage and experimentation.
Join the experiment
This is just the beginning. You can experience writing and reading articles on Bonfire today at our campground instance or by setting up your own Bonfire instance.
If your community is interested in test-driving or co-designing long-form content features, we’d love to collaborate.
To build a fully integrated, community-shaped publishing experience — and continue improving Bonfire in many other areas — we’re actively seeking support. You can back Bonfire on OpenCollective or get in touch to help shape the future of federated publishing.
---
What would you like to see in federated long-form content? Join the conversation and help us build the open social web together!
@tchambers @strypey
Indeed, we have FEPs that either directly address the UX issues mentioned in your post, or could be parts of final solutions:
The Sin of Overwhelming Complexity: Instance Selection Paralysis
- https://codeberg.org/fediverse/fep/src/branch/main/fep/61cf/fep-61cf.md
- https://codeberg.org/fediverse/fep/src/branch/main/fep/ae97/fep-ae97.md
The Sin of Remote Interaction Purgatory: Federation Gymnastics
- https://codeberg.org/fediverse/fep/src/branch/main/fep/07d7/fep-07d7.md (withdrawn; https://fedilinks.org is a similar proposal)
- https://codeberg.org/fediverse/fep/src/branch/main/fep/3b86/fep-3b86.md
The Sin of DM Disasters Waiting to Happen
Some FEPs talk about limited visibility posts and private groups:
- https://codeberg.org/fediverse/fep/src/branch/main/fep/171b/fep-171b.md
- https://codeberg.org/fediverse/fep/src/branch/main/fep/db0e/fep-db0e.md
The Sin of Ghost Conversations and Phantom Follower Counts
Synced conversations:
- https://codeberg.org/fediverse/fep/src/branch/main/fep/1b12/fep-1b12.md
- https://codeberg.org/fediverse/fep/src/branch/main/fep/171b/fep-171b.md
- https://codeberg.org/fediverse/fep/src/branch/main/fep/76ea/fep-76ea.md
- https://codeberg.org/fediverse/fep/src/branch/main/fep/f228/fep-f228.md
The Sin of Invisible Discovery: The Content Mirage
The Sin of User Discovery Hell
I think ActivityPub relays could be used to solve those problems:
- https://codeberg.org/fediverse/fep/src/branch/main/fep/ae0c/fep-ae0c.md
Thanks for compiling that list! We've opened a few issues with FEPs to investigate: github.com/bonfire-networks/...
@jonny@neuromatch.social @strypey@mastodon.nzoss.nz @tchambers@indieweb.social @moshidon@floss.social @pre@boing.world
Has anybody built a UI for browsing longform writing over #ActivityPub?
@jsit@social.coop we're working on it right now 😊
Mayel
boosted
Event
🔥 Bonfire Install Party #1 – Get your fediverse instance running!
Friday, June 27, 2025 at 3:30 PM (+0:00)
Join us this Friday at 15:30 UTC for our first Bonfire Install Party!
A casual peer-led session where we’ll set up Bonfire instances together, ask questions, and tackle challenges in real time.
This session will focus on deploying Bonfire using Co-op Cloud — our recommended method, especially for fresh servers. Whether you’re ready to install or just want to follow along and learn, you’re welcome.
What to expect
• Hands-on walkthrough of live deployment using Co-op Cloud
• Real-world troubleshooting and debugging — we’ll learn together
• Shared note-taking to improve our documentation and install guides
• Help shape better tools and recipes by trying them out in the wild
• A no-pressure, collaborative learning environment
What to bring
Ideally:
• A domain or subdomain
• A publicly-accessible server (VPS, dedicated, or local) with SSH access
• DNS configured for your domain
• Your curiosity and questions!
Not ready? That’s fine too — join to watch, learn, and prep for next time. No experience required.
Please note the time is 15:30 UTC, you can see what that means in your timezone using this link and add the event to your calendar using the Actions dropdown menu.