Bonfire UX and features are great @mayel and team, thanks for your work! 🙏
Btw, is there a way to make pages load faster? Thanks! #bonfire_feedback
Discussion
Bonfire UX and features are great @mayel and team, thanks for your work! 🙏
Btw, is there a way to make pages load faster? Thanks! #bonfire_feedback
I posted this on my federated account but I'll report here. snowdin.town/notice/AWmsURDe...
I took a look at Bonfire recently and it looks promising. It has the idea of Circles which is one of my most desired features on fedi, so you can organize your followers into meaningful groups and make posts visible to them. There's two things that I'm struggling with there though.
One is terminology, the interface has a feed for 'Activities' and a feed for 'Posts', I don't know what those mean. Similarly the permissions system ('Roles') uses multiple terms that are hard for me to remember ('Read', 'Interact', 'Participate', 'Contribute'). The last three in particular all sound like they mean the same thing to me.
The other problem I'm having is that these permission roles are themselves adjustable. You can open up each one and toggle individual actions. That's a pretty cool idea from a customization perspective but it means that the labels themselves are now meaningless. That is, 'Interact' will mean different things to each user. Also, these permissions operate at different levels. 'Request', 'Follow', 'Mention', and 'Message' apply to users, but the rest apply to posts. So when I'm creating a post and I set the permissions to 'Participate' for a given Circle, am I giving users new permissions to interact with my account? Or am I controlling their permissions just on that post? The blending of these levels is really confusing to me.
I think it's a great idea to build more precise permissions around requests and follows, but I think that should probably be a separate section of the config. Post permissions should be relevant only to posts. I think it might also be nice if these default permission categories were not configurable, so that they meant the same thing to everyone on the network. Custom categories could be created by the user if they want more fine-tuned options.
All in all I'm still pretty impressed and glad that someone is thinking about these things. I like the frontend a lot.
@smitten just a correction: you cannot toggle the permissions on the default roles (interact, participate, etc) to customise them, you can only do so when you create custom roles.
Some updates about the development of federated #groups in bonfire:
indieweb.social/@bonfire/110...
Article: bonfirenetworks.org/posts/de...
(The federated group development has been made possible thanks to the #Nlnet Entrust grant)
Fractal Software for Fractal Futures
Apparently I can't follow this account from Mastodon, is that expected? It just stays stuck waiting for the follow to be accepted. #bonfire_feedback
@dragfyre Yes federation is currently disabled on this instance.
@bonfire@indieweb.social Love the new add to circles feature!
Just now, on a post by @ivan that @mayel had boosted, I noticed something unexpected and wanted to ask if it was intended.
What happened: I clicked on the three dots to interact with the post and my options were to ghost / silence, etc. @mayel
What I expected: my options being to ghost / silence, etc. @ivan
(I've just checked and that is the default behaviour on Mastodon and Calckey)
@dajb @ivan @bonfire@indieweb.social Ah good point! Think it would be useful to have both, or only the original author there?
🔥🔥 Managing your circles on #bonfire is now a breeze. 🌟 Create new #circles effortlessly and organize your users directly from any feed or user profile. Check out the video or experience it firsthand here on the campground! 🏕️
Hi, I think it would be nice to add an "add to circle" button on profile pages #bonfire_feedback
It will be in the next release 😊
It there any federation already? I could search and “follow” my main account, but the follow request never arrived.
@miro Federation is currently disabled on this instance. We'll more working on it further as part of this milestone: github.com/bonfire-networks/...
@ivan i cannot add people to circles, and autofill does not work (javascript enabled in chromium) ...
A busy day for bonfire 🔥🔥🔥
We've just published a new blog post about how to use boundaries and circles 🙃
Fedi:
indieweb.social/@bonfire/110...
Blog post:
bonfirenetworks.org/posts/ho...
@mayel I like that you write your own SQL queries. So many project use ORMs which in most cases create pretty bad queries.
For those who are interested, here is an explanation of why the campground had become so slow, and how we fixed that (browsing feeds is now up to 95% faster!):
When you're browsing your feed on Bonfire, each page on the app displays 20 activities, but there are tens of thousands of activities in total. Fetching all the activities at once, including related data like their authors and threads, and checking permissions for each activity can be slow and inefficient.
To address this challenge, we implemented deferred joins and boundary checking. Instead of fetching all the data and performing boundary checks for every activity before selecting the ones for a specific page, we defer these operations until after an initial pagination has been applied.
Here's how it works: First, the app creates an optimized query that loads only the necessary information needed for pagination. This includes filtering activities based on a specific feed, ensuring that only relevant activities are considered. This optimized query is designed to load less data from disk and thus is faster. It returns just the IDs of one or two pages, which could be up to 40 activities.
Next, the database takes the results of the optimized query and fetches the complete details of those activities. At this stage, it also computes the boundaries for each of those 40 activities, checking permissions to determine if the user has access to view them. The database filters out any activities that the user is not allowed to see. Finally, another round of pagination is applied to the filtered activities, ensuring that 1 to 20 activities are returned as the final result.
By deferring the retrieval of complete details and boundary computation until after pagination, the database minimizes the amount of data it needs to process. This significantly improves performance, even when the instance contains a large number of activities. It reduces the time and resources required to handle pagination, resulting in a much faster and more responsive user experience.
For those familiar with SQL, this looks something like (though the real query is much more complex):
SELECT * from activities
INNER JOIN (SELECT id from activities WHERE [...] LIMIT 40)
LEFT OUTER JOIN [...]
WHERE EXISTS (SELECT [...] WHERE [boundaries.id](http://boundaries.id) = [activities.id](http://activities.id))
LIMIT 20
Oops, domain names / URLs shouldn't be detected and turned into links when they're instead of a code block, created an issue for that: github.com/bonfire-networks/...
Exciting news! Bonfire 0.9.4 is here! 🔥
We've improved the UX of user moderation and boundaries to ensure a safer, more engaging community experience. But that's not all - expect a much faster performance and a smoother experience with our latest optimisations! #NewRelease 🚀
The main cause for slowness in browsing Bonfire has been identified and fixed. Such a relief! 😅 🔥 🏃
I've shared details about the issue here: campground.bonfire.cafe/post...
Exciting news! Bonfire 0.9.4 is here! 🔥
We've improved the UX of user moderation and boundaries to ensure a safer, more engaging community experience. But that's not all - expect a much faster performance and a smoother experience with our latest optimisations! #NewRelease 🚀
For those who are interested, here is an explanation of why the campground had become so slow, and how we fixed that (browsing feeds is now up to 95% faster!):
When you're browsing your feed on Bonfire, each page on the app displays 20 activities, but there are tens of thousands of activities in total. Fetching all the activities at once, including related data like their authors and threads, and checking permissions for each activity can be slow and inefficient.
To address this challenge, we implemented deferred joins and boundary checking. Instead of fetching all the data and performing boundary checks for every activity before selecting the ones for a specific page, we defer these operations until after an initial pagination has been applied.
Here's how it works: First, the app creates an optimized query that loads only the necessary information needed for pagination. This includes filtering activities based on a specific feed, ensuring that only relevant activities are considered. This optimized query is designed to load less data from disk and thus is faster. It returns just the IDs of one or two pages, which could be up to 40 activities.
Next, the database takes the results of the optimized query and fetches the complete details of those activities. At this stage, it also computes the boundaries for each of those 40 activities, checking permissions to determine if the user has access to view them. The database filters out any activities that the user is not allowed to see. Finally, another round of pagination is applied to the filtered activities, ensuring that 1 to 20 activities are returned as the final result.
By deferring the retrieval of complete details and boundary computation until after pagination, the database minimizes the amount of data it needs to process. This significantly improves performance, even when the instance contains a large number of activities. It reduces the time and resources required to handle pagination, resulting in a much faster and more responsive user experience.
For those familiar with SQL, this looks something like (though the real query is much more complex):
SELECT * from activities
INNER JOIN (SELECT id from activities WHERE [...] LIMIT 40)
LEFT OUTER JOIN [...]
WHERE EXISTS (SELECT [...] WHERE [boundaries.id](http://boundaries.id) = [activities.id](http://activities.id))
LIMIT 20
I encountered this issue while using Bonfire:
@BonfireBuilders #bonfire_feedback
@hxgdzyuyi it looks like we have a bug in the issue reporting code 🙈 and the error message wasn't copied into your post. do you remember what it was?