A universal web-of-trust reputation protocol on Nostr. UniWoT.

[brainspacer]

A universal relative web-of-trust reputation protocol on Nostr. UniWoT.
https://github.com/brainspacer/nips/blob/master/55.md

Authors: @brainspacer, @distbit0

Overview

Reputation is multi-dimensional and sharding can be implemented to allow relays to handle specific dimensions of reputation, achieving load balancing and increased federation/censorship resistance. A more general reputation model can be used, denoted by Category, Dimension, and Scale. Each reputation rating is given in a single event, including the elements ratedID, raterID, category, dimension and scale (refer to the spec below for further details). This allows for a greater range of reputation use cases and increased adoption. Use cases include whitelisting and blacklisting and many more. Additionally, external reputation ratings can be recognised by Nostr, thereby enabling it to overcome any network effects of existing silos of reputation data.

—-

As some earlier nostr reputation models have proposed, reputation is multi-dimensional and different clients will be interested in different reputation dimensions.

Here are a few issues that I suggest pertain to the proposals so far:

• Sharding is not easily facilitated with the above reputation model - leading to relay bloat and fewer opportunities to load-balance and achieve improved federation/censorship resistance.
• The comment in the ‘content’ field has to be general in nature because it does not pertain to a specific dimension of reputation.
• The reputation model proposed above narrowly defines a reputation model, which may limit adoption and its applicability to a more general set of use cases. For example, there might be a myriad of distinctions in how one would rate someone as a good ‘judge’.
• In-protocol blacklist and whitelist may be better facilitated with separate events that specify the context of the blacklist/whitelist. And separate events could better support explicit replication of any reputation types another relay may be interested in, including whitelists/blacklists.
• There is no manner to recognise ratings where the rater does not have a Nostr public key (i.e. can’t recognise/import ratings from outside of Nostr)
• There is no manner to recognise ratings where the rated does not have a Nostr public key (i.e. can’t rate entities from outside of Nostr)

Given reputation will become progressively important in many apps that employ Nostr and in general, it warrants thought to address the above issues. Additionally, apps outside of social media will be vectors for Nostr adoption because they can also employ Nostr-based reputation. My thoughts on all this and how to implement it are laid out below.

Sharding

The earlier proposals rely on relays storing the full reputation from one user to another user (in the set of tags in a single Nostr event). There is a way to shard reputations and thus allow a relay to handle select dimensions of reputation.

A more ideal setup could be that relays can specialise in handling dimensions of reputation that they are interested in/incentivised to handle. This enables load balancing and sharding. This also facilitates selected replication and further federation/censorship resistance via the selected replication model described in the discussion here ==> https://github.com/Cameri/Nostream/issues/41.

Import existing external ratings

For ratings where the rater does not have a Nostr public key (i.e. where the rating is outside of Nostr) to be expressed as a Nostr rating, this will require the ability for the Nostr rating event to specify the non-Nostr rater identifier and also to include the proof of the rating that is external to Nostr.

A separate NIP will describe how to achieve recognition of external ratings within Nostr. This post describes a reputation rating scheme NIP contained to ensure ‘remote ratings’ are not locked out from being incorporated into Nostr at some future time - by including in this spec the additional elements of Informant, RaterID, ProofType and ExternalRatingProof.

The benefit for Nostr in being able to import external ratings is to overcome the network effect of ratings stored in external systems. Therefore, if any Nostr users/communities are interested in reputation data, it can be made available in-protocol irrespective of origin.

Reputation importers can specialise in importing reputation to Nostr and are trusted to not DoS clients, which allows for network and computationally intensive external reputation proofs to be verified by clients.

Clients can also opt to only verify proofs of ratings which their trusted reputation importers disagree on, thereby significantly reducing client-side computational load.

Reputation importers can determine which ratings to import based on which external entities their users/subscribers trust and hence which external ratings their users/subscribers care about. This takes the burden of verifying external ratings in order to prevent clients being DoS'd, off of relays, and places it on specialised, incentivised reputation importers.

Examples might include the following:

• Proof X follows Y on Twitter
• Proof X has accepted pull requests from Y on github
• Proof X has rated Y business on trip advisor
• Proof X is in DAO Y’s multisig
• Proof X rated Y w/ five stars on localbitcoins
• (also, see the section below regarding future possible relay-side proof verification)

How to implement

Reputation can be denoted by not just a single reputation dimension (e.g. “judge” or “driver” in the earlier proposals) but can be more generally denoted using the following data structure:

Element	Description	Nostr Implementation
Rater	For Nostr-native ratings, this is the rater’s pubkey. For external ratings, this is the external identifier.	Tag ‘w’
Rated	This holds the rated party’s ID. Sometimes, this will be a Nostr pubkey and sometimes not. Nostr-native ratings: It will be a Nostr pubkey when the rated is a known Nostr pubkey. It will be a non-Nostr identifier where the rated party does not have a Nostr pubkey. E.g. when rating the Fed. :) Imported external ratings: It will be a non-Nostr identifier for imported external ratings.	Tag ‘p’
Dimension	akin to the tags in the example given in the earlier proposals	Tag ‘y’
Category	Used to categorise Dimensions and allow re-use of Dimensions in different contexts and thus differentiate different uses of a given Dimension. For example, if someone is deemed a good “judge” of others in the field of, say, Austrian economics, that same good judgement may not apply in the field of, say, orchid gardening. Category allows for ratings to be filtered (by clients or relays) for more than one purpose and allows for applications to more flexibly share and reuse ratings.	Tag ‘x’
Scale	Could be -1 to 1, say, and thus support positive and negative ratings - similar to the earlier proposals.	Tag ‘scale’
Comment (optional)	Used to optionally provide supporting text.	event.content
Expiration timestamp (optional)	This allows reputation events to be used as time-limited accreditations.	Tag ‘expiration’
RatingProofType	Indicates the method by which proof of the rating can be achieved. For example, ‘Type 2 = check that external rater has contributed to a Github project.’ Inextricably related to the Nostr rating’s Dimension. Type 1 = internal Nostr rating.	Tag ‘rateprooftype’
ExternalRatingProof	(conditionally required, depending on Rating Proof Type) This field is required for any external rating. May be a URL. Will be described more fully in an upcoming NIP to allow external proofs.	Tag ‘exrateproof’
Informant	Given this scheme supports Nostr recognising external ratings, the informant will be the Nostr pubkey who creates the Nostr record. This is not necessarily the rater.	event.pubkey
Whitelisted/blacklisted IP address		Tag ‘p’

Private ratings

A user may wish to maintain a list of ratings which are private. To achieve this, some elements of a rating can be encrypted, such as the following:

• Scale. With Scale encrypted, others may see that a user has rated someone in a certain dimension, but are unable to see whether that is a positive or negative rating.
• Comment. Any comment fields can be hidden to other users.
• RatedID. The identity of the rated entity can be hidden to other users.

A user may also encrypt other elements of the rating, such as Category and Dimension to hide more elements of the rating. However, this may pose issues including the following:

• Relays may selectively accept (or reject) certain ratings based on Category and Dimension and therefore this may limit a user’s ability to store such ratings.
• Selective replication (as described in the discussion https://github.com/Cameri/Nostream/issues/41) may not replicate such ratings given they are not able to identify the Category or Dimension.
• Allow certain fields to be encrypted either with pub key of recipient or of sender for both purposes of:
  • Making rating of someone which you do not want others to be able to see unless recipient chooses to share
  • Various attestations (which are more general than just ratings)

Encrypted fields can be prefixed with, say, “##:” to indicate it is encrypted.

One reputation rating per event. Examples - see NIP-55. 55.md file

Reason for single-letter tag names for some rating elements

The reason for using single-letter tag names (such as ‘x’, ‘y’, category, dimension, respectively) is to allow for relay-side queries on reputation events, given Nostr’s current design where only single-letter tags are queryable (NIP-12 Generic Tag Queries). Efficient reputation event queries are important now to allow clients to select only reputation events they are interested in. Also, this better supports the future selective replication model linked above (https://github.com/Cameri/Nostream/issues/41) given the selective reputation relies on relay-side filtering.

Regarding tag ‘expiration’, we understand caution may be in order because NIP-40 Expiration Timestamp is not currently implemented widely by relays. The side effect if NIP-40 has not been implemented by a relay is that an expired reputation (accreditation) event will continue to be propagated. From a functional perspective for reputation (accreditation) purposes, this is not an issue so long as clients check for expiration. However, this could result in DoS of clients if some ratings are expired and renewed very frequently. Ideally, ‘expiration’ should be supported by the relay.

NIP

The specification in this post requires no relay development and is currently supported by existing Nostr relays.This data type specification is described in the proposed update to the draft NIP in the heading Reputation Datatype NIP below.

Future related extensions

The reputation datatype scheme described in this post enables future NIP possibilities, as follows:

• **Relative trust score calculation: **A future relay NIP can be drafted that employs the above reputation scheme to calculate a relative trust score for an entity. This future NIP would define the weighting, scoring and calculation of the relative reputation score of one entity in relation to another entity for a specified Dimension or Category.

  For example, for a given Dimension, the relative trust score calculated for someone is low the more distant they are from me. And someone who is close to my web of trust will have a low relative trust score if they are rated poorly by others I trust highly.

  This potential future NIP is not drafted here and will require community input to define the scoring calculation.

• Richer tag queries and symmetric difference set handling: Nostr relays currently support queries on tags (NIP-12 Generic Tag Queries), but these are limited to OR operations. To best support the selective replication by custom clients described in the linked discussion (https://github.com/Cameri/Nostream/issues/41), it will be useful to add support for AND operations on tag queries. And symmetric difference set handling, using devices such as RSA accumulators as described in the linked discussion ...issues/41. And eventually add support for a generalised relay-side rich query facility.

  Potential NIPs for these future possibilities are not drafted here.

• Support for multiple hashtags per rating. The primary advantage of being able to add multiple hashtags to a rating would be that said rating would be more easily filtered/searched, allowing both clients and relays to more accurately discriminate between relevant and irrelevant ratings. This functionality however would necessitate a more flexible querying capability, as the current querying mechanism does not allow for queries to treat the contents of a tag as a list and apply an OR operator on the elements in the list.

  This potential future NIP is not drafted here.

• Rating non-Nostr entities

  The reputation model proposed in this post already supports the ability for Nostr ratings to be made for non-Nostr entities, which can later be linked to entities. e.g. I can auto endorse all my eBay sellers without them needing to be on Nostr reputation. When they join Nostr, they can auto claim these ratings by providing proof that they control said eBay account. This proof model to claim an ID has not been described here.

  This potential future NIP is not drafted here.

  ~~ ~~

• Web3/evm compatibility

  Create a Nostr reputation on-chain oracle to prove that a rating does not exist between two parties, or attest the rating score of one party from another's perspective.

  The specification for this facility is not further defined here.

Use cases

This proposal enables a (relative) web of trust with sharding, selective replication, improved load balancing and improved federation/censorship resistance.

This can be used by Nostr apps, increasing the utility of those Nostr apps and therefore promoting Nostr adoption.

In addition, this permits in-protocol registration of whitelist and blacklist PKs and IPs, thus facilitating replication of blacklists/whitelists amongst relays (as per the selective replication mechanism described in the linked discussion …issues/41).

As may be apparent by several of the example events above, this reputation model can be also used by non-Nostr apps, therefore further promoting Nostr adoption. Wholly new use cases for Nostr are enabled, in-line with ‘notes and other stuff transmitted by relays.’

For further information, see the list of motivating examples of use cases in the updated NIP proposal below.

(The authors of this post are aware of at least two Nostr clients under development that employ the reputation model proposed in this post, and others that are currently being conceptualised. We are led to believe the clients under development will soon be made open-source and can act as a reference client to enable other clients to employ this reputation model described in this post.)

Incentive compatible

The reputation model described in this post enables an incentive compatible model for relays and custom replication clients to arise, whereby the events are selectively handled by sponsored relays according to their (community’s) areas of interest, achieving sharding. Incentive compatibility is critical for a network’s long-term viability. Also, the replication mechanism (...issues/41 linked above) can allow communities/clients to sponsor custom replication clients to perform the selective replication/sharding to/from the relays interested in the selective datasets.

[brainspacer]

Further reading:
https://github.com/WebOfTrustInfo/self-sovereign-identity/blob/master/Schutte-on-SSI.md
https://github.com/WebOfTrustInfo/rwot1-sf/blob/master/topics-and-advance-readings/Trust-Exchange-An-Architecture-for-a-Permanent-Open-Trust-Network.md
https://github.com/WebOfTrustInfo/rwot1-sf/blob/master/topics-and-advance-readings/Distributed-Trust-Systems-and-the-Kenyesian-Beauty-Contest.md
https://reaction.la/security/social_networking.html
https://roamresearch.com/#/app/EAAKL/page/0nfYFRK4u
https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/advance-readings/a-minimal-approach-to-linked-trust-with-uncertainty.md
https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/advance-readings/words-matter-a-rethink-of-current-terminology.md
https://github.com/trustgraph/trustgraph
https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/advance-readings/Multi-dimensional%20reputation%20systems%20using%20webs-of-trust.md
http://comboy.pl/wot.html
https://github.com/WebOfTrustInfo/rwot1-sf/blob/master/Five-Desired-WoT-Features.md
https://slides.com/mmalmi/identifi/fullscreen
https://makopool.com/fast_big_wot.html
https://github.com/WebOfTrustInfo/rwot1-sf/blob/master/topics-and-advance-readings/shared_terminology_for_digital_identity_systems.md
https://github.com/WebOfTrustInfo/rwot1-sf/blob/master/topics-and-advance-readings/DecentralizedCooperationNeedsDecentralizedReputation.md
https://github.com/WebOfTrustInfo/rwot1-sf/blob/master/topics-and-advance-readings/Web-of-Trust-with-Blockchain-IDs.md
https://docs.google.com/document/d/1DSHW8tEEWJrBXGtiwUjB5qTp6hxkFRWLKq_BJuzZkiE/export?format=html
https://github.com/WebOfTrustInfo/rwot1-sf/blob/master/topics-and-advance-readings/Key-revokation-of-lost-and-stolen-keys.md
https://cblgh.org/trustnet/
https://github.com/WebOfTrustInfo/rwot1-sf/blob/master/topics-and-advance-readings/advanced-web-of-trust-concepts.md
https://github.com/lapp0/Smart-Market
https://github.com/WebOfTrustInfo/rwot1-sf/blob/master/Principle-of-Relativity-for-WoT.md
https://github.com/WebOfTrustInfo/rwot1-sf/blob/master/topics-and-advance-readings/dealing_with_key_loss_in_digital_identity.md
https://github.com/WebOfTrustInfo/rwot1-sf/blob/master/topics-and-advance-readings/progressive-trust.md
https://github.com/WebOfTrustInfo/rwot1-sf/blob/master/topics-and-advance-readings/decentralized_e-commerce.md
https://gist.github.com/dionyziz/e3b296861175e0ebea4b
https://makopool.com/better_space_with_wots.html
https://github.com/WebOfTrustInfo/rwot1-sf/blob/master/topics-and-advance-readings/tensions-related-to-identity-and-community-regulation.md
https://github.com/WebOfTrustInfo/rwot1-sf/blob/master/topics-and-advance-readings/ReputationAndTheRealWorld.md
https://arxiv.org/abs/2208.11443
https://link.springer.com/content/pdf/10.1007/s10796-005-4807-3.pdf
https://lup.lub.lu.se/student-papers/record/9020253/file/9020270.pdf
https://web.cs.ucdavis.edu/~defigued/index_files/trustdavis.pdf

[fiatjaf]

How did you do this?

[distbit0]

Pasted from google doc 😅 @fiatjaf. Will replace all text w/ md instead 👍

[fiatjaf]

There is no need for that, although I do think some better formatting would help making this thing readable.

[brainspacer]

Formatting fixed.

[Giszmo]

Maybe you want to link https://github.com/brainspacer/nips/blob/master/55.md in your top post instead of pasting your soon to be outdated original suggestion there?

[Giszmo]

A markdown converter helped me with this:

Suggested change

<table>

<tr>

<td><strong>Element</strong>

</td>

<td><strong>Description</strong>

</td>

<td><strong>Nostr Implementation</strong>

</td>

</tr>

<tr>

<td>Rater

</td>

<td>For Nostr-native ratings, this is the rater’s pubkey. For external ratings, this is the external identifier.

</td>

<td>Tag ‘w’

</td>

</tr>

<tr>

<td>Rated

</td>

<td>This holds the rated party’s ID.

<p>

Sometimes, this will be a Nostr pubkey and sometimes not.

<p>

<strong>Nostr-native ratings:</strong>

<p>

It will be a Nostr pubkey when the rated is a known Nostr pubkey.

<p>

It will be a non-Nostr identifier where the rated party does not have a Nostr pubkey. E.g. when rating the Fed. :)

<p>

<strong>Imported external ratings:</strong>

<p>

It will be a non-Nostr identifier for imported external ratings.

</td>

<td>Tag ‘p’

</td>

</tr>

<tr>

<td>Dimension

</td>

<td>akin to the tags in the example given in the earlier proposals

</td>

<td>Tag ‘y’

</td>

</tr>

<tr>

<td>Category

</td>

<td>Used to categorise Dimensions and allow re-use of Dimensions in different contexts and thus differentiate different uses of a given Dimension.

<p>

For example, if someone is deemed a good “judge” of others in the field of, say, Austrian economics, that same good judgement may not apply in the field of, say, orchid gardening. Category allows for ratings to be filtered (by clients or relays) for more than one purpose and allows for applications to more flexibly share and reuse ratings.

</td>

<td>Tag ‘x’

</td>

</tr>

<tr>

<td>Scale

</td>

<td>Could be -1 to 1, say, and thus support positive and negative ratings - similar to the earlier proposals.

</td>

<td>Tag ‘scale’

</td>

</tr>

<tr>

<td>Comment

<p>

(optional)

</td>

<td>Used to optionally provide supporting text.

</td>

<td>event.content

</td>

</tr>

<tr>

<td>Expiration timestamp

<p>

(optional)

</td>

<td>This allows reputation events to be used as time-limited accreditations.

</td>

<td>Tag ‘expiration’

</td>

</tr>

<tr>

<td>RatingProofType

</td>

<td>Indicates the method by which proof of the rating can be achieved. For example, ‘Type 2 = check that external rater has contributed to a Github project.’ Inextricably related to the Nostr rating’s Dimension.

<p>

Type 1 = internal Nostr rating.

</td>

<td>Tag ‘rateprooftype’

</td>

</tr>

<tr>

<td>ExternalRatingProof

</td>

<td>(conditionally required, depending on Rating Proof Type)

<p>

This field is required for any external rating. May be a URL. Will be described more fully in an upcoming NIP to allow external proofs.

</td>

<td>Tag ‘exrateproof’

</td>

</tr>

<tr>

<td>Informant

</td>

<td>Given this scheme supports Nostr recognising external ratings, the informant will be the Nostr pubkey who creates the Nostr record. This is not necessarily the rater.

</td>

<td>event.pubkey

</td>

</tr>

<tr>

<td>Whitelisted/blacklisted IP address

</td>

<td>

</td>

<td>Tag ‘p’

</td>

</tr>

</table>

| **Element** | **Implementation** | **Description** |

|-------------|--------------------|-----------------|

| **Rater** | `"w"`-tag | For Nostr-native ratings, this is the rater’s pubkey. For external ratings, this is the external identifier. |

| **Rated** | `"p"`-tag | This holds the rated party’s ID.Sometimes, this will be a Nostr pubkey and sometimes not.Nostr-native ratings:It will be a Nostr pubkey when the rated is a known Nostr pubkey. It will be a non-Nostr identifier where the rated party does not have a Nostr pubkey. E.g. when rating the Fed. :)Imported external ratings:It will be a non-Nostr identifier for imported external ratings. |

| **Dimension** | `"y"`-tag | akin to the tags in the example given in the earlier proposals |

| **Category** | `"x"`-tag | Used to categorise Dimensions and allow re-use of Dimensions in different contexts and thus differentiate different uses of a given Dimension. For example, if someone is deemed a good “judge” of others in the field of, say, Austrian economics, that same good judgement may not apply in the field of, say, orchid gardening. Category allows for ratings to be filtered (by clients or relays) for more than one purpose and allows for applications to more flexibly share and reuse ratings. |

| **Scale** | `"scale"`-tag | Could be -1 to 1, say, and thus support positive and negative ratings - similar to the earlier proposals. |

| **Comment (optional)** | event.content | Used to optionally provide supporting text. |

| **Expiration timestamp (optional)** | `"expiration"`-tag | This allows reputation events to be used as time-limited accreditations. |

| **RatingProofType** | `"rateprooftype"`-tag | Indicates the method by which proof of the rating can be achieved. For example:<br>* `"1"`: internal Nostr rating.<br>* `"2"`: check that external rater has contributed to a Github project. Inextricably related to the Nostr rating’s Dimension. |

| **ExternalRatingProof** | `"exrateproof"`-tag | (conditionally required, depending on Rating Proof Type)This field is required for any external rating. May be a URL. Will be described more fully in an upcoming NIP to allow external proofs. |

| **Informant** | `event.pubkey` | Given this scheme supports Nostr recognising external ratings, the informant will be the Nostr pubkey who creates the Nostr record. This is not necessarily the rater. |

| **Whitelisted/blacklisted IP address** | `"p"`-tag | |

[Giszmo]

comes to mind ...

In that sense, if there is a claim about it being universal, you probably should also comment on what it fixes compared to other WoT implementations that aspire to be universal.

[Giszmo]

Reputation is something that might need updating, right? Maybe a replaceable (nip16) or parametrized replaceable (nip33) event kind would be better?

[Semisol]

Parameterized would be best. Also, sharding is not required

[Giszmo]

markdown quirk?

Suggested change

	##
	**Examples**
	## Examples

[Giszmo]

All tags are arrays of strings, not mixed type. Please fix not only here.

Suggested change

	["scale", 30]
	["scale", "30"]

[Giszmo]

// Nostr pubkey in this case.

Nothing else is allowed here.

Suggested change

	"pubkey": informant // Nostr pubkey in this case.
	"pubkey": <informant's pubkey>,

[Semisol]

Missing a comma maybe too?

[Giszmo]

Relays index single-letter tags but some don't index ratingprooftype or scale for example. As "scale" might be worth querying for a range which is not supported in nostr currently, that's ok to not be indexed but "ratingprooftype" I don't understand. By the sound of it, one might want to filter for it but your examples include either "nostr-native" which sounds like a default or you omitted the line so ... do we need it?

[Giszmo]

The nip is not prescriptive about the scale. It only wants it to be numeric but suggests -1 and 1. In other discussions we were exploring how to rate trustworthiness for example over multiple hops. If I trust you somewhat and you trust Alice 100%, I would trust Alice somewhat. To express this numerically, a fixed scale 1-100 or 0.0 to 1.0 would be nice.

[Giszmo]

The nip is a bit too long for my taste while lacking how "external proofs" could look like. The encrypted examples are also not very helpful.

[mikedilger]

I didn't read the NIP, I'm commenting on Giszmo's comment:

If I trust you somewhat and you trust Alice 100%, I would trust Alice somewhat.

Trust isn't transitive, at least not very much. If I trust you somewhat to not send spam, and you trust Alice 100% to not send spam, this says nothing about how much I trust Alice to not send spam... because it doesn't take into account how much I trust you to properly place trust in others.

[Giszmo]

@mikedilger turns out @brainspacer's nip has a solution for that: The nip allows you to store you how you judge others to report on others but we are going on a tangent here, as the nip at hands isn't talking about transitive ratings at all.

[Semisol]

because it doesn't take into account how much I trust you to properly place trust in others.

We could also include that. We could have it determined based off of the existing trust (constant or exponentially increasing with trust increasing, ...) or set it manually.
If I trust Alice 90% and I trust them 90% to properly place trust in others, and Alice trusts Bob 100% it would be

1 * // you trust yourself fully
0.9 * // trust in Alice
(0.9 * 1) // how much Alice trusts Bob, multiplied by how much I trust Alice to properly place trust
= 0.81

[ghost]

NACK

Blacklists have no place in a "censorship resistant" protocol particularly based on reputation system defined in this NIP.

[Giszmo]

Blacklists can and will be used by users and relays alike. Nostr's censorship resistance doesn't emerge out of everybody processing all messages ever. It emerges out of relays being redundant.

Users will want block lists and I want to know your block list to at least de-boost who you block, so having them public makes a lot of sense.

Not even the most wild-west relay on TOR will work without some kind of black- or white listing as storage/bandwidth is not free and infinite.

[ghost]

Blacklists can and will be used by users and relays alike. Nostr's censorship resistance doesn't emerge out of everybody processing all messages ever. It emerges out of relays being redundant.

No, they wont be used. Dont spam this repo with non sense.

[earonesty]

I want to be sure that Alice is Alice, so that when Bob zaps Alce, Bob's not not accidentally zapping Eve. Reputation is OK for this. But identity is also important.

The best way to do this is pubkey verification, perhaps using a bip-39 word set derived from Alices's pubkey.

Alice can verbally confirm a handful of words. Bob can verify. Bob can sign a verification of that wordset "verified by Bob". Then verifications can propagate as notes, and I can build up a WOT profile for all my contacts (Bob trusts Alice now, Alice trusts Carol, Bob can configure his client to show that as a partial trust). UX should not allow verification publishing without manual confirmation of at least 4 deterministic-randomly selected words, for example. This would prevent widespread "fake trust spam". UX should allow contacts to be "untrusted" (I'm sure this person lies and verifys people all the time for no good reason... ). UX can show purple checks next to people that are "very verified".

Maybe a special-case of a reputation system can be "identity verifications" that are published.

Reputation is a much broader concept than identity. (Maybe this person is who they say they are, but they're a scammer, for example). That speaks to more subjective stuff, and has nothing to do with "verification of a public key".

[nostronaut]

the proposal is a bit too verbose and subjective

we are trying to derive some initial scores in #419 that may be independently computed by users monitoring the network in real time, that have to do with publisher's consistency, rather than trust.

The WoT component comes second, and it is computed from the previous scores of consistent publishers interacting, cross-referencing each other in their event threads. The intuition being: referencing, responding to someone's event endorses it with one more signature over their previous event.

[brainspacer]

the proposal is a bit too verbose and subjective

we are trying to derive some initial scores in #419 that may be independently computed by users monitoring the network in real time, that have to do with publisher's consistency, rather than trust.

The WoT component comes second, and it is computed from the previous scores of consistent publishers interacting, cross-referencing each other in their event threads. The intuition being: referencing, responding to someone's event endorses it with one more signature over their previous event.

Noted, @nostronaut
Agreed - this NIP is too verbose as-is. We will revise it to contain its scope and to be more succinct - and remove the importing of reputation.
Regarding the requirement you mention for 'scoring' a publisher - that is a valid notion with respect to social media posts. The reputation model we're proposing in this NIP, however, is intended for being applied to not just social media, but to a number of other domains. For example, this includes contract performance, contract damages insurance, dispute resolution and a number of other related domains. It's all part of a master plan to enable actors in the Network State to interact without needing ever to rely on escalations to any nation state, with all its attendant corruptions, distortions, confiscatory tendencies, censoring tendencies etc. WOTs and multi-dimensional reputation ratings are key to enabling this. Nostr is potentially the ideal federated persistent state platform for this. This further realises the "and other stuff" remit of Nostr. We have a project in the making that employs all of this.

[Giszmo]

@brainspacer please consolidate the feedback above. This PR feels a bit abandoned as is.

[Giszmo]

Feel free to re-open this but no reply in two months ... looks abandoned.