Nostr Web Client

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

david 11mo ago

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?

Reply to this note

Please Login to reply.

Discussion

franzap 11mo ago

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.