From 80fbea33a0e8717e20a44b52b7fb358349978fc6 Mon Sep 17 00:00:00 2001 From: ArjenStens Date: Wed, 6 Nov 2024 12:00:21 +0000 Subject: [PATCH 1/6] NIP-37 draft --- 37.md | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 37.md diff --git a/37.md b/37.md new file mode 100644 index 0000000000..88e18e3f11 --- /dev/null +++ b/37.md @@ -0,0 +1,40 @@ +NIP-37 +====== + +Transport methods announcement +----------------------------------- + +`draft` `optional` + +This NIP describes how digital services can announce how clients can reach them, it describes which network is used and depending on the network what other data is needed to reach it. + +## Motivation +Nostr decouples applications completely from the transportation layer, meaning services no longer have to be designed around a single transportation method, but can be accessible through a plethora of ways. This NIP is meant to act as a lookup system that tells a client what transportation methods can be used to access a service. + +#### Spec + +A replacable event of kind `11111` event containing or more of the following tag(s): +```json +["", "
"] +``` +- `` describes the network. +- `
` describes how to address the service, this value may or may not include a protocol based on the tag's first value. + +#### Example + +```json +{ + "kind": 11111, + "tags": [ + ["clearnet", "wss://some.domain.com"], + ["clearnet", "mailto:mail@example.com"], + ["tor", "ws://somehash.onion"], + ["i2p", "ws://somehash.b32.i2p/"], + ["lo-ra", "914.3Mhz"], + ["ipv4", "157.240.212.35"], + ["ipv6", "2001:db8:3333:4444:CCCC:DDDD:EEEE:FFFF"], + ["aviation", "pigeon://MainSt.45thAve"] + ] +} +``` + From 1ff0fade33881d9f33678ec3d66d12baf0b2414c Mon Sep 17 00:00:00 2001 From: ArjenStens Date: Thu, 7 Nov 2024 10:55:23 +0000 Subject: [PATCH 2/6] Add example --- 37.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/37.md b/37.md index 88e18e3f11..9b438514e1 100644 --- a/37.md +++ b/37.md @@ -11,7 +11,7 @@ This NIP describes how digital services can announce how clients can reach them, ## Motivation Nostr decouples applications completely from the transportation layer, meaning services no longer have to be designed around a single transportation method, but can be accessible through a plethora of ways. This NIP is meant to act as a lookup system that tells a client what transportation methods can be used to access a service. -#### Spec +## Spec A replacable event of kind `11111` event containing or more of the following tag(s): ```json @@ -20,7 +20,7 @@ A replacable event of kind `11111` event containing or more of the following tag - `` describes the network. - `
` describes how to address the service, this value may or may not include a protocol based on the tag's first value. -#### Example +## Example ```json { @@ -33,7 +33,8 @@ A replacable event of kind `11111` event containing or more of the following tag ["lo-ra", "914.3Mhz"], ["ipv4", "157.240.212.35"], ["ipv6", "2001:db8:3333:4444:CCCC:DDDD:EEEE:FFFF"], - ["aviation", "pigeon://MainSt.45thAve"] + ["aviation", "pigeon://MainSt.45thAve"], + ["nip04", ""] ] } ``` From 70e3cf76d9d1f96b0e07d4d9d3fc46c069b3abf9 Mon Sep 17 00:00:00 2001 From: ArjenStens Date: Thu, 7 Nov 2024 11:46:51 +0000 Subject: [PATCH 3/6] add rationale --- 37.md | 35 +++++++++++++++++++++++++++++++---- 1 file changed, 31 insertions(+), 4 deletions(-) diff --git a/37.md b/37.md index 9b438514e1..ba7f94b441 100644 --- a/37.md +++ b/37.md @@ -1,6 +1,7 @@ -NIP-37 +NIP-37 - Transport methods announcement ====== + Transport methods announcement ----------------------------------- @@ -9,9 +10,9 @@ Transport methods announcement This NIP describes how digital services can announce how clients can reach them, it describes which network is used and depending on the network what other data is needed to reach it. ## Motivation -Nostr decouples applications completely from the transportation layer, meaning services no longer have to be designed around a single transportation method, but can be accessible through a plethora of ways. This NIP is meant to act as a lookup system that tells a client what transportation methods can be used to access a service. +Nostr decouples applications completely from the transportation layer, meaning services no longer have to be designed around a single transportation method, but can be accessible through a plethora of ways. This NIP is meant to act as a lookup system that tells a client which transportation methods can be used to access its services. -## Spec +## Specification A replacable event of kind `11111` event containing or more of the following tag(s): ```json @@ -20,7 +21,30 @@ A replacable event of kind `11111` event containing or more of the following tag - `` describes the network. - `
` describes how to address the service, this value may or may not include a protocol based on the tag's first value. -## Example + +## Rationale + +### Similar proposals +There have been NIP proposals that touch the connection between pubkeys and addresses, examples of this are: +- [NIP-97 - Nostr Naming System](https://github.com/nostr-protocol/nips/blob/91fc18746824b3bf980ad1fa223927764dc51c74/97.md) +- [NIP-66 - Relay Discovery and Liveness Monitoring](https://github.com/nostr-protocol/nips/pull/230) + +#### NIP-97 +I believe NIP-97 is very close to solving the issue of this mapping. But it attempts to also include human-readable naming into the solution. I believe that human-readable naming of pubkeys/services is inherently different from mapping a pubkey to an address where a user can access that pubkey's services, which may or may not map to a legacy domain name. + +I argue that Nostr introduces a new paradigm of addressing services, and that that creates an opportunity to make services accessible through different networks and protocols at simultaneously. + +#### NIP-66 +NIP-66 covers discoverability from the client side and can be a very important tool to discern which services are worth connecting to. I think it can act as the feedback mechanism to the proposed event of this NIP. It can be used to build metrics for the various networks a pubkey announces it to be accessible. Things like `rtt` (round trip time) can also be different for each network and should be measured seperately. + +### Naming of services +Human-readable names are and will always be ambiguous and opinionated. Addressing is not nearly as ambiguous. A location is either controlled by a pubkey, or it is not. A pubkey can quite easily prove that it controls a location. +Therefore connecting a name to pubkey to a pubkey should be solved in a separate NIP. + +## Backwards Compatibility +This NIP introduces no breaking changes. + +## Examples ```json { @@ -39,3 +63,6 @@ A replacable event of kind `11111` event containing or more of the following tag } ``` +## Reference Implementation +- Epoxy + From dbe381b779527e75d6a64f72c7855a9d7664632c Mon Sep 17 00:00:00 2001 From: ArjenStens Date: Thu, 7 Nov 2024 11:50:34 +0000 Subject: [PATCH 4/6] wording --- 37.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/37.md b/37.md index ba7f94b441..22d31618e9 100644 --- a/37.md +++ b/37.md @@ -30,7 +30,7 @@ There have been NIP proposals that touch the connection between pubkeys and addr - [NIP-66 - Relay Discovery and Liveness Monitoring](https://github.com/nostr-protocol/nips/pull/230) #### NIP-97 -I believe NIP-97 is very close to solving the issue of this mapping. But it attempts to also include human-readable naming into the solution. I believe that human-readable naming of pubkeys/services is inherently different from mapping a pubkey to an address where a user can access that pubkey's services, which may or may not map to a legacy domain name. +I believe NIP-97 is very close to solving the issue of this mapping. However, it attempts to also include human-readable naming into the solution. I believe that human-readable naming of pubkeys/services is inherently different from mapping a pubkey to an address where a user can access that pubkey's services, which may or may not map to a legacy domain name. I argue that Nostr introduces a new paradigm of addressing services, and that that creates an opportunity to make services accessible through different networks and protocols at simultaneously. From 51c7cf591b8648cec7c5c28939ef4e36cca04cb6 Mon Sep 17 00:00:00 2001 From: ArjenStens Date: Mon, 18 Nov 2024 13:07:29 +0000 Subject: [PATCH 5/6] simplify --- 37.md | 58 +++++++++++++--------------------------------------------- 1 file changed, 13 insertions(+), 45 deletions(-) diff --git a/37.md b/37.md index 22d31618e9..1cda6cd17e 100644 --- a/37.md +++ b/37.md @@ -9,60 +9,28 @@ Transport methods announcement This NIP describes how digital services can announce how clients can reach them, it describes which network is used and depending on the network what other data is needed to reach it. -## Motivation -Nostr decouples applications completely from the transportation layer, meaning services no longer have to be designed around a single transportation method, but can be accessible through a plethora of ways. This NIP is meant to act as a lookup system that tells a client which transportation methods can be used to access its services. - ## Specification -A replacable event of kind `11111` event containing or more of the following tag(s): +A replacable event of kind `11111`, containing one or more of the following tag(s): + ```json -["", "
"] +["", "
", ""] ``` -- `` describes the network. -- `
` describes how to address the service, this value may or may not include a protocol based on the tag's first value. - - -## Rationale - -### Similar proposals -There have been NIP proposals that touch the connection between pubkeys and addresses, examples of this are: -- [NIP-97 - Nostr Naming System](https://github.com/nostr-protocol/nips/blob/91fc18746824b3bf980ad1fa223927764dc51c74/97.md) -- [NIP-66 - Relay Discovery and Liveness Monitoring](https://github.com/nostr-protocol/nips/pull/230) - -#### NIP-97 -I believe NIP-97 is very close to solving the issue of this mapping. However, it attempts to also include human-readable naming into the solution. I believe that human-readable naming of pubkeys/services is inherently different from mapping a pubkey to an address where a user can access that pubkey's services, which may or may not map to a legacy domain name. - -I argue that Nostr introduces a new paradigm of addressing services, and that that creates an opportunity to make services accessible through different networks and protocols at simultaneously. +- `` describes which network is used. +- `
` describes where to address the service. +- `` describes which protocol/schema should be used -#### NIP-66 -NIP-66 covers discoverability from the client side and can be a very important tool to discern which services are worth connecting to. I think it can act as the feedback mechanism to the proposed event of this NIP. It can be used to build metrics for the various networks a pubkey announces it to be accessible. Things like `rtt` (round trip time) can also be different for each network and should be measured seperately. - -### Naming of services -Human-readable names are and will always be ambiguous and opinionated. Addressing is not nearly as ambiguous. A location is either controlled by a pubkey, or it is not. A pubkey can quite easily prove that it controls a location. -Therefore connecting a name to pubkey to a pubkey should be solved in a separate NIP. - -## Backwards Compatibility -This NIP introduces no breaking changes. - -## Examples +## Example ```json { "kind": 11111, "tags": [ - ["clearnet", "wss://some.domain.com"], - ["clearnet", "mailto:mail@example.com"], - ["tor", "ws://somehash.onion"], - ["i2p", "ws://somehash.b32.i2p/"], - ["lo-ra", "914.3Mhz"], - ["ipv4", "157.240.212.35"], - ["ipv6", "2001:db8:3333:4444:CCCC:DDDD:EEEE:FFFF"], - ["aviation", "pigeon://MainSt.45thAve"], - ["nip04", ""] + ["clearnet", "some.domain.com", "wss"], + ["tor", "somehash.onion", "ws"], + ["i2p", "somehash.b32.i2p/", "ws"], + ["ipv4", "157.240.212.35", "http"], + ["ipv6", "2001:db8:3333:4444:CCCC:DDDD:EEEE:FFFF", "http"] ] } -``` - -## Reference Implementation -- Epoxy - +``` \ No newline at end of file From 6312073d783b346ca36ccea515071d7624331042 Mon Sep 17 00:00:00 2001 From: ArjenStens Date: Mon, 18 Nov 2024 13:09:55 +0000 Subject: [PATCH 6/6] change title --- 37.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/37.md b/37.md index 1cda6cd17e..e2216631ae 100644 --- a/37.md +++ b/37.md @@ -1,7 +1,6 @@ -NIP-37 - Transport methods announcement +NIP-37 ====== - Transport methods announcement -----------------------------------