fix: sequence diagram

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).
 
 ![](./http.png)
 
@@ -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
+ * `"content"` - encrypted (NIP-44) JSON with location of blob and decryption key **OR** the content itself (if under a threshold)
- * `"x"` - Blossom file hash of the encrypted request or response
  * `"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)
+
+
+
+
+
+
+
+