Switching from Wi-Fi to Ethernet while a document is open can leave the previous presence session visible for several seconds after the new connection is established. I can reproduce it consistently when the network handoff happens while the tab is in the background.

Extensions currently have no reliable way to distinguish an active connection from reconnecting or offline state. Exposing a small connection-state API would let integrations defer network-dependent actions instead of guessing from failed requests.

Rivet currently allows a client to present the same resume token again while the preious transport is still being torn down. In normal recconects this is harmless, but during a fast network handoff two transports can briefly race to restore the same subscription state. This affects Northstar because its client reconnect flow can open the replacemnet transport before the previous one has fully disappeared. I'd like to agree on the contract at the Rivet boundary rather than relying on client-side timing.

ight now the reconnect path assumes the remote document still exists. I think a local draft should survive deletion as a recoverable copy instead of disappearing when synchronization resumes.

This discussion began in `#general` after a user reported that reconnecting could silently overwrite unsent editor changes. The selected messages capture the investigation, the proposed operation-replay approach, the deleted-block edge case, and the resulting recovery behavior we agreed to implement.

Rivet currently uses a bounded per-subscriber queue before handing messages to Drift. When a client stops reading, we need a clear contract between the channel layer and the transport layer. The main options are: * block publishers until the subscriber catches up; * drop messages when the queue is full; * disconnect the slow subscriber with an explicit reason. My preference is a bounded queue followed by disconnection, because silently dropping messages would break Rivet’s delivery semantics. What guarantees can Drift provide when WebSocket writes remain backpressured?

After a project tab remains suspended for several minutes, resuming it causes the client to reconnect every few seconds. The UI state is restored correctly, but the realtime subscription appears to consume the same resume token twice. I’m reporting this in Northstar first because it presents as an application bug. We still need to determine whether the cause is in Northstar or Rivet.

You can see live beryl demos of presence, typing indicators, and cursors at https://demo.beryl.tylerbutler.com.

Thought this might be a good test out of the "to thread" feature.