rankings shouldn't (exclusively) use search params

[lumenkeyes]

From reading the code a little bit, (frontend/src/lib/search.ts) it seems like stract uses the search parameters, and only the search parameters, to determine a user's ranking/block preferences. As far as I can tell, a ranking store is already implemented and used by the like/dislike/block modal. I would propose that the results page fully utilize this store for a more consistent experience (and shorter, more readable URLs).

Currently some use cases are infeasible for the end user if they also want to keep their ranking preferences, such as using stract as a custom search engine from the search bar in e.g. Firefox. Since the &sr param seems to change every time the user updates their ranking preferences, it is impossible to use a consistent link, which is required for custom search engines.

Currently, if one uses stract as a custom search engine with a simple url like https://stract.com/search?q=%s, blocked sites appear in the results, but when one opens the modal for the offending result, the block option is already highlighted.

As a matter of personal opinion, it seems like a bad idea to store preferences in URL params at all, but at the very least this workflow/usage pattern should not be required, especially when the modal is already using the svelte store.