Suppose we wanted to build automerge-auth, a successor to localfirst/auth. What would that look like?
Develop a recommended approach to authentication, authorization, and end-to-end encryption in the Automerge ecosystem.
type Group = {
id: Uuid
members: Group[]
keys: KeysetWithSecrets
graph:
}
import { exec as _exec } from 'child_process' | |
import fs from 'fs' | |
import path from 'path' | |
import { fileURLToPath } from 'url' | |
import { promisify } from 'util' | |
const exec = promisify(_exec) | |
// ensure outputDir exists | |
const __dirname = fileURLToPath(new URL('.', import.meta.url)) |
// Available variables: | |
// - Machine | |
// - interpret | |
// - assign | |
// - send | |
// - sendParent | |
// - spawn | |
// - raise | |
// - actions |
This is pseudo-documentation for a hypothetical auth provider for Automerge Repo built around @localfirst/auth.
A LocalFirstAuthProvider
is configured with information about the local user and device.
import { LocalFirstAuthProvider, createUser, createDevice } from 'automerge-repo-auth-localfirstauth'
This is a talk I keep referring back to, and I wanted to have it in text form. I grabbed the raw machine-generated transcript from YouTube and used GPT-3 to help me turn it into well-punctuated sentences and paragraphs. I had to do some additional cleanup, but it got me most of the way there - my first experience getting AI to help me out with a real task!
Rich Hickey, author of Clojure, and designer of Datomic presents a new way to look at database architectures in this talk from JaxConf 2012. https://www.youtube.com/watch?v=Cym4TZwTCNU
The title of this talk is "Deconstructing the Database".
A replicated key-value store that magically synchronizes with peers in the background.
Automerge is a CRDT that ...
The original Automerge API leaves a number of difficult problems to be solved in userland: Storage, network communication, and synchronization are all left as an exercise for the developer.