Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Trusted Assertions #1534

Open
wants to merge 13 commits into
base: master
Choose a base branch
from

Conversation

vitorpamplona
Copy link
Collaborator

Certain calculations in Nostr require access to the entire dataset of events and are impossible to do directly by Clients. This PR offers a simple way for users to declare trust in service providers for those calculations.

Yes, it's similar to DVMs, but without the need to request/response each item. The service just runs constantly and updates events as quickly as it can.

Read here

@vitorpamplona
Copy link
Collaborator Author

vitorpamplona commented Oct 11, 2024

@alexgleason I think you already have something like this, using the same kinds
@nostrband we can add all of your stats here if you want
@nostr-wine I'd love to get some of your services here as well

@melvincarvalho
Copy link

Follower count can be easily gamed by automated agents. And this NIP encourages that.

@vitorpamplona
Copy link
Collaborator Author

vitorpamplona commented Oct 11, 2024

Follower count can be easily gamed by automated agents. And this NIP encourages that.

Deciding what counts is up to each service provider and user. This NIP just specifies how they declare trust in each other.

@nostrband
Copy link
Collaborator

Concept ack, need to try it.

@cesardeazevedo
Copy link

It is possible to add event quotes too?

@manimejia
Copy link

WoT "scores" are not absolute for any user, but relative from the perspective of an "observer".

So the event sent (from service) SHOULD specify an observer tag as well as the recipient of the score.

In addition ... our service (and prolly other WoT recommendation engines) would prefer to output a list of scores (possibly thousands) for any given observer. So maybe having a "d" tag for the whole event is not the right format?

@vitorpamplona
Copy link
Collaborator Author

vitorpamplona commented Oct 11, 2024

WoT "scores" are not absolute for any user, but relative from the perspective of an "observer".

Correct, but for these events, they will have to be absolute. Picture a WOT algorithm that is just a "page rank" for pubkeys.

So the event sent (from service) SHOULD specify an observer tag as well as the recipient of the score.

No, I don't think this would work (too much data - quadratic on the amount of users). DVMs would work better for the personalized score services (which this PR does NOT replace)

@staab
Copy link
Member

staab commented Oct 11, 2024

I would use DVMs to do this. Most people think of them as a request/response flow, but they also easily support zero requests and 0+ responses. A client looking for these events would just query for the DVM response without publishing a request.

@vitorpamplona
Copy link
Collaborator Author

I would use DVMs to do this.

That was my initial conclusion as well. But after months of testing and debates, I think that just overloads the DVM spec with a use case that needs a different tooling from what they use.

It's a similar thing with your recent NIP-29 fork. It initially looks similar, but in the end it's not the same thing.

@staab
Copy link
Member

staab commented Oct 11, 2024

Actually, on a second read of the PR you're right. It's a totally different use case, even if it could be shoe-horned into the same structure. Onward 🫡

@manimejia
Copy link

I CAN picture a WoT algorithm that is just a "page rank" for pubkeys. It's called GrapeRank, and there is no such thing as an absolute WoT score.

https://github.com/Pretty-Good-Freedom-Tech/graperank-nodejs

There MAY BE such a thing as an "average observed" score for a pubkey, but this is only useful AFAIKT if the requestor either does not have a pubkey of their own (because directly observed scores ARE more accurate for any user's use case) or if the requestor does not want their "observed network" to be transmitted publicly. In this latter case, we are working on a better solution for transmitting WoT scores privately.

And you may be right about DVMs being a better solution for WoT lists. An API architecture that accommodates a "list of recommendations for a given observer" is MUCH more useful for transmitting WoT "scores" (and other user and content recommendations) than the NiP proposed here.

IMHO, mostly because WoT scores ARE relative, I do not think this proposal actually solves for any real world problem of transmitting WoT recommendations from a remote service.

@vitorpamplona
Copy link
Collaborator Author

vitorpamplona commented Oct 11, 2024

There MAY BE such a thing as an "average observed" score for a pubkey, but this is only useful AFAIKT if the requestor either does not have a pubkey of their own

It's not hypothetical, this is one of the main use cases for this PR. Apps don't need high-precision in WoT scores most of the time. We just need some basic reputational scores to.. say.. rank search results when people are trying to @ someone. Things like that.

Sure, personalized and private WoT are better versions of this but the added performance costs sometimes are not acceptable. For instance, I need the WoT to show up while the user scrolls really fast in the app. We wouldn't be able to call a server for each user in time.

Obviously, this doesn't replace the need for personalized and private WoT. It's just solving a different need.

@manimejia
Copy link

I appreciate the need for speed when clients make use of WoT recommendations ... but I still don't think "generic" scores are a great solution. Indeed, a cached "wot list" may perform even better than discrete "wot score" requests.

  • our recommendation service will provide cached WoT lists as per each users subscription level for updates. No need for OUR service to calculate per request.

  • our service will provide these results in a number of formats and channels for clients to make use of (NIP51 lists over relay, DVM results, ect...) ... This includes a possible "wot list" NIP specified format of the future.

  • clients SHOULD cache these lists and update ONLY upon expiry (for NIP51 lists, expiry is determined by the most recently updated list "d" tag ... a "wot list" NIP may specify some expiry tag) There are many ways for clients to determine if a list has expired using a SINGLE request for each observer.

In many ways ... an observer-centric "recommendation list" is a better solution for "wot scores" than this proposal. IMHO

@alexgleason
Copy link
Member

Interesting! In Ditto I am using these kind 30382 events with n tags to mark users as verified, suggested, blocked etc (moderation actions, basically) by the Ditto server. But I haven't used it to cache stats about them - for that I'm making use of custom Postgres tables, and exposing that data only through the Mastodon API. I had considered putting those stats in the same kind 30382 event (basically I had the exact same thought as you), but I simply wasn't brave enough to do it, that's my only reason. So, I think it's a good idea. It's a little harder from a performance standpoint than using a Postgres table, so I thought it was only worth doing if there was standardization around it.

It competes slightly with what I'm doing with labels, but not by much. The drawback of using labels in this way is that they store fixed values (not dynamic ones), they're not replaceable events, and when you start labeling a lot of things at once they can have collisions. A good way I'm using labels is for trending posts, but now I'm considering moving my captcha solved label to kind 30382.

@vitorpamplona
Copy link
Collaborator Author

The cool part of moving to 30382 is that you can add ditto's pubkey to the user's trusted providers and then I can display the same info you have on Amethyst.

And maybe one day Ditto can rely on other service providers as well.

@alexgleason
Copy link
Member

alexgleason commented Oct 11, 2024

I think kind 30078 should be extended, to require a third parameter of the d-tag, "p", like this:

["d", "<pubkey>", "p"]

And then a p-tag with a matching pubkey is also required or else validation fails. Same with "e", "r", etc. This way you can also p-tag query them, and it enforces the type of the "d" tag.

I think this should be a general rule for d-tags whose value references another common type of tag.

EDIT: See #1536

Copy link
Member

@pablof7z pablof7z left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 on the idea; I think something like this is useful.

I don't think this should include the WoT stuff; that's a cheap and subjective calculation that belongs in the client; all indications of an absolute-ish WoT score are pervasive − even if here it's presented as "WoT from the point of view of the service provider" -- it will lead to misunderstandings and misuse.

ACK

@vitorpamplona
Copy link
Collaborator Author

that's a cheap and subjective calculation that belongs in the client

Are you referring to the follows of follows set of keys that everyone calls web of trust in Nostr? If so yes, that is cheap, but that is not WoT in my mind. My hope for the WoT is to do a full graph analysis of all keys and iteratively assemble a score for each pubkey from a global perspective. I don't think that can be done in the client.

And again, that does not replace any other approach, neither simpler nor more complex, for WoT calculations. It just offers a base layer that will likely be whatever algorithm the provider wants to make. We will have a competition for the best WoT providers out there.

@pablof7z
Copy link
Member

that's a cheap and subjective calculation that belongs in the client

My hope for the WoT is to do a full graph analysis of all keys and iteratively assemble a score for each pubkey from a global perspective.

You lost me at global. 😂

I wouldn't call that WoT, the nature of WoT implies that it would be from someone's perspective, I'd say a "global WoT" is an oxymoron.

Anyways, this is beside the point of this PR and I don't want to derail the conversation.

Are you working on implementing one of these services?

@vitorpamplona
Copy link
Collaborator Author

vitorpamplona commented Oct 12, 2024

I wouldn't call that WoT, the nature of WoT implies that it would be from someone's perspective, I'd say a "global WoT" is an oxymoron.

Makes sense. We can call it rank or something else.

Are you working on implementing one of these services?

Yes, but I don't really want to. I don't really want to run any services at all. I find these decisions (when the app also runs the service) extremely centralizing in the long run.

If anyone puts a service like this, I will completely shutdown mine.

@nostrband
Copy link
Collaborator

Created wss://nip85.nostr.band and uploaded 30382 by "4fd5e210530e4f6b2cb083795834bfe5108324f1ed9f00ab73b9e8fcfe5f12fe" with "rank" scores (instead of "wot"). Let me know if that looks good.

- Adds relay hints for base events. 
- Adds private list options
- Adds kind to the list-tag settings
explains kind:tag in the trusted service lists.
@manimejia
Copy link

We DO need a NIP for clients to retrieve 'on-demand' rankings of users and content from trusted sources, but these values will ALSO need to be 'relative' to the pubkey of the client user (the network observer). With a couple tweaks, I believe this NIP could be perfect for publishing Assertion events with such an 'observer' relationship. @nostrband @vitorpamplona @pablof7z

To indicate this 'observer' relationship, a kind 30382 Assertion event COULD optionally include a delegation tag, used in the same manner as NIP 26

The argument is such : If a signed kind 10040 Authorization event specifies that the service provider is "trusted" by an end user to provide calculated content, then (for certain calculations) these kind 30382 Assertion events ARE in effect 'delegated' content that is signed by the service provider on BEHALF of the end user. If a kind 30382 event includes such a tag, then it SHOULD be treated as content having this relationship.

ALSO : To be clear, if an Assertion event is published in this manner, then the value of "d" tag would need to reflect this relationship. So... "d" == "p" as suggested by @alexgleason would NOT always work for kind 30382 events.

["p", "e88a691e98d9987c964521dff60025f60700378a4879180dcbbb4a5027850411", "<user-home-relay-url>"], // relay hints to find the user
["rank", "89"],
["zap_amt_sent", "1000000"],
],

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

["delegation", "4fd5e210530e4f6b2cb083795834bfe5108324f1ed9f00ab73b9e8fcfe5f12fe"], // publish this assertion on 'behalf' of another pubkey ... as for 'relative' ranks of user and content

| name | kind | `d` tag value | result tags |
| ----------------------- | ----- | ------------- | ----------------------------------- |
| Follower Count | 30382 | pubkey | `"followers"` (int) |
| User Rank | 30382 | pubkey | `"rank"` (int, normalized 0-100) |

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Absolute ranks are pointless. Relative ranks will require "d" tag to reflect the ID of 'observer' AS WELL as 'subject'.

Copy link
Collaborator Author

@vitorpamplona vitorpamplona Oct 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the relative rank should be made via a DVM, where there is a request/response that facilitates creating each pair that matters. Otherwise, generating ranks for every pair of public keys in Nostr will take a huge processing power.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree with @vitorpamplona

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

generating ranks for every pairs of public keys in Nostr will take a huge processing power.

No. Ranking services won't have to calculate "Every pair of public keys" on Nostr.

  • Services will only calculate "subject" pubkeys for an "observer" who "trusts" and authorizes (and subscribes to?) the service.

  • Services will (presumably) cache rankings for each "subscribed" observer.

  • Clients and services only need to handle rankings for ONE "observer" (client user) per session.

In the end... this is no additional work for the client ... and services providers can "optionally" provide relative (observer centric) rankings or not.

@mikedilger
Copy link
Contributor

+1 for this NIP.

The list of names should be open enough to include all of our disparate ideas. We have different ideas about what WoT means... just add multiple names for each different algorithm people are actually implementing. So I don't think fighting over which ones are in that list makes any sense, just add more as we make up more, and deprecate ones that nobody ended up using.

@mikedilger
Copy link
Contributor

We DO need a NIP for clients to retrieve 'on-demand' rankings of users and content from trusted sources, but these values will ALSO need to be 'relative' to the pubkey of the client user (the network observer). With a couple tweaks, I believe this NIP could be perfect for publishing Assertion events with such an 'observer' relationship. @nostrband @vitorpamplona @pablof7z

To indicate this 'observer' relationship, a kind 30382 Assertion event COULD optionally include a delegation tag, used in the same manner as NIP 26

The argument is such : If a signed kind 10040 Authorization event specifies that the service provider is "trusted" by an end user to provide calculated content, then (for certain calculations) these kind 30382 Assertion events ARE in effect 'delegated' content that is signed by the service provider on BEHALF of the end user. If a kind 30382 event includes such a tag, then it SHOULD be treated as content having this relationship.

ALSO : To be clear, if an Assertion event is published in this manner, then the value of "d" tag would need to reflect this relationship. So... "d" == "p" as suggested by @alexgleason would NOT always work for kind 30382 events.

I hard disagree. It means instead the following: "Hey Mr nostr client that I am currently using, please get this data from the service I specified". It doesn't mean the service can sign on your behalf. At all.

@mikedilger
Copy link
Contributor

I would change the name of this PR to something more like "Data Aggregation". The fact that someone publishes an event that says "I accept the values this relay is giving me" is the smaller part of this... the larger part is the data being published.

@wds4
Copy link

wds4 commented Jan 30, 2025

I’ve done a test run of kind 30382 Trusted Attestations, all authored by me (pk: e5272de914bd301755c439b88e6959a43c9d2664831f093c51e9c799a16a102f), all published to wss://relay.hasenpfeffr.com, with these scores:

  • rank which is the GrapeRank influence score * 100 so it goes from 0 to 100 to conform with the tags as outlined in this NIP
  • personalized_grapeRank, the GrapeRank influence score which ranges from 0 to 1
  • personalized_pageRank calculated using the neo4j graph data science library as discussed here
  • dos, which means degrees of separation by follows.

I've included all pubkeys with a nonzero GrapeRank score which comes to about 88k events for this run.

There are various other scores I can include, including followers count (only includes pubkeys in your extended Follows Network so excludes thousands of spam accounts for many users) and any of the other scores you see at the grapevine-brainstorm profile page.

I haven't yet pushed the changes but when it's ready then anybody will be able to go to https://grapevine-brainstorm.vercel.app, generate personalized WoT scores and publish their own personalized batch of Trusted Attestations.

Here's an example event:

{
  "content": "",
  "created_at": 1738210377,
  "id": "3431811827570478883de44b9cd453995c4cc9ce5a0a6d6745a243d9e8a9f14b",
  "kind": 30382,
  "pubkey": "e5272de914bd301755c439b88e6959a43c9d2664831f093c51e9c799a16a102f",
  "sig": "7fe2f78e32db378c747d05480b1a5b142da77f31532b930a4729c59da043ae64c991436abc788569ffe78975fee6cb69ed4cbbfb4228c7748b3246399a8064e4",
  "tags": [
    [
      "d",
      "82341f882b6eabcd2ba7f1ef90aad961cf074af15b9ef44a09f9d2a8fbfbe6a2"
    ],
    [
      "rank",
      "99"
    ],
    [
      "personalized_grapeRank",
      "0.9913"
    ],
    [
      "personalized_pageRank",
      "0.002083"
    ],
    [
      "dos",
      "1"
    ]
  ]
}

If there's enough interest in using these Trusted Attestations then I could easily set up a schedule to refresh them on a periodic basis. (Daily would be no problem.)

@vitorpamplona
Copy link
Collaborator Author

Ohh this is super interesting. Will you be generating new keys for each algorithm? In that way a user could have Grapevine and Pagerank as two keys they could choose in the app. In that way the entire set can also be easily deleted when updating it. The only issue is that for clients, the user will need to know the pubkeys of each algo. 🤔

@vitorpamplona
Copy link
Collaborator Author

Hum.. on a second thought, managing multiple keys will be a mess. We might as well just have different standard tag names for different algos.

@wds4
Copy link

wds4 commented Jan 30, 2025

Hum.. on a second thought, managing multiple keys will be a mess. We might as well just have different standard tag names for different algos.

Yup I agree: different tag names for different algos is probably the way to go.

GrapeRank is designed to be contextual, and to have a string field to represent the context, which could be a human readable string (e.g. "genericTrust") or not (e.g. it could be a note id, naddr, something that points to some more complex data object). So far, I've only done a single GrapeRank context and I haven't assigned it a string bc there are no other scores to distinguish it from yet, but if I were forced to do so it would be "verified real nostr user" or "notSpam" or something like that.

When I do start to produce contextual GrapeRank scores, I'll have to figure out how to craft the tag. Maybe personalized_grapeRank_. I imagine I'll wait and see how you and other devs utilize the generic trust scores and go from there.

@wds4
Copy link

wds4 commented Jan 30, 2025

Ohh this is super interesting. Will you be generating new keys for each algorithm? In that way a user could have Grapevine and Pagerank as two keys they could choose in the app. In that way the entire set can also be easily deleted when updating it. The only issue is that for clients, the user will need to know the pubkeys of each algo. 🤔

Given that each user produces on the order of almost 100k events for these scores and that that number will grow as nostr grows, I worry about flooding nostr with all those events. I can imagine storing them on a specialized relay; either your own personal WoT relay or a third party service. Each user could designate a relay contains those events. Maybe modify NIP-65 with a special tag so you can point to your Trusted Assertions relay in a kind 10002 event? Something to think about.

For now, I'll plan on storing all of them in my own relay: wss://relay.hasenpfeffr.com.

@wds4
Copy link

wds4 commented Feb 1, 2025

Following this NIP I am declaring the Trusted Service Provider as a kind 10040 note. The following is an example:

{
  "content": "",
  "created_at": 1738373640,
  "id": "8b3e9195bc6bab9ca1c8b47e7588524f2cf1e18c932a869b9110c691be879d57",
  "kind": 10040,
  "pubkey": "e5272de914bd301755c439b88e6959a43c9d2664831f093c51e9c799a16a102f",
  "sig": "af7943122751e7bb344b75229f8590ca54284c1e63ea5e8c246286d803af66ba9cfbb525c48448dd4e7fb2154dad992b6d47328e77de357a4542c8d886c8a5ef",
  "tags": [
    [
      "30382:rank",
      "e5272de914bd301755c439b88e6959a43c9d2664831f093c51e9c799a16a102f",
      "wss://relay.hasenpfeffr.com"
    ],
    [
      "30382:personalized_grapeRank",
      "e5272de914bd301755c439b88e6959a43c9d2664831f093c51e9c799a16a102f",
      "wss://relay.hasenpfeffr.com"
    ],
    [
      "30382:personalized_pageRank",
      "e5272de914bd301755c439b88e6959a43c9d2664831f093c51e9c799a16a102f",
      "wss://relay.hasenpfeffr.com"
    ],
    [
      "30382:dos",
      "e5272de914bd301755c439b88e6959a43c9d2664831f093c51e9c799a16a102f",
      "wss://relay.hasenpfeffr.com"
    ]
  ]
}

The initial plan is for Trusted Assertions to be self-published, as indicated in the above example, where the TSP and the event author are the same. Hopefully in the near future, I'll create a service to play the role of Trusted Service Provider which will automatically update Trusted Assertions on some sort of schedule.

Longer term, my plan is to build personalized WoT relays with personalized Trusted Service Provider capability, among other things.

@wds4
Copy link

wds4 commented Feb 10, 2025

Looks like poster.place is using kind 30382 notes to record captcha. Here is a sample note.

@franzaps
Copy link
Contributor

After we launched Vertex there was a bit of debate around NIP-85 vs web of trust DVMs, on nostr socials and here, so I'm going to give our view of how they compare.

From previous discussion on here it's clear that precomputing Personalized Pagerank is not ideal as it scales as n^2.

I think the relative rank should be made via a DVM, where there is a request/response that facilitates creating each pair that matters. Otherwise, generating ranks for every pair of public keys in Nostr will take a huge processing power. – @vitorpamplona

We are left with "global", which as Pablo has said is an oxymoron in nostr, and far from ideal in practice as influencers and bots get a disproportionate amount of rank. So this is the first downside of NIP-85 for web of trust.

I will break down the different use-cases below and try to replicate these DVMs using NIP-85. Please correct me if I made any mistakes.

A general observation is that for NIP-85 a significantly larger amount of events need to have their signatures verified in the client, which may be taxing to low power devices.

VerifyReputation

  • Scour all contact lists for p tags that contain the target in order to build the target followers list (one could start querying 1-2 hops from the source but that would leave out a portion of the network, and the problem gets worse as nostr grows)
  • Query for kind 30382 events with d tag of followers + target itself
  • Sort events by rank and return top X followers and target

RecommendFollows

The process would be similar to VerifyReputation but more expensive as the first hop (direct follows) have to be removed, and do 3-4 hops to get decent results.

SortAuthors

This is the most straightforward, as a limited amount of pubkeys is provided by the client.

  • Query for kind 30382 events with d tag of authors
  • Sort events by rank and return top X authors

All of these DVMs require one event for the request and one event as response. We are also working on a SearchProfile DVM to search for profiles and get them sorted by rank, again in one call. We also might send the kind 0s on the same socket if required.

@wds4
Copy link

wds4 commented Feb 14, 2025

We are left with "global", which as Pablo has said is an oxymoron in nostr, and far from ideal in practice as influencers and bots get a disproportionate amount of rank. So this is the first downside of NIP-85 for web of trust.

My published NIP-85 scores are personalized, not global.

@wds4
Copy link

wds4 commented Feb 14, 2025

A general observation is that for NIP-85 a significantly larger amount of events need to have their signatures verified in the client, which may be taxing to low power devices.

For use cases where a huge number of scores will be needed, then you can make an argument that it makes sense to package lots of scores into one event, to avoid the problem you mention. And a WoT DVM could be a good answer to that.

We should avoid the mindset that there is a competition between Trusted Assertions and WoT DVMs. My current stance is that we need both. The question is not which is better in an absolute sense. The questions are these: what are the tradeoffs to each approach; and what are the scenarios where we should use one approach as opposed to the other.

@wds4
Copy link

wds4 commented Feb 14, 2025

From previous discussion on here it's clear that precomputing Personalized Pagerank is not ideal as it scales as n^2.

I'm currently building a personalized WoT relay (strfry + neo4j graph database) that will precompute personalized PageRank (to be followed soon by other scores, like personalized graperank) periodically. Could be once an hour, whatever. Could also recompute in response to some event that would trigger a significant change in a high profile trust score.

In the context of personalized WoT relays, storing precomputed personalized trust scores locally using something like NIP-85 makes a lots of sense to me.

Now that I think about it, personalized WoT relays could ALSO offer access to scores via a WoT DVM. Why not both?

@vitorpamplona
Copy link
Collaborator Author

Now that I think about it, personalized WoT relays could ALSO offer access to scores via a WoT DVM. Why not both?

I always assumed that calculating WoT for a given pubkey on-demand would take too long. Is that true? If so, can NIP-85 be seen as a cache for the DVMs?

On the content DVMs, Users don't wait more than 2 seconds for a DVM to return. If it takes more than that they already think it is broken.

@franzaps
Copy link
Contributor

I always assumed that calculating WoT for a given pubkey on-demand would take too long. Is that true? If so, can NIP-85 be seen as a cache for the DVMs?

iirc our DVMs using Personalized Pagerank return in ~800ms on average, and we haven't started worrying about optimization or vertical scaling. To the point where we will also offer them via REQ filters.

Yes we could produce NIP-85 events for Global Pagerank maybe. WoT DVM responses can also be cached.

@wds4
Copy link

wds4 commented Feb 15, 2025

I always assumed that calculating WoT for a given pubkey on-demand would take too long. Is that true? If so, can NIP-85 be seen as a cache for the DVMs?
On the content DVMs, Users don't wait more than 2 seconds for a DVM to return. If it takes more than that they already think it is broken.

For now, I could probably provide personalized PageRank on demand, which means NIP-85 and WoT DVMs are both viable options; but personalized GrapeRank would take to long to calculate on demand, which means I either stick to NIP-85 or deliver a precalculated result through DVM. I could optimize GrapeRank to calculate it faster, but at a fundamental level I think we need to embrace the fact we can do some of the calculations on the fly some of the time, but we won't be able to do all of the calculations on the fly all of the time. Which means we may as well go ahead and embrace the NIP-85 method.

But here's something I like better about the WoT DVM method: suppose I want to sell my WoT data for a few sats. For that use case, the NIP-85 method won't work.

We need both methods.

@franzaps
Copy link
Contributor

Nothing stopping you from returning slightly stale data from your DVM as well. We could add a freshness timestamp or similar if necessary.

@cypherhoodlum
Copy link
Contributor

I always assumed that calculating WoT for a given pubkey on-demand would take too long. Is that true?

We're using mmalmi's nostr-social-graph to cache the WoT on the unreleased Nestr client so on-demand scores become trivial to calculate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.