From 6acbf9fbe69920203cf522d35641f9ea4a14c407 Mon Sep 17 00:00:00 2001 From: _ <> Date: Tue, 25 Mar 2025 22:07:41 +0000 Subject: [PATCH] fix: sequence diagram --- README.md | 71 ++++++++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 65 insertions(+), 6 deletions(-) diff --git a/README.md b/README.md index c32db03..8598333 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,6 @@ # HTTP Messages -A specification for exchanging data using remote HTTP messages on a trusted server +A specification for sending/receiving HTTP messages (request/response) via a remote server. Header / Body etc are encrypted, either in the `content` (small messages) or via a blossom server (larger requests).  @@ -32,18 +32,46 @@ pc:L -- R:blossom pc:L -- R:relay pc:B <--> T:bbi - ``` +## Sequence Diagram + +```mermaid +sequenceDiagram + autoNumber + participant c as Nostr Client + participant r as Nostr Relay + participant b as Blossom Server + participant s as HTTP Server + + Note over c: Convert Request<br>into kind 1120 + c-->>b: Encrypt & push payload (if large) + c->>r: Publish <br>Event + r<<-->>s: Fetch event + Note over s: Decrypt event + s<<-->>b: Fetch payload <br>(if large) + Note over s: Prepare REQUEST + Note over s: Make HTTP REQUEST + Note over s: Get HTTP RESPONSE + s-->>b: Encrypt & push <br>payload (if large) + s->>r: Publish <br>Event + r<<-->>c: Fetch event + Note over c: Decrypt event + c<<-->>b: Fetch payload (if large) + Note over c: Provide RESPONSE + + +``` + + ## Event Structure ```jsonc { "kind": 1120, "pubkey": "<pubkey>", - "content": "nip44Encrypt({'url':'blossom.one','decrypt':'password123'})", + "content": "nip44Encrypt({'url':'blossom.one','hash':'xx','decrypt':'password123'})", "tags": [ - ["x", "<hash of encrypted message blob>"] ["E", "<request event id>"], // (RES) Request ID (mandatory) ["r", "https://relay.one"] // (REQ) Response Relay (optional) ], @@ -54,11 +82,42 @@ pc:B <--> T:bbi Explanations: * `kind:1120` - BIP39 word #1120 ([message](https://github.com/bitcoin/bips/blob/master/bip-0039/english.txt#L1120)). - * `"content"` - encrypted (NIP-44) JSON with location of blob and decryption key - * `"x"` - Blossom file hash of the encrypted request or response + * `"content"` - encrypted (NIP-44) JSON with location of blob and decryption key **OR** the content itself (if under a threshold) * `"E"` - ID of the request event. Enables a response to be easily identified. * `"r"` - (optional) relay on which the response should be sent. For Requests only. +## Considerations + +This approach only makes sense in cases where privacy and anonymity are important, or if censorship is a concern. + +There are a number of drawbacks to the approach: + + - Complexity. Many more moving parts than a direct request. + - Speed. Each request/response now requires: + - Encrypting the payload + - Loading to blossom (if large) + - Signing event + - broadcasting event + - remote server fetching event + - remote server decrypting event + - remote server fetching blossom blob (if large) + - remote server decrypting blossom blob (if used) + - making the actual request + +And the same flow in reverse. + +So why would you use it? Several reasons: + +- enables a plethora of open source apps to be privately hosted "on nostr" using a localhost API +- maximum server privacy (no domain needed, or port forwarding) + + + + + + + +