Regarding complexity: the Grapevine as I envision it is VERY complex for the developer, but it can be made as simple for the user as we want it to be. The Grapevine has lots of parameters that users can adjust, and a common question will be when to give the user the option to adjust some parameter vs when to set some default value and hide it. Too many options can be overwhelming. But these parameters will be essential when the invariable sybil attacks and bad actors try to infiltrate your Grapevine. It will take some mad design skillz to know how to unveil some of these options when the time is right.

Regarding hierarchies: the long term plan will be that your Grapevine manages all hierarchies for you, unless you want to roll up your sleeves and dig into it yourself. Most users will not want to spend the time and effort editing hierarchies, UNLESS they want some category(ies) to exist that have not yet been submitted and placed into the hierarchy. In that case, many users will want to roll up their sleeves and get it done, but once the hierarchy is properly edited and a few users endorse the changes (assuming they’re reasonable), then the entire world will benefit from your work and no one will have to repeat it.

Reply to this note

Please Login to reply.

Discussion

Yes, I meant complexity for devs might make it hard to get traction (that's what nostr got right).

Have you written elsewhere about potential sybil attacks on a Grapevine? I'd like to understand what those parameters are and why they are needed.

If you go to the link in my bio and scroll down to more info, one of the links is to the Curated Lists Proof of Concept (url copied in this note below), and it has information on how some of the parameters work. All of the parameters can be thought of as having two extremes: the permissive extreme, for when sybils and bad actors are not a problem and you want as much input from as many users as possible, and the restrictive extreme, for when sybils and bad actors are a problem and you want to weed them out. And the first two (of many) parameters that users will discover are:

1. The default influence score for users about whom you have no information. The restrictive extreme is to give them an influence score of zero. In other words, you blacklist everyone who is not actively endorsed by your grapevine. The permissive extreme is to give everyone a high default influence score. In other words, you whitelist everyone except those who are identified by your grapevine as bad actors. There is scrollbar between these two extremes. Actually, two scrollbars: one for the default trust score and one for your confidence in that default score, which is 0 to 100 percent. Influence is the product of these two numbers: score * confidence. If your default trust score is assigned a low confidence, then it is easy for your grapevine to overcome the default; if high confidence, harder for your grapevine to overcome the default.

2. The attenuation factor, which is a parameter controlled by a scrollbar, between 0 (restrictive) and 1 (permissive). The issue is this: how many hops away do you let your grapevine extend? Most people pick a number of hops like maybe 2 or 3 or 4. But my solution is a gradual decrease, achieved by multiplying the confidence that YOU have in each trust attestation authored by someone other than you by the attenuation factor.

If you go to my desktop app: Pretty Good Apps, then go to Curated Lists app, you can play with the above parameters and watch the influence scores of each user change in real time, as shown in a table and as depicted graphically, where the radius of each user is proportional to that user’s influence. This is the app that nostr:npub1p2uwv7qme2u92y2qcpqqvafhkkqsxfrrnz8m79lm60v4005s7vuqnexr0s is rebuilding as a web app, because I want people, particularly devs, to be able to play around with these parameters and discover how the Grapevine works.

https://github.com/wds4/pretty-good/blob/main/appDescriptions/curatedLists/overview.md

The Grapevine is definitely complicated under the hood, but there’s a certain minimum complexity that is needed if we really want it to fly, and the fact that one self-taught dev (me) can build a working proof of concept shows that it can be done.

Think of it like an airplane. There’s a certain minimum degree of complexity that needs to be achieved if we want it to fly. Web of trust is the same way. But it’s absolutely doable.