Skip to content

Commit

Permalink
Sync with upstream including CONFLICT
Browse files Browse the repository at this point in the history
  • Loading branch information
github-actions[bot] committed Nov 29, 2024
2 parents 21330f2 + 0352f84 commit 6d10cd3
Show file tree
Hide file tree
Showing 8 changed files with 389 additions and 58 deletions.
12 changes: 6 additions & 6 deletions 29.md
Original file line number Diff line number Diff line change
Expand Up @@ -22,15 +22,15 @@ Relays are supposed to generate the events that describe group metadata and grou

A group may be identified by a string in the format `<host>'<group-id>`. For example, a group with _id_ `abcdef` hosted at the relay `wss://groups.nostr.com` would be identified by the string `groups.nostr.com'abcdef`.

Group identifiers must be strings restricted to the characters `a-z0-9-_`.
Group identifiers must be strings restricted to the characters `a-z0-9-_`, and SHOULD be random in order to avoid name collisions.

When encountering just the `<host>` without the `'<group-id>`, clients can choose to connect to the group with id `_`, which is a special top-level group dedicated to relay-local discussions.

Group identifiers in most cases should be random or pseudo-random, as that mitigates message replay confusion and ensures they can be migrated or forked to other relays easily without risking conflicting with other groups using the same id in these new relays. This isn't a hard rule, as, for example, in `unmanaged` and/or ephemeral relays groups might not want to migrate ever, so they might not care about this. Notably, the `_` relay-local group isn't expected to be migrated ever.
When encountering just the `<host>` without the `'<group-id>`, clients MAY infer `_` as the group id, which is a special top-level group dedicated to relay-local discussions.

## The `h` tag

Events sent by users to groups (chat messages, text notes, moderation events etc) must have an `h` tag with the value set to the group _id_.
Events sent by users to groups (chat messages, text notes, moderation events etc) MUST have an `h` tag with the value set to the group _id_.

`h` tags MAY include the group's name as the second argument. This allows `unmanaged` groups to be assigned human-readable names without relay support.

## Timeline references

Expand Down Expand Up @@ -241,4 +241,4 @@ A definition for `kind:10009` was included in [NIP-51](51.md) that allows client

### Using `unmanaged` relays

To prevent event leakage, replay and confusion, when using `unmanaged` relays, clients should include the [NIP-70](70.md) `-` tag, as just the `previous` tag won't be checked by other `unmanaged` relays.
To prevent event leakage, when using `unmanaged` relays, clients should include the [NIP-70](70.md) `-` tag, as just the `previous` tag won't be checked by other `unmanaged` relays.
24 changes: 23 additions & 1 deletion 46.md
Original file line number Diff line number Diff line change
Expand Up @@ -45,16 +45,38 @@ _リモート署名器_は、接続トークンを以下の形式で提供する
bunker://<remote-signer-pubkey>?relay=<wss://relay-to-connect-on>&relay=<wss://another-relay-to-connect-on>&secret=<optional-secret-value>
```

<<<<<<< HEAD
このトークンはユーザーによって_クライアント_に渡され、クライアントは指定されたリレーを介してリモート署名器に`connect`リクエストを送る。オプションのシークレットは、正常な1回の接続確立にのみ使用でき、_リモート署名者_は古いシークレットを用いて新たに接続を確立しようとする試みを無視するべきだ (SHOULD)。
=======
_user_ passes this token to _client_, which then sends `connect` request to _remote-signer_ via the specified relays. Optional secret can be used for single successfully established connection only, _remote-signer_ SHOULD ignore new attempts to establish connection with old secret.
>>>>>>> upstream/master
### クライアントによって直接接続が開始される場合

<<<<<<< HEAD
_クライアント_は次のような接続トークンを提供する:
=======
_client_ provides a connection token using `nostrconnect://` as the protocol, and `client-pubkey` as the origin. Additional information should be passed as query parameters:

- `relay` (required) - one or more relay urls on which the _client_ is listening for responses from the _remote-signer_.
- `secret` (required) - a short random string that the _remote-signer_ should return as the `result` field of its response.
- `perms` (optional) - a comma-separated list of permissions the _client_ is requesting be approved by the _remote-signer_
- `name` (optional) - the name of the _client_ application
- `url` (optional) - the canonical url of the _client_ application
- `image` (optional) - a small image representing the _client_ application

Here's an example:
>>>>>>> upstream/master
```
nostrconnect://<client-pubkey>?relay=<wss://relay-to-connect-on>&metadata=<json metadata: {"name":"...", "url": "...", "description": "...", "perms": "..."}>&secret=<required-secret-value>
nostrconnect://83f3b2ae6aa368e8275397b9c26cf550101d63ebaab900d19dd4a4429f5ad8f5?relay=wss%3A%2F%2Frelay1.example.com&perms=nip44_encrypt%2Cnip44_decrypt%2Csign_event%3A13%2Csign_event%3A14%2Csign_event%3A1059&name=My+Client&secret=0s8j2djs&relay=wss%3A%2F%2Frelay2.example2.com
```
<<<<<<< HEAD
このトークンはユーザーによって_リモート署名器_に渡され、リモート署名器は指定されたリレーを介して`client-pubkey``connect`*応答*イベントを送る。クライアントは接続応答の作成者から`remote-signer-pubkey`を探す。接続相手のなりすましを防ぐために`secret`値を指定する必要があり (MUST) _クライアント_は`connect`応答によって得られた`secret`を検証する必要がある (MUST)。
=======

_user_ passes this token to _remote-signer_, which then sends `connect` *response* event to the `client-pubkey` via the specified relays. Client discovers `remote-signer-pubkey` from connect response author. `secret` value MUST be provided to avoid connection spoofing, _client_ MUST validate the `secret` returned by `connect` response.
>>>>>>> upstream/master
## Request Events `kind: 24133`

Expand Down
2 changes: 1 addition & 1 deletion 47.md
Original file line number Diff line number Diff line change
Expand Up @@ -175,7 +175,7 @@ Request:
Response:

For every invoice in the request, a separate response event is sent. To differentiate between the responses, each
response event contains an `d` tag with the id of the invoice it is responding to, if no id was given, then the
response event contains a `d` tag with the id of the invoice it is responding to, if no id was given, then the
payment hash of the invoice should be used.

```jsonc
Expand Down
2 changes: 1 addition & 1 deletion 51.md
Original file line number Diff line number Diff line change
Expand Up @@ -29,7 +29,7 @@ For example, _mute list_ can contain the public keys of spammers and bad actors
| Public chats | 10005 | [NIP-28](28.md) chat channels the user is in | `"e"` (kind:40 channel definitions) |
| Blocked relays | 10006 | relays clients should never connect to | `"relay"` (relay URLs) |
| Search relays | 10007 | relays clients should use when performing search queries | `"relay"` (relay URLs) |
| Simple groups | 10009 | [NIP-29](29.md) groups the user is in | `"group"` ([NIP-29](29.md) group ids + mandatory relay URL) |
| Simple groups | 10009 | [NIP-29](29.md) groups the user is in | `"group"` ([NIP-29](29.md) group id + relay URL), `"r"` for each relay in use |
| Interests | 10015 | topics a user may be interested in and pointers | `"t"` (hashtags) and `"a"` (kind:30015 interest set) |
| Emojis | 10030 | user preferred emojis and pointers to emoji sets | `"emoji"` (see [NIP-30](30.md)) and `"a"` (kind:30030 emoji set) |
| DM relays | 10050 | Where to receive [NIP-17](17.md) direct messages | `"relay"` (see [NIP-17](17.md)) |
Expand Down
92 changes: 92 additions & 0 deletions 68.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,92 @@
NIP-68
======

Picture-first feeds
-------------------

`draft` `optional`

This NIP defines event kind `20` for picture-first clients. Images must be self-contained. They are hosted externally and referenced using `imeta` tags.

The idea is for this type of event to cater to Nostr clients resembling platforms like Instagram, Flickr, Snapchat, or 9GAG, where the picture itself takes center stage in the user experience.

## Picture Events

Picture events contain a `title` tag and description in the `.content`.

They may contain multiple images to be displayed as a single post.

```jsonc
{
"id": <32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>,
"pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
"created_at": <Unix timestamp in seconds>,
"kind": 20,
"content": "<description of post>",
"tags": [
["title", "<short title of post>"],

// Picture Data
[
"imeta",
"url https://nostr.build/i/my-image.jpg",
"m image/jpeg",
"blurhash eVF$^OI:${M{o#*0-nNFxakD-?xVM}WEWB%iNKxvR-oetmo#R-aen$",
"dim 3024x4032",
"alt A scenic photo overlooking the coast of Costa Rica",
"x <sha256 hash as specified in NIP 94>",
"fallback https://nostrcheck.me/alt1.jpg",
"fallback https://void.cat/alt1.jpg"
],
[
"imeta",
"url https://nostr.build/i/my-image2.jpg",
"m image/jpeg",
"blurhash eVF$^OI:${M{o#*0-nNFxakD-?xVM}WEWB%iNKxvR-oetmo#R-aen$",
"dim 3024x4032",
"alt Another scenic photo overlooking the coast of Costa Rica",
"x <sha256 hash as specified in NIP 94>",
"fallback https://nostrcheck.me/alt2.jpg",
"fallback https://void.cat/alt2.jpg",

"annotate-user <32-bytes hex of a pubkey>:<posX>:<posY>" // Tag users in specific locations in the picture
],

["content-warning", "<reason>"], // if NSFW

// Tagged users
["p", "<32-bytes hex of a pubkey>", "<optional recommended relay URL>"],
["p", "<32-bytes hex of a pubkey>", "<optional recommended relay URL>"],

// Specify the media type for filters to allow clients to filter by supported kinds
["m", "image/jpeg"],

// Hashes of each image to make them queryable
["x", "<sha256>"]

// Hashtags
["t", "<tag>"],
["t", "<tag>"],

// location
["location", "<location>"], // city name, state, country
["g", "<geohash>"],

// When text is written in the image, add the tag to represent the language
["L", "ISO-639-1"],
["l", "en", "ISO-639-1"]
]
}
```

The `imeta` tag `annotate-user` places a user link in the specific position in the image.

Only the following media types are accepted:
- `image/apng`: Animated Portable Network Graphics (APNG)
- `image/avif`: AV1 Image File Format (AVIF)
- `image/gif`: Graphics Interchange Format (GIF)
- `image/jpeg`: Joint Photographic Expert Group image (JPEG)
- `image/png`: Portable Network Graphics (PNG)
- `image/webp`: Web Picture format (WEBP)

Picture events might be used with [NIP-71](71.md)'s kind `34236` to display short vertical videos in the same feed.
90 changes: 90 additions & 0 deletions 86.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,90 @@
NIP-86
======

Relay Management API
--------------------

`draft` `optional`

Relays may provide an API for performing management tasks. This is made available as a JSON-RPC-like request-response protocol over HTTP, on the same URI as the relay's websocket.

When a relay receives an HTTP(s) request with a `Content-Type` header of `application/nostr+json+rpc` to a URI supporting WebSocket upgrades, it should parse the request as a JSON document with the following fields:

```json
{
"method": "<method-name>",
"params": ["<array>", "<of>", "<parameters>"]
}
```

Then it should return a response in the format

```json
{
"result": {"<arbitrary>": "<value>"},
"error": "<optional error message, if the call has errored>"
}
```

This is the list of **methods** that may be supported:

* `supportedmethods`:
- params: `[]`
- result: `["<method-name>", "<method-name>", ...]` (an array with the names of all the other supported methods)
* `banpubkey`:
- params: `["<32-byte-hex-public-key>", "<optional-reason>"]`
- result: `true` (a boolean always set to `true`)
* `listbannedpubkeys`:
- params: `[]`
- result: `[{"pubkey": "<32-byte-hex>", "reason": "<optional-reason>"}, ...]`, an array of objects
* `allowpubkey`:
- params: `["<32-byte-hex-public-key>", "<optional-reason>"]`
- result: `true` (a boolean always set to `true`)
* `listallowedpubkeys`:
- params: `[]`
- result: `[{"pubkey": "<32-byte-hex>", "reason": "<optional-reason>"}, ...]`, an array of objects
* `listeventsneedingmoderation`:
- params: `[]`
- result: `[{"id": "<32-byte-hex>", "reason": "<optional-reason>"}]`, an array of objects
* `allowevent`:
- params: `["<32-byte-hex-event-id>", "<optional-reason>"]`
- result: `true` (a boolean always set to `true`)
* `banevent`:
- params: `["<32-byte-hex-event-id>", "<optional-reason>"]`
- result: `true` (a boolean always set to `true`)
* `listbannedevents`:
- params: `[]`
- result: `[{"id": "<32-byte hex>", "reason": "<optional-reason>"}, ...]`, an array of objects
* `changerelayname`:
- params: `["<new-name>"]`
- result: `true` (a boolean always set to `true`)
* `changerelaydescription`:
- params: `["<new-description>"]`
- result: `true` (a boolean always set to `true`)
* `changerelayicon`:
- params: `["<new-icon-url>"]`
- result: `true` (a boolean always set to `true`)
* `allowkind`:
- params: `[<kind-number>]`
- result: `true` (a boolean always set to `true`)
* `disallowkind`:
- params: `[<kind-number>]`
- result: `true` (a boolean always set to `true`)
* `listallowedkinds`:
- params: `[]`
- result: `[<kind-number>, ...]`, an array of numbers
* `blockip`:
- params: `["<ip-address>", "<optional-reason>"]`
- result: `true` (a boolean always set to `true`)
* `unblockip`:
- params: `["<ip-address>"]`
- result: `true` (a boolean always set to `true`)
* `listblockedips`:
- params: `[]`
- result: `[{"ip": "<ip-address>", "reason": "<optional-reason>"}, ...]`, an array of objects

### Authorization

The request must contain an `Authorization` header with a valid [NIP-98](./98.md) event, except the `payload` tag is required. The `u` tag is the relay URL.

If `Authorization` is not provided or is invalid, the endpoint should return a 401 response.
Loading

0 comments on commit 6d10cd3

Please sign in to comment.