🔒️(yprovider) readOnly connections awareness propagation

[AntoLC]

Purpose

We noticed that a read-only connection was still able to propagate awareness updates (cursor/selection presence) to other clients, even though connectionConfig.readOnly already blocked document sync updates.

Override MessageReceiver.apply to no-op for any read-only connection instead of delegating to the original implementation, so neither document updates nor awareness updates ever propagate from it.
The connection itself is left open; only the message is dropped.

[dmonad]

Looks good! I will add an option to ignore awareness messages in yhub as well.

The one thing to look out for is whether the connection resets regularly. y-websocket-server, for example, will disconnect the user if it did not receive an update from that user.

[AntoLC]

Looks good! I will add an option to ignore awareness messages in yhub as well.

The one thing to look out for is whether the connection resets regularly. y-websocket-server, for example, will disconnect the user if it did not receive an update from that user.

@dmonad - Thank you for the review - Yes you were right, the ping pong to keep the connection alive was based on awareness , at least in Hocuspocus v3.4.4, I think they change this mechanism in their last version (>v4).

I did a fixup commit - when we get a awareness message from readOnly connection, we still intercept it, but send our own awareness message to keep this ping pong mechanism.

Wdyt ?

[dmonad]

Please investigate if that fixes the issue. y-websocket doesn't disconnect, it is the server that disconnects after a timeout. Returning the awareness message to the client might not help.