fix: sequence diagram
This commit is contained in:
parent
4dee92a508
commit
6acbf9fbe6
71
README.md
71
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)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user