nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-12-22 08:25:53 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

simplify

Browse Source
This commit is contained in:
ArjenStens 2024-11-18 13:07:29 +00:00
parent dbe381b779
commit 51c7cf591b
1 changed files with 13 additions and 45 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

58
37.md
View File

@ -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
["<network>", "<address>"]
["<network>", "<address>", "<protocol>"]
```
- `<network>` describes the network.
- `<address>` describes how to address the service, this value may or may not include a protocol based on the tag's first value.
- `<network>` describes which network is used.
- `<address>` describes where to address the service.
- `<protocol>` describes which protocol/schema should be used
## 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.
#### 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", "<pubkey>"]
["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
```