Trusted pubkey sets

[franzaps]

A web of trust can be derived from NIP-02 follow lists, however, it's clear that follows do not necessarily imply trust.

I propose kind 30006 that consists of a list of trusted pubkeys (p tags) for a specific role (d tag).

{
  "id": "8f5518a7870135d8226b28df3a5496c55cc09bf5a34c2155824b73b5fb100a0a",
  "pubkey": "cfa399d0574c8501fcdabceca50df8f0a640c3ffd09e293999a72ee2057d87a5",
  "created_at": 1708750093,
  "kind": 30006,
  "tags": [
    [
      "d",
      "developer"
    ],
    [
      "p",
      "7a6f61e672934aa14ace7f9c36b32df064e4654bd403a6b9bda8903da5382fcc"
    ],
    [
      "p",
      "23af7285db45a46362bfb92b5e93ccfce300e473222f3bd5951ac3b5f4bf1625"
    ],
    [
      "p",
      "d3b9c758df5904cc44a0588ad264385cd893fb6dbbc077c66691c215a0fd9889"
    ]
  ],
  "content": "",
  "sig": "a0aaecd546ff0092af92518f6ceaeae68b9484eb534519f4c12b900fa8245fe70058471e152da8696e57f183cacf3278707a9f67fe26b60fa5835a4748ee927e"
}

Lists like the example above are very useful in the context of zap.store, which assists in the establishment of developer trust. A pubkey pointing to another via the developer role is more meaningful that a regular follow.

Thoughts?

[alexgleason]

I thought web of trust is based on follow lists. That's what makes it a "web" instead of a flat list.

[franzaps]

@alexgleason pubkey graphs are constructed from flat lists in both cases

[mterenzio]

Unclear what this adds above a kind 30000 Follow set

On Mon, Feb 12, 2024 at 11:12 AM Alex Gleason @.***> wrote:

I thought web of trust is based on follow lists. That's what makes it a "web" instead of a flat list.

— Reply to this email directly, view it on GitHub https://github.com/nostr-protocol/nips/issues/1039#issuecomment-1939020718, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAAWDXGQCZPG3UYR3BX2WDYTI5OZAVCNFSM6AAAAABDE7IAR2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZZGAZDANZRHA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[alexgleason]

You could also use NIP-32 to label users as "developer", etc.

You need a reason to trust the "web of trust" event, and the best solution we have (aside from whitelisting certain pubkeys in specific scenarios, which maybe this is?) is the follow list.

[vitorpamplona]

I truly don't like lists for Graph building.

I have been trying to do a Relationship Status event that describes the relationship between two keys and allow more tags to enhance the description of that relationship. My use case requires Private statuses, but we can open up to have public as well.

Public Status

{
  "kind": 30382,
  "tags": [
    ["d", "<randomUUID>"],
    ["n", "Clients"],
    ["p", "<pubkey>", "relay"],
    ["trust_level", "1"],
    ["nickname", "<My buddy>"],
    ["summary", "<Summary of the relationship>"]
  ],
  "content": "",
  // ...other fields
}

Private Status

{
  "kind": 30382,
  "tags": [
    ["d", "<randomUUID>"],
    ["n", "Clients"]
  ],
  "content": "<NIP-44 encrypted Stringified TAG-List(
    ["p", "<pubkey>", "relay"],
    ["nickname", "<My buddy>"],
    ["trust_level", "1"],
    ["summary", "<Summary of the relationship>"],
    ["nip82secret", "<secret used to decrypt medical data for this pubkey>"]
  )",
  // ...other fields
}

n puts them into lists. Filter by n downloads all relationships in that list.

[franzaps]

I want to emphasize that this proposed kind is exclusive to trusted pubkeys.

@alexgleason with NIP-32 I can indeed label someone as "developer" but that does not necessarily mean I trust them

@vitorpamplona that could work too, but potentially implies a ton of events. What's wrong with lists for graph building (vs standalone events)? You still get a list as a query response

[vitorpamplona]

@vitorpamplona that could work too, but potentially implies a ton of events. What's wrong with lists for graph building (vs standalone events)? You still get a list as a query response

The trade-off is:

1. Lists: Race conditions + force to download the entire list all the time at a smaller space footprint
2. Individual events: no race conditions + ability to use Nostr filters to partially download the parts of lists that might matter at a bigger space footprint.

If one of the edges of the graph is being updated frequently, 2 makes more sense. If the entire graph is updated, 1 makes more sense.

[franzaps]

@vitorpamplona Relays may remove older individual events, how do you deal with this? Chances of this happening with lists is lower as the timestamp gets refreshed with every modification

[vitorpamplona]

Yep, with unbound lists you will never know if they are complete. Multiple relays should solve the need for trusting the central point.

[vitorpamplona]

People can also add expiration to individual edges in the graph and use delete events that will make edges automatically disappear.

[staab]

I'm with @vitorpamplona on team NIP 32 or granular events.

Aside from that, I think there are use cases for this, but fewer than people think. WoT is very important, but in practice it will almost always be an implicit trust graph. Follows are explicit follow, but like you said don't necessarily indicate trust. Interpreting follows (or likes, replies, bookmarks, reviews, DMs, etc) as indications of trust is not 100% reliable in any case.

Obviously, explicit trust indicators would be preferable, but the problem with that is UX — users are never going to maintain abstract "trust" lists (unless they're huge nerds). An exception would be something like nostrocket, where the trust graph is core to the domain the user is working in. So that would be where something like this would fit in, but in pretty much every "social" case, trust is going to be derived from organic interactions like those I listed above.

[franzaps]

I'm with @vitorpamplona on team NIP 32 or granular events.

Yes, I can see the case for individual events

Aside from that, I think there are use cases for this, but fewer than people think. WoT is very important, but in practice it will almost always be an implicit trust graph. Follows are explicit follow, but like you said don't necessarily indicate trust. Interpreting follows (or likes, replies, bookmarks, reviews, DMs, etc) as indications of trust is not 100% reliable in any case.

Obviously, explicit trust indicators would be preferable, but the problem with that is UX — users are never going to maintain abstract "trust" lists (unless they're huge nerds). An exception would be something like nostrocket, where the trust graph is core to the domain the user is working in. So that would be where something like this would fit in, but in pretty much every "social" case, trust is going to be derived from organic interactions like those I listed above.

Agree with everything you're saying here. Similar to the nostrocket use-case, I'm expecting some zap.store users to be huge nerds. Even if a fraction of them maintain a developer trust list, this can be greatly beneficial overall.

Some developers who have expressed interest in nostr-signing their releases have mentioned they might use a separate keypair do to so (build systems and so on). Having a stronger vouch for this npub is extremely important as it must compensate for trust exponentially decreasing with more hops.

[fiatjaf]

My proposal is to have an event format like

{
  "id": "...",
  "kind": 38888,
  "tags": [
    ["d", "<pubkey-of-person-being-rated>"],
    ["honest", 97],
    ["judge", 90],
    ["driver", 25],
    ["any-other-category", 12]
  ],
  "content": "Paul is great person, but not good with cars."
}

Apps can decide which tags they will use. The basic ones most apps would care about are "honest" and "judge". "honest" means this is not a thief or scammer or whatever. "judge" means how much we trust their judgement of others, so we can inherit their judgements of others (and also someone that marks us as a good "judge" can inherit our judgements and also this next person's judgements, and so on).

[franzaps]

Apps can decide which tags they will use. The basic ones most apps would care about are "honest" and "judge". "honest" means this is not a thief or scammer or whatever. "judge" means how much we trust their judgement of others, so we can inherit their judgements of others (and also someone that marks us as a good "judge" can inherit our judgements and also this next person's judgements, and so on).

I think having all this nuance is not helpful. As @staab previously noted, most people are not going to be doing this. If we ask them to come up with adjectives (and points!) it's going to be even harder.

How do I, an external viewer, understand the trust between two pubkeys from an event like this? You used "honest" but maybe someone else uses "trustworthy" or "brother". It makes it very difficult. Transitive trust is also very complex.

IMO trust is so important that it should have a dedicated way of representing it. It should also be binary: do you trust this person for X or you don't?

[fiatjaf]

These adjectives would have to be standardized. This proposal is old and I hadn't thought about it since I wrote it. I guess it would be better to have different kinds or something for each.

But you are right, I think it's not a good time to think about it. I retract it.

[staab]

I actually like the judge% concept, it could be built as "delegate more WoT points to this person", which is a useful end-user concept.

[vitorpamplona]

IMO trust is so important that it should have a dedicated way of representing it. It should also be binary: do you trust this person for X or you don't?

Trust doesn't work like that. You trust people in topics or segments of topics. I trust @fiatjaf with the NIPs repo but not with health recommendations.

There is always a but in any trust statement.

Basics: https://en.wikipedia.org/wiki/Trust_metric

[vitorpamplona]

BTW, I am confident that trust information is something clients can automatically generate/refine based on user behavior while using the client. It's never going to be a UI option for users to set for each other pubkey. Even if binary, it's just too much work and it quickly gets outdated.

[fiatjaf]

but not with health recommendations.

outrageous, my health recommendations are the best.

[franzaps]

IMO trust is so important that it should have a dedicated way of representing it. It should also be binary: do you trust this person for X or you don't?

Trust doesn't work like that. You trust people in topics or segments of topics. I trust @fiatjaf with the NIPs repo but not with health recommendations.

Exactly, that's what I meant by "trust this person for X" (I should've said trust them on X?)

Obviously trust is not a binary metric. I guess my suggestion was to make binary representations of trust (on a certain topic) to simplify things, knowing that this wouldn't be the one and only deciding factor shown in the UI. Anyway let's include a tag for a trust level as suggested in your kind 30382 draft. (Can we make it better than this? 🙏 )

So, in terms of UX my idea is to present the user with a compact, compressed, high-level overview of the web of trust between them and the developer who signed the app they want to install. The ultimate trust decision is subjective, and that is the user choosing to install that application or not.

@vitorpamplona I'm curious about how you were thinking to generate/refine trust levels in the UX, can you share? I would eventually need to implement something like this. Would you be generating new 30382 events with an updated trust_level and calculating an average for a given pubkey?

[vitorpamplona]

I'm curious about how you were thinking to generate/refine trust levels in the UX, can you share?

The 30382 events set the groundwork for the bigger things. For instance, I can already turn Follows, and every person in every NIP-51 list, into 30382 events. Then I can label which ones the user had a chat with. Then Amethyst can track how many seconds you spend reading each pubkey's post or how fast replies go back and forth and add that to the same 30382 event. Then sum the number of reactions, the number of zaps, reports, mutes, Etc. A simple local emotional AI can capture the positiveness of each post/message, its main topics and that value can be a weighted factor in the "trust" number.

All of that in both in private and public events: that's why Clients are better than Relays in this, Clients can see the private stuff.

Essentially you start to assemble a graph with very sophisticated edge weights per topic.

[franzaps]

My use-case is much simpler (at least initially) but I see where you're going. Thanks for sharing.

Are you planning to send a PR for that NIP? I probably will start using/pushing it soon.

[vitorpamplona]

Are you planning to send a PR for that NIP?

Right here: https://github.com/nostr-protocol/nips/pull/761

Feel free to use it as a base and tweak it around for your needs.

[lez]

I posted an update to a web-of-trust NIP I'm working on: https://github.com/lez/nips/blob/master/77.md

It is a simple extensible way to express trust between people, plus a simple way to use this info in filters.

I'm trying to make it so that it's extensible for being used in more complex usecases, but keep it simple for simple usecases. So far tried to incorporate ideas from this thread + ideas talked about in https://njump.me/note1m69f00rzyqrgwlrcsx56dxr8572rj4psl6zqr0cpqwvjl83mfyrsugevgv

As always, any feedback is welcome!