Bonfire

We've just published a new blog post "Why are we building yet another (federated) todo list app?"
https://bonfirenetworks.org/posts/bonfire_coordination/
#valueflows #nlnet #project-coordination #forgefed

@mike_hales @yala

I personally think it's a great idea, and while it isn't yet on our roadmap, we have discussed implementing wiki-style functionality before. Would have to look into what protocol fedwiki uses though (probably not ActivityPub)...

- Mayel

Our first blog post is out there 😃
We shared some thoughts about what guided us during the creation of our logo...
https://bonfirenetworks.org/posts/bonfire_identity/

@mbajur yes, we're building graphql APIs for it, though not all extensions have them yet

Happy to unveil the Bonfire iconography, along with an updated website: bonfirenetworks.org

@EmbraceTheGray@social.privacytools.io That's one aspect we're working towards, yes.

@yaaps@banana.dog oooh thanks!

@0x1C3B00DA

The Bonfire team will operate an instance of the AP server in the cloud for users of the device (and potentially others).

Whether and how anyone will set up open instances of the apps is TBD.

@0x1C3B00DA

The device is not required (though would be the easiest to get set up). You could run the apps on another device at home, like a Raspberry Pi, regular server, or even on your personal computer (though they'd of course only be usable when it is online). You could also host them in the cloud, though we want to discourage that.

@jvalleroy

TL;DR: Try out Elixir, we think you'll like it! For example Phoenix LiveView enables building reactive apps without all the JavaScript ;)

@jvalleroy

Also note that this would mean missing out on all the libraries (be they a generic AP implementation, circles functionality, a search index, a collection of UI components, etc, etc) that we are developing to make it easy to build something bespoke without having to rewrite all the common functionality from scratch...

@jvalleroy

We'd of course welcome others wanting to implement the sync protocol that Bonfire will use (for the apps to talk to the AP server) in other languages to enable non-Elixir apps to participate in the ecosystem, but the Bonfire team only has the bandwidth and interest to focus on and support Elixir apps (along with some Rust components).

@stevenroose @mayel @rysiek @tcit@social.tcit.fr @karen@kawen.space

It's basically the same project, in that Bonfire shares all the goals that CommonsPub had but adds things like the hardware device and the optional separation of the federation server (AP inbox/outbox and storage ActivityStreams data in the cloud) and the apps (UI, app logic, relational DB).

@Downes

And to address your concern, we're thinking to try a sustainably model where you can pay for convenience (in the form of optional cloud services and preconfigured hardware) but everything is FLOSS so you can self-host and DIY without loosing out on any functionality.

@dajbelshaw @ton

@Downes @dajbelshaw @ton check out Nextcloud which is a fork of OwnCloud (by many of the same people, who didn't agree with the direction)

@Argus@mastodon.technology They're also one of the few spaces we can still socialise in this age of social distancing (at least during the cold months). Let's light more bonfires!

@Argus@mastodon.technology bonfires often start among a small group of friends and then may attract neighbours and others who want hang out for a while. Also burning stuff is fun!

@humanetech@mastodon.social

Thanks 😊 still lots of work to do in this, but we think it's worth trying!

Just launched a first draft of our website with a little info about what we're cooking: https://bonfire.cafe

TL;DR: Bonfire will be:

1. a pre-configured device
2. a fediverse identity hosted service (which syncs between the fediverse and the device whenever it comes online)
3. apps (web apps but they run on the device instead of the cloud)

Hello, fediverse!