A magical notebook being built by Chris Joel, carrying on the tradition of Subconscious and Noosphere.
- A user-sovereign public key infrastructure
- A self-verifying capability scheme
- Content addressable, versioned user data
- An efficient partial replication strategy
- A petname scheme for building connections with other users
- A native content type with petname-aware hyperlinks
Familiar Emails
Familiar #2
Dialog is designed for the user-origin web. A Dialog database is content addressed, forkable, mergeable and efficiently syncable. It is local-first, runs in a web browser tab, and works just fine when the user's device is completely offline. It assumes a user-centered authority model; no external authority is required to enable any of its features. It is even agnostic to the transport used when syncing across forks and replicas (sneakernets welcome).
Dialog will sound familiar to those of you who followed along when I was building Noosphere. Noosphere was remarkably effective for what it was. But, Noosphere made different trade-offs. I am hopeful that the trade-offs we have chosen for Dialog will make it a worthy successor and more generalized to boot.
Familiar #3
I'm three months into the effort to bootstrap Familiar. The jet lag is waning after my travel to and from the second annual Local-First Conference in Berlin. The premise of "LoFi" is in the name: developers increasingly value the end-user experience of network software that is able to run on their users' device with or without network availability. The talks were interesting across the board if you care about this topic (and you can stream them here on YouTube). My high-level takeaways are:
- Sync is a major topic of concern for local-first software: many (if not most) of the talks either focused on state synchronization, or included it as a major element of the presentation; there were several talks by folks building developer tools focused on enabling a combination local caching + some form of real-time synchronization of the local cache.
- Most local-first stacks still assume server authority: from the OG local-first duo PouchDB/CouchDB, to more recent projects like Jazz) and Zero, many of our tools still assume that there is a centralized canonical data source that is (probably) not controlled by the "local" user, which is another way of saying that they are built for a Same-origin Policy web.
aka Tyranny of Origin but I think this is still too shorthand for now.
We still haven't cracked the local-first authority model: we have a lot of tools that enable local-first data, but scant options for local-first authority; I was excited to learn about the progress being made on Keyhive and Beelay, a promising initiative being driven by some of the most talented people who are working on these problems. Much work remains ahead of us.
Many people are waiting on Keyhive and the Beelay sync layer.
The passion and ingenuity on display at the conference was exhilarating. But, I remain preoccupied with ruminations about power and how it manifests in the network. Most of the tools that we are building assume an authoritarian web. An excellent talk by Robin Berjon hit YouTube recently that explores the implications of this assumption. The Single-origin Policy web begets a digital feudal system, and this power structure in the network is increasingly shaping the power structures of our society. We need to make new assumptions, new kinds of tools and new institutions as we seek to subvert the powers that be.
Dialog DB
Dialog DB is nascent and highly experimental, but if it interests you then I invite you to follow its ongoing development on Github.
Dialog is being designed for a local-first, User-origin Policy web. Users of the single-origin web give up authority over their identity and their data to the hegemon of a digital fief. The user-origin web places the root of authority in the hands of each user. So, in Dialog:
- The canonical replica of a user's data is the local copy - the one on their device - even when the database lives in a web browser tab
- Authority is encoded in the data itself so it access control is self-evident and moves with data as it replicates across the network
- The server's role is to facilitate the transfer of data between replicas; it can be "dumb" storage (e.g., Amazon S3)
Dialog makes a new assumption about the shape of the web: that there may not be a server (and even when there is a server, it is not the canonical authority over a user's data). I gave a vertical slice demo of Dialog's query and "serverless" replication properties in Berlin; here is a hastily recorded screencast of the demo.