History
Reading recent messages and recent presence events, and when to use rewind instead.
Messages
const messages = await channel.history({ limit: 50 });Newest first. Each entry is the message as it was published:
{
channel: 'chat:lobby',
name: 'message',
data: { text: 'hello' },
connectionId: 'conn-…',
timestamp: 1710000000000,
}limit defaults to 100.
This is a REST call — it goes to restEndpoint, not over the socket, and it
needs the history capability on that channel. It works from a Blackevin.Rest
client with no connection at all:
const rest = new Blackevin.Rest({ key: process.env.BLACKEVIN_KEY });
await rest.channels.get('orders:new').history({ limit: 50 });Presence history
The enter / leave / update log, same shape of call:
const events = await channel.presence.history({ limit: 100 });{
channel: 'chat:lobby',
action: 'enter',
clientId: 'alice',
connectionId: 'conn-…',
data: { status: 'online' },
timestamp: 1710000000000,
}It also checks the history capability, not presence — reading the past is
one permission whatever it is the past of.
If the node has no presence-history store wired, this answers [] rather than
failing. An empty list therefore means "nothing recorded", which on a node
without persistence is always true.
History or rewind?
Both hand you old messages. They differ in what you do with them.
history() | rewind | |
|---|---|---|
| transport | REST | the socket |
| when | any time, including with no connection | at subscribe |
| order | newest first | oldest first |
| arrives as | a returned array | ordinary Message frames |
| after a reconnect | you call it again | replayed automatically |
Use rewind when the old messages should flow through the same code path as the
live ones — a chat log, an event feed. Use history() when you want them as
data: a paginated view, an export, a diff.
const channel = realtime.channels.get('chat:lobby', { params: { rewind: 20 } });See rewind.
What gets written
History is written on the origin publish only. A message forwarded to another node in a cluster is not persisted a second time, and a rewind delivery is not persisted at all — otherwise every replay would grow the log it read from.
Retention
Messages are stored partitioned by day and read newest-first. There is no Ably-style hard cap in the schema; what you can read back depends on the retention configured for your account in the console.