doing my part sir. where can i find the nip-50 modifiers it supports? how does that look like in REQs? linked post seems to filter by language & sort by top/rising

I'm not sure how to advertise the supported NIP-50 modifiers yet, there's no NIP-11 field for that afaik. Currently there are these ones that may be freely mixed: is:popular (from popular pubkeys), is:rising (from those almost reaching popular status), is:spam, include:spam, sort:top (sort content by highest engagement), language:xx. On REQs you just add an extra "search" field to the filter, e.g.: `{ "kinds": [1], "search": "sort:top language:es language:fr" }` Or use a custom wss url so that you don't need to add the "search" field to the filter.

Good approaches. Eventually it would be good to have a list of the most common of these modifiers in NIP-50 as well as a way to advertise support for them, and some convention around custom feed paths too maybe. I @Alex Gleason has wanted something like this for years.

:110percent:

That's a broader problem in Nostr design: clients need to be relays too in a single app, so we don't end up with such massive imbalances between giant relays and tiny ones. Otherwise, Nostr will be decentralised in name only; in practice, it'll be just like XMPP, which was popular as long as Google Messenger (I can't remember the exact name) used it, and then pretty much vanished once they stopped. Unfortunately, I fear there's no real desire to understand how to structure a truly decentralised network. We do need entities to help with NAT traversal, absolutely, because many people are behind NAT, but then clients should simply have a default setting for storage and bandwidth available to the network being relays as well. We could have WoT filtering if we want, or explicit blocking of someone's content (even using DBACL and the like) if we want, but the rest should be decided algorithmically and spread out. Evolving towards a handful of major hubs while the rest of the relays remain obscure isn't decentralisation, it's the death from the start. At some point, some big relay will be bought out by some who want to censor; most people will stay there anyway because that's where the bulk of other humans are, and you'll get the same effect we're seeing with Reddit compared to Lemmy.

Google or other big player does could capture Nostr by luring norms to their unlimited-ish storage infra that would end up working only with a very convinient "Sign-in with Google" flow. But Nostr soul is the relay. It was (somewhat) successful because of relays being easy to connect to from any platform. If someone could turn it into a fast P2P protocol that was just as easy to code and reason about that would be great and could avoid the likely Nostr dark fate.

GitHub

Add nip extensions to NIP-11 by arthurfranca · Pull Request #2280 · nostr-protocol/nips

This is a way to advertise support for NIP-50 extensions such as include:spam. Also added NIP-45's hll (hyperloglog) to the example. These are ...

<- a way to advertise support

sir, your relay is way too sensitive, it can't really handle basic requests without complaining... what's the limit? this req has 60 pubkeys and a since for the last 12h, not even that big. Also, then it keeps disconnecting (or upgrading the connection) which triggers another auth request and more notices. The ok-false message has no id.