Keyhive

Summary

Keyhive Local-first access control 🐝 Keyhive is a project exploring local-first access control. It aims to provide a firm basis for secure collaboration, similar to the guarantees of private chat but for any local-first application. In this lab notebook, we’ll share snippets of our findings as we explore the problem space and prototype potential solutions. The entries start from the beginning, but you can jump to the most recent post: 05 · Syncing Keyhive 2024 Aug 1 As the local-first ecosystem matures, the contexts that local-first applications fill has also expanded. Local-first emphasizes collaboration, but the constraints on an application are different if you build an application for you and a handful of friends versus delivering a team-oriented product. Your data not being viewable or editable by everyone in the world is a basic requirement of applications ranging from planning a surprise party, corporate meeting notes, book drafts, and legal contracts. Today’s most common access control patterns assume a central server. While cloud auth tools are forever developing, generally speaking existing tools for cloud auth are very mature. Doing access control without a cloud auth server requires rethinking the underlying mechanics of how auth works. Keyhive is an attempt to do secure and efficient local-first auth while retaining the user experience found in familiar applications like Google Docs, Dropbox, GitHub, and Discord. We believe that these are table stakes for the next generation of local-first applications. A GitHub repository permissions page We’ve seen user-agency principals successfully applied to other contexts. Signal popularized end-to-end encrypted chat while retaining much of the convenience of less-secure messaging applications. We find ourselves asking “what would Signal for documents look like?” Least Surprise Unlike a cloud auth system which can depend on the network to keep data hidden behind a web API, local-first runs a complete copy of the a...