Discussion

yeah, making it editable later (rather than when you start a new thread) is intended to make it more of a curation feature, and I think extending that power beyond the original thread creator makes sense, but of course it shouldn't be editable by anyone by default and it's worth discussing what the ideal UX may look like. This will tie into work on circles and custom boundaries: https://github.com/bonfire-networks/bonfire-app/issues/223

(now implemented and will be in the next release)

it's visible in the modal when you click on the image, but that's a good idea!

You can do so right here, or directly on the roadmap where we're keeping track of them: https://changemap.co/bonfire/bonfire/

Well we've implemented a GraphQL API for Bonfire, which is a much more flexible way for frontend apps to get exactly the data they need and provide a richer experience, so hopefully some alternative frontends and mobile apps will want to implement that at some point (maybe we can even standardise on a common GraphQL schema to be use by different federated platforms!)... The other option would be that we/someone implements the Mastodon REST API as a Bonfire extension.

I've always kept it mind what Dave Winer (creator of RSS) advised: to publish in a place under your control (basically hosted on your own domain name) with that always being the canonical home for your stuff, and then syndicating wherever you want (linking back to the source). I think the same can apply for community and discussions. Why not use the closed platforms like one would dump leaflets out of an airplane over an authoritarian territory?

that feature is already there but needs some improvements ;)

not yet, we're planning to organise some install parties soon... focused first on testing federation (rather than being a place to host your main fediverse identity before being sure it's working as expected)

the code generating those URIs wasn't making any requests, but it's possible that it was happening somewhere else in the backend, since we we have code that compresses images for "lazy loading", though that usually applies only for locally-uploaded ones