Subnostr

I know we are discussing DVMs more broadly but I want to focus on search (and I believe topic classification fits in to the same category).

For search, you generally don’t know what events you want so I don’t think not knowing if an aggregator has particular events or not is really a concern. If you don’t find what you’re looking for, you can always look on a different aggregator. Better yet, connect to a handful of them and execute your REQs in parallel. If you don’t find them on any of the aggregators, I don’t see why you would be able to find them on a DVM.   Relays that enforce AUTH for certain or all events generally do NOT want their events to be indexed. Creatr.nostr.wine certainly doesn’t want public indexers involved. If we wanted to offer search for our patreon relay, we would offer it directly on the relay - that makes way more sense than authorizing certain aggregators to access the data.   There have been on and off discussions about implementing NIP-50 in to strfry. A few relay implementations supporting it out of the box would decentralize search a lot more overnight. I’m afraid I still don’t see any reason to involve a DVM here.

Mazin 1y ago

On a separate but related note - I think we can expand NIP-50 to offer a lot more optional functions in the search, including one you mentioned.

Isolating results to only one relay (even if NIP-50 relay is an aggregator), negative keywords, wildcards, topics, language, sentiment, nsfw, etc etc.

Obviously I don’t expect every relay to implement these, but even if we only have a handful of aggregators we can query directly, thats at least on the decentralization spectrum compared to all existing social media search.   We should also expect the number of aggregators and search providers to grow with time if nostr succeeds (even if their data become more fragmented).

Reply to this note

Please Login to reply.

Discussion

Mazin 1y ago

One last thing and then I’ll stop harassing you guys, just lots of questions and want to understand.

We DO have common ground here. I think DVMs are useful, particularly for things like translation, text to speech, etc. The more generalized the request can be and the less coupled it is to a relay, the more sense it makes to me to use a DVM. In those instances it’s incredibly valuable to have multiple service providers accessible through a single job request on any client/relay.

When the providers of the data are relays, as in the case of NIP-50, I don’t see why we should bend DVMs to try to fit this use case.

Happy Sunday!

hodlbod 1y ago

You as well! I think maybe a part of our disagreement is our vision of how big relays ought ultimately be. I would like there to be many small relays which are cheap to operate and sovereign, but which can delegate advanced functionality to other services. This doesn't make sense for nostr.wine, because you have no problem running those other services. Both visions can coexist, but as a client dev I'd like to access both with the same interface.

But these are just opinions, the proof is in the pudding. I look forward to seeing what you come up with. 🫡