What should your app save before sending a message?

For a shared board, save the task in your app’s database, then send a message to the people watching that board. A new visitor needs a read of the current board from your app before the stream of changes can make sense.

Ably’s message history can help with earlier messages if retention and permissions cover them. Keep the saved board separate so a missed message or expired history does not change what the app treats as true.

Who decides which board a browser can listen to?

Your server checks the account’s membership before issuing a short-lived token for the browser. Give the token permission to receive updates only from the board it may open. Ably calls those rights capabilities.

Keep the service key on your server. A member who only needs to listen can get a token with permission to subscribe, without permission to send events. Check the board’s ordinary read and write permissions as well.

What happens when a connection drops?

Ably’s client library can resume a live connection after a short interruption and deliver missed messages if continuity is restored. Ably documents an automatic recovery window of about two minutes. For a longer gap or a failed recovery, have the app fetch the latest saved board.

Treat a message as a reason to refresh the part of the board that changed. If an older message arrives after the screen has fetched newer data, it should not undo that newer state.

How can you test a short and a longer interruption?

Use a disposable Ably app, a separate test board and fictional accounts. Confirm the browser token, database and any event or notification destinations belong to the test setup before connecting. If you cannot confirm them, sketch the expected screen states on paper.

See a change with both browsers connected
Open the sample board as a member in two separate browser profiles. Move the sample task from To do to Doing in the first. Check that the second shows Doing and that the database saved it.
Let one browser miss a change
Disconnect only the second browser without closing or refreshing it. Save Done in the first and reconnect the second within the recovery window. Check whether its connection resumed and whether it reaches Done.
Check the fallback after continuity is lost
Repeat with a longer interruption. Save a new status while the second browser is disconnected. When it reconnects without recovery, check that its fresh board read shows the latest status.
Check a different board’s access
With a fresh nonmember test session, try the same test board’s read and subscription separately. The ordinary account should get neither records nor updates while a member sees the next change. If the app never attempts one path, mark it untested and check it separately in the disposable setup.

What should you count and keep if the board grows?

The current public packages use monthly active users. Ably’s Free package lists up to 500. Ably counts distinct device-side identities for this measure, so check how your app supplies a stable identity. Older resource-based accounts can use different billing units.

Also check service limits such as peak connections and message bandwidth for the account you use. Keep your board records and the meaning of your events in your own app. Moving the live channel to another service still means replacing its connection, permission and reconnect logic.