@mayel I like that you write your own SQL queries. So many project use ORMs which in most cases create pretty bad queries.
Also on
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/...
Mayel
boosted
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?
The main cause for slowness in browsing Bonfire has been identified and fixed. Such a relief! 😅 🔥 🏃
Did you notice that the words count didn't work? It's stuck at 0/2000 words for me… #bonfire_feedback
yeah I think we need re-wire some javascript for that
Mayel
boosted
🔥🔥🔥 New Bonfire release: v0.9.2! We're thrilled to announce the latest update, bringing you a more robust and tested boundary system and polished UI.
Testing on Firefox on Android both of the videos autoplay when I click them.
Mayel
boosted
Is there a how to get started blog post or documentation somewhere?
I am just looking for some ideas on how I can test out the features here in the Campground.
I really can't figure out in any practical way how circles, roles, and boundaries work.
Ok, so apparently I can't post image attachements, at least not with image descriptions.
Here I try to post an image without any description:
@Oceane testing an image with description... what error did you get?
The campground instance was updated to a new release with various improvements 🔥
@bonfire@indieweb.social The latest release includes a way to switch between both modes while drafting a post, so you don't have to choose just one!
That's the same thing that happened to me! However, it's still going. Currently, whenever I click on one of my "active apps" (i.e. pages) it will tell me something like "this string is not found" or "you don't have permission to view this string". I wonder what happened. Also, I posted about this some months ago, with the #bonfire_feedback tag and non of the dev's have responded. Has anybody else gotten engagement from the devs?
#support tag maybe?
Still pumped for this project though.
@versolalto The pages extension is currently disabled because it is still in development (you should be getting an error saying that instead of the ones you got though, will look into that). Sorry you didn't get a response last time!
Yeah I see s3.nl-ams.scw.cloud on the list. Will open an issue on that repo.
There's also a merge request: gitlab.com/malware-filter/ph...
Hi gangsters, the Phishing URL Blocklist used by uBlock Origin seems to block our media cache server. You need to disable this block list temporarily in the uBlock Origin settings to be able to view images.
Go sack them at gitlab.com/malware-filter/ph...
(PSA, it's a joke, we're all in the same boat and sometimes automated filters have false positive, you don't collect 55,653 malicious domains by hand. These brave people are doing the State's job for free, something quite unusual in tech ˀ!)
Yeah I see s3.nl-ams.scw.cloud on the list. Will open an issue on that repo.
