I’ve been playing around with creating a nostr client focus on Latin American users and would welcome the language filter. Any way to increase the signal to noise ratio for users is a welcomed improvements in my eyes. 🤙
Discussion
You really don't have to do this at the client level. I mean sure, a client with relay defaults that reject other languages or something, but you don't have to use the users processing power and battery life to do sorting.
In any case at least we all agree on a language parameter for both of our use cases and the protocol level is all we really have to agree on.
having a languages query parameter would mean clients can query for only one language of notes and don't need any processing power for sorting notes by language....
yes at least it seems like we all agree on that point which is promising!
LOVE this tag.l and potential to use it as query param. I’d like to browse English, German, and Spanish nostr separately as I am less than fluent and have a hard time switching back and forth rapidly.
You still have to do
if lang == english
return note
else
#implicitely drop the note
But I guess the argument is supposed to be that this check for every single note relayed to the user isn't significant enough to have noticeable performance issues for the user....
no the argument is that every note relayed to the user would already have lang === english. bc the client uses '["#l","en"]' query filter which means relays only send back posts with language tag of english.
ugh filter would actually be '{"#l":["en"]}' or something
You're still performing a check.
yes but its less checks bc client receives less notes
Oh so we're still talking about relay filtering then and not actually client side filtering. Yeah alright memorization can help there then.
i'm talking about the same query filters that search for hashtag or event thread. relays would still hold all languages (unless they want to be a specialized relay). standard query filters from clients would query the posts the user wants.
I think it makes the most economic sense for there to be specialized relays specifically language specific relays, but there's nothing keeping both from existing (except that maybe nonspecialized relays might go broke or switch to being paid services but I think we're moving towards paid relays or friend hosted relays either way)
yes, hard to know what the future relay landscape will look like. I do agree that languages specific relays will be a thing. I also agree that people would likely want translation relays and such.
all i'm saying is language query filter is first step and good short term solution to jump start language specific feeds.