Syncing data between peers

How bedrock updates propagate

Urbit is a distributed network, so bedrock must be a distributed database. Paths and peers specify the rules around the data distribution, but how does that data actually sync up between ships? We use the one-at-a-time subscription model described here. When a new path is created, the peers in that path are all poked by the host agent, telling them they have been added to a path. In response, they update their own paths-table and peers-table to match, and then subscribe to the "next" update from the host. This subscription remains open until the host actually sends out some update (like creating a new row). They receive the update on the subscription, are kicked, mutate their own state to process the update, and then resubscribe for the next update. By forcing peers to subscribe for each update, we avoid the unbounded memory problem that undelivered pokes can have, since when a peer goes offline, they simply will not be re-subscribing to the next update, and won't be "bothering" the host anymore until they come back online, at which point the host just brings them up to speed on what they missed. This is essentially a custom implementation of solid-state subscriptions we developed which solves some of the issues we have seen in our development of chat-db.

When the host adds a data-row to the path, it's no big deal, because he just sends out the update since he's the host. But what if a peer wants to add (or edit or delete) a data-row? The peer simply forwards its create/edit/delete poke to the host, who checks if that peer actually has permissions to modify the data in that way, and then the host does the modification and pushes the update to subscribers on the original peer's behalf. Simple.