Enum Notification 

pub enum Notification {
    DatabaseWrite {
        root_id: ID,
        previous_tips: Snapshot,
        post_tips: Snapshot,
        source: WriteSource,
    },
}

Server-initiated push to the client, interleaved with normal responses at any point after a connection has authenticated.

Notifications are not solicited by a specific request; the client signs up for them with a DatabaseOp::SubscribeWrites and unsubscribes by dropping the connection or sending DatabaseOp::UnsubscribeWrites.

Notifications are triggered only by settled-state writes — i.e. entries that have passed local verification on the daemon. An entry that arrives Unverified (via sync, or as a SubmitSignedEntry body) is ingested silently and only produces a notification once the daemon’s verification pass promotes it to Verified.

This does not mean the bracket contains only Verified entries. The cursors are raw DAG frontiers (Backend::snapshot), not the Verified frontier, so an Unverified or Failed entry sitting as a raw tip falls inside every subsequent bracket and Database::ids_added will enumerate it. A subscriber that expands a bracket and fetches the IDs can therefore observe entries that failed the daemon’s auth settings. Consumers that care must filter on verification status themselves; locally that is Backend::get_verification_status, and over the wire there is currently no way to do it at all — treat bracket-derived IDs as untrusted until read back through a gated path.

A second consequence of the raw-frontier cursor: because it advances past a still-Unverified tip, a later verify() that promotes that entry fires with previous_tips == post_tips for the subscriber, so ids_added returns empty and the promotion is never signalled. An entry can be reported once while untrusted and never mentioned again.

The frame carries cursor brackets only — no entry payloads, no entry IDs. Subscribers that need to enumerate the new entries expand the brackets locally via Database::ids_added. This decision has two consequences:

1. Security: per-tree Read is gated once at SubscribeWrites; the publisher fan-out does not re-check on each event. Shipping cursors only means a subscriber whose permission is revoked mid-session can at most learn that some write happened on the tree — never the contents of those writes, which would only reach the client through an explicit, currently-gated read.
2. Efficiency: sync ingest can batch many entries; a cursor pair is constant-size regardless of batch width.

Variants

DatabaseWrite

A settled-state write landed on the daemon for root_id.

• previous_tips is the daemon-side subscription cursor at the moment of this fire — i.e. the previous_tips of the event the daemon dispatched to this subscription’s callback. Useful for thin-forwarder topologies and trace/debug.
• post_tips is the daemon’s tips after this write. The client uses it to advance every local per-callback cursor for this tree — each local callback’s next event will have previous_tips = post_tips (the cursor moves forward by exactly one event).
• source distinguishes local-vs-sync for consumers that want to branch.

Fields

root_id: ID

previous_tips: Snapshot

post_tips: Snapshot

source: WriteSource

Trait Implementations

impl Clone for Notification

fn clone(&self) -> Notification

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for Notification

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl<'de> Deserialize<'de> for Notification

fn deserialize<__D>(__deserializer: __D) -> Result<Self, __D::Error>

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl Serialize for Notification

fn serialize<__S>(&self, __serializer: __S) -> Result<__S::Ok, __S::Error>

where __S: Serializer,

Serialize this value into the given Serde serializer.