DVMs are not the perfect design but honestly it's not that hard. Instead of sending a REQ you publish a signed request event.
I never tried building a WoT relay so I don't know.
Besides DVMs and the monetization, it makes sense to me for this to be a service rather than precomputed events for the use-cases that clients have (verifying reputation, sorting, recommending follows, etc). Are you going to keep 30382 events for all permutations of pubkeys, for all services, sorted by all different algos, and all reflecting the latest updates to contact lists? A service really is most suited tor this kind of thing, imo.
Also, kind 30382 is too generic and not expressive enough for our needs.
If you'd like, tell me how I would use those to replicate the WoT i currently have on Zapstore (follows who follow). Are you familiar with that? No, it's not recommended follows. It's who of my follows, follow the signer of an app, sorted and limited to top 5.
We can continue the discussion next week when I publish the DVM PRs, as I would love to hear your input and if it could potentially work for your usecase and algos
Replies (4)
Regarding the WoT on zapstore, follows who follow: iiuc you want the intersection of two sets, Alice’s follows and Bob’s followers. And you want to calculate that quickly. Keeping track of follows is simple: all you need is the most up to date kind 3 note. Keeping track of followers and producing that list within the fraction of a second is the challenge. When I click on followers on damus, my app scours the known universe to compile the list from scratch. Takes on the order of 10s of seconds, too long for your purposes.
So am I correct to assume that zapstore maintains a cache of pubkeys and their follows? In sql perhaps? With a column for follows and another column for followers? I tried that for a while and discovered that keeping it current was a pita. Why? Keeping follows current is simple, but doing it for followers is a pita.
My solution for tracking followers is to use a graph database. Why? Because it can retrieve not only follows but also followers very quickly. To test this, I built a few api endpoints to produce follows, followers, mutes, muters, etc on demand. All very fast. And I have one endpoint currently active which would produce the WoT score exactly as you describe, very quickly, if I’ve understood you correctly. You provide the pubkeys for Alice and Bob and you get back either a number or, if desired, the entire array of pubkeys. I can give you the endpoint if you’d like to play with it, maybe check to see if your code and my code produce the same results.
So that doesn’t use NIP-85. But it does use neo4j, which I believe is very powerful.
Regarding NIP-85: zapstore is an app, currently android or desktop. And you’re planning on calculating personalized PageRank. So I presume the calculations happen on the user’s app, cached locally, and can be updated whenever you want. My zapstore will scour the universe for kind 3 notes and use them as the raw data for PageRank calculations.
But that would mean don’t need NIP-85 *OR* DVMs. So maybe I’m not understanding your plan. Who is going to be calculating PageRank?
No, Zapstore never calculated any of this client side. I could do the intersection but it's too much processing and bandwidth, all without any Pagerank sorting. Awful UX.
I used to have an API service powered by Memgraph, pretty sure we discussed it.
And now, about to launch nostr:nprofile1qqstq4j6pk2sgaupru6l7ah9nq0dueafq356jllwcy7uzlek9yx7hlspz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9mhwden5te0wfjkccte9ec8y6tdv9kzumn9wshsz9mhwden5te0wfjkccte9ehx7um5wghxyctwvshs4kprv3 which is DVM-based and currently being tested out in the latest Zapstore. It supports personalized Pagerank and it's blazing fast. This is what I've been building with nostr:nprofile1qqs0dqlgwq6l0t20gnstnr8mm9fhu9j9t2fv6wxwl3xtx8dh24l4auspz4mhxue69uhkzat5dqhxummnw3erztnrdaksz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcpzemhxue69uhhyetvv9ujumn0wd68ytnzv9hxgxmpqkh , which I also thought you knew?
I asked you earlier because I wanted to know how you'd approach the Zapstore usecase purely with NIP-85, as I didn't (and still don't) see how that is better than a DVM.
So you're saying that neo4j could be used as a service, then it would be awesome to have it running under the same DVM spec - which I'll share with you next week. That's why I wanted your feedback, so it works for your approach too