You are reading content from Scuttlebutt
@luandro %pGdE4ckDBiBBqe2c6jbsn3GZxxw0k1yI+lLqw/P4fKM=.sha256
Re: %tz/6ms3u5

From SSB protocol guide:

Message format

 {
  "previous": "%XphMUkWQtomKjXQvFGfsGYpt69sgEY7Y4Vou9cEuJho=.sha256",
  "author": "@FCX/tsDLpubCPKKfIrw4gc+SQkHcaD17s7GI6i/ziWY=.ed25519",
  "sequence": 2,
  "timestamp": 1514517078157,
  "hash": "sha256",
  "content": {
    "type": "post",
    "text": "Second post!"
  }
}
  • previous: as Arj noted, this is not strictly necessary, but how to we pass ssb-validation with this?
  • author: as Andre suggested, we can use just the 4 initial chars as prefix, and re-construct them on the other side (special id LoRa messages containing the full pub key and name would have been sent before-hand)
  • sequence: is necessary for other nodes to identify it's a message they don't have from this feed, correct?
  • timestamp: we could use LoRa device's timestamp for this
  • hash: we can trust all nodes to have the same
  • content: this is the heavy part, which we'll enforce on the client-side to use 140 characters

Signature ⚠️

All messages in a feed are signed by that feed’s long-term secret key.

This is tricky, and can't be re-constructed on the other side without leaking the private-key and it's an extra 117 bytes, which makes it impractical, requiring at least two packets to be sent ❗

Message key

A message ID is a hash of the message including signature.

This can be reconstructed on the other side as long as we have the signature.

Use case

  • LB (local offline network browser-user)
  • LM (local Manyverse user)
  • LP (local Pub)
  • IB (Internet browser-user)
  • IP (Internet Pub)

LB sends a public identification message to the LoRa mesh

LB --> name, full_pub_key --> SSB (about) --> compression --> LoRa mesh -->

All nodes eventually receive the identification message. Clients (just browser for now) pull the message from the LoRa node and reconstructs the about message (using trusted or already known secrets, such as Meshtastic channel), adds it to their db, and replicates it further using any means available (Bluetooth, Intranet, Internet).

LB sends a private message to IB

Since we don't know where the message receiver is at any given time, LB sends a private message to the whole LoRa mesh:

LB ----> boxed_msg ---> SSB ----> compression --> LoRa mesh ----> allNodes

       LB-11, LB-12 <--- SSB <------ decompression <----- LoRa node1 <-----

        LB-21 <--- SSB <------ decompression <----- LoRa node2 <-----

(Internet) <--- LM-31 <-- LP-31 <-- SSB <-- decompression <-- LoRa node3 <--
   |
   |
   |---> IP ---> IB ---> unbox

All LoRa nodes eventually receives the message and stores it.

LP-31 pulls messages from node3 decompresses the post message, adds to it's ssb-db, and replicates it.

LM-31 replicates with LP-31 through the local network.

LM-31 goes to town and replicates with IP

IB connects to IP and eventually receives the private message.


Signatures seem to be the byte-size bottleneck so far for SSB integration.

Join Scuttlebutt now