nips/74.md

NIP-74
======

Nostr Web Services (NWS)
======

`draft` `optional`

This NIP defines a standard for facilitating TCP requests over NOSTR relays to a specified destination. One basic implementation is currently available at [https://github.com/asmogo/nws](https://github.com/asmogo/nws).

### Motivation

While Nostr has been primarily focused on message-based communications, there is a growing need to extend its capabilities to support other types of network communication, such as TCP.

The motivation behind NWS is to leverage the existing Nostr infrastructure to facilitate TCP connections in a decentralized and privacy-preserving manner. By using Nostr relays as intermediaries, clients can establish connections to remote servers without needing direct access to their IP addresses, thereby reducing exposure to potential security risks and censorship.

### Terminology
* `client` - The entity initiating a TCP request over NOSTR.
* `exit-node` - The entity receiving a TCP request over NOSTR and forwarding it to the intended destination.

## Kinds
* `28333: KindEphemeralEvent` - Used to specify TCP messages. Exit nodes must subscribe to this message kind. 
* `38333: KindAnnouncementEvent` - Used to publicly announce the exit node to clients.
* `38334: KindCertificateEvent` - Used to publish the SSL certificate for the exit node.

### Message Format
Every message must have the following format:
```json
{
    "key": "3b1f09a8-2b10-4daa-880c-2a392e781f09",
    "type": "CONNECT",
    "data": "GET /hello HTTP/1.1",
    "destination": "google.com",
}
```

The `key` field is used to identify the message and is required. All TCP messages from one stream must have the same key.

The `data` field contains the data to be transmitted to the destination.

The `destination` field specifies the destination of the TCP connection (if the exit node wants to establish a connection to a remote server).

The `type` field specifies the type of message and is required. There are three defined message types within this protocol:

1. `CONNECT`:
    - Used to establish the initial TCP connection.
    - The exit node receives this message to initiate a TCP connection with the upstream target (the destination).
2. `DATA`:
    - Used for transmitting data to the upstream destination after a connection has been established.

Messages must be sent using events with `kind:28333`. The content must be encrypted using NIP-44.

### Domain Name System

The `.nostr` domain of an exit node is a [base32](https://datatracker.ietf.org/doc/html/rfc4648) encoded public key with the `.nostr` TLD suffix.  
Subdomains are also [base32](https://datatracker.ietf.org/doc/html/rfc4648) encoded and are used to specify relay servers.
Base32 encodings are required to use the "Extended Hex Alpabeth" defined in RFC 4648 and should no contain any padding. 

This domain name system essential, as exit nodes can inform clients of how they can be reached while creating a `kind:38333` event.
Clients can use this domain to resolve the relays and the recipient of the messages they want dispatch.

#### Example:
Sending a request to the following domain:
`etpjkbpf60n30bhg5oo3kdpn6srg.7rqkr7rul8t6vbtekq0b3k274i696g47eo1765t9add20llitt9g.nostr`

will create direct message events for public key `3ef54d9f7eaa3a6fafaea680b1d047248c93408776027317a9535a2056b2ef53` on relay `ws://0.0.0.0:7777`.

### Basic Control Flow
Unlike traditional TCP/IP communications that resolve a domain name to an IP address and establish a direct connection, NIP-74 leverages NOSTR relays as intermediate proxies for TCP communications.

The client must send an encrypted direct message to the desired NOSTR public key, following the format outlined in the [Message Format] section.  
Upon receiving the message, the exit node will process the request according to the specified message type, facilitating communication between the client and the destination.