Files
bookhoard/docs/developer/api/websocket/protocol.md
T
John O'Keefe e40be80e78 docs(dev): websocket wire doc rewritten from source; endpoint doc ping claim fixed
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.
2026-11-02 14:55:16 -05:00

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"
}
```