1  # Project
 2  
 3  # 2026 Jan 6
 4  
 5  Status
 6  
 7  - Working libp2p swarm, can detect peers with MDNS, good enough to start testing
 8  - Need to get libp2p-stream connections established, unlocks e.g. automerge-repo
 9  
10  Todo
11  
12  - Want to create mock discord-esque ui, where discord servers now correspond to Willow
13    namespaces (or subspaces, yet to be seen)
14  - Add contacts window like discord friends, populate suggestions from detected peers?
15  
16  # 2025 Dec 5
17  
18  I've written about this elsewhere but I can't find my notes so I'm going to write a summary here.
19  I want Zed to become a pluggable ecosystem for p2p local-first applications. I've already got a
20  fork of Zed that allows plugins in the shape of `fn init(cx: &mut App)` that works.
21  I want to prototype at least one full vertical including a p2p network and a distributed file system.
22  However I eventually want to have abstractions over network type and file system. For example, here
23  are building blocks I've been eyeing for some time:
24  
25  - Willow for data store / filesystem
26  - Iroh for p2p network (or libp2p, etc.)
27  - Automerge for collaborative editing (but I also now see iroh-docs)
28  - Zed itself has a native CRDT Text type, I'd want other doc formats to be pluggable so they could
29    be used first-class in Zed buffers/editors.
30  
31  One of the main challenges I foresee trying to abstract over several types of systems is needing some
32  way to unify an identity system. P2p systems tend to use some kind of public key for identity, but it's
33  not guaranteed for this to be the case and even so, there may be different key types. For example, Iroh
34  and Libp2p may have different formats used for public keys / Peer IDs. I think there may be a way to use
35  signed messages as a way to "associate" identities/keys, but I also worry about leaking such associations
36  in a world where privacy/anonymity should be treated as first-class.
37  
38  For now, I think I'll choose one full vertical stack and try to make an end-to-end prototype. Today I'm
39  mostly interested in Willow, Iroh, and Automerge. I see Iroh already has a working example of an automerge
40  repository. I think that Willow could serve as more of a "cold store" which is also the basis for permissioning,
41  given that Willow+Meadowcap already have permissioning and privacy built in mind. I think Automerge documents
42  could be cold-saved into Willow and be subject to Namespace/Subspace rules and capability sharing. On opening
43  a document, we could create a "Session" which is essentially loading into automerge-repo/samod to do live
44  editing. We could write a Session file into Willow, then when it syncs to other Willow peers, the hosting
45  Zed plugin could visually show that the document is being edited by somebody (subject to the visibility rules
46  of Willow namespaces).
47  
48  Side thought: Could a standard OS filesystem be expressed as a special case of a Willow namespace? In other
49  words, could Willow's own API be used as a filesystem abstraction that Zed could be pointed to, so that Zed
50  could be a first-class editor over both OS and Willow filesystems? Similarly, could we find an abstraction
51  that encompasses both Automerge and Zed CRDTs?
52  
53  Today's plan (because I need to focus)
54  
55  - Follow the iroh-examples/iroh-automerge-repo example and try to integrate it visually in Zed
56  - Can start with ad-hoc Iroh keys but eventually need a key store / identity/contact management system
57  -