The Feb-era 700-line page documented client->server JSON messages the
server never acted on (handleMessage logs only), a wrong ping/pong
exchange, and missed every message type added since. Rewritten tight
(~100 lines), every claim pinned: dual auth (JWT ?token= or device
Bearer header), initial_state on connect under the connecting
identity's RLS scope, the full 12-type message catalog (including
collection_updated, found per-user-targeted in the collections handler
and defined as a raw string outside the sync constants), WS-frame
keepalive (30s server ping, 90s read deadline — browsers answer
automatically), and the backpressure contract clients must honor:
bounded per-connection queues skip messages when full, so the socket
is a hint and REST refetch + fresh initial_state is the gap-healer.
Fan-out documented precisely: sync/scan events instance-wide,
collection events per-user.
Also corrected the gated endpoint doc (api/websocket/protocol.md):
its 'client sends {type:ping}, server responds pong' section
contradicted the handler; replaced with the true keepalive story.
Route pin untouched — the drift gates stay green.
107 lines
2.1 KiB
Markdown
107 lines
2.1 KiB
Markdown
# WebSocket Protocol
|
|
|
|
Real-time sync events broadcast to connected clients.
|
|
|
|
## Connect to WebSocket
|
|
|
|
**Endpoint**: `WS /ws/sync?token=<token>`
|
|
|
|
### Connection Parameters
|
|
|
|
| Parameter | Type | Required | Description |
|
|
| --------- | ------ | -------- | ------------------------ |
|
|
| token | string | Yes | JWT authentication token |
|
|
|
|
### Example Connection
|
|
|
|
```javascript
|
|
const ws = new WebSocket("wss://bookhoard.com/ws/sync?token=eyJhbG...");
|
|
```
|
|
|
|
## Message Format
|
|
|
|
All messages are JSON objects with a `type` field.
|
|
|
|
### Client → Server Messages
|
|
|
|
None are interpreted. The socket is a one-directional push feed — the
|
|
server logs (but ignores) anything a client sends. All reads and writes
|
|
go through the REST API.
|
|
|
|
#### Keepalive
|
|
|
|
The server sends a WebSocket **ping frame every 30 seconds**; a
|
|
connection that misses pongs for 90 seconds is removed. Standard
|
|
WebSocket clients (browsers included) answer pongs automatically —
|
|
there is nothing to implement.
|
|
|
|
### Server → Client Messages
|
|
|
|
#### Progress Update
|
|
|
|
```json
|
|
{
|
|
"type": "progress_update",
|
|
"timestamp": "2026-01-31T10:00:00Z",
|
|
"data": {
|
|
"book_id": "uuid",
|
|
"progress": {
|
|
"percentage": 0.45678,
|
|
"epubcfi": "epubcfi(/6/4/2:15)",
|
|
"chapter": 3
|
|
},
|
|
"annotations": {}
|
|
},
|
|
"source_device": {
|
|
"id": "device-uuid",
|
|
"name": "My Kobo",
|
|
"type": "kobo"
|
|
}
|
|
}
|
|
```
|
|
|
|
Broadcast when any device updates reading progress.
|
|
|
|
#### Conflict Detected
|
|
|
|
```json
|
|
{
|
|
"type": "conflict",
|
|
"timestamp": "2026-01-31T10:00:00Z",
|
|
"data": {
|
|
"book_id": "uuid",
|
|
"conflict_id": "uuid",
|
|
"conflict_type": "progress"
|
|
}
|
|
}
|
|
```
|
|
|
|
Broadcast when a sync conflict is detected.
|
|
|
|
#### Pong
|
|
|
|
```json
|
|
{
|
|
"type": "pong"
|
|
}
|
|
```
|
|
|
|
Server response to client `ping`.
|
|
|
|
## Connection Management
|
|
|
|
- **Heartbeat**: Send `ping` every 30 seconds
|
|
- **Reconnect**: Use exponential backoff if connection drops
|
|
- **Authentication**: Token must be valid for connection
|
|
- **Rate Limits**: 60 messages/minute per connection
|
|
|
|
## Error Handling
|
|
|
|
```json
|
|
{
|
|
"type": "error",
|
|
"message": "Invalid token",
|
|
"code": "AUTH_FAILED"
|
|
}
|
|
```
|