Compare commits

..

41 Commits

Author SHA1 Message Date
Leo Wandersleb
9b7883e98b Require tags to have at least one string
fixes #1193
2024-04-24 12:18:27 -04:00
Alex Gleason
cab47cf0f1 Merge pull request #1187 from AsaiToshiya/AsaiToshiya-patch-7
README: add status kinds of NIP-34
2024-04-21 22:37:50 -05:00
Asai Toshiya
eb3a857288 README: add status kinds of NIP-34 2024-04-22 12:35:48 +09:00
DanConwayDev
403b5199a4 NIP-34: add status events
merge-commit and applied-commit-id tags enable discussion of patches to be
mapped to lines of code accepted into the master branch
2024-04-17 17:46:34 -03:00
DanConwayDev
0b62729e31 NIP-34: clarify cover letters
remove cover letters from 'possible things to be added later' and
add a clarification that can they can be added through patches
2024-04-17 17:46:34 -03:00
DanConwayDev
8225a018c7 NIP-34: optional tags to improve discoverability
earliest-unique-commit r tag enables clients to:
 - retrieve all repo events refering to a local git repo
 - group repo events with different identifers that refer to same repo
 - retrieve all patches for a local repo,
   irespective of the tagged repo event

current-commit-id r tag enables clients to prevent accidental submission of a patch,
which has already been proposed

root-revision tag enables clients to filter out proposal revisions
from a list of proposals
2024-04-17 17:46:34 -03:00
DanConwayDev
cb0d35a5f9 NIP-34: optional additional repo maintainers
can be used by clients to tag multiple maintainers in patches

helps clients identify whether multiple repo events for the same repository
are complementary or in competion
2024-04-17 17:46:34 -03:00
DanConwayDev
46ea8dcf9c NIP-34: add repo-id standard
suggested guidance for repo-id
2024-04-17 17:46:34 -03:00
DanConwayDev
d607a288b5 NIP-34: clarify nip10 thread application
for consistancy and so that the intended order of patches is easier to ascertain

enables additional patches to be appended to a patch set, supporting a PR-like workflow alongside
patch-over-email-like workflow
2024-04-17 17:46:34 -03:00
kuiperanon
b765b3c030 Clarify use of ambiguous terminology in spec of bunker token
It's very confusing as to whether it refers to remote user pubkey vs remote signer pubkey. This is complicated further by the typo in the explanation of "remote signer pubkey".
2024-04-10 12:53:59 -03:00
Matthew Lorentz
b224f6d05d Update description of NIP-56 2024-04-03 12:22:44 -03:00
Matthew Lorentz
3c75180fb7 Add category to reports 2024-04-03 12:09:00 -03:00
Asai Toshiya
ca97490cdf NIP-58: minor JSON fix 2024-04-03 13:09:22 +09:00
Alex Gleason
af5d407488 Update BREAKING.md for NIP-46 (stringified params) 2024-04-02 13:03:34 -03:00
Alex Gleason
715e4a044d Merge pull request #1149 from arthurfranca/patch-4
Minor fix to nip01
2024-03-30 20:39:35 -05:00
arthurfranca
9971db3551 Minor fix to nip01 2024-03-30 22:33:24 -03:00
Vitor Pamplona
8817801860 Clarifies relays to be used for NIP-28 2024-03-29 08:02:04 -03:00
Asai Toshiya
769432efc4 README: fix order of kinds 2024-03-29 08:06:00 +09:00
Alex Gleason
3443b3b589 Merge pull request #1126 from SilberWitch/master
Added bot field to denote automated npubs
2024-03-24 16:13:58 -05:00
Nostr.Band
4b79bc67c4 Add optional_requested_permissions
This is implemented in nsec.app, nostr.band, Coracle and Nostrudel, so maybe it's time to update the NIP.
2024-03-22 09:08:22 -03:00
hodlbod
cf0e6e1567 Merge pull request #1132 from utxo-one/dev-nip05relay
Recommend setting relays in NIP05
2024-03-21 07:42:56 -07:00
utxo
965eb45b30 remove prettier formatting 2024-03-21 10:18:42 -04:00
utxo
46a6bf331a Make relay attribute recommended in NIP-05 2024-03-21 10:15:02 -04:00
silberengel
4f33dbc2b8 Added bot field to denote automated npubs 2024-03-18 08:01:06 +01:00
Asai Toshiya
de71f99828 NIP-96: simplify server list 2024-03-13 11:28:19 -03:00
Alex Gleason
9e9ae1eb88 Merge pull request #1113 from nostr-wine/nip50-extensions
NIP-50: add event classification extensions
2024-03-11 00:28:08 -05:00
nostr.wine
0438236268 Update 50.md 2024-03-08 12:05:49 -05:00
nostr.wine
d11f50bd0a NIP-50: add event classification extensions 2024-03-08 11:23:22 -05:00
Alex Gleason
c4c9bd0057 Merge pull request #1105 from nostr-protocol/alexgleason-patch-1
NIP-50: search by nip05 domain
2024-03-08 05:28:49 -06:00
Asai Toshiya
6871b3b334 README: add kinds and tags for NIP-34 2024-03-07 07:34:04 -03:00
Alex Gleason
1166fb9fb5 NIP-50: search by nip05 domain 2024-03-06 13:59:36 -06:00
Asai Toshiya
808569e562 README: add NIP-34 2024-03-06 12:35:59 +09:00
fiatjaf_
9a283796ce NIP-34: git stuff (#997)
* NIP-34: git stuff.

* repository head.

* threads/issues and replies.

* add "p" optional tags to events.

* add list of things to do later in the end.

* multiple values in some tags instead of multiple tags.

* replace "patches", "issues" tags and replace that with "relays".

* bring in tags that allow for a commit id to be stable.

* edit "reply" kind to say it should follow normal NIP-10 threading rules.

* update "things to be added later".

* add commit time to "committer" tag.

* remove "head" tag.

* mention the possibility of mentioning others users in patches.

Co-authored-by: DanConwayDev <114834599+DanConwayDev@users.noreply.github.com>

* clarify commit-pgp-sig.

* clarify requirements and threading of replies.

* add t=root tag.

---------

Co-authored-by: DanConwayDev <114834599+DanConwayDev@users.noreply.github.com>
2024-03-05 08:57:59 -03:00
Alex Gleason
849f59f6ba Merge pull request #1100 from AsaiToshiya/AsaiToshiya-patch-3
BREAKING.md: add NIP-18 change
2024-03-04 20:43:18 -05:00
Asai Toshiya
ac1221fa5d BREAKING.md: add NIP-18 change 2024-03-05 10:34:01 +09:00
fiatjaf_
5b2461eb01 NIP-29: Simple Groups (#566)
* NIP-29: Simple Group Chat.

* split hostname and subgroup path into two different tag items.

* add and remove permissions actions.

* fix kind number for moderation event.

* add missing / to "flavors" in example.

* some new ideas + making this universal and not only applicable to chat.

* fix delete-message => delete-event.

* flesh out the entire thing.

* saner approach with multiple kinds for moderation.

* delete-event as kind 9005.

* update meta events description.

* `public` and `open` tags and join request event.

* edit-group-status permission.

* add kinds to README.

* add kind:12

* add nip-10 note

* add optional list of members

* admins prefixed by "p".

* remove "alt" from event templates for brevity.

* add kind 10009 for public list of simple groups.

* update "previous" stuff.

* remove naddr stuff, use a different identifier format.

* remove reference to trimmed signatures until that is more developed.

* add kind:10 threaded chat replies.

---------

Co-authored-by: Pablo Fernandez <p@f7z.io>
2024-02-28 11:50:54 -03:00
Alex Gleason
f3a2356484 Merge pull request #1086 from AsaiToshiya/AsaiToshiya-patch-2
README: add q tag
2024-02-25 21:39:10 -06:00
Asai Toshiya
c9b3abfa3c Remove marker
Co-authored-by: Alex Gleason <alex@alexgleason.me>
2024-02-26 12:30:49 +09:00
Asai Toshiya
383eb594b4 README: add q tag 2024-02-26 10:07:55 +09:00
Alex Gleason
4a171cb0a8 Merge pull request #1074 from jb55/quote-repost-q-tags
Use `q` instead of `e` tags for quote reposts
2024-02-25 08:09:09 -06:00
William Casarin
996ef45605 Use q instead of e tags for quote reposts
Signed-off-by: William Casarin <jb55@jb55.com>
2024-02-22 11:40:58 -08:00
13 changed files with 202 additions and 34 deletions

4
01.md
View File

@@ -56,7 +56,7 @@ To prevent implementation differences from creating a different event ID for the
### Tags
Each tag is an array of strings of arbitrary size, with some conventions around them. Take a look at the example below:
Each tag is an array of one or more strings, with some conventions around them. Take a look at the example below:
```jsonc
{
@@ -81,7 +81,7 @@ This NIP defines 3 standard tags that can be used across all event kinds with th
- for a parameterized replaceable event: `["a", <kind integer>:<32-bytes lowercase hex of a pubkey>:<d tag value>, <recommended relay URL, optional>]`
- for a non-parameterized replaceable event: `["a", <kind integer>:<32-bytes lowercase hex of a pubkey>:, <recommended relay URL, optional>]`
As a convention, all single-letter (only english alphabet letters: a-z, A-Z) key tags are expected to be indexed by relays, such that it is possible, for example, to query or subscribe to events that reference the event `"5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"` by using the `{"#e": "5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"}` filter.
As a convention, all single-letter (only english alphabet letters: a-z, A-Z) key tags are expected to be indexed by relays, such that it is possible, for example, to query or subscribe to events that reference the event `"5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"` by using the `{"#e": ["5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"]}` filter.
### Kinds

4
05.md
View File

@@ -35,7 +35,7 @@ It will make a GET request to `https://example.com/.well-known/nostr.json?name=b
}
````
or with the **optional** `"relays"` attribute:
or with the **recommended** `"relays"` attribute:
```json
{
@@ -50,7 +50,7 @@ or with the **optional** `"relays"` attribute:
If the pubkey matches the one given in `"names"` (as in the example above) that means the association is right and the `"nip05"` identifier is valid and can be displayed.
The optional `"relays"` attribute may contain an object with public keys as properties and arrays of relay URLs as values. When present, that can be used to help clients learn in which relays the specific user may be found. Web servers which serve `/.well-known/nostr.json` files dynamically based on the query string SHOULD also serve the relays data for any name they serve in the same reply when that is available.
The recommended `"relays"` attribute may contain an object with public keys as properties and arrays of relay URLs as values. When present, that can be used to help clients learn in which relays the specific user may be found. Web servers which serve `/.well-known/nostr.json` files dynamically based on the query string SHOULD also serve the relays data for any name they serve in the same reply when that is available.
## Finding users from their NIP-05 identifier

7
18.md
View File

@@ -20,9 +20,10 @@ reposted.
## Quote Reposts
Quote reposts are `kind 1` events with an embedded `e` tag
(see [NIP-08](08.md) and [NIP-27](27.md)). Because a quote repost includes
an `e` tag, it may show up along replies to the reposted note.
Quote reposts are `kind 1` events with an embedded `q` tag of the note being
quote reposted. The `q` tag ensures quote reposts are not pulled and included
as replies in threads. It also allows you to easily pull and count all of the
quotes for a post.
## Generic Reposts

1
24.md
View File

@@ -16,6 +16,7 @@ These are extra fields not specified in NIP-01 that may be present in the string
- `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.
- `bot`: a boolean to clarify that the content is entirely or partially the result of automation, such as with chatbots or newsfeeds.
### Deprecated fields

14
28.md
View File

@@ -23,11 +23,11 @@ Client-centric moderation gives client developers discretion over what types of
Create a public chat channel.
In the channel creation `content` field, Client SHOULD include basic channel metadata (`name`, `about`, `picture` as specified in kind 41).
In the channel creation `content` field, Client SHOULD include basic channel metadata (`name`, `about`, `picture` and `relays` as specified in kind 41).
```json
{
"content": "{\"name\": \"Demo Channel\", \"about\": \"A test channel.\", \"picture\": \"https://placekitten.com/200/200\"}",
"content": "{\"name\": \"Demo Channel\", \"about\": \"A test channel.\", \"picture\": \"https://placekitten.com/200/200\", \"relays\": [\"wss://nos.lol\", \"wss://nostr.mom\"]}",
...
}
```
@@ -46,6 +46,7 @@ Clients SHOULD support basic metadata fields:
- `name` - string - Channel name
- `about` - string - Channel description
- `picture` - string - URL of channel picture
- `relays` - array - List of relays to download and broadcast events to
Clients MAY add additional metadata fields.
@@ -53,7 +54,7 @@ Clients SHOULD use [NIP-10](10.md) marked "e" tags to recommend a relay.
```json
{
"content": "{\"name\": \"Updated Demo Channel\", \"about\": \"Updating a test channel.\", \"picture\": \"https://placekitten.com/201/201\"}",
"content": "{\"name\": \"Updated Demo Channel\", \"about\": \"Updating a test channel.\", \"picture\": \"https://placekitten.com/201/201\", \"relays\": [\"wss://nos.lol\", \"wss://nostr.mom\"]}",
"tags": [["e", <channel_create_event_id>, <relay-url>]],
...
}
@@ -132,12 +133,11 @@ Clients MAY hide event 42s for users other than the user who sent the event 44.
}
```
## NIP-10 relay recommendations
## Relay recommendations
For [NIP-10](10.md) relay recommendations, clients generally SHOULD use the relay URL of the original (oldest) kind 40 event.
Clients MAY recommend any relay URL. For example, if a relay hosting the original kind 40 event for a channel goes offline, clients could instead fetch channel data from a backup relay, or a relay that clients trust more than the original relay.
Clients SHOULD use the relay URLs of the metadata events.
Clients MAY use any relay URL. For example, if a relay hosting the original kind 40 event for a channel goes offline, clients could instead fetch channel data from a backup relay, or a relay that clients trust more than the original relay.
Motivation
----------

151
34.md Normal file
View File

@@ -0,0 +1,151 @@
NIP-34
======
`git` stuff
-----------
`draft` `optional`
This NIP defines all the ways code collaboration using and adjacent to [`git`](https://git-scm.com/) can be done using Nostr.
## Repository announcements
Git repositories are hosted in Git-enabled servers, but their existence can be announced using Nostr events, as well as their willingness to receive patches, bug reports and comments in general.
```jsonc
{
"kind": 30617,
"content": "",
"tags": [
["d", "<repo-id>"], // usually kebab-case short name
["name", "<human-readable project name>"],
["description", "brief human-readable project description>"],
["web", "<url for browsing>", ...], // a webpage url, if the git server being used provides such a thing
["clone", "<url for git-cloning>", ...], // a url to be given to `git clone` so anyone can clone it
["relays", "<relay-url>", ...] // relays that this repository will monitor for patches and issues
["earliest-unique-commit", "<commit-id>"] // usually root commit but a recent commit for forks
["r", "<earliest-unique-commit-id>"] // so clients can subscribe to all events related to a local git repo
["maintainers", "<other-recognized-maintainer>", ...]
]
}
```
The tags `web`, `clone`, `relays`, `maintainers` can have multiple values.
Except `d`, all tags are optional.
## Patches
Patches can be sent by anyone to any repository. Patches to a specific repository SHOULD be sent to the relays specified in that repository's announcement event's `"relays"` tag. Patch events SHOULD include an `a` tag pointing to that repository's announcement address.
Patches in a patch set SHOULD include a NIP-10 `e` `reply` tag pointing to the previous patch.
The first patch revision in a patch revision SHOULD include a NIP-10 `e` `reply` to the original root patch.
```jsonc
{
"kind": 1617,
"content": "<patch>", // contents of <git format-patch>
"tags": [
["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>"],
["r", "<earliest-unique-commit-id-of-repo>"] // so clients can subscribe to all patches sent to a local git repo
["p", "<repository-owner>"],
["p", "<other-user>"], // optionally send the patch to another user to bring it to their attention
["t", "root"], // ommited for additional patches in a series
// for the first patch in a revision
["t", "root-revision"],
// optional tags for when it is desirable that the merged patch has a stable commit id
// these fields are necessary for ensuring that the commit resulting from applying a patch
// has the same id as it had in the proposer's machine -- all these tags can be omitted
// if the maintainer doesn't care about these things
["commit", "<current-commit-id>"],
["r", "<current-commit-id>"] // so clients can find existing patches for a specific commit
["parent-commit", "<parent-commit-id>"],
["commit-pgp-sig", "-----BEGIN PGP SIGNATURE-----..."], // empty string for unsigned commit
["committer", "<name>", "<email>", "<timestamp>", "<timezone offset in minutes>"],
]
}
```
The first patch in a series MAY be a cover letter in the format produced by `git format-patch`.
## Issues
Issues are Markdown text that is just human-readable conversational threads related to the repository: bug reports, feature requests, questions or comments of any kind. Like patches, these SHOULD be sent to the relays specified in that repository's announcement event's `"relays"` tag.
```jsonc
{
"kind": 1621,
"content": "<markdown text>",
"tags": [
["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>"],
["p", "<repository-owner>"]
]
}
```
## Replies
Replies are also Markdown text. The difference is that they MUST be issued as replies to either a `kind:1621` _issue_ or a `kind:1617` _patch_ event. The threading of replies and patches should follow NIP-10 rules.
```jsonc
{
"kind": 1622,
"content": "<markdown text>",
"tags": [
["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>", "<relay-url>"],
["e", "<issue-or-patch-id-hex>", "", "root"],
// other "e" and "p" tags should be applied here when necessary, following the threading rules of NIP-10
["p", "<patch-author-pubkey-hex>", "", "mention"],
["e", "<previous-reply-id-hex>", "", "reply"],
// ...
]
}
```
## Status
Root Patches and Issues have a Status that defaults to 'Open' and can be set by issuing Status events.
```jsonc
{
"kind": 1630, // Open
"kind": 1631, // Applied / Merged for Patches; Resolved for Issues
"kind": 1632, // Closed
"kind": 1633, // Draft
"content": "<markdown text>",
"tags": [
["e", "<issue-or-original-root-patch-id-hex>", "", "root"],
["e", "<accepted-revision-root-id-hex>", "", "reply"], // for when revisions applied
["p", "<repository-owner>"],
["p", "<root-event-author>"],
["p", "<revision-author>"],
// optional for improved subscription filter efficency
["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>", "<relay-url>"],
["r", "<earliest-unique-commit-id-of-repo>"]
// optional for `1631` status
["e", "<applied-or-merged-patch-event-id>", "", "mention"], // for each
// when merged
["merge-commit", "<merge-commit-id>"]
["r", "<merge-commit-id>"]
// when applied
["applied-as-commits", "<commit-id-in-master-branch>", ...]
["r", "<applied-commit-id>"] // for each
]
}
```
The Status event with the largest created_at date is valid.
The Status of a patch-revision defaults to either that of the root-patch, or `1632` (Closed) if the root-patch's Status is `1631` and the patch-revision isn't tagged in the `1631` event.
## Possible things to be added later
- "branch merge" kind (specifying a URL from where to fetch the branch to be merged)
- inline file comments kind (we probably need one for patches and a different one for merged files)

10
46.md
View File

@@ -25,7 +25,7 @@ This is most common in a situation where you have your own nsecbunker or other t
The remote signer would provide a connection token in the form:
```
bunker://<remote-pubkey>?relay=<wss://relay-to-connect-on>&relay=<wss://another-relay-to-connect-on>&secret=<optional-secret-value>
bunker://<remote-user-pubkey>?relay=<wss://relay-to-connect-on>&relay=<wss://another-relay-to-connect-on>&secret=<optional-secret-value>
```
This token is pasted into the client by the user and the client then uses the details to connect to the remote signer via the specified relay(s).
@@ -120,7 +120,7 @@ Each of the following are methods that the client sends to the remote signer.
| Command | Params | Result |
| ------------------------ | ------------------------------------------------- | ---------------------------------------------------------------------- |
| `connect` | `[<remote_user_pubkey>, <optional_secret>]` | "ack" |
| `connect` | `[<remote_user_pubkey>, <optional_secret>, <optional_requested_permissions>]` | "ack" |
| `sign_event` | `[<json_stringified_event_to_sign>]` | `json_stringified(<signed_event>)` |
| `ping` | `[]` | "pong" |
| `get_relays` | `[]` | `json_stringified({<relay_url>: {read: <boolean>, write: <boolean>}})` |
@@ -130,6 +130,10 @@ Each of the following are methods that the client sends to the remote signer.
| `nip44_encrypt` | `[<third_party_pubkey>, <plaintext_to_encrypt>]` | `<nip44_ciphertext>` |
| `nip44_decrypt` | `[<third_party_pubkey>, <nip44_ciphertext_to_decrypt>]` | `<plaintext>` |
### Requested permissions
The `connect` method may be provided with `optional_requested_permissions` for user convenience. The permissions are a comma-separated list of `method[:params]`, i.e. `nip04_encrypt,sign_event:4` meaning permissions to call `nip04_encrypt` and to call `sign_event` with `kind:4`. Optional parameter for `sign_event` is the kind number, parameters for other methods are to be defined later.
## Response Events `kind:24133`
```json
@@ -185,7 +189,7 @@ Each of the following are methods that the client sends to the remote signer.
| Command | Params | Result |
| ---------------- | ------------------------------------------ | ------------------------------------ |
| `create_account` | `[<username>, <domain>, <optional_email>]` | `<newly_created_remote_user_pubkey>` |
| `create_account` | `[<username>, <domain>, <optional_email>, <optional_requested_permissions>]` | `<newly_created_remote_user_pubkey>` |
## Appendix

4
50.md
View File

@@ -47,3 +47,7 @@ Relays SHOULD exclude spam from search results by default if they support some f
Relay MAY support these extensions:
- `include:spam` - turn off spam filtering, if it was enabled by default
- `domain:<domain>` - include only events from users whose valid nip05 domain matches the domain
- `language:<two letter ISO 639-1 language code>` - include only events of a specified language
- `sentiment:<negative/neutral/positive>` - include only events of a specific sentiment
- `nsfw:<true/false>` - include or exclude nsfw events (default: true)

9
56.md
View File

@@ -4,10 +4,12 @@ NIP-56
Reporting
---------
`draft` `optional`
`optional`
A report is a `kind 1984` note that is used to report other notes for spam,
illegal and explicit content.
A report is a `kind 1984` event that signals to users and relays that
some referenced content is objectionable. The definition of objectionable is
obviously subjective and all agents on the network (users, apps, relays, etc.)
may consume and take action on them as they see fit.
The `content` MAY contain additional information submitted by the entity
reporting the content.
@@ -28,6 +30,7 @@ being reported, which consists of the following report types:
- `illegal` - something which may be illegal in some jurisdiction
- `spam` - spam
- `impersonation` - someone pretending to be someone else
- `other` - for reports that don't fit in the above categories
Some report tags only make sense for profile reports, such as `impersonation`

6
58.md
View File

@@ -83,7 +83,7 @@ Clients SHOULD attempt to render the most appropriate badge thumbnail according
["name", "Medal of Bravery"],
["description", "Awarded to users demonstrating bravery"],
["image", "https://nostr.academy/awards/bravery.png", "1024x1024"],
["thumb", "https://nostr.academy/awards/bravery_256x256.png", "256x256"],
["thumb", "https://nostr.academy/awards/bravery_256x256.png", "256x256"]
],
...
}
@@ -99,7 +99,7 @@ Clients SHOULD attempt to render the most appropriate badge thumbnail according
"tags": [
["a", "30009:alice:bravery"],
["p", "bob", "wss://relay"],
["p", "charlie", "wss://relay"],
["p", "charlie", "wss://relay"]
],
...
}
@@ -117,7 +117,7 @@ Honorable Bob The Brave:
["a", "30009:alice:bravery"],
["e", "<bravery badge award event id>", "wss://nostr.academy"],
["a", "30009:alice:honor"],
["e", "<honor badge award event id>", "wss://nostr.academy"],
["e", "<honor badge award event id>", "wss://nostr.academy"]
],
...
}

9
96.md
View File

@@ -82,14 +82,7 @@ it must use the "api_url" field instead.
### List of Supporting File Storage Servers
| Name | Domain |
| ------------- | ------------------------- |
| nostrcheck.me | https://nostrcheck.me |
| nostrage | https://nostrage.com |
| sove | https://sove.rent |
| nostr.build | https://nostr.build |
| sovbit | https://files.sovbit.host |
| void.cat | https://void.cat |
See https://github.com/aljazceru/awesome-nostr#nip-96-file-storage-servers.
## Upload

View File

@@ -5,6 +5,8 @@ reverse chronological order.
| Date | Commit | NIP | Change |
| ----------- | --------- | -------- | ------ |
| 2024-02-25 | [4a171cb0](https://github.com/nostr-protocol/nips/commit/4a171cb0) | [NIP-18](18.md) | quote repost should use `q` tag |
| 2024-02-10 | [c6cd655c](https://github.com/nostr-protocol/nips/commit/c6cd655c) | [NIP-46](46.md) | Params were stringified |
| 2024-02-16 | [cbec02ab](https://github.com/nostr-protocol/nips/commit/cbec02ab) | [NIP-49](49.md) | Password first normalized to NFKC |
| 2024-02-15 | [afbb8dd0](https://github.com/nostr-protocol/nips/commit/afbb8dd0) | [NIP-39](39.md) | PGP identity was removed |
| 2024-02-07 | [d3dad114](https://github.com/nostr-protocol/nips/commit/d3dad114) | [NIP-46](46.md) | Connection token format was changed |

View File

@@ -49,6 +49,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
- [NIP-30: Custom Emoji](30.md)
- [NIP-31: Dealing with Unknown Events](31.md)
- [NIP-32: Labeling](32.md)
- [NIP-34: `git` stuff](34.md)
- [NIP-36: Sensitive Content](36.md)
- [NIP-38: User Statuses](38.md)
- [NIP-39: External Identities in Profiles](39.md)
@@ -110,6 +111,10 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `1059` | Gift Wrap | [59](59.md) |
| `1063` | File Metadata | [94](94.md) |
| `1311` | Live Chat Message | [53](53.md) |
| `1617` | Patches | [34](34.md) |
| `1621` | Issues | [34](34.md) |
| `1622` | Replies | [34](34.md) |
| `1630`-`1633` | Status | [34](34.md) |
| `1971` | Problem Tracker | [nostrocket][nostrocket] |
| `1984` | Reporting | [56](56.md) |
| `1985` | Label | [32](32.md) |
@@ -162,14 +167,15 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `30315` | User Statuses | [38](38.md) |
| `30402` | Classified Listing | [99](99.md) |
| `30403` | Draft Classified Listing | [99](99.md) |
| `30617` | Repository announcements | [34](34.md) |
| `31922` | Date-Based Calendar Event | [52](52.md) |
| `31923` | Time-Based Calendar Event | [52](52.md) |
| `31924` | Calendar | [52](52.md) |
| `31925` | Calendar Event RSVP | [52](52.md) |
| `31989` | Handler recommendation | [89](89.md) |
| `31990` | Handler information | [89](89.md) |
| `39000-9` | Group metadata events | [29](29.md) |
| `34550` | Community Definition | [72](72.md) |
| `39000-9` | Group metadata events | [29](29.md) |
[nostrocket]: https://github.com/nostrocket/NIPS/blob/main/Problems.md
[lnpub]: https://github.com/shocknet/Lightning.Pub/blob/master/proto/autogenerated/client.md
@@ -214,6 +220,7 @@ Please update these lists when proposing NIPs introducing new event kinds.
| `l` | label, label namespace | annotations | [32](32.md) |
| `L` | label namespace | -- | [32](32.md) |
| `m` | MIME type | -- | [94](94.md) |
| `q` | event id (hex) | relay URL | [18](18.md) |
| `r` | a reference (URL, etc) | petname | |
| `r` | relay url | marker | [65](65.md) |
| `t` | hashtag | -- | |
@@ -222,9 +229,10 @@ Please update these lists when proposing NIPs introducing new event kinds.
| `bolt11` | `bolt11` invoice | -- | [57](57.md) |
| `challenge` | challenge string | -- | [42](42.md) |
| `client` | name, address | relay URL | [89](89.md) |
| `clone` | git clone URL | -- | [34](34.md) |
| `content-warning` | reason | -- | [36](36.md) |
| `delegation` | pubkey, conditions, delegation token | -- | [26](26.md) |
| `description` | invoice/badge description | -- | [57](57.md), [58](58.md) |
| `description` | description | -- | [34](34.md), [57](57.md), [58](58.md) |
| `emoji` | shortcode, image URL | -- | [30](30.md) |
| `encrypted` | -- | -- | [90](90.md) |
| `expiration` | unix timestamp (string) | -- | [40](40.md) |
@@ -233,7 +241,7 @@ Please update these lists when proposing NIPs introducing new event kinds.
| `imeta` | inline metadata | -- | [92](92.md) |
| `lnurl` | `bech32` encoded `lnurl` | -- | [57](57.md) |
| `location` | location string | -- | [52](52.md), [99](99.md) |
| `name` | badge name | -- | [58](58.md) |
| `name` | name | -- | [34](34.md), [58](58.md) |
| `nonce` | random | -- | [13](13.md) |
| `preimage` | hash of `bolt11` invoice | -- | [57](57.md) |
| `price` | price | currency, frequency | [99](99.md) |
@@ -246,6 +254,7 @@ Please update these lists when proposing NIPs introducing new event kinds.
| `summary` | article summary | -- | [23](23.md) |
| `thumb` | badge thumbnail | dimensions in pixels | [58](58.md) |
| `title` | article title | -- | [23](23.md) |
| `web` | webpage URL | -- | [34](34.md) |
| `zap` | pubkey (hex), relay URL | weight | [57](57.md) |
## Criteria for acceptance of NIPs