One contract per layer, or keep ISocket and IDriver

Question

Are ISocket and IDriver the right seam?

Evidence they are not:

• DDPDriver implements both, so at runtime there is exactly one object behind two contracts.
• The split is arbitrary: subscribe sits on ISocket but subscribeRoom on IDriver; login is on IDriver though Socket implements it; IDriver.config is any; subscribeNotifyUser is declared twice with different return types.
• The clients implement ISocket only to delegate — that is a facade, not a transport contract. RocketChatClient.socket is typed as the union and nearly every call site casts to pick a half.
• Protocols.MQTT has no driver and the import is commented out in lib/clients/Livechat.ts. That dead branch was the only justification for protocol pluggability.

The layering the code actually has is three: the DDP engine (frames, send, open/close, heartbeat), the driver (Rocket.Chat streams, method calls, login), and the client facade (REST plus realtime).

Decide whether to collapse to one contract per layer, whether the client facade is derived from the driver contract or hand-maintained, and whether Protocols.MQTT dies with the split.

Start by comparing ISocket, IDriver, DDPDriver, and the RocketChatClient.socket call sites, noting where casts and delegated implementations occur. Read lib/clients/Livechat.ts and the commented Protocols.MQTT import to understand the remaining protocol path. Done means the layering and contract strategy are decided, affected interfaces and callers are consistently updated, and the MQTT fate is resolved.