Non so bene cosa stiamo facendo ma per ora sembra piacergli....
Anna Tsing - Wonder in the midst of dread (A very recent lecture)
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
Use cases and proposed implementation approach:...
Bonfire
🤮 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
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...
Bonfire
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
@Bonfire your link to "back Bonfire on OpenCollective" seems broken!
@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 🔥
🔥 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...
Bonfire
@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.
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
we have 3 years to create a common transnational infrastructure to defeat Elon Musk American party
@ivan Thanks! This list is outdated now and long overdue an update, but I tried to list a few regional ones here: https://coxy.co/mastodon/#regions
@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 🏕️
@matt@oslo.town so cool to see more location-based communities in the fediverse ✊
@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/...
