Replying to Avatar hodlbod

DVMs are very easy to implement for clients in fact (unless you're paying for the service, that's a little bit harder). See my search implementation here: https://github.com/coracle-social/coracle/blob/master/src/engine/network/utils/dvms.ts, it's only about 50 lines of code.

Have you read my article on DVMs as functions? I think I dropped the link before but it describes what I'm thinking of here: https://habla.news/u/hodlbod@coracle.social/0gmn3DDizCIesG-PCD-JK

Here's how I imagine the DVM search flow looking:

1. Client connects to relay(s) where any DVM that supports search is listening (based on a nip 89 advertisement).

2. Client makes dvm search request on behalf of user by signing a job request, optionally including the relay urls they want to search

3. DVM uses negentropy or some other sync implementation to index the requested relays or a static set of relays.

4. DVM responds with event IDs that match the search

5. Client makes REQ across multiple relays for result IDs

6. Client displays results (if they can find the events)

Step 3 is obviously the difference here. It's a fairly difficult implementation for the relay, because it relies on keeping an index across multiple relays and potentially rebuilding it on the fly for clients.

There are two benefits though:

- Any relay can be searched using any algorithm, regardless of nip 50 support or implementation quality

- DVM caches can be as big or small as they want. If they want to index the whole network, they can, and you avoid duplicate results from querying a bunch of relays using nip 50. If they only want to index a single relay (even a private one), they can. Returning event ids means they're not leaking any information about private data, since clients still have to AUTH with the relay that holds the information.

The idea is that relays are data structures (or names encapsulating data structures), and DVMs are functions. Functions can do *anything* with data. So search is only one of an infinite number of possibilities — very few of which would ever be widely supported by relays.

50 lines of code is a lot more than leaving it to a relay to implement actual search

DVMs are a retarded idea, all databases have to have some kind of indexes and metadata so it's just, IMO, a problem of too much funding going to so many clients and too little going to relay development

Reply to this note

Please Login to reply.

Discussion

No replies yet.