Thread

Both nostr:nprofile1qqsw2feday2t6vqh2hzrnwywd9v6g0yayejgx8cf83g7n3ue594pqtcpz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3kamnwvaz7tmjv4kxz7fwvf5hgcm0d9h8qctjdvhxxmmdqyt8wumn8ghj7erpwe5kgtnwdaehgu339e3k7mgxeu5tj and nostr:nprofile1qqsrx4k7vxeev3unrn5ty9qt9w4cxlsgzrqw752mh6fduqjgqs9chhgpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszrnhwden5te0dehhxtnvdakz7auwthp are providing we of trust info natively on nostr if you need. https://github.com/nostr-protocol/nips/pull/1534

Update Zapstore. nostr:nevent1qqszyt7ku2havsjrgw33aweqf6ejrh9g8lwx3cp3lepzw0yu8f45uggpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygrceeh65u3xgwrjsnny0wnf8zv4wd0v3374ckn9wdl92yc0qf3s05psgqqqqqqs575e32

fyi I’m going to be issuing kind 10040 notes soon as per NIP-85.

Done 👍

Just published my first NIP-85, kind 10040 note to declare Trusted Service Providers - I may be the first one. Don’t see any other such notes

I need relevant follows who follow. How do I use this NIP for that? At a glance I could not figure out

You mean you want to find new people to follow? For now you can go to my app and stratify users in your extended Follows Network by their GrapeRank or their PageRank score. Filter out the ones you already follow (set minimum hops = 2), check out the high scores and decide if you want to follow them. People like nostr:npub1clk6vc9xhjp8q5cws262wuf2eh4zuvwupft03hy4ttqqnm7e0jrq3upup9 have told me they particularly want to look at their followers and maybe follow some of them back, but they don’t want to wade through thousands of bots. NIP-85 allows these scores to be exported so other clients can use them for that purpose plus lots of other purposes. https://grapevine-brainstorm.vercel.app/

I need to read NIP-85 in full to give my opinion but exporting this data for every single pubkey permutation seems like a waste of resources. Thanks but Zapstore is already using Vertex, we need this actionable information in under a second. Early next week (Tue-Wed probably) I will publish our draft DVM specs and I would love if y'all could chime in. I'll ping you

It’s not gonna be one size fits all. I look forward to seeing the DVM specs! It is a lot of data. But the question is this: do we calculate WoT scores on the fly just when we need them? Or ahead of time? Right now, we’re trying to do all of them on the fly. I think that’s great for some use cases, but it places severe limitations on what we can accomplish. If we want the notion of WoT to mature, some calculations are simply gonna have to be done ahead of time. Per NIP-85: there is one event which holds multiple personalized WoT scores (I export GrapeRank, PageRank, & hops, with more scores to be added later) per pubkey. So that’s one event with multiple WoT scores, all concerning Alice, from the perspective of Bob. (“Personalized” means from the perspective of Bob, as opposed to “global” which really just means from the perspective of a big centralized entity like Google.) We can have third party services to generate and store these events. Right now my app exports these events to my relay. But my vision is personalized WoT relays where Bob will store all of the events that are calculated from his perspective. NIP-85 provides a way for Bob to tell clients where to look for any given WoT score (kind 10040 notes), which can be a personalized WoT relay, a third party service, wherever. So I see this as basic division of labor. Let each app do what it does best without also necessarily having to provide a complete WoT solution from scratch all by itself.

Here’s one way it could play out: either third party services or personalized WoT relays create a big picture snapshot, with generic-ish trust scores for a huge number of pubkeys. This will require lots of raw data and lots of compute. So these are the scores that are in greatest need for recalculation and storage. Next, we have trust scores that are highly contextual. The opposite of generic-ish. Like who are the experts in some narrow topic. These scores require less raw data, less compute and involve fewer pubkeys. So perhaps specialized apps could handle these calculations. The generic-ish trust scores could be accessed and used as filters so that the raw data used for contextual scores is not polluted by spam. So two ends of a spectrum: generic trust scores calculated ahead of time with results made accessible for lots of purposes; versus highly contextual, specific trust scores that could be handled on the fly.

*precalculation and storage

This seems very complicated. As a left curve individual I want to query a service and get the stuff I want, very fast, and yes that includes personalized Pagerank. It's up to the service to cache internally if it can't do realtime, no need to generate a massive amount of events. As a client, I can ofc keep these signed results cached if I want, put them on a relay, whatever. I just don't think this belongs to a spec

Do you think that every nostr client that wants to use PageRank should calculate it from scratch?

Not at all, they should query a specialized DVM. Clients are free to do anything they want with those results, share them, keep them for offline usage, etc

So maybe we’re doing basically the same thing, except I’m using NIP-85 and you’re using DVMs. To me, DVMs seem too complicated. But in all fairness I’ve never tried building with DVMs. Having calculated the WoT scores, it didn’t take me long at all to make a button to format and publish the data as kind 30382 notes, plus one kind 10040 note. That’s all that NIP-85 requires. I suppose DVMs will be useful if I want to make money as a third party WoT service provider. But if I want to calculate WoT scores myself, using my own personalized WoT relay, is the complexity of a DVM really necessary?

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

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

Yeah it probably could! I’ve been wanting to dig into DVMs so maybe your spec will be the place for me to start. Definitely let me know when you have something ready for review and discussion. 🔥

😀

Not Pablo. You're on an old version of Zapstore, please update nostr:nevent1qqszyt7ku2havsjrgw33aweqf6ejrh9g8lwx3cp3lepzw0yu8f45uggprpmhxue69uhkv6tvw3jhytnwdaehgu3wwa5kuef0qgs83nn04fezvsu89p8xg7axjwye2u67errat3dx2um725fs7qnrqlgrqsqqqqqpeqy6w7