mirror of
https://github.com/nostr-protocol/nips.git
synced 2025-10-04 02:16:08 +02:00
Fix typos (#2014)
This commit is contained in:
2
34.md
2
34.md
@@ -45,7 +45,7 @@ An optional source of truth for the state of branches and tags in a repository.
|
||||
"kind": 30618,
|
||||
"content": "",
|
||||
"tags": [
|
||||
["d", "<repo-id>"], // matches the identifier in the coresponding repository announcement
|
||||
["d", "<repo-id>"], // matches the identifier in the corresponding repository announcement
|
||||
["refs/<heads|tags>/<branch-or-tag-name>","<commit-id>"]
|
||||
["HEAD", "ref: refs/heads/<branch-name>"]
|
||||
]
|
||||
|
2
55.md
2
55.md
@@ -91,7 +91,7 @@ Signer MUST answer multiple permissions with an array of results
|
||||
val results = listOf(
|
||||
Result(
|
||||
package = signerPackageName,
|
||||
result = eventSignture,
|
||||
result = eventSignature,
|
||||
id = intentId
|
||||
)
|
||||
)
|
||||
|
2
61.md
2
61.md
@@ -78,7 +78,7 @@ Clients should REQ for nutzaps:
|
||||
* Filtering with `#u` for mints they expect to receive ecash from.
|
||||
* this is to prevent even interacting with mints the user hasn't explicitly signaled.
|
||||
* Filtering with `since` of the most recent `kind:7376` event the same user has created.
|
||||
* this can be used as a marker of the nutzaps that have already been swaped by the user -- clients might choose to use other kinds of markers, including internal state -- this is just a guidance of one possible approach.
|
||||
* this can be used as a marker of the nutzaps that have already been swapped by the user -- clients might choose to use other kinds of markers, including internal state -- this is just a guidance of one possible approach.
|
||||
|
||||
`{ "kinds": [9321], "#p": ["my-pubkey"], "#u": ["<mint-1>", "<mint-2>"], "since": <latest-created_at-of-kind-7376> }`.
|
||||
|
||||
|
4
73.md
4
73.md
@@ -6,7 +6,7 @@ External Content IDs
|
||||
|
||||
`draft` `optional`
|
||||
|
||||
There are certain established global content identifiers such as [Book ISBNs](https://en.wikipedia.org/wiki/ISBN), [Podcast GUIDs](https://podcastnamespace.org/tag/guid), and [Movie ISANs](https://en.wikipedia.org/wiki/International_Standard_Audiovisual_Number) that are useful to reference in nostr events so that clients can query all the events assosiated with these ids.
|
||||
There are certain established global content identifiers such as [Book ISBNs](https://en.wikipedia.org/wiki/ISBN), [Podcast GUIDs](https://podcastnamespace.org/tag/guid), and [Movie ISANs](https://en.wikipedia.org/wiki/International_Standard_Audiovisual_Number) that are useful to reference in nostr events so that clients can query all the events associated with these ids.
|
||||
|
||||
|
||||
`i` tags are used for referencing these external content ids, with `k` tags representing the external content id kind so that clients can query all the events for a specific kind.
|
||||
@@ -47,7 +47,7 @@ For the webpage "https://myblog.example.com/post/2012-03-27/hello-world" the "i"
|
||||
|
||||
- Book ISBN: `["i", "isbn:9780765382030"]` - https://isbnsearch.org/isbn/9780765382030
|
||||
|
||||
Book ISBNs MUST be referenced _**without hyphens**_ as many book search APIs return the ISBNs without hyphens. Removing hypens from ISBNs is trivial, whereas adding the hyphens back in is non-trivial requiring a library.
|
||||
Book ISBNs MUST be referenced _**without hyphens**_ as many book search APIs return the ISBNs without hyphens. Removing hyphens from ISBNs is trivial, whereas adding the hyphens back in is non-trivial requiring a library.
|
||||
|
||||
### Podcasts:
|
||||
|
||||
|
2
77.md
2
77.md
@@ -99,7 +99,7 @@ When finished, the client should tell the relay it can release its resources wit
|
||||
|
||||
### Preparation
|
||||
|
||||
There are two protocol participants: Client and server. The client creates an initial message and transmits it to the server, which replies with its own message in response. The client continues querying the server until it is satisifed, and then terminates the protocol. Messages in either direction have the same format.
|
||||
There are two protocol participants: Client and server. The client creates an initial message and transmits it to the server, which replies with its own message in response. The client continues querying the server until it is satisfied, and then terminates the protocol. Messages in either direction have the same format.
|
||||
|
||||
Each participant has a collection of records. A records consists of a 64-bit numeric timestamp and a 256-bit ID. Each participant starts by sorting their items according to timestamp, ascending. If two timestamps are equal then items are sorted lexically by ID, ascending by first differing byte. Items may not use the max uint64 value (`2**64 - 1`) as a timestamp since this is reserved as a special "infinity" value.
|
||||
|
||||
|
2
87.md
2
87.md
@@ -41,7 +41,7 @@ There are three actors to this workflow:
|
||||
}
|
||||
```
|
||||
|
||||
The recommendation event is a parameterized-replacable event so that a user can change edit their recommendation without creating a new event.
|
||||
The recommendation event is a parameterized-replaceable event so that a user can change edit their recommendation without creating a new event.
|
||||
|
||||
The `d` tag in `kind:38000` is the `kind:38173`/`kind:38172` event identifier this event is recommending, if no event exists, the `d` tag can still be calculated from the mint's pubkey/id.
|
||||
The `k` tag is the kind number that corresponds to the event kind that the user is recommending, in this case `kind:38173` for fedimints and `kind:38172` for cashu mints.
|
||||
|
Reference in New Issue
Block a user