0 Fork 0

Files

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

2.1 KiB

Raw Blame History

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

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

{
  "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

{
  "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

{
  "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

{
  "type": "error",
  "message": "Invalid token",
  "code": "AUTH_FAILED"
}

2.1 KiB Raw Blame History