>accidentally hit unfollow on j
>instantly disappears from my feed competely
>pleroma search is useless, returns nothing when I search for @j
>try to hit remote follow on bae st, gives error
the fediverse user experience
>instantly disappears from my feed competely
>pleroma search is useless, returns nothing when I search for @j
>try to hit remote follow on bae st, gives error
the fediverse user experience
Gidi Kroon likes this.
Getgle Patriot - God, Glee and Country
in reply to Getgle Patriot - God, Glee and Country • • •Joel
in reply to Getgle Patriot - God, Glee and Country • • •cc @lanodan @hj
Den Datafag Trollmann :flag:
in reply to Joel • • •Haelwenn /элвэн/ :triskell:
in reply to Den Datafag Trollmann :flag: • • •Gidi Kroon likes this.
Joel
in reply to Haelwenn /элвэн/ :triskell: • • •Den Datafag Trollmann :flag:
in reply to Joel • • •Joel
in reply to Den Datafag Trollmann :flag: • • •Den Datafag Trollmann :flag:
in reply to Joel • • •@p @lanodan IIRC it at least used to be client does its own search first and waits for backend to respond and then updates autocomplete with backend response, but it causes jumpy behavior, and additionally we don't (didn't?) have proper sorting by "last active" so order is a mess.
It could be done and improved but it's gonna take some doing
Joel
in reply to Den Datafag Trollmann :flag: • • •What about indexing? Is there a better way to index it? IIRC pleroma uses a lot of custom functions and stuff but doesn't have any cost values assigned.
pistolero
in reply to Joel • • •@hj @lanodan Well, at least trivially, searching by prefix instead of substring would get not just the 90% case but probably the 99% case, and I *think* this part has been fixed but before it was doing tsvector, like it was dropping the "@" and treating "@p@fseb" as a search for "p" and "fseb"; I'd have to go looking again.
...Then I ended up looking again.
That code actually has kind of a long path between the HTTP request and the database, like lib/pleroma/activity/search.ex around the query_with()s which, while I'm here, it looks like what I said abut substrings is wrong, because it's doing "to_tsvector('english', ?->>'content') @@ plainto_tsquery('english', ?)". Autocomplete uses the same search endpoint as regular search, so /api/v1/accounts/search?q=asd&resolve=true , and I could have sworn there was a substring bit but I don't see anything like that.
Haelwenn /элвэн/ :triskell:
in reply to pistolero • • •Which is quite a mess and makes me wish Elixir would have early returns for the case where a @ is present and so where we could assume substring rather than FTS…
pistolero
in reply to Den Datafag Trollmann :flag: • • •Haelwenn /элвэн/ :triskell:
in reply to pistolero • • •@p @hj Yeah for users you could probably store the whole shebang in RAM.
But due to how brain dead MastodonAPI got designed, most searches are combined users+full-text+hashtags (I'd guess hashtags are basically gratis in comparison to full-text).
And shoving the list of users to clients… reminds me that AdminFE somehow manages to almost choke on just loading the list of instances, most of that is likely because the UI was just clobbered together and ending up generating a massive DOM rather than just keeping a JSON in memory but still.