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

nip443 initial commit

Browse Source
This commit is contained in:
asmogo 2024-10-16 09:06:25 +02:00 committed by GitHub
parent 1cda2dcc59
commit be57590435
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 74 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

74
443.md Normal file
View File

@ -0,0 +1,74 @@
NIP-443
======
Nostr Web Services (NWS)
======
`draft` `optional`
This NIP defines a standard for facilitating TCP requests over NOSTR relays to a specified destination. The 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.
* `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",
"entryPublicAddress": "<client public IP>"
}
```
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 `entryPublicAddress` field specifies the public IP address of the client (when the client wants to use the `CONNECTR` message type).
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 an initial TCP connection.
- The exit node receives this message to initiate a TCP connection with the upstream target (the destination).
2. `CONNECTR`:
- Similar to `CONNECT`, but includes a secondary connection from the exit node back to the client.
- The exit node creates a connection to the client using the `entryPublicAddress` provided in the message, allowing bidirectional communication.
3. `DATA`:
- Used for transmitting data to the upstream destination after a connection has been established.
- The `entryPublicAddress` parameter should only be provided when using `CONNECTR` message types.
Messages must be sent using events with `kind:28333`. The content must be encrypted using NIP-04 or NIP-44.
### Domain
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.
The client can use this domain to resolve the relays and the recipient of the messages.
#### 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-443 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.