1. 20
  1.  

  2. 3

    Global key-value stores without cryptocurrency crap are pretty cool, I wish one took off. dename didn’t, sadly.

    It’s mostly written in Go (1.11+ required)

    >_<

    LF’s intrinsic conflict resolution mechanism relies upon proof of work as a hard to forge proxy for time

    hmm, right, with a merkle dag it sort of is like time.

    I have some ideas though:

    • why not use multiple known public sources of signed timestamps as a(nother) proof of time? The node that wants to claim a name gets (a hash of) the name signed together with a timestamp by public servers:
      • For example, including the name in a Roughtime request nonce might accomplish that;
      • as well as including it as a request header when getting a Signed HTTP Exchange (and the cool thing here is that the certificate of the server that signed the exchange can be checked on Certificate Transparency..)
    • why not protect subsequent updates of a claimed name with a simple pubkey signature check? (updates must be signed simply by the same key as the initial claim) — sort of like TOFU in SSH, a simpler alternative to certificates
      • this can be exposed to users in a convenient way via text passphrases (like BIP39 “brainwallets”)
    1. 2

      I’m the author, and here’s some responses:

      Why not use multiple known public sources of signed timestamps…?

      Not a bad idea. LF is a work in progress. They could be another input in trust / conflict resolution.

      Why not protect subsequent updates…?

      It does this. Multiple entries with the same claimed name are treated as one in terms of trust verification and also carry the ‘weight’ (proof of work cumulative weight) of all versions, not just the latest version. That’s just not clear in the current docs. The query and scoring code is actually somewhat complex: look up all records by key, group by owner, add all revisions, …

    2. 2

      This looks really, really cool. I have a couple questions that I didn’t see covered in the blog post (but if I missed something feel free to just point that out!):

      1. What’s the timeline like for integrating this into ZeroTier? Has it already been done?
      2. What is the relationship between LF to ZeroTier root servers? Does this completely obsolete ZeroTier root servers, and if so is that replacement optional? Or does it just augment them?
      1. 3
        1. Integration is happening.

        2. It’ll run behind a root server as its data store giving it full “situational awareness.” Basically it will let the roots that we run and the roots that you run be effectively the same node, like different instances of a microservice connected to the same database and event bus. So if you want to run your own roots they will act exactly like ours, but be on your stuff (even in the same building if you want really good low latency!).

        BTW LF has another neat property: you can disconnect from the network and it keeps working with its current data set, then when you reconnect your data will be merged. So you could set up roots that work across transient connections. You could also go air-gapped and your stuff would keep working. If you ever want to un-air-gap, it keeps working and just re-merges with the net.

        (I’m the author.)