nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-09-19 22:35:50 -04:00
Code Issues Actions Packages Projects Releases Wiki Activity

Merge branch 'master' into patch-3

Browse Source
This commit is contained in:
gsovereignty 2023-11-14 09:13:20 +08:00 committed by GitHub
commit b06375d164
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
6 changed files with 189 additions and 173 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
24.md
View File

@ -13,7 +13,7 @@ kind 0
These are extra fields not specified in NIP-01 that may be present in the stringified JSON of metadata events:
- `display_name`: a bigger name with richer characters than `name`. Implementations should fallback to `name` when this is not available.
- `display_name`: an alternative, bigger name with richer characters than `name`. `name` should always be set regardless of the presence of `display_name` in the metadata.
- `website`: a web URL related in any way to the event author.
- `banner`: an URL to a wide (~1024x768) picture to be optionally displayed in the background of a profile screen.

122
32.md
View File

@ -6,7 +6,30 @@ Labeling
`draft` `optional` `author:staab` `author:gruruya` `author:s3x-jay`
A label is a `kind 1985` event that is used to label other entities. This supports a number of use cases, from distributed moderation and content recommendations to reviews and ratings.
A label is a `kind 1985` event that is used to label other entities. This supports a number of use cases,
including distributed moderation, collection management, license assignment, and content classification.
This NIP introduces two new tags:
- `L` denotes a label namespace
- `l` denotes a label
Label Namespace Tag
----
An `L` tag can be any string, but publishers SHOULD ensure they are unambiguous by using a well-defined namespace
(such as an ISO standard) or reverse domain name notation.
`L` tags are REQUIRED in order to support searching by namespace rather than by a specific tag. The special `ugc`
("user generated content") namespace MAY be used when the label content is provided by an end user.
`L` tags starting with `#` indicate that the label target should be associated with the label's value.
This is a way of attaching standard nostr tags to events, pubkeys, relays, urls, etc.
Label Tag
----
An `l` tag's value can be any string. `l` tags MUST include a `mark` matching an `L` tag value in the same event.
Label Target
----
@ -16,47 +39,18 @@ labeled: `e`, `p`, `a`, `r`, or `t` tags. This allows for labeling of events, pe
or topics respectively. As with NIP-01, a relay hint SHOULD be included when using `e` and
`p` tags.
Label Tag
----
This NIP introduces a new tag `l` which denotes a label, and a new `L` tag which denotes a label namespace.
A label MUST include a mark matching an `L` tag. `L` tags refer to a tag type within nostr, or a nomenclature
external to nostr defined either formally or by convention. Any string can be a namespace, but publishers SHOULD
ensure they are unambiguous by using a well-defined namespace (such as an ISO standard) or reverse domain name notation.
Namespaces starting with `#` indicate that the label target should be associated with the label's value.
This is a way of attaching standard nostr tags to events, pubkeys, relays, urls, etc.
Some examples:
- `["l", "footstr", "#t"]` - the publisher thinks the given entity should have the `footstr` topic applied.
- `["l", "<pubkey>", "#p"]` - the publisher thinks the given entity is related to `<pubkey>`
- `["l", "IT-MI", "ISO-3166-2"]` - Milano, Italy using ISO 3166-2.
- `["l", "VI-hum", "com.example.ontology"]` - Violence toward a human being as defined by ontology.example.com.
`L` tags containing the label namespaces MUST be included in order to support searching by
namespace rather than by a specific tag. The special `ugc` ("user generated content") namespace
MAY be used when the label content is provided by an end user.
`l` and `L` tags MAY be added to other event kinds to support self-reporting. For events
with a kind other than 1985, labels refer to the event itself.
Label Annotations
-----
A label tag MAY include a 4th positional element detailing extra metadata about the label in question. This string
should be a json-encoded object. Any key MAY be used, but the following are recommended:
- `quality` may have a value of 0 to 1. This allows for an absolute, granular scale that can be represented in any way (5 stars, color scale, etc).
- `confidence` may have a value of 0 to 1. This indicates the certainty which the author has about their rating.
- `context` may be an array of urls (including NIP-21 urls) indicating other context that should be considered when interpreting labels.
Content
-------
Labels should be short, meaningful strings. Longer discussions, such as for a review, or an
explanation of why something was labeled the way it was, should go in the event's `content` field.
Self-Reporting
-------
`l` and `L` tags MAY be added to other event kinds to support self-reporting. For events
with a kind other than 1985, labels refer to the event itself.
Example events
--------------
@ -70,38 +64,61 @@ A suggestion that multiple pubkeys be associated with the `permies` topic.
["l", "permies", "#t"],
["p", <pubkey1>, <relay_url>],
["p", <pubkey2>, <relay_url>]
],
"content": "",
...
]
}
```
A review of a relay.
A report flagging violence toward a human being as defined by ontology.example.com.
```json
{
"kind": 1985,
"tags": [
["L", "com.example.ontology"],
["l", "relay/review", "com.example.ontology", "{\"quality\": 0.1}"],
["r", <relay_url>]
],
"content": "This relay is full of mean people.",
...
["l", "VI-hum", "com.example.ontology"],
["p", <pubkey1>, <relay_url>],
["p", <pubkey2>, <relay_url>]
]
}
```
Publishers can self-label by adding `l` tags to their own non-1985 events.
A moderation suggestion for a chat event.
```json
{
"kind": 1985,
"tags": [
["L", "nip28.moderation"],
["l", "approve", "nip28.moderation"],
["e", <kind40_event_id>, <relay_url>]
],
}
```
Assignment of a license to an event.
```json
{
"kind": 1985,
"tags": [
["L", "license"],
["l", "MIT", "license"],
["e", <event_id>, <relay_url>]
],
}
```
Publishers can self-label by adding `l` tags to their own non-1985 events. In this case, the kind 1 event's author
is labeling their note as being related to Milan, Italy using ISO 3166-2.
```json
{
"kind": 1,
"tags": [
["L", "com.example.ontology"],
["l", "IL-frd", "com.example.ontology"]
["L", "ISO-3166-2"],
["l", "IT-MI", "ISO-3166-2"]
],
"content": "Send me 100 sats and I'll send you 200 back",
...
"content": "It's beautiful here in Milan!",
}
```
@ -124,3 +141,8 @@ Vocabularies MAY choose to fully qualify all labels within a namespace (for exam
formal vocabularies that should not be confused with another namespace when querying
without an `L` tag. For these vocabularies, all labels SHOULD include the namespace
(rather than mixing qualified and unqualified labels).
A good heuristic for whether a use case fits this NIP is whether labels would ever be unique.
For example, many events might be labeled with a particular place, topic, or pubkey, but labels
with specific values like "John Doe" or "3.18743" are not labels, they are values, and should
be handled in some other way.

2
65.md
View File

@ -53,7 +53,7 @@ This NIP allows Clients to connect directly with the most up-to-date relay set f
1. Clients SHOULD guide users to keep `kind:10002` lists small (2-4 relays).
2. Clients SHOULD spread an author's `kind:10002` events to as many relays as viable.
2. Clients SHOULD spread an author's `kind:10002` event to as many relays as viable.
3. `kind:10002` events should primarily be used to advertise the user's preferred relays to others. A user's own client may use other heuristics for selecting relays for fetching data.

61
84.md
View File

@ -35,64 +35,3 @@ last value of the tag.
### Context
Clients MAY include a `context` tag, useful when the highlight is a subset of a paragraph and displaying the
surrounding content might be beneficial to give context to the higlight.
### Ranges
Clients MAY include `range` tags with the start/end indexes of where the highlight begins and finishes within
the referenced article/tagged-event.
```
[ "range", <start-index>, <end-index> ]
```
Additionally a range with `context` as the third value of the tag MAY be added to indicate the begin/finish indexes
of the highlight within the included `context` tag.
```
[ "range", <start-index>, <end-index>, "context" ]
```
#### Text-based nostr events' highlights
Highlights of Nostr events SHOULD use the range index of the content as-is
(e.g. NIP-23 articles include the markdown instead of computing the index from the rendered markdown).
```
[ "range", 3000, 3042 ] # highlight begins at index position 3000 of the tagged event's `.content`
[ "range", 42, 84, "context" ] # highlight begins at index position 42 of the `context` tag's value
```
#### Non-text-based nostr events' highlights
A `kind:9802` event that tags a NIP-94 event which includes a video or audio file can use ranges to
indicate the start/end time position in seconds.
#### Ranges in URL highlights
When creating a highlight from a URL the range should be expressed over
the extracted plain text of the formatted content (e.g. rendered HTML instead of including the HTML markup);
this helps make finding the correct indexes easier on websites with markup variations on each render.
e.g. `<html><body>hello, world</body></html>`
Tagging `hello, world` would result in using a range tag like `["range", 0, 12 ]`.
Text extraction (i.e. translation from non-plain text medium like HTML or PDF) is highly subjective and the value
of the range should be carefully interpreted by the different clients that support this.
```json
{
"created_at": 1682707885,
"content": "while allowing creators to simply keep doing what they’re doing. Creators don’t need to be blatant shills for brands",
"tags": [
[ "r", "https://footstr.com/zapvertise/" ],
[ "p", "c48e29f04b482cc01ca1f9ef8c86ef8318c059e0e9353235162f080f26e14c11", "wss://relay.url", "author" ],
[ "context", "The Nostr zapvertising model creates a truly free market for advertisers, while allowing creators to simply keep doing what they’re doing. Creators don’t need to be blatant shills for brands, they just have to create high quality content people find valuable, and companies will naturally want to zapvertise on their posts." ]
[ "range", 3916, 4032 ],
[ "range", 74, 190, "context" ],
],
"kind": 9802,
"pubkey": "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52",
"id": "59e5887a3cdf32d5f11edf9b8cd098c620d278514b2edde3e6d1ba8a541d262c",
"sig": "f2d15b8bc2csf6d198350f8df0a31dcf66d7c32ec9c54e6b3f102d579370b7de9d164d70350a5b32a2911db3b124e972bafa9a1bc8fd60c1e338903d2f6306b0"
}
```

54
90.md
View File

@ -67,6 +67,37 @@ All tags are optional.
* `relays`: List of relays where Service Providers SHOULD publish responses to
* `p`: Service Providers the customer is interested in. Other SPs MIGHT still choose to process the job
## Encrypted Params
If the user wants to keep the input parameters a secret, they can encrypt the `i` and `param` tags with the service provider's 'p' tag and add it to the content field. Add a tag `encrypted` as tags. Encryption for private tags will use [NIP-04 - Encrypted Direct Message encryption](https://github.com/nostr-protocol/nips/blob/master/04.md), using the user's private and service provider's public key for the shared secret
```json
[
[ "i", "what is the capital of France? ", "text" ],
[ "param", "model", "LLaMA-2" ],
[ "param", "max_tokens", "512" ],
[ "param", "temperature", "0.5" ],
[ "param", "top-k", "50" ],
[ "param", "top-p", "0.7" ],
[ "param", "frequency_penalty", "1" ]
]
```
This param data will be encrypted and added to the `content` field and `p` tag should be present
```
"content": "BE2Y4xvS6HIY7TozIgbEl3sAHkdZoXyLRRkZv4fLPh3R7LtviLKAJM5qpkC7D6VtMbgIt4iNcMpLtpo...",
"tags": [
["p", "04f74530a6ede6b24731b976b8e78fb449ea61f40ff10e3d869a3030c4edc91f"],
["encrypted"]
]
```
## Job result (`kind:6000-6999`)
Service providers publish job results, providing the output of the job result. They should tag the original job request event id as well as the customer's pubkey.
@ -90,6 +121,27 @@ Service providers publish job results, providing the output of the job result. T
* `amount`: millisats that the Service Provider is requesting to be paid. An optional third value can be a bolt11 invoice.
* `i`: The original input(s) specified in the request.
## Encrypted Output
If the request has encrypted params, then output should be encrypted and placed in `content` field. If the output is encrypted, then avoid including `i` tag with input-data as clear text.
Add a tag encrypted to mark the output content as `encrypted`
```json
{
"pubkey": "<service-provider pubkey>",
"content": "<encrypted payload>",
"kind": 6xxx,
"tags": [
[ "request", "<job-request>" ],
[ "e", "<job-request-id>", "<relay-hint>" ],
[ "p", "<customer's-pubkey>" ],
[ "amount", "requested-payment-amount", "<optional-bolt11>" ],
["encrypted"]
]
}
```
## Job feedback
Service providers can give feedback about a job back to the customer.
@ -110,6 +162,8 @@ Service providers can give feedback about a job back to the customer.
* `amount` tag: as defined in the [Job Result](#job-result) section.
* `status` tag: Service Providers SHOULD indicate what this feedback status refers to. [Appendix 1](#appendix-1-job-feedback-status) defines status. Extra human-readable information can be added as an extra argument.
* NOTE: If the input params requires input to be encryped, then `content` field will have encrypted payload with `p` tag as key.
### Job feedback status
| status | description |

7
README.md
View File

@ -7,12 +7,12 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
- [List](#list)
- [Event Kinds](#event-kinds)
- [Event Kind Ranges](#event-kind-ranges)
- [Message Types](#message-types)
- [Client to Relay](#client-to-relay)
- [Relay to Client](#relay-to-client)
- [Standardized Tags](#standardized-tags)
- [Criteria for acceptance of NIPs](#criteria-for-acceptance-of-nips)
- [Mailing Lists](#mailing-lists)
- [License](#license)
---
@ -74,9 +74,8 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
- [NIP-99: Classified Listings](99.md)
## Event Kinds
| kind | description | NIP |
| ------- | -------------------------- | ----------- |
| ------------- | -------------------------- | ----------- |
| `0` | Metadata | [1](01.md) |
| `1` | Short Text Note | [1](01.md) |
| `2` | Recommend Relay | |
@ -99,6 +98,8 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `1984` | Reporting | [56](56.md) |
| `1985` | Label | [32](32.md) |
| `4550` | Community Post Approval | [72](72.md) |
| `5000`-`5999` | Job Request | [90](90.md) |
| `6000`-`6999` | Job Result | [90](90.md) |
| `7000` | Job Feedback | [90](90.md) |
| `9041` | Zap Goal | [75](75.md) |
| `9734` | Zap Request | [57](57.md) |