HTTP Messages

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).

Overview

Enables a local client to make and receive http requests from a remote computer. Requires:

A trusted machine to process the messages (can be a home PC or Raspberry Pi)
A relay (can be untrusted)
A blossom server (can be untrusted)

Architecture

Sequence Diagram

Event Structure

{
  "kind": 1120,
  "pubkey": "<pubkey>",
  "content": "nip44Encrypt({'url':'blossom.one','hash':'xx','decrypt':'password123'})",
  "tags": [
    ["E", "<request event id>"], // (RES) Request ID (mandatory)
    ["r", "https://relay.one"] // (REQ) Response Relay (optional)
  ],
  // other fields...
}

Explanations:

kind:1120 - BIP39 word #1120 (message).
"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 made available from inside private networks (localhost) but over nostr
maximum server privacy (no domain needed, or port forwarding)
Make regular API calls over Nostr