Add files via upload

Universal relative web-of-trust reputation protocol on Nostr - UniWoT
This commit is contained in:
brainspacer 2023-01-28 19:50:31 +11:00 committed by GitHub
parent 3b1cd96798
commit f0d64d405c
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

437
55.md Normal file

@ -0,0 +1,437 @@
Universal relative web-of-trust reputation protocol on Nostr - UniWoT
Clients may submit and query reputation events denoted by kind=9400 and
that contain tags representing the reputation rating.
The reputation query mechanism relies on the existing NIP-12 Generic Tag
Queries.
This NIP is a data type definition and does not require any change to
relays.
A reputation definition comprises a dimension, category, scale, rater,
rated, comment and optionally an expiry date. Also, the elements
informant, ratingProofType and externalRatingProof will allow external
ratings to be recognised by Nostr (to be described in a future NIP).
Dimension = dimension of reputation. E.g. 'judge', 'creator',
'businessPartner', 'employee'. Stored in tag 'y'
Category = the dimension's context. E.g. 'politics', 'gardening',
'socialMedia', 'contract'. Stored in tag 'x'
Scale = -1 to +1, enabling positive and negative ratings. Stored in tag
'scale'
Comment = optional text comment provided by the rater to compliment the
reputation rating. Stored in event.content
Whitelisted/blacklisted IP address = tag 'p'.
Expiry Date = optional date of expiry of the reputation event. Stored in
the 'expiration' tag.
Apps can decide the categories and dimensions they wish to use. There is
no centrally-defined list of categories or dimensions. Other apps may
adopt or query reputation events made by other apps if they are
interesting to them. Clients may synthesise disparate reputations that
will enable wholly new use cases to emerge.
Regarding blacklist/whitelist registration. It is recognised that
blacklist/whitelist detection and management is a complex issue and
outside the scope of this NIP. The whitelist/blacklist tag is just to
bring such lists in-protocol, allow sharding and enable efficient
selective replication.
**Examples**
------------
// rate someone as a good judge of 'AustrianEcon' content
{
\"id\": \"\...\",
\"kind\": 9400,
"pubkey": informant // Nostr pubkey in this case.
\"tags\": \[
\[\"w\", raterID\], // Nostr pubkey in this case.
\[\"p\", ratedID\], // Nostr pubkey in this case.
\[\"ratingprooftype\", "1"\], // Nostr-native rating.
\[\"x\", "AustrianEcon"\],
\[\"y", "judge\"\],
\[\"scale\", 80\]
\],
\"content\": \"Paul follows a wide breadth of quite good Austrian econ
commentators.\"
}
// rate someone as a producer of 'AustrianEcon' content
{
\"id\": \"\...\",
\"kind\": 9400,
"pubkey": informant // Nostr pubkey in this case.
\"tags\": \[
\[\"w\", raterID\], // Nostr pubkey in this case.
\[\"p\", ratedID\], // Nostr pubkey in this case.
\[\"ratingprooftype\", "1"\], // Nostr-native rating.
\[\"x\", "AustrianEcon"\],
\[\"y", "blogger\"\],
\[\"scale\", -20\]
\],
\"content\": \"Paul's Austrian econ commentary is somewhat interesting
but not highly insightful.\"
}
// rate someone as a good judge of 'MilitaryAnalysis' content
{
\"id\": \"\...\",
\"kind\": 9400,
"pubkey": informant // Nostr pubkey in this case.
\"tags\": \[
\[\"w\", raterID\], // Nostr pubkey in this case.
\[\"p\", ratedID\], // Nostr pubkey in this case.
\[\"ratingprooftype\", "1"\], // Nostr-native rating.
\[\"x\", "MilitaryAnalysis"\],
\[\"y", "judge\"\],
\[\"scale\", 30\]
\],
\"content\": \"Paul follows a mixed bag of military analysts, some good,
some not so good.\"
}
// rate someone as a good producer of 'gardening / orchids' content
{
\"id\": \"\...\",
\"kind\": 9400,
"pubkey": informant // Nostr pubkey in this case.
\"tags\": \[
\[\"w\", raterID\], // Nostr pubkey in this case.
\[\"p\", ratedID\], // Nostr pubkey in this case.
\[\"ratingprooftype\", "1"\], // Nostr-native rating.
\[\"x\", "Gardening"\],
\[\"y", "orchids\"\],
\[\"scale\", 100\]
\],
\"content\": \"His series of first places in the national orchid growing
competitions 2019-2022 makes him an authority on this subject.\"
}
// declare someone as a paid subscriber to relay class XYZ
{
\"id\": \"\...\",
\"kind\": 9400,
"pubkey": informant // Nostr pubkey in this case.
\"tags\": \[
\[\"w\", raterID\], // Nostr pubkey in this case.
\[\"p\", ratedID\], // Nostr pubkey in this case.
\[\"x\", "PaidSubscriptionExpiry"\],
\[\"y", "XYZRelayAccess\"\],
\[\"expiration\", "3248923749287"\]
\]
}
// blacklist user from relay 'branle'
{
\"id\": \"\...\",
\"kind\": 9400,
"pubkey": informant // Nostr pubkey in this case.
\"tags\": \[
\[\"w\", raterID\], // Nostr pubkey in this case.
\[\"p\", ratedID\], // Nostr pubkey in this case.
\[\"x\", "branle"\],
\[\"y", "blacklist\"\]
\]
}
// blacklist IP from relay 'branle'
{
\"id\": \"\...\",
\"kind\": 9400,
"pubkey": informant // Nostr pubkey in this case.
\"tags\": \[
\[\"w\", raterID\], // Nostr pubkey in this case.
\[\"p\", blacklisted/whitelisted\_IP\_address\],
\[\"x\", "branle"\],
\[\"y", "blacklist\"\]
\]
}
// rate user in respect of their contractworhiness.
{
\"id\": \"\...\",
\"kind\": 9400,
"pubkey": informant // Nostr pubkey in this case.
\"tags\": \[
\[\"w\", raterID\], // Nostr pubkey in this case.
\[\"p\", ratedID\], // Nostr pubkey in this case.
\[\"ratingprooftype\", "1"\], // Nostr-native rating.
\[\"x\", "Contract"\],
\[\"y", "contractworthiness\"\],
\[\"scale\", 90\]
\],
\"content\": \"This entity has performed well as a trading partner.\"
}
// private rating
{
\"id\": \"\...\",
\"kind\": 9400,
"pubkey": informant // Nostr pubkey in this case.
\"tags\": \[
\[\"w\", raterID\], // Nostr pubkey in this case.
\[\"p\", encryptedRatedID\], // Nostr pubkey in this case.
\[\"ratingprooftype\", "1"\], // Nostr-native rating.
\[\"x\", "Gardening"\],
\[\"y", "orchids\"\],
\[\"scale\", encryptedScaleValue\]
\],
\"content\": encryptedComment
}
// private rating
{
\"id\": \"\...\",
\"kind\": 9400,
"pubkey": informant // Nostr pubkey in this case.
\"tags\": \[
\[\"w\", raterID\], // Nostr pubkey in this case.
\[\"p\", encryptedRatedID\], // Nostr pubkey in this case.
\[\"ratingprooftype\", "1"\], // Nostr-native rating.
\[\"x\", encryptedCategoryeValue\],
\[\"y", encryptedDimensioneValue\],
\[\"scale\", encryptedScaleValue\]
\],
\"content\": encryptedComment
}
// declare someone as an employee
{
\"id\": \"\...\",
\"kind\": 9400,
"pubkey": informant // Nostr pubkey in this case.
\"tags\": \[
\[\"w\", raterID\], // Nostr pubkey. Employer
\[\"p\", ratedID\], // Nostr pubkey. Employee.
\[\"x\", "employment"\],
\[\"y", "CEOrole\"\]
\]
}
**Suggested Use Cases**
-----------------------
Motivating examples for reputation events
- Allow an entity to rate other entities, thereby building a web of
> trust. Allow reputation ratings to be numerically scaled and to be
> positive or negative.
- Allow an entity to determine a trust score for entities outside
> their web of trust.
- Allow multi-dimensional reputation to be established in any domain,
> including social media, ride sharing, business partnership
> ratings, employment/employer ratings, DeFi lending, decentralised
> ratings agencies. More generally, enables a flexible mechanism of
> reputation to emerge.
- Social media app which automatically suggests content to a user
> using ratings automatically calculated from their existing web of
> trust ratings of other users
- Ride sharing app users to rate drivers and vice-versa.
- Marketplace platform to allow buyers and sellers to rate each other.
- Business partners to rate each others' contract performance in
> various dimensions.
- Decentralised finance lending platforms to permit lenders to
> nominate and rate trusted users so as to extend favourable lending
> terms, thus introducing a new model of DeFi lending in addition to
> the currently capital-inefficient over collateralised lending
> model.
- Bounty platform clients and service providers to rate each other in
> various dimensions so as to provide extra heuristics of reputation
> when choosing partners and negotiating contract terms.
- Employment listing platforms to provide the extra heuristics of
> reputation of both employees and employers in various dimensions
> to allow better decision-making for both parties.
- DeFi insurance providers to use an extra heuristic of reputation in
> determining an insured party's risk in calculating insurance
> premiums.
- Blacklist/whitelists: Any community (such as a Nostr client app, for
> example) or individual to register a user or an IP address on a
> specific blacklist or whitelist.
- Rating agency to rate entities. If one chooses to trust the rating
> agency, the rating agency's ratings then appear in their WoT.
- Attestations: allows an entity to declare a generalised attestation
> regarding another entity. e.g. effectively declare 'Bob is the CTO
> of Swan Bitcoin," via a proof provided by Swan Bitcoin.
- Allow an entity to issue an accreditation to another entity, with an
> optional time-limit.
- The above two examples largely intersect with the facility of
> soulbound tokens.
- And more.
- The motivating philosophy for this NIP is to better enable the
> decentralised economy via a flexible, extensible, relative
> web-of-trust reputation protocol, better manage spam and improve
> censorship resistance. This reputation model is conceptualised to
> enable organisations and individuals to establish and maintain
> their reputation as a valuable asset to facilitate interactions
> and seek favourable trading terms without involvement of third
> parties. This circumvents coercion by state actors, the censorship
> of the establishment financial system and dystopian WEF/UN ideals.
> A universal WoT reputation can be a key factor in enabling a
> global, pseudonymous economy. UniWoT.