Listening to nostr:npub1kuy0wwf0tzzqvgfv8zpw0vaupkds3430jhapwrgfjyn7ecnhpe0qj9kdj8 with nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn

nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn very interested in your opinion on NIP-90 Data Vending Machines.

You mention how you see clients using feed algorithms as a centralizing force where the algorithm becomes a feature of the client and you argue for pushing algorithms to the relay.

I agree that’s a preferable model, but know you’re coupling data availability (even if it can be ported with some work) with algorithms.

Do you see the data vending machine idea where there is no coupling between feed algorithms and relays or clients as a good idea or do you still consider relays executing algorithms as superior?

Very curious on your take on NIP-90 btw!

Reply to this note

Please Login to reply.

Discussion

Pull your nips out baby !

This is such an interesting question I wrote a blog post in response: https://habla.news/u/hodlbod@coracle.social/dvms-and-custom-feeds

We have tons of options for building custom feeds, and they all seem to have unique benefits. I think DVMs are super cool, and expand nostr into new areas which is awesome, but I see it as more akin to the coinjoin nips than custom feeds. What sort of unique benefits do you see DVMs providing for the social use case?

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.

I love that you’re thinking of moving away from the infinite feed scrolling. Great exploration of options!

Ps: Will you integrate list-based feeds in Coracle? I need a non-android client that does that. And maybe make ‘m finite ;)

Definitely, just have to think about how to do it

Im going to go feed less for highlighter; once you reach the bottom of the page perhaps suggest related topics or something but no endless scroll.

Fuck dark patterns.

Less but more tailored content and easier to deep dive on. ¡Me gusta!

Let’s do it 🤝