mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-12-22 16:35:52 -05:00
Merge pull request #1230 from adamdecaf/misc-spelling-fixes
all: minor spelling fixes
This commit is contained in:
commit
69e14f1dca
2
34.md
2
34.md
|
@ -125,7 +125,7 @@ Root Patches and Issues have a Status that defaults to 'Open' and can be set by
|
||||||
["p", "<root-event-author>"],
|
["p", "<root-event-author>"],
|
||||||
["p", "<revision-author>"],
|
["p", "<revision-author>"],
|
||||||
|
|
||||||
// optional for improved subscription filter efficency
|
// optional for improved subscription filter efficiency
|
||||||
["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>", "<relay-url>"],
|
["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>", "<relay-url>"],
|
||||||
["r", "<earliest-unique-commit-id-of-repo>"]
|
["r", "<earliest-unique-commit-id-of-repo>"]
|
||||||
|
|
||||||
|
|
2
46.md
2
46.md
|
@ -208,7 +208,7 @@ When the user types a NIP-05 the client:
|
||||||
|
|
||||||
#### Remote signer discovery via NIP-89
|
#### Remote signer discovery via NIP-89
|
||||||
|
|
||||||
In this last case, most often used to fascilitate an OAuth-like signin flow, the client first looks for remote signers that have announced themselves via NIP-89 application handler events.
|
In this last case, most often used to facilitate an OAuth-like signin flow, the client first looks for remote signers that have announced themselves via NIP-89 application handler events.
|
||||||
|
|
||||||
First the client will query for `kind: 31990` events that have a `k` tag of `24133`.
|
First the client will query for `kind: 31990` events that have a `k` tag of `24133`.
|
||||||
|
|
||||||
|
|
2
54.md
2
54.md
|
@ -79,7 +79,7 @@ Wiki-events can tag other wiki-events with a `defer` marker to indicate that it
|
||||||
|
|
||||||
This is a stronger signal of trust than a `+` reaction.
|
This is a stronger signal of trust than a `+` reaction.
|
||||||
|
|
||||||
This marker is useful when a user edits someone else's entry; if the original author includes the editor's changes and the editor doesn't want to keep/maintain an indepedent version, the `link` tag could effectively be a considered a "deletion" of the editor's version and putting that pubkey's WoT weight behind the original author's version.
|
This marker is useful when a user edits someone else's entry; if the original author includes the editor's changes and the editor doesn't want to keep/maintain an independent version, the `link` tag could effectively be a considered a "deletion" of the editor's version and putting that pubkey's WoT weight behind the original author's version.
|
||||||
|
|
||||||
Why Markdown?
|
Why Markdown?
|
||||||
-------------
|
-------------
|
||||||
|
|
2
72.md
2
72.md
|
@ -76,7 +76,7 @@ The post-approval event MUST include `a` tags of the communities the moderator i
|
||||||
|
|
||||||
It's recommended that multiple moderators approve posts to avoid deleting them from the community when a moderator is removed from the owner's list. In case the full list of moderators must be rotated, the new moderator set must sign new approvals for posts in the past or the community will restart. The owner can also periodically copy and re-sign of each moderator's approval events to make sure posts don't disappear with moderators.
|
It's recommended that multiple moderators approve posts to avoid deleting them from the community when a moderator is removed from the owner's list. In case the full list of moderators must be rotated, the new moderator set must sign new approvals for posts in the past or the community will restart. The owner can also periodically copy and re-sign of each moderator's approval events to make sure posts don't disappear with moderators.
|
||||||
|
|
||||||
Post Approvals of replaceable events can be created in three ways: (i) by tagging the replaceable event as an `e` tag if moderators want to approve each individual change to the repleceable event; (ii) by tagging the replaceable event as an `a` tag if the moderator authorizes the replaceable event author to make changes without additional approvals and (iii) by tagging the replaceable event with both its `e` and `a` tag which empowers clients to display the original and updated versions of the event, with appropriate remarks in the UI. Since relays are instructed to delete old versions of a replaceable event, the `.content` of an `e`-approval MUST have the specific version of the event or Clients might not be able to find that version of the content anywhere.
|
Post Approvals of replaceable events can be created in three ways: (i) by tagging the replaceable event as an `e` tag if moderators want to approve each individual change to the replaceable event; (ii) by tagging the replaceable event as an `a` tag if the moderator authorizes the replaceable event author to make changes without additional approvals and (iii) by tagging the replaceable event with both its `e` and `a` tag which empowers clients to display the original and updated versions of the event, with appropriate remarks in the UI. Since relays are instructed to delete old versions of a replaceable event, the `.content` of an `e`-approval MUST have the specific version of the event or Clients might not be able to find that version of the content anywhere.
|
||||||
|
|
||||||
Clients SHOULD evaluate any non-`34550:*` `a` tag as posts to be included in all `34550:*` `a` tags.
|
Clients SHOULD evaluate any non-`34550:*` `a` tag as posts to be included in all `34550:*` `a` tags.
|
||||||
|
|
||||||
|
|
2
90.md
2
90.md
|
@ -199,7 +199,7 @@ Some service providers might choose to submit a `payment-required` as the first
|
||||||
It's not up to this NIP to define how individual vending machines should choose to run their business.
|
It's not up to this NIP to define how individual vending machines should choose to run their business.
|
||||||
|
|
||||||
# Cancellation
|
# Cancellation
|
||||||
A job request might be cancelled by publishing a `kind:5` delete request event tagging the job request event.
|
A job request might be canceled by publishing a `kind:5` delete request event tagging the job request event.
|
||||||
|
|
||||||
# Appendix 1: Job chaining
|
# Appendix 1: Job chaining
|
||||||
A Customer MAY request multiple jobs to be processed as a chain, where the output of a job is the input of another job. (e.g. podcast transcription -> summarization of the transcription). This is done by specifying as input an event id of a different job with the `job` type.
|
A Customer MAY request multiple jobs to be processed as a chain, where the output of a job is the input of another job. (e.g. podcast transcription -> summarization of the transcription). This is done by specifying as input an event id of a different job with the `job` type.
|
||||||
|
|
Loading…
Reference in New Issue
Block a user