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.

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:

{
    "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:

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).
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 encoded public key with the .nostr TLD suffix.
Subdomains are also base32 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.

3.8 KiB Raw Blame History