research/remote_log
Oskar Thoren 6955e4c162
Sketch use cas hash for ns wip
2019-08-07 14:51:07 +08:00
..
src Sketch use cas hash for ns wip 2019-08-07 14:51:07 +08:00
.gitignore Better dir structure 2019-08-06 13:15:27 +08:00
README.md Node works with ad hoc protocol for both CAS and NS naive 2019-08-07 14:05:13 +08:00
node.nim WIP node async 2019-08-06 13:44:53 +08:00

README.md

Remote log mocking

Using socket server and client in Nim to mimick behavior of a remote log for data sync.

See https://notes.status.im/Rwh-18AdSgKAkhfwfBE-OA# for current sketch. More full spec to come.

Interfaces

A server represents a remote log. A client is an endpoint.

We need something to represent storage as well.

TODO: Break down roles into individual actors as scripts.

Node

Represents an endpoint, like a data sync node. Multiple actors.

Outside of using transport to send "live" messages (outside of scope here), it also uploads them to CAS and NS. Flow looks different for sending node and reciving node.

Sending node flow:

  1. CAS Update
  2. NS Update

Receiving node flow:

  1. NS fetch
  2. CAS fetch

Details to come.

Name system (NS)

E.g. DNS/ENS/Feeds. Fixed name for mutable resoures.

Supports which operations:

  • Update name with data => Ok/Error
  • Fetch name => data

Content-addressed storage (CAS)

Request/response interface for immutable data.

Supports two operations:

  • Upload data => id
  • Fetch id => data

Sketching interface

NS POST <> NS GET <>

CAS POST <> CAS GET <>

What's in <>?

  • hash string

  • blob

  • h1_3, h2_3], [h1_2, h2_2, next_page_chunk]

  • How do we want to encode this?

  • Or we can use protobuf or json

  • This seems mostly relevant for ns_head

  • lets just start with json thingy and NS/CAS sep