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.