Glossary

Advanced Message Queuing Protocol (AMQP) is a protocol that can be used to retrieve messages from a queue.

See the queues documentation and Wikipedia for further information.

Ably uses API keys for authentication, either directly (basic authentication) or for generating tokens (token authentication). Each application will have at least one API key and each key can confer different rights for access to channels and other resources within its associated application.

API keys contain three parts: the public app ID and public app key ID (which, combined, form the API key ID) and the API key secret. API keys should be kept secret and only shared with trusted parties.

An app (or application) in the context of Ably is a grouping of channels, queues and other resources that are managed as a collection. An app defines a namespace for its channels and queues so that they are unique to that application. An Ably account can contain multiple apps, with each app having its own set of API keys to limit client access to its resources. Access can then be further limited to a subset of channels and queues within an app and the permissions on those resources, such as whether a client can publish or subscribe to them.

Active Traffic Management (ATM) is an Enterprise-only service that allows Ably engineers to manage the endpoints that customers connect to. This allows Ably to proactively route customer traffic to specific data centers or regions, ensuring service availability in the event of an incident.

Batch requests enable multiple queries to be made in parallel as part of a single HTTP request. Examples include publishing a message to multiple channels and retrieving the presence state of multiple channels.

See the batch request documentation for further information.

A capability represents a collection of resources, each with a set of permitted operations. For example, a capability can grant permission to subscribe to the finance: channel namespace. Capabilities are used to define the rights associated with an authentication credential such as an API key or token, although the rights expressed by a capability for a token cannot exceed those of its associated API key.

See the capabilities documentation for further information.

Channels are used to logically separate messages into different topics. Clients subscribe to channels for topics they are interested in, to receive all messages sent on those channels. When a publisher sends a message on a channel, all subscribers receive that message.

See the channels documentation for further information.

Channel namespaces provide a way for certain properties (such as persistence) to be assigned to a group of channels, rather than requiring them to be assigned to individual channels. The namespace is the first colon-delimited segment of a channel name, or the channel name itself if no colon exists. For example, the channels finance and finance:approvals would both be considered part of the finance namespace.

See the channel namespace documentation for further information.

A connection to Ably must be established and maintained for realtime communication. A connection goes through several different connection states throughout its lifecycle, such as connecting, connected and suspended.

See the connection documentation for further information.

The Control API is a REST API that enables an Ably account to be managed programmatically. This includes the creation and management of resources such as Ably apps, API keys and queues.

See the Control API documentation for further information.

The Ably dashboard is the user interface for managing applications, viewing statistics, creating API keys and setting up integrations and channel rules.

Once you have registered for an account, you can sign in to view your dashboard.

Dead letter queues store messages that were intended to be delivered to a queue, but have failed to be processed correctly. They are created when a queue is provisioned, with one dead letter queue per application, not per queue.

See the dead letter queue documentation for further information.

Delta compression is a feature that enables a subscriber to only receive the difference between the payload of the current message and the one sent previously. It is used when there is a degree of similarity between successive messages.

See the delta compression documentation for further information.

See delta compression.

Firehose is a feature that enables the realtime data published in Ably to be streamed directly into another streaming or queuing service such as Amazon Kinesis.

See the Firehose documentation for further information.

An idempotent operation is one whose effect is the same whether it is performed once or multiple times. In the context of Ably, idempotence ensures that retried publish attempts, such as in response to a network failure, do not result in duplicate messages being published.

See the idempotent messages documentation for further information.

The inband channel occupancy feature enables a client to subscribe to occupancy events related to a channel. The events are then delivered to that client as messages on the channel.

See the inband channel occupancy documentation for further information.

The Internet of Things (IoT) is a term used to describe a network of physical objects that use software or sensors to connect to the internet. Examples include smart meters, smart appliances and smart security systems.

See IoT at Ably and Wikipedia for further information.

JSON Web Token (JWT) is an open standard for securely representing claims transmitted between parties. The claims and metadata of a JWT are in JSON format and can be verified by recipients because they are cryptographically signed. JWTs can be used for authenticating with Ably.

See the authentication documentation for further information.

Kinesis is serverless streaming data service for capturing, processing, and storing data streams provided by Amazon Web Services. You can use Ably’s Firehose to set up a Kinesis rule to send data streams from Ably to Kinesis.

See the Kinesis rule documentation for more information.

Lambda is an event-driven serverless service provided by Amazon Web Services that allows users to easily run code when specified conditions are met. You can set up Ably Webhooks to trigger Lambda functions when events occur.

See the Lambda documentation for more information.

Latency is a measure of the delay between an operation being initiated and its effect. In the context of Ably, latency typically refers to the time elapsed between a message being published on a channel and being received by a channel subscriber on another connection.

A message is the unit of information sent using the Ably platform. Messages are sent by publishers on a channel and received by all subscribers to that channel.

See the messages documentation for further information.

A metachannel is a channel that receives messages containing metadata or events relating to an application. Metachannels exist outside of regular channel namespaces and instead have their names qualified with [meta], for example [meta]log or [meta]channel.lifecycle.

See the metachannels documentation for further information.

Message Queuing Telemetry Transport (MQTT) is a lightweight publish-subscribe protocol for minimal code implementations, or low bandwidth networks.

See Wikipedia for further information.

The Ably MQTT Adapter can translate between MQTT and the Ably protocol.

See the MQTT Adapter documentation for further information.

Occupancy is a feature that enables you to view the number of occupants attached to a channel and specific metrics about their connections.

See the occupancy documentation for further information.

Persistence (or persisted history) is a feature that enables messages on a channel to be stored on disk. The last message published on a channel can be stored for 365 days, or all messages on a channel can be stored from between 24 hours up to 365 days or longer, based on your account package. Persisted messages can be retrieved by API or replayed to clients using the rewind feature when they attach to a channel.

See the history documentation for further information.

The presence feature enables clients in a channel to be aware of other presence members in the same channel. Each client has a presence state, and that state is communicated to all presence subscribers on the channel when a client enters or leaves.

See the presence documentation for further information.

Publish-subscribe (or pub/sub) is a pattern of information exchange where a publisher does not need to interact directly with, or even know the existence or identities of, any subscribers. Conversely, a subscriber can gain access to published information without interacting directly with the publisher.

A publisher is an entity that sends messages on one or more channels.

See the channels documentation for further information.

Push notifications are messages that are pushed to a device’s user interface such as a visual notification. Ably can deliver push notifications using platforms such as Apple’s Push Notification service or Google’s Firebase Cloud Messaging service.

See the push notification documentation for further information.

Ably Queues provide a service that distributes messages between subscribers, so that each message is only received by one subscriber. This model is referred to as “competing consumers” and is different to the pub/sub model where each message is delivered to every subscriber. Ably uses integration rules to publish messages received in a channel into a queue.

See the queues documentation for further information.

The realtime interface of an Ably SDK is implemented using an Ably-defined protocol, with communication primarily over WebSockets. It enables devices and browsers to maintain a persistent connection to Ably. SDKs are available in various languages and platforms, such as JavaScript, Ruby and Android.

See the available SDKs for further information on the realtime interface and the languages and platforms supported by the SDKs.

The REST interface of an Ably SDK communicates with the Ably service using the HTTP protocol and is effectively stateless. The REST interface provides a convenient way to access the REST HTTP API and is intended to be used by clients that don’t require realtime updates.

See the available SDKs for further information on the REST interface and the languages and platforms supported by the SDKs.

Rewind is a feature that enables a client to subscribe to a channel from a position earlier than the current point in time. rewind is a channel parameter that can specify an earlier position as a time interval or set number of messages. When a client first attaches to a channel using rewind, all messages from that earlier position are replayed to them.

See the Rewind documentation for further information.

Simple Queue Service (SQS) is an Amazon Web Service that allows you to send, store, and receive messages between systems. You can use Ably’s Firehose feature to set up a SQS rule for sending from Ably to SQS.

See the SQS rule documentation for more information.

Server Sent Events (SSE) is an HTTP-based protocol for streaming events from a server to a client. In the context of Ably, SSE can be used to establish a realtime subscription to a set of channels.

See the SSE documentation for further information on using SSE with Ably.

Simple (or Streaming) Text Orientated Messaging Protocol (STOMP) is a protocol that can be used to retrieve messages from a queue.

See the queues documentation and Wikipedia for further information.

A subscriber is an entity that establishes a realtime connection to Ably in order to receive messages on one or more channels.

See the channels documentation for further information.

Webhooks are HTTP callbacks that are triggered by a specified event. Ably supports incoming and outbound webhooks. Incoming webhooks take data from an external application or service and publish it as messages on a channel. Outgoing webhooks notify an external application or service when a message or event is received.

See the incoming webhook documentation and outbound webhook documentation for further information.

WebSocket is a communication protocol. A WebSocket connection is established with Ably when a client is instantiated using the realtime interface of an SDK. This connection is multiplexed, enabling multiple channels to share it. Messages can then be sent between Ably and the client in realtime.

See the websocket deep dive and Wikipedia for further information.