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. 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. To facilitate discovery of HTTP-over-Nostr servers, a dedicated event kind is used to advertise server availability.
```jsonc ```jsonc
{ {
"kind": 11120, "kind": 31120,
"pubkey": "<pubkey of server operator>", "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": [ "tags": [
["name", "My HTTP Server"], // Optional server name ["d", "<hex pubkey of server>"], // Server pubkey that will be listening for requests
["server", "<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.one"], // Relay where server is listening (can have multiple)
["relay", "wss://relay.two"], ["relay", "wss://relay.two"],
["expiry", "<unix timestamp>"], // How long this server will be online ["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... // other fields...
} }
@ -91,14 +88,14 @@ To facilitate discovery of HTTP-over-Nostr servers, a dedicated event kind is us
Explanations: 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. * `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 * `"content"` - Optional description of the server in markdown
* `"server"` - The pubkey of the HTTP server that will be processing requests * `"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) * `"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 * `"expiry"` - Timestamp after which this server advertisement should be considered expired. Can update this to 0 to indicate an expired event.
* `"p"` - Pubkeys allowed to send requests to this server (if none specified, server is public)
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>
<div class="diagram-container"> <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> <p class="diagram-caption">HTTP Messages Architecture Overview</p>
</div> </div>
@ -86,24 +86,50 @@
<li><strong>Blossom Storage</strong>: Stores larger payloads that don't fit in event content (untrusted)</li> <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> <li><strong>Trusted Device</strong>: Processes encrypted requests, makes actual HTTP calls, and returns responses</li>
</ul> </ul>
<h3>Process Flow</h3>
<h3>Sequence Diagram</h3>
<ol> <ol>
<li>Client converts HTTP request into kind 21120 event</li> <li>Client converts HTTP request into kind 21120 event</li>
<li>For large payloads, data is stored in Blossom server</li> <li>Client encrypts & pushes payload to Blossom (if large)</li>
<li>Event is published to a Nostr relay</li> <li>Client publishes event to Nostr relay</li>
<li>Trusted device retrieves the event</li> <li>Trusted device fetches the event</li>
<li>Trusted device decrypts event, fetches any blossom payloads if needed</li> <li>Trusted device decrypts event</li>
<li>Trusted device makes the actual HTTP request to the target server</li> <li>Trusted device fetches payload from Blossom (if large)</li>
<li>Response is encrypted and sent back through the same channel</li> <li>Trusted device makes the actual HTTP request</li>
<li>Client decrypts and processes the response</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> </ol>
<p>The remote server should periodically scan for expired RESPONSE events (and associated blossom blobs) and delete them.</p>
</section> </section>
<section class="section"> <section class="section">
<h2>Event Structure</h2> <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>{ <pre>{
"kind": 21120, "kind": 21120,
"pubkey": "&lt;pubkey&gt;", "pubkey": "&lt;pubkey&gt;",
@ -115,10 +141,11 @@
["expiration",&lt;unix timestamp&gt;] ["expiration",&lt;unix timestamp&gt;]
] ]
}</pre> }</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>{ <pre>{
"kind": 21120, "kind": 21121,
"pubkey": "&lt;pubkey&gt;", "pubkey": "&lt;pubkey&gt;",
"content": "encrypt({'url':'blossom.one','hash':'xx'},$decryptkey)", "content": "encrypt({'url':'blossom.one','hash':'xx'},$decryptkey)",
"tags": [ "tags": [
@ -127,17 +154,26 @@
["expiration",&lt;unix timestamp&gt;] ["expiration",&lt;unix timestamp&gt;]
] ]
}</pre> }</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>
<section class="section"> <section class="section">
<h2>Use Cases</h2> <h2>Considerations & Use Cases</h2>
<p>HTTP Messages is particularly useful in scenarios where:</p> <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> <ul>
<li>Privacy and anonymity are important concerns</li> <li><strong>Complexity</strong>: Many more moving parts than a direct request</li>
<li>Censorship might block direct connections</li> <li><strong>Speed</strong>: Each request/response requires multiple steps (encryption, signing, transmission, decryption, etc.)</li>
<li>You want to make regular API calls over Nostr</li> </ul>
<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> <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> </ul>
</section> </section>
</div> </div>