Compare commits
7 Commits
133bd9029f
...
87a7063086
| Author | SHA1 | Date |
|---|---|---|
ice-orestes
|
87a7063086 | |
Awiteb
|
7dec812f99 | |
Yoji Shidara
|
739f3c5263 | |
|
Yoji Shidara
|
8830525250 | |
|
ice-orestes
|
8b26618c30 | |
|
ice-orestes
|
587ba71a7e | |
|
ice-orestes
|
b99267571f |
2
21.md
2
21.md
|
|
@ -21,7 +21,7 @@ The identifiers that come after are expected to be the same as those defined in
|
||||||
|
|
||||||
### Linking HTML pages to Nostr entities
|
### Linking HTML pages to Nostr entities
|
||||||
|
|
||||||
`<link>` tags with `rel="alternate"` can be used to associate webpages to Nostr events, in cases where the same content is served via the two mediums (for example, a web server that exposes Markdown articles both as HTML pages and as `kind:30023' events served under itself as a relay or through some other relay). For example:
|
`<link>` tags with `rel="alternate"` can be used to associate webpages to Nostr events, in cases where the same content is served via the two mediums (for example, a web server that exposes Markdown articles both as HTML pages and as `kind:30023` events served under itself as a relay or through some other relay). For example:
|
||||||
|
|
||||||
```
|
```
|
||||||
<head>
|
<head>
|
||||||
|
|
|
||||||
8
22.md
8
22.md
|
|
@ -143,13 +143,13 @@ A comment on a website's url looks like this:
|
||||||
"tags": [
|
"tags": [
|
||||||
// referencing the root url
|
// referencing the root url
|
||||||
["I", "https://abc.com/articles/1"],
|
["I", "https://abc.com/articles/1"],
|
||||||
// the root "kind": for an url, the kind is its domain
|
// the root "kind": for an url
|
||||||
["K", "https://abc.com"],
|
["K", "web"],
|
||||||
|
|
||||||
// the parent reference (same as root for top-level comments)
|
// the parent reference (same as root for top-level comments)
|
||||||
["i", "https://abc.com/articles/1"],
|
["i", "https://abc.com/articles/1"],
|
||||||
// the parent "kind": for an url, the kind is its domain
|
// the parent "kind": for an url
|
||||||
["k", "https://abc.com"]
|
["k", "web"]
|
||||||
]
|
]
|
||||||
// other fields
|
// other fields
|
||||||
}
|
}
|
||||||
|
|
|
||||||
13
24.md
13
24.md
|
|
@ -8,8 +8,7 @@ Extra metadata fields and tags
|
||||||
|
|
||||||
This NIP keeps track of extra optional fields that can added to events which are not defined anywhere else but have become _de facto_ standards and other minor implementation possibilities that do not deserve their own NIP and do not have a place in other NIPs.
|
This NIP keeps track of extra optional fields that can added to events which are not defined anywhere else but have become _de facto_ standards and other minor implementation possibilities that do not deserve their own NIP and do not have a place in other NIPs.
|
||||||
|
|
||||||
kind 0
|
### kind 0
|
||||||
======
|
|
||||||
|
|
||||||
These are extra fields not specified in NIP-01 that may be present in the stringified JSON of metadata events:
|
These are extra fields not specified in NIP-01 that may be present in the stringified JSON of metadata events:
|
||||||
|
|
||||||
|
|
@ -19,24 +18,22 @@ These are extra fields not specified in NIP-01 that may be present in the string
|
||||||
- `bot`: a boolean to clarify that the content is entirely or partially the result of automation, such as with chatbots or newsfeeds.
|
- `bot`: a boolean to clarify that the content is entirely or partially the result of automation, such as with chatbots or newsfeeds.
|
||||||
- `birthday`: an object representing the author's birth date. The format is { "year": number, "month": number, "day": number }. Each field MAY be omitted.
|
- `birthday`: an object representing the author's birth date. The format is { "year": number, "month": number, "day": number }. Each field MAY be omitted.
|
||||||
|
|
||||||
### Deprecated fields
|
#### Deprecated fields
|
||||||
|
|
||||||
These are fields that should be ignored or removed when found in the wild:
|
These are fields that should be ignored or removed when found in the wild:
|
||||||
|
|
||||||
- `displayName`: use `display_name` instead.
|
- `displayName`: use `display_name` instead.
|
||||||
- `username`: use `name` instead.
|
- `username`: use `name` instead.
|
||||||
|
|
||||||
kind 3
|
### kind 3
|
||||||
======
|
|
||||||
|
|
||||||
These are extra fields not specified in NIP-02 that may be present in the stringified JSON of follow events:
|
These are extra fields not specified in NIP-02 that may be present in the stringified JSON of follow events:
|
||||||
|
|
||||||
### Deprecated fields
|
#### Deprecated fields
|
||||||
|
|
||||||
- `{<relay-url>: {"read": <true|false>, "write": <true|false>}, ...}`: an object of relays used by a user to read/write. [NIP-65](65.md) should be used instead.
|
- `{<relay-url>: {"read": <true|false>, "write": <true|false>}, ...}`: an object of relays used by a user to read/write. [NIP-65](65.md) should be used instead.
|
||||||
|
|
||||||
tags
|
### tags
|
||||||
====
|
|
||||||
|
|
||||||
These tags may be present in multiple event kinds. Whenever a different meaning is not specified by some more specific NIP, they have the following meanings:
|
These tags may be present in multiple event kinds. Whenever a different meaning is not specified by some more specific NIP, they have the following meanings:
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,113 @@
|
||||||
|
NIP-XXX
|
||||||
|
=======
|
||||||
|
|
||||||
|
Multiple Public Key Types and Signature Algorithms for Event Signing
|
||||||
|
-----
|
||||||
|
|
||||||
|
`draft` `optional`
|
||||||
|
|
||||||
|
This NIP defines a way for clients and relays to allow other types of ECC Public Keys and Signature Algorithms to be used in Nostr in a seamless manner.
|
||||||
|
|
||||||
|
### Motivation
|
||||||
|
|
||||||
|
As mentioned in [NIP-01](https://github.com/nostr-protocol/nips/blob/master/01.md):
|
||||||
|
|
||||||
|
> Each user has a keypair. Signatures, public key, and encodings are done according to the [Schnorr signatures standard for the curve `secp256k1`](https://bips.xyz/340).
|
||||||
|
|
||||||
|
This is a limitation for Nostr adoption, as many Blockchains and other Cryptographic Networks have already identities in place using different ECC Public Key curves, and may use different Signature Algorithms. Even Bitcoin pre Taproot uses `ECDSA/secp256k1` and not `Schnorr/secp256k1`.
|
||||||
|
|
||||||
|
In this case it is just the signatures that differ, and the public key derivation is based out of the same `secp256k1` curve, so the public keys remain valid, but for other networks that use `ed25519` signatures, for instance, not even the public keys would be valid, as the curve used is `Curve25519` instead.
|
||||||
|
|
||||||
|
This means that Nostr identities would have to be different than the ones used in the other networks, making it impossible to consider a direct match between one network identity and the other, for instance, for having a smart contract as a Nostr identity (public key).
|
||||||
|
|
||||||
|
### References
|
||||||
|
|
||||||
|
This proposal came together with inputs from many other proposals and discussions, but these are the main ones:
|
||||||
|
|
||||||
|
[NIP-01: Basic protocol flow description](https://github.com/nostr-protocol/nips/blob/master/01.md)<br>
|
||||||
|
[NIP-06: Basic key derivation from mnemonic seed phrase](https://github.com/nostr-protocol/nips/blob/master/06.md)
|
||||||
|
|
||||||
|
### Public Key Types and Signature Algorithms
|
||||||
|
|
||||||
|
A small list of networks and their ECC Key Derivation curves and Signature Algorithms:
|
||||||
|
|
||||||
|
| Network | ECC Curve | Signature Algorithm |
|
||||||
|
|---|---|---|
|
||||||
|
| Bitcoin (legacy) | secp256k1 | ECDSA |
|
||||||
|
| Bitcoin (taproot) | secp256k1 | Schnorr |
|
||||||
|
| Ethereum | secp256k1 | ECDSA |
|
||||||
|
| Litecoin | secp256k1 | ECDSA |
|
||||||
|
| Monero | curve25519 | EdDSA |
|
||||||
|
| Cardano | curve25519 | EdDSA |
|
||||||
|
| Ripple | secp256k1 | ECDSA |
|
||||||
|
| TON (Telegram) | curve25519 | EdDSA |
|
||||||
|
| Cardano | curve25519 | EdDSA |
|
||||||
|
| Stellar | curve25519 | EdDSA |
|
||||||
|
| Tezos | curve25519 | EdDSA |
|
||||||
|
| Zcash | curve25519 | EdDSA |
|
||||||
|
| Zcash (shielded) | secp256k1 | ECDSA |
|
||||||
|
|
||||||
|
From this small list it is clear that more than half of the public keys from these selected networks wouldn't be compatible with Nostr, and only a Bitcoin taproot wallet would be able to generate compatible signatures for Nostr events.
|
||||||
|
|
||||||
|
We want to eliminate this problem, and it is quite simple...
|
||||||
|
|
||||||
|
### Signature Prefixes
|
||||||
|
|
||||||
|
This NIP introduces a prefix mechanism for the `.sig` field of Nostr events, that by default (without any prefix) falls back to `schnorr/secp256k1`, but when present defines the signature algorithm and public key derivation curve.
|
||||||
|
|
||||||
|
#### Signature Algorithms
|
||||||
|
|
||||||
|
| Prefix | Signature Algorithm | ECC Curve (default) |
|
||||||
|
|---|---|---|
|
||||||
|
| schnorr | Schnorr | secp256k1 |
|
||||||
|
| ecdsa | ECDSA | secp256k1 |
|
||||||
|
| eddsa | EdDSA | curve25519 |
|
||||||
|
|
||||||
|
#### Public Key Derivation Curves
|
||||||
|
|
||||||
|
| Prefix | ECC Curve |
|
||||||
|
|---|---|
|
||||||
|
| secp256k1 | secp256k1 |
|
||||||
|
| secp256r1 | secp256r1 |
|
||||||
|
| curve25519 | Curve25519 |
|
||||||
|
| curve448 | Curve448 |
|
||||||
|
|
||||||
|
#### Signature Algorithm Prefix
|
||||||
|
|
||||||
|
To use a different Signature Algorithm, for instance ECDSA for legacy Bitcoin wallets, an event would look like this:
|
||||||
|
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"id": "567b41fc9060c758c4216fe5f8d3df7c57daad7ae757fa4606f0c39d4dd220ef",
|
||||||
|
"kind": "1",
|
||||||
|
"pubkey": "8e0d3d3eb2881ec137a11debe736a9086715a8c8beeeda615780064d68bc25dd",
|
||||||
|
"tags": [],
|
||||||
|
"content": "some note",
|
||||||
|
...
|
||||||
|
"sig": "ecdsa:3046022100a0e03de740d3a1136d443b0c24a252e08ae1ae4dd73f0f7dacfdc440c69ce45102210083b5ba4e0f34261b605848ad85ddf585637c7579e58e73058ab3c934a7ca05c2"
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
#### Signature Algorithm Prefix with a Different ECC Curve
|
||||||
|
|
||||||
|
To use another Signature Algorithm and another ECC Curve, an event would look like this:
|
||||||
|
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"id": "567b41fc9060c758c4216fe5f8d3df7c57daad7ae757fa4606f0c39d4dd220ef",
|
||||||
|
"kind": "1",
|
||||||
|
"pubkey": "8e0d3d3eb2881ec137a11debe736a9086715a8c8beeeda615780064d68bc25dd",
|
||||||
|
"tags": [],
|
||||||
|
"content": "some note",
|
||||||
|
...
|
||||||
|
"sig": "ecdsa/secp256r1:3046022100c04f4139d4d52aa516873a8a9fba77c54810ade51e7e1720b45934d51a9a1216022100a645e11aa3877f111caf486fbd199781dca85373da504f6eb3690439f7a1a222"
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
### Clients and Relays
|
||||||
|
|
||||||
|
Clients and Relays are free to choose what combinations of Signatures Algorithms and ECC Curves they support, the only mandatory one is `schnorr/secp256k1`, which is the default for Nostr, but highly encouraged to support more, at least `ecdsa` and `eddsa` with their default curves. This way Nostr network will be increasingly more compatible and possible to interoperate with other networks.
|
||||||
|
|
||||||
|
### Integration into NIP-01
|
||||||
|
|
||||||
|
We propose that this NIP, when discussed and approved, should be integrated into NIP-01, as it represents a global improvement for event signing. We decided to keep it separated in a different file to be more concise for discussion for now.
|
||||||
Loading…
Reference in New Issue