1. 35
  1. 3

    The Prototypes section, esp. the Findings subsection, are very interesting.

    1. 3

      This writing style/article layout makes it hard to stop reading, reminiscent of Bret Victor’s articles. What a nice read.

      1. 2

        Scuttlebutt (scuttlebutt.nz) is another example of peer to peer network with offline first support

        1. 4

          As somebody on scuttlebutt observed the other day, this document appears to be the result of an independent reinvention of offline-first philosophy by folks unaware of SSB.

          I suspect that a lot of SSB’s more elaborate mechanisms for guaranteeing consistency in the face of potentially-long update delays (like signature chains unique to individual nodes, the heavy use of large hashes for addressing, blocks & self-identification as messages, store-and-forward with a hop limit for message traversal, and design around potentially asymmetrical message visibility) will be required in local-first designs, & that complicates expectations around the operation of some of the applications they mention here.

          For instance: google docs’ collaborative editing mechanism simply fails to handle simultaneous editing if delays get too long, and intermediate delays cause unexpected behavior because there’s the expectation that every edit is with respect to a global ‘current’ state that the user of a slow machine might not be able to see; a local-first or offline-first collaborative editing system would not only need tree versioning & various kinds of merge support for that, but would need to expose the details of tree versioning to users much moreso than (say) vim does. (Presumably, signature chains would be used to handle the version tree – something that XU92 did or was planned to do, way back in the mid-80s.)

          Not all applications are even compatible with an offline-first attitude. A few weeks ago, I struggled to explain to somebody that cryptocurrency integration with SSB is a hard problem because we need to handle arbitrarily long delays in message delivery (in other words, if I sent somebody a payment a year ago they could recieve it tomorrow, if the three or four hops between us happen to prioritize the message wrong or be mostly offline, or never, if we never have less than five hops, and being able to handle such a delayed delivery or non-delivery is fundamental to an offline-first attitude). A single distributed ledger can’t handle such delays reliably and still be expected to be consistent enough to use for money: we can’t have payments be legitimate and then delegitimatize them based on delays in delivery that would be acceptable for the whole rest of the system, particularly if the user’s wallet takes the ‘offline first’ attitude that payments sent represent money that can’t be reused. One can drop out-of-band and use a normal cryptocurrency, but that’s in no wise real integration, since such payments don’t obey the rules of the rest of the system – it’s just a bag on the side of a scuttlebutt client.