mirror of
https://github.com/nostr-protocol/nips.git
synced 2025-03-29 03:02:07 +01:00
Create 52.md
Submission of initial draft. Actively seeking review and comments.
This commit is contained in:
neilck
GitHub
parent
d179cd9758
commit
9a10207655
143
52.md
Normal file
143
52.md
Normal file
@ -0,0 +1,143 @@
|
||||
|
||||
NIP-52
|
||||
======
|
||||
|
||||
Issued Claims
|
||||
-------------
|
||||
|
||||
`draft` `optional` `author:neilck`
|
||||
|
||||
This NIP is currently in draft, and review / comments are sought. May overlap with [NIP-32](https://github.com/nostr-protocol/nips/blob/39bfb2db32899dd2eb4a7c9a313f27103a18409b/32.md).
|
||||
|
||||
This NIP defines new event kinds for the issuing of claims.
|
||||
|
||||
It reserves two event kinds (30001, 1001) for immediate use.
|
||||
|
||||
- `30001 - issue claim`
|
||||
- `1001 - refresh claim request`
|
||||
|
||||
A issue claim event records what one user attests is true about another user.
|
||||
|
||||
## Kind 30001: Issue claim
|
||||
|
||||
Sent by a user acting as an issuer, submitting a claim about another user, the claim's subject.
|
||||
|
||||
```json
|
||||
{
|
||||
"id": <32-bytes lowercase hex-encoded sha256 of the the serialized event data>
|
||||
"pubkey": <32-bytes lowercase hex-encoded public key of the issuer>,
|
||||
"created_at": <unix timestamp in seconds>,
|
||||
"kind": 30001,
|
||||
"tags": [
|
||||
["p", <32-bytes hex of the subject's pubkey>, <recommended relay URL>],
|
||||
["d", <32-bytes hex of the subject's pubkey + claim type>],
|
||||
["claim_type", <optional string specifying claim type>],
|
||||
["is_maintained", <optional boolean, yes if refresh claim supported>]
|
||||
],
|
||||
"content": <claim data>,
|
||||
"sig": <64-bytes signature of the sha256 hash of the serialized event data, which is the same as the "id" field>
|
||||
}
|
||||
```
|
||||
|
||||
`"d" tag` is required as event is treated as a parameterized replaceable event [NIP-33](https://github.com/nostr-protocol/nips/blob/master/33.md). Issuers issuing more than one type of claim will need to append a claim type identifier to the subject's pubkey hex to prevent overwrites.
|
||||
|
||||
The p tag MUST contain exactly one entry, the pubkey of the claim's subject.
|
||||
|
||||
A relay MAY choose to honor claim key/value pairs in the event's tag.
|
||||
|
||||
Self-issued claims (issuer is the subject) is specifically allowed.
|
||||
|
||||
|
||||
## Kind 1001: Refresh Claim Request
|
||||
|
||||
A claim may change over time. This event allows a user to request the issuer submits an updated issue claim event for the same subject and claim_type.
|
||||
|
||||
```json
|
||||
{
|
||||
"id": <32-bytes lowercase hex-encoded sha256 of the the serialized event data>
|
||||
"pubkey": <32-bytes lowercase hex-encoded public key of the sender>,
|
||||
"created_at": <unix timestamp in seconds>,
|
||||
"kind": 1001,
|
||||
"tags": [
|
||||
["e", <original issue claim event-id>, <relay-url>]
|
||||
"sig": <64-bytes signature of the sha256 hash of the serialized event data, which is the same as the "id" field>
|
||||
}
|
||||
```
|
||||
|
||||
A client SHOULD check that the original event contains "is_maintained": true before sending event to relay
|
||||
|
||||
A relay MAY choose to ignore this event if original event does not contain "is_maintained"
|
||||
|
||||
Design Notes
|
||||
------------
|
||||
|
||||
### Why treat issue claim events as parameterized replaceable event (NIP-33)?
|
||||
|
||||
The intended use for claims is to enable clients to display the latest claim information for a user and for relays to take different actions on an incoming event based on claims. Treating issue claim events as parameterized replaceable events allows any consumer to get the only latest issue claim event for a user by setting a subscription filter specifying the kind, issuer, the subject as the p tag, and a limit of 1.
|
||||
|
||||
### Why is "is_maintained" necessary?
|
||||
|
||||
It's optional, and not technically necessary, but is a practical consideration.
|
||||
|
||||
- If adhered to, prevents clients from sending refresh claim request events that are useless, reducing "garbage" events relays have to handle
|
||||
- Alows users acting as issuers to periodically send new issue claim events, updating claims for individual users "on demand" only when necessary
|
||||
|
||||
### App-specific data tags instead of content?
|
||||
|
||||
I considered allowing claim data to be stored in the event tags after reading this [discussion of another NIP](https://github.com/nostr-protocol/nostr/issues/20#issuecomment-913027389).
|
||||
Simple data directly in event tags instead of content may be useful for owners of relays to communicate with each other about pubkeys acting badly (from purely a network point of view). Given throughput and stability is important fo relays, reading single values from an event's tags seems faster and safer than parsing a object from content.
|
||||
Still unsure if this should be allowed.
|
||||
|
||||
Motivation
|
||||
----------
|
||||
As a protocol, Nostr is application agnostic, easy to implement, and censorhip resistant. While current apps built on Nostr focus on messaging (Twitter, Telegram, etc.) I envision Nostr being the underlying protocol of other social media apps as well (Instagram, LinkedIn, Tinder, etc.).
|
||||
|
||||
Apps that create new relationships between strangers need more user profile information that Nostr currently supports, but how do we do that will still being application agnostic, easy to implement, and censorship resistant?
|
||||
|
||||
This NIP attempts to accomplish this by:
|
||||
- re-using existing structures from standard Nostr events as much possible
|
||||
- allowing any user to act as a issuer, submitting claims about another user without any type of approval
|
||||
- separating the protocol for communicating claims from the definition of claim data
|
||||
- having all claim data public, allowing for full transparency
|
||||
|
||||
As a first attempt, there are many unresolved concerns like how to establish trust for an issuer [NIP-05](https://github.com/nostr-protocol/nips/blob/master/05.md)?, how to handle profile information that shouldn't be public, and how to define standard profile fields so clients can design attractive profile screens. However, I believe that this NIP has JUST ENOUGH to be useful.
|
||||
|
||||
Potential Use Cases
|
||||
-------------------
|
||||
|
||||
### Profile Metadata
|
||||
|
||||
A common use case today is linking a Notr pubkey with other social accounts (e.g. (nostr.directory)[https://github.com/pseudozach/nostr.directory]). Apps can act as issuers, sending a Issue Claim event with other account specific claim data (Twitter handle, number of followers, proof link to Twitter message with Nostr pubkey, etc). Clients subscribed to Issue Claim events can then display other social account links provided by multiple issuers in a user's profile page. Ideally, issuers would use the same claim_type when the properties are the same, so client code doesn't have to be re-written.
|
||||
|
||||
### Community Pins / Badges
|
||||
|
||||
Because any user can act as a issuer, this NIP makes it easy for a community manager to reward their members with pins / badges. For example, the owner of the Damus client could issue a claim with a badge to their users who have made a donation.
|
||||
|
||||
### Pukey Behavior
|
||||
|
||||
While claims can be associated with the owner of the pubkey, claims can be made against the pubkey itself based on its usage. The first use case that comes to mind is the owner of a relay communicating that a pubkey is actly badly, allowing other relay others to take appropriate actions on that pubkey's events.
|
||||
|
||||
About Privacy
|
||||
-------------
|
||||
|
||||
While additional profile information is needed for apps that create new relationships between stranger, as soon as we start associating information with a person via their pubkey, there are privacy concerns.
|
||||
|
||||
- What happens when an issuer makes a claim about me that is untrue?
|
||||
- What happens when an issuer makes a claim about me that is true, but I don't want public?
|
||||
- Can the correlation of claims about me reveal my identity?
|
||||
|
||||
### Untrue Claims
|
||||
|
||||
This NIP uses the term "claim" instead of "credential" or "attribute" to emphasize that the issuer is making a claim, which can be true or untrue. In an censorship resistant application, any person can make any claim about someone else, without their permission, regardless of if it is as a regular Nostr message or as a issue claim event. The issue for this NIP is, does the channel incorrectly convey legitimacy to the claims, or does the display of an issued claim on a client's profile page convey more legitimacy than a message? It probably does.
|
||||
|
||||
An immediate solution is to blacklist that issuer's pubkey, a configuration setting that already exists in some Notr relays. An alternate solution is for the wrong users to sent their own Issue Claim event against the pukey of the issuer, and use heuristics to automatically blacklist or hide event from bad issuers.
|
||||
|
||||
### True Claims that Shouldn't be Public
|
||||
|
||||
If an issuer is acting in good faith, once informed, the issue claim event can be deleted [NIP-09](https://github.com/nostr-protocol/nips/blob/master/09.md). However, the same issue exists as Tweets that are taken down, there is no guarantee that it hasn't already been copied, or in Nostr's case, that a relay will respect the deletion event. A client may have to verify the relay properly supports event deletion before sending a issue claim event to that relay.
|
||||
|
||||
### Correlation of Identity
|
||||
Doxing is an issue. If claims against my pubkey include membership in "Women in Tech", "Atlantic Falcons Fan", and "Austism Support Network", something searching for my real identity knows to look to a woman in Atlanta, likely working for one of the thirteen big tech firms in Atlanta, likely in a photo with wearing Falcons merch, and has an autistic child. That's dangerous.
|
||||
|
||||
It takes user education, but one nice thing about Nostr though, it's trivial for a person to create multiple pubkeys, and no single login / wallet. Claims about the same person, but spread across multiple unrelated pubkeys greatly reduces the risk of doxing.
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user