Two-factor authentication (2FA) adds an additional layer of security to your account by requiring more than just a password to log in.

Good news: it's now available for you to try as part of our Early Access program 🎉

How does it work?

Once a user has enabled 2FA, when they log in with a password they will also be sent an SMS with a security code that must be input.

Account owners can also force all users who access their account to have 2FA enabled.

📝 Please note: 2FA is only relevant for those using passwords to log in, so excludes Google, Twitter, GitHub and SAML based authentication.

How do I try it?

Navigate to My Settings in your Ably dashboard, click on the Enable two-factor authentication button, and follow the instructions.

Based on feedback we will consider adding additional 2FA functionality, such as TOTP (e.g. Google Authenticator) and push notifications.

How can I provide feedback?

Please visit the Ably portal where you can tell us what you think of this, and other features. Alternatively contact us.

What is the Early Access program?

The Early Access program is about getting new features into our customer's hands as quickly as possible so that we can use their feedback to help build a better product. ⚠️While all our software is thoroughly tested, early access features haven’t yet had a thorough shakedown so there is a greater chance you will discover bugs. The way certain features work may even change before they are released

Fixed bugs:

Address impact of change to interface on extras field on Message #580

Merged pull requests:

Support outbound message extras #581 (QuintinWillison)

Full release notes and changelog on GitHub.

Message Delta Compression reduces the bandwidth required to transmit realtime messages by sending only the changes from the previous message to subscribers each time there’s an update, instead of the entire message.

Let’s say the first message sent over a channel is 16KiB and the message after that is the same but with an additional 4KiB of new data. With Delta Compression that message will have a payload of only 4KiB instead of 20KiB.

This reduces bandwidth costs, improves latencies for end-users, and simplifies development by taking care of message size optimization.

Message Delta Compression is a stable feature: we expect it to be forwards-compatible with future Ably updates.

Using Message Delta Compression with an Ably Client Library SDK

When we released Channel Rewind we introduced channel parameters, expressed as a query string in the connection request or channel name itself. This was a first step to specifying parameters on a per channel basis.

With Ably’s 1.2 Client Library SDKs, available today, there’s now a proper ChannelOptions interface to express channel parameters, of which there are three:

• delta to enable Message Delta Compression
• rewind to enable and specify Ably’s existing Rewind functionality
• cipherParams to manage encryption on a channel

The libraries available in this 1.2 release are:

• JavaScript
• Java
• Cocoa
• .NET

Check our Client Library SDK feature support matrix for full feature coverage across all Client Library SDKs.

A note on ably-js

We're aware of Ably’s JavaScript Client Library SDK footprint and we're actively avoiding bloat. As such we’ve split out the VCDIFF decoder from the core of ably-js. In order to use Delta Compression with ably-js you need to plug in a separate VCDIFF decoder library. This is hosted on Ably’s CDN. We will be modularizing this in the future, but right now this is something you will need to consider.

Message Delta Compression using a non-Ably library

If you need to use a non-Ably library, say to stream over MQTT, and want to use Delta Compression you’ll need to reconstruct the messages yourself using the deltas. Ably provides a VCDIFF decoder library to decode messages yourself for Java, Cocoa, .NET, and JavaScript. The limitations with this is that you must use channel qualifiers. Read the docs for more.

Get started

• The announcement blog post
• Documentation for Message Delta Compression
• Documentation for ChannelOptions
• Ably's practical guide to diff algorithms and delta file formats

Merged pull requests:

• Add logs to help in troubleshooting RestClient http api calls #162 (gernest)
• Remove unused fields definition on RealtimeClient #161 (gernest)
• add implementation for RTN15b-c spec #159 (gernest)

Full release notes and changelog on GitHub.

Fixed bugs:

• Lib failing to retrying on 5xx if it can't parse the body #154
• Flaky TestAuth_ClientID test #80
• Likely leaking goroutines in multiple places #68

Closed issues:

• Implementing reauthentication before or after token expires #153

Merged pull requests:

• Properly set Error.StatusCode #157 (gernest)
• Use ClientOptions.TLSPort for tls connections #156 (gernest)
• RTN15a: Reconnect after networking error. #152 (tcard)
• Fix goroutine leaks #151 (tcard)
• Remove fmt.Println leftovers. #150 (tcard)
• Don't read from connection on inactive state. #149 (tcard)
• RTN23a: Receive from WebSocket with a timeout. #148 (tcard)

Full changelog and release notes.

Changes

• EventEmitter.whenState: fix for promises #630
• Typings: re-export Types namespace in 'ably/promises' sub-package #634
• Support promises with PaginatedResult#next() etc. #635
• Reduced npm package size #646
• Update msgpack dependency to version explicitly Apache-2.0 licensed #650

Full release notes on GitHub.

Merged pull requests:

• Push Activation State Machine: validate an already-registered device on activation #543 (paddybyers)

Full changelog and release notes.

Changes

Implemented enhancements:

• Remove queueing messages in a channel-level queue #894

Fixed bugs:

• lib fails all the user's channels on transition to connecting/disconnected if queueMessages is disabled? #1004

Closed issues:

• Implement push spec update ably/docs#710 #876

Merged pull requests:

• Refine release procedure #1014 (QuintinWillison)
• Fix 'queueMessages' expected behaviour #1005 (ricardopereira)

Versions

Podfile

pod 'Ably', '1.1.23'

Cartfile

github "ably/ably-cocoa" == 1.1.23

Objective-C

#import <Ably/Ably.h>

Swift

import Ably

Compatibility

Carthage release for Swift is built with Xcode 11.3.1.

See GitHub for full release notes.

Earlier releases:

• Ably Cocoa v1.1.22 release notes.

• Ably Cocoa v1.1.21 release notes.

Closed issues:

• Signed version of the .Net Standard 2.x assembly #412

For full v1.1.20 release notes please see GitHub.

Earlier releases:

Ably .NET Client Library SDK v1.1.19 release notes.

As of today Ably integrates with three new services, allowing you to act on realtime events in the Ably network by triggering actions and executing business logic across Zapier, IFTTT, and Cloudflare Workers. And, in the case of Zapier, publish to an Ably channel as part of a Zap workflow.

A common requirement in realtime messaging applications is for developers to be able to insert some business logic into a message processing pipeline. Typical use-cases might be to perform filtering or payload transformation on a message-by-message basis, either when first ingested into the messaging service, or as part of a rule that captures messages from one channel, applies the business logic, and then forwards the message to another channel.

Ably supports these use-cases through Reactor Integration rules that invoke cloud functions (e.g. AWS Lambdas or Google Cloud Functions). By providing a gateway to cloud functions from cloud services providers, we believe we provide the best available mechanism for these use-cases while making it easier to build with the ecosystems you’re already operating in.

Get started

• Read the announcement blog post
• Check out the docs for Zapier, IFTTT, Cloudflare Workers
• Browse the tutorials for Zapier, IFTTT, Cloudflare Workers

How these new integrations work

All three integrations essentially use webhooks to communicate with these services. You can set up a Reactor Rule in your app dashboard to control exactly how and what you wish to communicate with your endpoint. This can vary from the data you want to send (message or presence events), which of your channels to send from, and which endpoint to send to. Once that’s done, Ably handles the logic, execution, and delivery.

IFTTT has known limitations

The IFTTT integration is fully functional but the capabilities are more limited than other integrations. This is down to how IFTTT accepts HTTP requests. Please read the IFTTT documentation for more info on this.

If you have any questions about these new integrations, or Reactor Integrations in general, please get in touch.