Replying to Avatar PABLOF7z

I haven't read your NIP-23 yet, but the initial one I want is trending list of highlights for a particular npub

when someone goes to highlighter, what "trending highlights" should I show them? that's a complex question that I can't compute client-side, but I could have DVMs computing for me easily, composably and have a long-tail of algorithms instead of just one or two

so instead of using e.g. GET api.nostr.band/highlights/bitcoin I can ask hundreds of different DVMs to give me highlights on topic "bitcoin" based on any number of parameters

some DVMs could look at zaps, some cool look at richness of discussion, some could look at SFW highlights, etc, etc, etc. Any number of combinations. Users could choose a number of "favorite" DVMs for different scenarios (i.e. I'm exploring a new topic, give me the most important stuff on topic A, especially when it relates to B and C)

and results are public and transparent, so you could browse the algorithmic results other people are seeing in their feeds and decide if that type of algorithm surfaces stuff you like and you might want to become a customer of theirs

that's also something I like about the flexible approach, a DVM can see that you are requesting some type of algorithmic feed and it can "advertise" itself by giving you results for free and you can experience their product to see if you want to buy feeds from that DVM (or mute them because they are spamming you)

The feed also applies to other stuff like Notifications:

You could have DVMs that add to your "notifications" tab stuff that doesn't explicitly tag you, but rather, that discuss stuff that is very closely related to you, or a DVM that filters out spam from your notifications, etc. I.e. I would like to see in my notifications stuff that people discuss about data vending machines since I've been thinking about them for some time. Even if those events don't specifically tag me.

Reifying results definitely is an interesting dimension. Otherwise, the main difference seems to be parameterization, which makes new functionality possible, with the downside being that a function signature defines a new protocol which sacrifices compatibility.

It seems to me that for custom feeds, DVMs are a better choice than virtual relays if 1. you want to publish the artifact of your query, 2. you need to parameterize your request, or 3. you want multiple DVMs to compete.

This could definitely be interesting to support the use case you describe, but normally feeds are disposable, and are already parameterized using a well-defined protocol.

For example, you could get "trending" stuff from a relay that does the same complex computation, and exposes it in a standard rather than bespoke format (i.e. you don't need to know its function signature to use it). Relays can also tailor their results at least to the user (the "this" parameter) using AUTH, and charge that way also.

I like that you're basically applying the javascript event loop pattern we had talked about to support arbitrary computation, data > behavior. I wonder if nostrscript could use DVM as a secure callout to extra functionality.

Reply to this note

Please Login to reply.

Discussion

No replies yet.