stuff/1120-messages
6
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

31120

Browse Source
This commit is contained in:
n 2025-04-08 21:13:56 +01:00
parent 2d70707062
commit 8150c3ce1f
2 changed files with 66 additions and 33 deletions

23
README.md

@ -67,23 +67,20 @@ sequenceDiagram
The remote server should periodically scan for expired RESPONSE events (and associated blossom blobs) and delete them.
## Server Advertisement Event (Kind 11120)
## Server Advertisement Event (Kind 31120)
To facilitate discovery of HTTP-over-Nostr servers, a dedicated event kind is used to advertise server availability.
```jsonc
{
"kind": 11120,
"kind": 31120,
"pubkey": "<pubkey of server operator>",
"content": "HTTP-over-Nostr server", // Optional description
"content": "HTTP-over-Nostr server", // Optional markdown description of the http server(s)
"tags": [
["name", "My HTTP Server"], // Optional server name
["server", "<pubkey of server>"], // Server pubkey that will be listening for requests
["d", "<hex pubkey of server>"], // Server pubkey that will be listening for requests
["relay", "wss://relay.one"], // Relay where server is listening (can have multiple)
["relay", "wss://relay.two"],
["expiry", "<unix timestamp>"], // How long this server will be online
["p", "<allowed client pubkey>"], // Clients allowed to use this server (can have multiple)
["p", "<allowed client pubkey>"]
],
// other fields...
}
@ -91,14 +88,14 @@ To facilitate discovery of HTTP-over-Nostr servers, a dedicated event kind is us
Explanations:
* `kind:1120` - BIP39 word #1120 ([message](https://github.com/bitcoin/bips/blob/master/bip-0039/english.txt#L1120)) plus 10000 to make it replaceable.
* `"content"` - Optional description of the server
* `"server"` - The pubkey of the HTTP server that will be processing requests
* `kind:31120` - BIP39 word #1120 ([message](https://github.com/bitcoin/bips/blob/master/bip-0039/english.txt#L1120)) plus 30000 to make it addressable.
* `"content"` - Optional description of the server in markdown
* `"d"` - The hex pubkey of the HTTP server that will be processing requests
* `"relay"` - Relays where this server is listening for kind 21120 events (can have multiple)
* `"expiry"` - Timestamp after which this server advertisement should be considered expired
* `"p"` - Pubkeys allowed to send requests to this server (if none specified, server is public)
* `"expiry"` - Timestamp after which this server advertisement should be considered expired. Can update this to 0 to indicate an expired event.
Clients looking to use HTTP over Nostr can query for these kind 1120 events to discover available servers and determine if they have permission to use them.
Clients looking to use HTTP over Nostr can query for these kind 31120 events to discover available servers and may communicate with the server operator to get permission to use them.

76
client/help.html

@ -35,7 +35,7 @@
</div>
<div class="diagram-container">
<img src="../http.png" alt="HTTP Messages Architecture Diagram">
<img src="./http.png" alt="HTTP Messages Architecture Diagram">
<p class="diagram-caption">HTTP Messages Architecture Overview</p>
</div>
@ -86,24 +86,50 @@
<li><strong>Blossom Storage</strong>: Stores larger payloads that don't fit in event content (untrusted)</li>
<li><strong>Trusted Device</strong>: Processes encrypted requests, makes actual HTTP calls, and returns responses</li>
</ul>
<h3>Process Flow</h3>
<h3>Sequence Diagram</h3>
<ol>
<li>Client converts HTTP request into kind 21120 event</li>
<li>For large payloads, data is stored in Blossom server</li>
<li>Event is published to a Nostr relay</li>
<li>Trusted device retrieves the event</li>
<li>Trusted device decrypts event, fetches any blossom payloads if needed</li>
<li>Trusted device makes the actual HTTP request to the target server</li>
<li>Response is encrypted and sent back through the same channel</li>
<li>Client decrypts and processes the response</li>
<li>Client encrypts & pushes payload to Blossom (if large)</li>
<li>Client publishes event to Nostr relay</li>
<li>Trusted device fetches the event</li>
<li>Trusted device decrypts event</li>
<li>Trusted device fetches payload from Blossom (if large)</li>
<li>Trusted device makes the actual HTTP request</li>
<li>Trusted device gets HTTP response</li>
<li>Trusted device encrypts & pushes response payload to Blossom (if large)</li>
<li>Trusted device creates kind 21121 response event</li>
<li>Trusted device publishes response event to relay</li>
<li>Client fetches response event</li>
<li>Client decrypts event</li>
<li>Client fetches payload from Blossom (if large)</li>
<li>Client converts kind 21121 into HTTP response</li>
<li>Client deletes request blob (if exists)</li>
<li>Client deletes request event</li>
</ol>
<p>The remote server should periodically scan for expired RESPONSE events (and associated blossom blobs) and delete them.</p>
</section>
<section class="section">
<h2>Event Structure</h2>
<p>HTTP Messages uses Nostr kind 21120 events with a specific structure:</p>
<p>HTTP Messages uses several Nostr event kinds with specific structures:</p>
<h3>Request Event</h3>
<h3>Server Advertisement Event (Kind 31120)</h3>
<p>Used to facilitate discovery of HTTP-over-Nostr servers:</p>
<pre>{
"kind": 31120,
"pubkey": "&lt;pubkey of server operator&gt;",
"content": "HTTP-over-Nostr server", // Optional markdown description of the http server(s)
"tags": [
["d", "&lt;hex pubkey of server&gt;"], // Server pubkey that will be listening for requests
["relay", "wss://relay.one"], // Relay where server is listening (can have multiple)
["relay", "wss://relay.two"],
["expiry", "&lt;unix timestamp&gt;"], // How long this server will be online
]
}</pre>
<p>Clients looking to use HTTP over Nostr can query for these kind 31120 events to discover available servers and may communicate with the server operator to get permission to use them.</p>
<h3>HTTP Request (Kind 21120)</h3>
<pre>{
"kind": 21120,
"pubkey": "&lt;pubkey&gt;",
@ -115,10 +141,11 @@
["expiration",&lt;unix timestamp&gt;]
]
}</pre>
<p>NIP-44 is NOT used for the content encryption as the payload may be large, affecting bunker signing stability.</p>
<h3>Response Event</h3>
<h3>HTTP Response (Kind 21121)</h3>
<pre>{
"kind": 21120,
"kind": 21121,
"pubkey": "&lt;pubkey&gt;",
"content": "encrypt({'url':'blossom.one','hash':'xx'},$decryptkey)",
"tags": [
@ -127,17 +154,26 @@
["expiration",&lt;unix timestamp&gt;]
]
}</pre>
<p>A different kind is used for responses to help with filtering. There is no "p" tag as the "E" tag already identifies the request.</p>
</section>
<section class="section">
<h2>Use Cases</h2>
<p>HTTP Messages is particularly useful in scenarios where:</p>
<h2>Considerations & Use Cases</h2>
<p>This approach only makes sense in cases where privacy and anonymity are important, or if censorship is a concern.</p>
<h3>Drawbacks</h3>
<ul>
<li>Privacy and anonymity are important concerns</li>
<li>Censorship might block direct connections</li>
<li>You want to make regular API calls over Nostr</li>
<li>You need to make open source apps available from inside private networks</li>
<li>You want maximum server privacy with no domain needed or port forwarding</li>
<li><strong>Complexity</strong>: Many more moving parts than a direct request</li>
<li><strong>Speed</strong>: Each request/response requires multiple steps (encryption, signing, transmission, decryption, etc.)</li>
</ul>
<h3>Why Use It?</h3>
<ul>
<li>Enables a plethora of open source apps to be made available from inside private networks (localhost) but over Nostr</li>
<li>Maximum server privacy (no domain needed, or port forwarding)</li>
<li>Make regular API calls over Nostr</li>
<li>Enhanced privacy and anonymity</li>
<li>Resistance to censorship</li>
</ul>
</section>
</div>