Oddbean new post about | logout
▲ ▼
fiatjaf | 8 months ago (raw) | root | parent | reply | flag 
 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 | 8 months ago (raw) | root | parent | reply | flag +1 
 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
▲ ▼
fiatjaf | 6 months ago (raw) | root | parent | reply | flag 
 I never suggested pushing custom REQs to DVMs. I don't think DVMs should be relied upon for core features of the protocol.