fix: sequence diagram

This commit is contained in:
_ 2025-03-25 22:07:41 +00:00
parent 4dee92a508
commit 6acbf9fbe6

@ -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
* `"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)