The larger half is the pattern: collaborative transcription. Instead of one machine listening to everyone, each person's computer transcribes that person's own voice and shares the text with the others. The transcript the group sees is assembled from pieces that each came from the speaker's own machine. Nobody's audio goes to a server, and nobody's audio goes to anyone else's AI either. We've implemented this in Presence, our video call tool, and it's what we mean by collaborative local AI.

A call that transcribes itself

Anyone in a Presence call can ask for transcription. Everyone else gets a yes-or-no prompt, and those who say yes start transcribing their own microphone. You can also set your copy of Presence to say yes automatically. Each person's words show up in the room's transcript as they finish a sentence, labelled with their name, and a small subtitles icon on their tile shows who is transcribing.

The pattern has some really nice advantages, and you can see each one in how Presence does it.

• The cleanest audio. Each computer hears its owner's voice straight from the microphone, before it's compressed and sent over the network. Presence reads the raw microphone track, so the model works from the best signal there is, not from what survived the call.
• Attribution for free. The person who transcribed a line is the person who said it. Presence never has to work out who was speaking; every line arrives already labelled, from the speaker's own Moss.
• The work is spread out. Each computer transcribes one voice. A call with eight people costs each of them the same as a call with two, and no one machine has to be big enough to transcribe everyone.
• Each person decides. Transcription is something you turn on for yourself, not something done to you. In Presence you say yes or no to a request, and only your own voice is affected by your answer.

Presence keeps a transcript per visit to a room, from when you join to when you leave, with everyone's lines in it. You can look at past transcripts from the room's card, read them, download them as Markdown, or delete them. They're stored on your computer, like everything else in Moss.

One service, every tool

Presence is the first tool to use transcription, but it doesn't own it. Transcription is a Moss service, and any tool can ask for it. Moss itself already uses it in a second place: the Foyer, each group's built-in chat, has a microphone button next to the message box, so you can dictate a message, fix it up, and send it. You turn the service on under Settings → Services → Transcription, next to Local Discovery from last week's post. It's off by default. The first time a tool asks to use it, Moss asks you, and you can withdraw that permission later from the same place.

This is the pattern we want for Moss. Running a speech model is a big thing to ask of a tool: there's a 140 MB model to ship, a runtime to build for every platform, and memory to manage. If every tool did that on its own, you'd have five copies of the same model and five switches to find. Instead, Moss does it once, and a notes tool that wants to transcribe a recording, or a chat tool that wants voice input like the Foyer's, gets it with a few lines of code. And because Moss does it, you decide once, in one place, what the AI on your machine is allowed to hear.

Transcription is the first service of this kind. The same shape, a model Moss runs on your machine that tools ask to use with your permission, will carry the others we have planned.

For the technically curious

Feel free to skip this part.

• The runtime is whisper.cpp, built per platform and run by Moss's main process as a sidecar whisper-server. Moss ships the ggml-base.en model (about 141 MB). From dev.10, Settings also lets you download and switch to others, from tiny to larger multilingual ones. The model loads on first use, which takes one to ten seconds, stays loaded while any session is open, and unloads after five minutes idle.
• The API is weaveClient.localModels.asr in @theweave/api. A tool checks capabilities(), opens a session, pushes PCM16 audio at whatever sample rate it has, and gets back one event per utterance. Moss resamples, runs an energy-based voice activity detector, and commits a transcript after about 500 ms of silence. The full guide is docs/build/transcription.md in the Moss repo.
• Consent has two gates: the global switch in Settings, and a per-tool decision Moss asks for the first time a tool opens a session. Turning the switch off, or revoking a tool, closes its open sessions.
• Presence reads the raw microphone track, before mixing and before WebRTC encoding, so shared system audio is never transcribed as the speaker's words. Each committed utterance goes to the other participants over the room's existing signal channel, which means it's signed by the speaker's own agent key. Transcripts are stored per visit in IndexedDB and rendered to Markdown on demand.
• What's next is a fallback where another participant volunteers to transcribe for someone whose machine can't.

Over the past month we've worked on all three. They're in Moss 0.16.0-dev.8, and together they mean a group of people on the same Wi-Fi can do all of that with no internet at all.

Finding each other without a server

Normally Moss finds the other members of a group through a bootstrap server, which is a meeting point on the internet, and connects to them through a relay server. That works well until the internet or those servers are down. Then two people at the same table can't see each other, even though their laptops are a meter apart.

Local Discovery adds a second way. Devices on the same local network find each other directly, the same way printers and speakers show up on your network. When it's on, your group keeps working with no internet at all, as long as you're on the same network.

You turn it on under Settings → Services → Local Discovery. It's off by default. While it's on, other devices on the network can see that yours is running Moss. They can't see the names of your groups, because Moss announces each group by a fingerprint, not its name.

Handing someone the invite, in person

Getting someone into a group used to mean copying an invite link and then working out how to get it to them: email, a chat app, a message to someone sitting right next to you. Often the two of you don't share any channel yet, and that's the whole reason you're setting this up.

Now Moss can hand the invite over the local network, in one of two ways. Both start from the Local Network Scan tab in Invite People.

• List the group. Click List Group, and anyone on the network can find it on the Local Network tab of Moss's welcome screen (or in Join Group) and click Request access to join. This is for a room where everyone is welcome.
• Admit people yourself. The newcomer clicks Announce Myself, and Moss gives them a name like "Purple Monkey Fern", which they say out loud. You find that name in your Invite People dialog and click Add to Group. The group never shows up for anyone else.

Either way, the invite is sealed so that only the person joining can open it. Anyone else on the network doesn't learn it.

This is useful even when the internet works fine. Friends around a kitchen table, a session at a conference, a local meet-up: in all of these the people are in the same room, and the room is what you trust. You can see who you're inviting, and they can see whose group they're joining. Nobody has to swap email addresses first. Some guest and café Wi-Fi networks stop devices from seeing each other, so it won't work everywhere. The old copy-and-paste link is still there for those.

Getting tools from each other

Moss tools come from the tool library, which Moss downloads from the internet. When you join a group and open one of its tools for the first time, Moss fetches it from there.

Now, when Moss can't reach the tool library, it asks the other members of your group instead. If someone who is online already has the tool, Moss copies it from their computer and shows you how far along it is. So on a local network with no internet, a newcomer can still install every tool the group uses, straight from the people around them.

It works on your own computer too. If you make a new group while offline, Moss offers the tools you already have from your other groups, marked so you can tell where they came from.

Try it

Put the three together and a room full of people with no internet can open Moss, find each other, bring in someone new, and set up the tools they need. That's closer to what local-first should mean. If you try it at a meet-up, on a train, or at your kitchen table, we'd love to hear how it went.

For the technically curious

Feel free to skip this part.

• Local Discovery lives in a new bootstrap_mdns module in our fork of kitsune2, the networking layer under Holochain, and Moss ships it in a Holochain 0.7 build. It announces each network space over mDNS by a fingerprint, not its name, and dials the peers it hears directly, alongside the usual bootstrap and relay servers.
• The invite handover is Moss's own and runs outside Holochain, as a small UDP multicast beacon that stays on the local network. Each side makes a throwaway P-256 key pair, and the invite code is encrypted to the newcomer's key (ECDH, then HKDF, then AES-GCM) and sent to them directly.
• The announced name, e.g. "Purple Monkey Fern", is derived from the newcomer's key and never sent over the network, so sharing it person is how you check you're admitting the right person.
• Tool transfer uses the group's existing remote signals. The tool comes over in 4 MiB chunks, and the happ is checked byte for byte against the hash recorded in the group. For now the UI is only checked against the sending member's own file hashes, and we plan to tighten that.

Two libraries came out of the work on Presence, our video-call tool for Moss, and we extracted both to that end. This post is about the first, @lightningrodlabs/webrtc-peer. You give it two callbacks: one that sends a message to a peer, and one that you call when a message arrives. It gives you back a managed WebRTC connection for each peer, over whatever peer-to-peer channel your app already has. The next post is about the second library, and about what we do when WebRTC cannot connect at all.

The two servers in the middle

WebRTC is peer-to-peer after it connects. Two servers stand in the way of connecting. The first is the signaling server. Before any media flows, two browsers must exchange an offer, an answer, and a stream of ICE candidates, which are network addresses to try. WebRTC says nothing about how those setup messages travel. So every tutorial starts with a server to carry them, usually a WebSocket relay, and every deployment keeps that server forever.

The second is the relay. Two peers behind strict routers sometimes cannot hole-punch, that is, open a direct path to each other. Then the only way through is a TURN server, which relays the media, and every serious deployment runs one. Traffic through it is not peer-to-peer at all. This post is about removing the first server. The relay is a harder problem, and it is the subject of the next post.

In a Holochain app, the signaling server is not needed. Agents can already send messages directly to each other, through what Holochain calls remote signals. The network layer under Holochain handles NAT traversal and relaying, because everything else needs them too. NAT traversal is how two peers behind home routers reach each other. Presence did its WebRTC signaling this way from the start. There is no server, and the offer goes to the other agent the same way a chat message does.

That is the good news, and it is real. The less good news is what remains after the signaling problem goes away: a raw RTCPeerConnection, which gives you primitives, not a connection.

You must handle both sides negotiating at the same time, because that corrupts the signaling state if you let it happen. You must decide when a dropped ICE path deserves a quick ICE restart and when it needs a full teardown. You must also decide how long to wait between tries. You must collapse four separate state machines (ICE, DTLS, signaling, and the data channel) into one answer that your UI can show. When a connection fails on a laptop in another country, you need a structured record of what happened, not console logs.

Two years with simple-peer

Presence started in December 2023, and matthme built it on simple-peer, the library most people reach for. It served us for two years, and I do not want to be unkind to it. But like most WebRTC libraries, it assumes what a signaling server gives you. That means a reliable, ordered channel, and one side told in advance that it starts the call. Over a peer-to-peer channel, neither holds. By early 2026 we maintained a fork, and the field logs kept describing the same kind of failure, each time in a different form.

The failure that finally moved us was a reconnection loop that we captured in March. A peer on a VPN connected fine the first time. Then something ordinary happened, such as a video toggle or an ICE timeout, and the connection dropped. After that, every reconnection attempt failed. ICE checked for fifteen seconds, went to disconnected, and retried a quarter of a second later, forever, until the user left the room.

Leaving and waiting was the only cure, and the timing told the story. If the user came back after ten seconds, it failed again. If they came back after fifty seconds, it worked. Our retries hammered a NAT that wanted to be left alone, and the harder we retried, the longer it sulked. Retrying is not recovering.

At the end of March, I rewrote the connection layer as a proper state machine. It uses the W3C "perfect negotiation" pattern for glare, the case where both sides send an offer at once. With it, two simultaneous offers resolve instead of corrupting the state, and nobody has to be told in advance who starts. A serialized signaling queue makes sure that SDP operations, the offer and answer steps, cannot interleave.

There is one lifecycle, from idle through signaling, connecting, connected, reconnecting, disconnected, failed, and closed. Its transitions are guarded, so the machine logs an illegal move instead of silently taking it. A two-tier reconnection policy tries a cheap ICE restart first, and a full reconnect only after that, with backoff. A transition log captures a snapshot of every transport state on every move, because the thing we missed most was evidence.

For a few months, the old and new connection layers ran side by side in Presence, and the app chose one per peer. That let us compare them in real rooms. We deleted simple-peer from the codebase at the end of July.

Pulling it out

The connection code knew nothing about Holochain, apart from a small adapter that turned "send this to that agent" into a remote signal. So on May 20 it became a package, for any peer-to-peer app that has its own way to move messages. It asks three things of your transport:

• A stable, authenticated identity per peer. The library assigns polite and impolite negotiation roles by comparing peer ids, and it trusts you about who is talking.
• Agent-to-agent delivery, not broadcast.
• Best-effort delivery. The library tolerates loss, reordering, and duplicates. A session id scoped to the connection filters out signals left over from a previous attempt.

You do not need a reliable ordered channel, a relay, or a rendezvous service. Anything that can carry an opaque JSON blob from one peer to another will do: Holochain remote signals, a libp2p stream, or a plain WebSocket.

It is layered, so you take only the tier that you need. The core is a thin perfect-negotiation wrapper around RTCPeerConnection. On top of that sits the single-peer state machine with the reconnection policy. On top of that sits a ConnectionManager. It owns every peer in a room, routes inbound signals to the right one, propagates your local media, and exposes a view model per peer. The view model has the phase, whether the path is relayed, whether tracks are flowing, and a retry countdown.

It has no runtime dependencies. The browser's RTCPeerConnection is injectable, so the whole library runs headless under a mock in a few seconds. Presence also runs it nightly against real connections in a browser harness. The harness establishes connections, silently drops them, and hands them over. A mock can only fail in the ways that you taught it to.

What it does not do

Discovery, identity, authentication, and transport are the job of your peer-to-peer substrate, and in our case that is Holochain. It cannot conjure a path where there is none. If two peers cannot hole-punch and nobody runs a TURN server, the state machine will tell you precisely that it failed. That is all it can do, and it is the relay problem from the start of this post. The bytes for the offer got through, after all, and that is where the second library starts.

Large calls without a server

Today the library does mesh only. Every peer connects to every other peer and sends its media to each one. That works for a small room. But the number of connections, and the upload bandwidth each peer needs, grow with the square of the number of peers. A mesh call with video maxes out at a handful of people.

The usual answer is an SFU, a selective forwarding unit. An SFU receives each peer's media once and forwards it to everyone else. It is another server in the middle, and it is the reason most video-call products are not peer-to-peer even when a call is small.

Our plan is a distributed SFU. Instead of a server, peers with spare bandwidth volunteer to forward media for the room. A volunteer receives each source once and forwards a chosen subset to the peers that subscribe to it. Every node in the room is still a participant, so the call stays peer-to-peer. A room can grow past the mesh limit with full video.

The type definitions already reserve markers for the forwarding roles. The roadmap lists the three pieces that the work needs: media direction per connection, track forwarding across connections, and a topology with loop prevention. None of it is working code yet, and the roadmap says which pieces belong in the library and which belong to the app.

The even nerdier bits

There are some lessons from this work worth reporting here, so even if no human reads them, an LLM might benefit. A note on process first. We added tooling to Presence so that one participant in a room can request the connection logs from every other participant. We drove all development off those aggregate logs, so we were solving the real-world peer-to-peer issues, not the ones a mock produces. Two of the lessons are specific to peer-to-peer, because there is no server to referee.

Both sides need a shared idea of which attempt is current. A signaling server can order messages and tell both sides which session is live. Over best-effort peer-to-peer delivery, nobody does that for you. In June, we chased a reconnect deadlock of about twenty seconds. Each side's connection minted its own random id. After a teardown, a fresh state machine on one side sometimes latched onto the dead session's id and rejected the live peer's answers as stale.

The fix was an epoch, a counter for the current attempt, on every signal. The orchestrator allocates the epoch, it survives recreation, and it is authoritative for ordering. In August, the same theme came back at a finer grain. We scoped the epoch to the remote side's connection id, with tombstones, records of dead sessions, so a resurrected dead session cannot sneak back in.

Back off, and stop shouting. With no server in front of the NAT, nothing throttles you but yourself. In the August field session that produced 0.5.0, a dead relay drove eleven back-to-back retry sessions in under two and a half minutes. Each one re-flooded some thirty-five ICE candidates at the peer. The retry gap is now exponential, from a few hundred milliseconds out to seven seconds, and the library filters and deduplicates outbound candidates.

The same session showed that giving up from the disconnected state was an illegal transition in our own table. So the machine logged it as blocked and sat there dead instead of failing cleanly. The lifecycle guard did its job and told us. We had just never read that particular line before.

The other lessons are general WebRTC. Connected must mean that media is flowing. The data channel can be stuck while audio and video flow perfectly. So since 0.3.0 the phase means media-ready, and data-channel readiness is its own flag. Emit state changes, not log entries. An app that re-runs its on-connect work on every "connected to connected" log entry will renegotiate a call that was fine.

And one lesson is about us, not WebRTC. After 0.5.0, we found that Presence shipped two releases that still bundled 0.4.0. npm pulled the older version from the registry instead of linking the workspace copy. There is now a test that fails if the app resolves the library anywhere but the workspace package. Fixes that do not ship are not fixes.

Since almost all of it was done by LLMs, I thought it would be interesting to have this post, about what it took and what we learned, be written by an LLM as well. So below is the LLM's report of what it did and the lessons it learned along the way. For kicks, I asked it to write in my voice. It did a reasonable job, and it's worth reading. Three big topics:

1. Maintaining DNA stability.
2. Getting mature open-source UIs to work well with Syn (our real-time engine).
3. Working with LLMs.

I've lightly edited what it wrote, because as usual there were some "brain" farts. So, anyways, enjoy!
-e

All fifteen of Lightningrod Labs' Moss tools are now on Holochain 0.7, and in the Moss 0.16 tool library.

Notebooks Emergence KanDo Talking Stickies Gamez Who's In? Spreadsheets Converge DataTub Glass Bead Game Files Vines FarmHack Slate Acorn

Files and Vines are built on Damien's (ddd-mtl) libraries. Big thanks to him for letting us finish and publish their 0.7 ports.

The bytes are the agreement

A DNA's hash is its identity. Change one byte of the compiled wasm and you have a different DNA, which means a different network. Everyone on the old one is now alone in a room nobody else can get into.

That makes "we didn't touch the DNA" a slippery claim. Wasm builds aren't reproducible by default, because absolute file paths end up in the debug sections. At one point we added a comment to an integrity zome in Emergence. Just a comment, and the hash moved: Holochain's error macro bakes line numbers into the binary.

So instead of trusting ourselves not to rebuild, we made rebuilding impossible:

1. Each tool's happ is built once, stripped with wasm-opt, and published as its own release, with its hash recorded in the repo.
2. Every UI release downloads that frozen happ.
3. CI refuses to publish if the hash inside the package doesn't match.

Every happ on the 0.16 list is byte-for-byte what we froze, and we can ship UI fixes whenever we like without splitting a group.

It's also why we didn't wait for Holochain 0.7.1. Its HDK and HDI differ from 0.7.0 only in version pins; the breaking changes are in the conductor, which Moss ships, not us. Rebuilding against 0.7.1 would have forked every network for nothing, so these tools stay pinned to exactly 0.7.0.

Syn as glue

When Will and I first sketched out Syn, the idea was a general pattern for real-time collaboration on Holochain. This upgrade made clearer to me what that pattern is: glue between two layers of mature technology.

Automerge is a CRDT library people have spent years getting right. You don't write merge logic or sync code. You describe your state and its changes, and build the interface.

KanDo and Talking Stickies are home-grown UIs built this way. But the pattern also lets you take a full-featured editor and make it collaborative peer-to-peer. Spreadsheets does it with Univer's spreadsheet engine, and Slate with Excalidraw, the whiteboard many of you already know. Both have been in Moss for a while, and both have been fragile. Making them work well is the part of this upgrade I'm proudest of.

The trick was to lean on both layers and invent nothing in between. That's easier said than done, because the editors are still getting there too. Their teams have been adding the hooks that real-time collaboration needs release by release, the same way we have in Syn, and moving to their current versions is what finally made things work. Excalidraw stamps every element with a version number and a random nonce, and settles conflicts with one rule: higher version wins, and on a tie, lower nonce wins. Univer expresses every change as a small mutation it can replay from a collaborator. Automerge merges, the editor decides what a change means, and Syn carries it between peers.

Spreadsheets

Spreadsheets moved to the current Univer engine, four releases newer. Univer calls those breaking changes, but the saved workbook format hadn't changed, so old boards open fine.

Then came my favorite bug of the upgrade. Add a sheet, and everyone else saw it, but it vanished from your own screen. Delete one, and every sheet except the first disappeared. Reload, and everything was back.

The reload was the tell. The shared change log had been correct all along; only your local view was wrong. A reconciler was comparing the live workbook against the board's original creation snapshot, which never updates, and "fixing" the difference by deleting anything that wasn't there on day one.

With that fixed, undo started working too, and the way you'd want in a collaborative tool. In both editors undo is local to each person, and your peers' changes never land on your undo stack. (Spreadsheets gets that from how it replays peer changes; Slate has to tell Excalidraw explicitly.) Undo only undoes your own edits, which is right when five people are in the same document.

Slate

Slate used to get collaboration wrong in an understandable way. It ignored remote changes while you were drawing, then saved the whole scene when you finished. If someone moved a shape while you were mid-stroke, your save could quietly put it back.

Now it applies Excalidraw's version rule in both directions, and merges into the shared document property by property: if you recolor a box while I'm moving it, we both get our way. A freehand stroke appends only its new points instead of rewriting the whole line on every save. And it runs on Excalidraw 0.18 now.

Collaboration bugs only show up when more than one person is using the thing, and clicking around in three windows only gets you so far. So before shipping Slate we built a harness that runs three real agents (three conductors, three browsers) and checks that everyone ends up with the same drawing after:

• each agent editing its own shapes at the same time
• two agents editing the same shape at once: dragging, text, properties, undo
• long freehand strokes, alone and all together
• soak runs of continuous random editing

It found a real bug right away. When two people edited the same shape at the same moment, Automerge merged both edits correctly, but the merged shape carried a version and nonce that one canvas already had. That canvas decided nothing had changed and stayed stale for good. Every copy of the document agreed, and one screen was wrong. Slate now compares content, not just the version stamp, when it takes a peer's copy of a shape. The same round of fixes stopped board switching from folding the old board's drawing into the new one.

A 200-round soak with three agents:

That's three conductors on one machine, so a real network will be slower. What mattered is that it converged every time. Slate 0.5.0 shipped on those results.

Working with agents

I wrote a plan with a standard recipe for each tool. LLM agents did most of the porting, and separate agents reviewed that work. My part was what they can't do: open each tool in Moss as two users and decide whether it was ready to publish. Apart from Slate's, most of the bugs above turned up in those walkthroughs.

The agents were fast and mostly very good, and also wrong in instructive ways. One reported CI as green after checking only the release workflow, while the test workflow on two repos had been red the whole time (an old Nix couldn't evaluate the new toolchain). Another agent's "passing" test log contained a crash that never used the word "error".

What worked: every claim comes with evidence, and another agent goes and checks it.

What's next

Updating the Tauri-based Android builds of Vines, Emergence and KanDo.

And Moss itself. Moss 0.16.0-dev.6 (test 17) is out as a pre-release, and we'd love help testing it. Read the note at the top of the release first: it runs a patched Holochain and can only see people on the same build, so install it together with whoever you're testing with.

It's trying out a new handshake between peers. To connect in a group, a peer has to prove it knows the group's secret, so someone who only learns a group's ID can't gossip with it or find out who's in it. The handshake also introduces new members right away; today someone who just joined can stay invisible to the group for up to five minutes. More like this is coming before the official 0.16 release.

See you in Moss!

P.S. For the technically inclined:

• The frozen-happ release scripts are in each tool's repo. Start with RELEASE.md in notebooks.
• Slate's Excalidraw merge is in ui/src/elementSync.ts, and the three-agent harness is in e2e/, both in slate.
• The skill covers the gotchas that cost us the most time: npm caret ranges on 0.x versions, two git tags of one repo quietly putting two copies of a crate in your DNA, and the Rust 1.91 floor for the 0.7 crates.

What is Moss?

Moss is a peer-to-peer, privacy-first groupware designed for small teams who want to work together without relying on centralized platforms. Built on Holochain technology, Moss gives groups:

• True ownership of their data and communications
• Customizable tools that adapt to their specific needs
• Privacy by design - no surveillance, no tracking
• Open source foundation for transparency and community contribution

Why We’re Building This

We believe people deserve better tools for collective work. Tools that respect privacy, enable true ownership, and put relationships at the center.

The current landscape of collaboration software is dominated by platforms that:

• Extract value from user data
• Lock teams into proprietary ecosystems
• Prioritize growth metrics over user needs
• Can cut off access at any time

Moss offers a different path forward.

What to Expect on This Blog

This blog will be a place to:

• Share product updates and new features
• Explore ideas about collaboration and peer-to-peer technology
• Tell stories from the community using Moss
• Discuss technical architecture for developers interested in building on Holochain
• Announce events and workshops for the Moss community

Get Involved

Moss is currently in group-onboarding beta. If you’re interested in being among the first to use Moss for your team:

• Join the Early Movers Collective
• Download Moss and try it out
• Contribute to the open source project

We’re just getting started, and we’re excited to build this future together.