You are reading content from Scuttlebutt
@cel %3OZxCa/l3MhsmkhM/3tkQx63Yj5FozBiyyDGikNLUlI=.sha256
Re: %Ylr4TEMOH

%I1liEhf...: Implemented the get RPC method, to read a SSB message from the flumelog and keys hash table as written by scuttlebot, reusing code from ssbget.
Also implemented accepting connections via local unix noauth socket.
Also added a manifest method [%PIqXk7G...].

Some of the RPC methods I've implemented are not strictly required for replication, but they help with testing, debugging and administration/usage, and mostly don't add a lot of complexity. (i.e. blobs.{add,has,size,want}, manifest, stop). So I think this is okay. I might change my mind though if I can figure out a good way to test blobs gossip without blobs.want, for example.

The filesystem operations are synchronous/blocking. That is reading, writing and statting blobs, and reading (and eventually writing) messages and message indexes. It would be nice to make these async, to ensure responsiveness and minimize peers disconnections due to timeouts. This could be done using an additional thread(s), or aio - but it would increase implementation complexity. For now I want to focus on feature completeness and correctness.

Next things to do:

  • fix an issue with blobs.want
  • implement ooo message gossip
  • update keys hashtable
  • message verification

Later things to do:

  • message indexing by feed+sequence and latest per feed
  • createHistoryStream
  • ebt
  • contact graph indexing and traversal; requesting remote feeds
  • local peer discovery
  • gossip scheduler; pub message indexing
  • more testing

More things to do later, maybe:

  • message canonicalizing and signing
  • out-of-process plugins
  • index backlinks
  • web[socket] server
  • hsdt
Join Scuttlebutt now