Nostr Web Client

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.

ManiMe 1y ago

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

Reply to this note

Please Login to reply.

Discussion

Laeserin 1y ago

Can we have subscriptions to relays that are coupled with DVMs?

Like, I'd buy access to the filter.wine and it would come with so-and-so many DVM calls per day to their custom DVMs?

fiatjaf 1y ago

I never suggested pushing custom REQs to DVMs. I don't think DVMs should be relied upon for core features of the protocol.