Oddbean

Well we won’t force anyone to migrate, but it won’t be useful anymore for anyone and we’ll encourage them to migrate. We’ve supported connecting at root for a while but it of course requires AUTH. Do you know if any NIPs exist for making a REQ for events of a specific topic or other classification? I just rolled out initial (undocumented) support for a “topic”, “sentiment”, “language” and “nsfw” REQ filters on filter.nostr.wine using our new classifier.

If I'm getting this right I don't think NIPs would be useful. I've actually always thought we could just use manually specified URL paths for this kind of arbitrary filtering. But there was also a proposal for algorithms in REQ filters which might be a good idea to revisit at some point. On the other hand many people who are interested in this kind of stuff have migrated to using DVMs instead of relay-based commands. I don't know anything, I would have to get a more concrete picture of how this works in the UI to have a better opinion.

The problem with pushing custom REQ filters to the DVM marketplace is that relays will become obsolete. Once this feature is mature, and nostr adoption grows, user customizable content feeds will be what sets nostr apart and keeps REAL user content visible. Because the threat model from bots and bad actors will be always changing, end users will want to stay on top with the BEST content filters. They will benefit from sharing filters with each other, independent of the client used. If this functionality (to share prepackaged filters) is only available through DVMs, then nostr event traffic will gradually flow more amen more through these DVMs. In addition, NIP90 for DVMs specifies an event to be published for EVERY request AND response. I kinda think this is overkill for the task at hand. Just single event to publish the “filtering service offered” by a relay and another event to “subscribe” to that filter. This is the NIP needed. IMHO nostr:note1aej3d6n9twm7y8vgvq8dq5aahhy0wkc900xpdh8n8a7rsxm0msdspyrf85