NIP-37 - Transport methods announcement
======


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 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):
```json
["<network>", "<address>"]
```
- `<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.


## 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
{
  "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>"]
  ]
}
```

## Reference Implementation
- Epoxy