Quick heads up that Matrix.org is going to be at Enterprise Connect next week in Orlando. If you're attending and interested in open federation between WebRTC solutions, Enterprise UC, messaging/voip apps, the PSTN etc - then needless to say we'd love to talk to you! Please come seek us out, or drop us an email (firstname at matrix.org) or find us on #matrix:matrix.org to schedule a chat in person.

Hi folks,

As of today you can install the basic reference Matrix client on iOS from the App Store. We've called the app "Matrix Console" to try to make it clear that it's very much a developer/poweruser tool for experimenting with Matrix and showcasing the Matrix APIs and an example of how to use the iOS SDK - whilst it can be used as a great replacement to IRC, it's by no means meant to be a glossy polished app like Hangouts or Slack.

Meanwhile you can also get the Android version of Console at the Google Play Store as we mentioned in the last post.

Needless to say, they're both entirely open-source (Apache license) and you can grab the code from https://github.com/matrix-org/matrix-ios-sdk and https://github.com/matrix-org/matrix-android-sdk respectively if you want to play with your own copy.

The mobile apps currently act very similarly to the reference web app - providing group chat (text/images/video etc) in decentralised public and private rooms, with room history kept in sync across all your different Matrix-enabled apps. They don't yet do VoIP, although we're working on it. Please give the apps a go and file all your bugs and feedback into JIRA or #ios:matrix.org and #android:matrix.org so we can make them even better :)

The iOS app in particular showcases one of the coolest new features in Matrix: the ability for homeservers to support highly configurable push notifications, ensuring you never miss messages on Matrix ever again. The way this works is that when you install the Matrix Console app from iTunes and log in, the app tells your homeserver to send push notifications to a simple push server on Matrix.org running the sygnal codebase (you can also run your own sygnal for your own Matrix apps). You can then configure some excitingly comprehensive push settings in the settings page of the web client (we haven't exposed the UI to configure these on the mobile apps yet) to configure what events in Matrix should trigger push notifications - and then you will automatically receive the desired pushes even when the app isn't running.

We think this is incredibly powerful: there are no longer any client-side notification settings. Instead, all your notifications are stored server-side - per-room, per-user, per-word and as many other extensible rules as you desire (plus some helpful common special cases). This means that the rules that determine whether you see notifications on the desktop from the webclient are identical to the notifications you receive push notifications on your mobile devices. We hope this is a huge improvement over the inflexible notification rules that iMessage, Hangouts etc push onto you (so to speak).

To support the new push rules we've just released a new version of the web client - 0.6.5. This implements the new rule configuration UI - see below for example UI.

The full list of changes in matrix-angular-sdk 0.6.5 is as per below. We hope you enjoy the new clients and push settings - thanks for flying Matrix :)

Changes in Matrix Angular SDK 0.6.5 (2015-03-12)
================================================
Features:
 - Push notifications can now be set up in the Settings page.
 - Text entered into the input box for a room will be preserved across
   room swaps.

Bug fixes:
 - Fixed a bug where auto-scroll for images did not work correctly.
 - Fixed a bug which resulted in a partially populated room when another
   device joined a room.
 - Fixed a bug which prevented files with the same name being uploaded
   sequentially.
 - Correctly remove redacted event text from the recent activity list.
 - Firefox: Can now join rooms which have a double ## alias.

Improvements:
 - Modified Settings page layout.
 - Angular SDK now relies on the Javascript SDK for new API features.
 - Transparent images will now be shown on a white background.
 - GIFs are now marked as such on the thumbnail for the image.
 - The web client version is now shown in Settings.

Hi folks,

We released a new version (0.2.3) of the Android Matrix Console application today - this is a decent upgrade over 0.2.2. Changelog below.

If you're an Android user, please install the app from the Play Store and give it a go and give us some feedback on #android:matrix.org or Google Play.

thanks!

Hi all,

What with the chaos of Mobile World Congress last week we seem to have been hoarding releases - so here's what's been happening!

Synapse 0.8.0 was released this afternoon. This is a major performance/stability release, with lots of good stuff going on - especially adding more customisable push notification support APIs for iOS/Android; support for registering accounts from mobile devices; extensions to the new Application Service API and lots of federation improvements and bug fixes. Please upgrade at your earliest convenience.

Meanwhile, we quietly released the Matrix Console Android example app to the Google Play last week, alongside v0.2.2 of the Android SDK - release notes below. There'll be a new version of the Android Console app out tomorrow, but mentioning here for completeness and to share the release notes. Also, the iOS SDK is now on v0.3.1, with lots of performance and usability improvements.

Finally, we have a whole new official Matrix client SDK for JavaScript, all packaged up ready for use by Node developers and JS purists alike as an NPM with minimal dependencies. Meanwhile, the matrix-angular-sdk has been switched to use matrix-js-sdk from now on. You can use the plain JS API with a npm install matrix-js-sdk and then:

var sdk = require("matrix-js-sdk");
var client = sdk.createClient("https://matrix.org");
client.publicRooms(function(err, data) {'{'}
    console.log("Public Rooms: %s", JSON.stringify(data));
{'}'});

Meanwhile, release notes for all & sundry lie below.

Changes in synapse v0.8.0 (2015-03-06)
======================================

General:

* Add support for registration fallback. This is a page hosted on the server
  which allows a user to register for an account, regardless of what client
  they are using (e.g. mobile devices).

* Added new default push rules and made them configurable by clients:

  * Suppress all notice messages.
  * Notify when invited to a new room.
  * Notify for messages that don't match any rule.
  * Notify on incoming call.

Federation:

* Added per host server side rate-limiting of incoming federation requests.
* Added a ``/get_missing_events/`` API to federation to reduce number of
  ``/events/`` requests.

Configuration:

* Added configuration option to disable registration:
  ``disable_registration``.
* Added configuration option to change soft limit of number of open file
  descriptors: ``soft_file_limit``.
* Make ``tls_private_key_path`` optional when running with ``no_tls``.

Application services:

* Application services can now poll on the CS API ``/events`` for their events,
  by providing their application service ``access_token``.
* Added exclusive namespace support to application services API.

Changes in Matrix Android SDK in 0.2.2 (2015-02-27)
===============================================

-----
 SDK
-----
  
-----------------
 Matrix Console
-----------------
Improvements:
 * Exif management : the uploaded image is rotated according to the exif metadata
   (if the device has enough free memory).
 * Add a piechart while downloading an image 
 * Add JSON representation of a message (tap on its row, “Message details”
 * The public rooms list is now sorted according to the number of members.

Features:
 * Add configuration and skeleton classes for receiving GCM messages
 * Add REST client for pushers API with add method for HTTP pushers.
 * Add the account creation.

Bug fixes:
 * Reset the image thumbnail when a row is reused.
 * SYAND-30 Notification should be away when entering a room.
 * Some images thumbnails were downloaded several times.
 * Restore the foreground service
 * The medias cache was not cleared after logging out.
 * The client crashed when joining #anime:matrix.org.
 * SYAND-29 Messages in delivery status are not seen
 * Some user display names were their matrix IDs.
 * The room name/ topic were invalid when inviting to a room.

Changes in Matrix iOS SDK in 0.3.1 (2015-03-03)
===============================================

-----
 SDK
-----
Improvements:
 * Improved push notifications documentation.
 * MXSession: Slightly randomise reconnection times by up to 3s to prevent all
   Matrix clients from retrying requests to the homeserver at the same time.
 * Improved logs
 
Bug fixes:
 * SYIOS-90 - iOS can receive & display messages multiple times when on bad connections
 
-----------------
 Matrix Console
-----------------
Improvements:
 * Fixed warnings with 64bits builds.
 * Room history: Improve scrolling handling when keyboard appears.
 * Contacts: Prompt user when local contacts tab is selected if constact sync is disabled.
 
Bug fixes:
 * Fix crash when switching rooms while the event stream is resuming.
 * SYIOS-69 - On Screen Keyboard can end up hiding the most recent messages in a room.
 * SYIOS-98 - Crash when attempting to attach image on iPad
 
Changes in Matrix iOS SDK in 0.3.0 (2015-02-23)
===============================================

-----
 SDK
-----
Breaks:
 * [MXSession initWithMatrixRestClient: andStore: ] and the onStoreDataReady argument in
   [MXSession start:] has been removed. The SDK client can now use the asynchronous
   [MXSession setStore:] method to define a store and getting notified when the SDK can
   read cached data from it. (SYIOS-62)
 * MXStore implementations must now implement [MXStore openWithCredentials].
 * All MXRestClient methods now return MXHTTPOperation objects.
 
Improvements:
 * Created the MXSession.notificationCenter component: it indicates when an event must be
   notified to the user according to user's push rules settings.
 * MXFileStore: Improved loading performance by 8x.
 * Added an option (MXSession.loadPresenceBeforeCompletingSessionStart) to refresh presence
   data in background when starting a session.
 * Created MXLogger to redirect NSLog to file and to log crashes or uncaught exception.
 * MXRestClient: Added [MXRestClient registerFallback].
 * Logs: Make all NSLog calls follows the same format.
 
Features:
 * SYIOS-40 - Any HTTP request can fail due to rate-limiting on the server, and need to be retried.
 * SYIOS-81 - Ability to send messages in the background.
 
Bug fixes:
 * SYIOS-67 - We should synthesise identicons for users with no avatar.
 * MXSession: Fixed crash when closing the MXSession before the end of initial Sync.

This post has now been edited into a guide - you can find the source in github, and the formatted guide on the matrix.org website!

Hi everyone. I'm Kegan, one of the core developers on Matrix. I'd like to explain a bit more about one of the upcoming features in Matrix: Application Services. This is an entirely new component in the Matrix architecture which gives great power (along with great responsibility!) to the wielder.

Application services are distinct modules which which sit alongside a home server providing arbitrary extensible functionality decoupled from the home server implementation. Just like the rest of Matrix, they communicate via HTTP using JSON. Application services function in a very similar way to traditional clients, but they are given much more power than a normal client. They can reserve entire namespaces of room aliases and user IDs for their own purposes. They can silently monitor events in rooms, or any events directed at any user ID. This power allows application services to have extremely useful abilities which overall enhance the end user experience.

One of the main use cases for application services is for protocol bridges. As you may know, we have an IRC bridge bot on matrix.org which resides as a user on #matrix, #matrix-dev, #openwebrtc and #vuc which bridges into freenode. There is nothing special about this bot; it is just treated as a client. However, this limits the things the bot can do. For example, the bot cannot reserve the virtual user IDs it creates, and cannot lazily bridge arbitrary IRC rooms on-the-fly. By using application services, the IRC bot can do both of these things. This would allow any Matrix user to join a room alias which doesn't exist: say #irc.freenode.python:matrix.org, which would then tell the application service to create a new Matrix room, make the alias for it, join #python on freenode and bridge into it. Any IRC user on #python would then be provisioned as a virtual user e.g. @irc.freenode.alice:matrix.org. This also allows PMs to be sent directly to @irc.freenode.alice:matrix.org, no matter what channel Alice is on.

Application services have enormous potential for creating new and exciting ways to transform and enhance the core Matrix protocol. For example, you could aggregate information from multiple rooms into a summary room, or create throwaway virtual user accounts to proxy messages for a fixed user ID on-the-fly. As you may expect, all of this power assumes a high degree of trust between application services and home servers. Only home server admins can allow an application service to link up with their home server, and the application service is in no way federated to other home servers. You can think of application services as additional logic on the home server itself, without messing around with the book-keeping that home servers have to do. This makes adding useful functionality very easy.

Example

The application service (AS) API itself uses webhooks to communicate from the home server to the AS:

• Room Alias Query API : The home server hits a URL on your application server to see if a room alias exists.
• User Query API : The home server hits a URL on your application server to see if a user ID exists.
• Push API : The home server hits a URL on your application server to notify you of new events for your users and rooms.

A very basic application service may want to log all messages in rooms which have an alias starting with "#logged_" (side note: logging won't work if these rooms are using end-to-end encryption).

Here's an example of a very basic application service using Python (with Flask and Requests) which logs room activity:

# app_service.py:

import json, requests  # we will use this later
from flask import Flask, jsonify, request
app = Flask(__name__)

@app.route("/transactions/<transaction>", methods=["PUT"])
def on_receive_events(transaction):
    events = request.get_json()["events"]
    for event in events:
        print "User: %s Room: %s" % (event["user_id"], event["room_id"])
        print "Event Type: %s" % event["type"]
        print "Content: %s" % event["content"]
    return jsonify({'{'}{'}'})

if __name__ == "__main__":
    app.run()

Set your new application service running on port 5000 with:

python app_service.py

The home server needs to know that the application service exists before it will send requests to it. This is done via a registration YAML file which is specified in Synapse's main config file e.g. homeserver.yaml. The server admin needs to add the application service registration configuration file as an entry to this file.

# homeserver.yaml
app_service_config_files:
  - "/path/to/appservice/registration.yaml"

NB: Note the "-" at the start; this indicates a list element. The registration file registration.yaml should look like:

# registration.yaml

# this is the base URL of the application service
url: "http://localhost:5000"

# This is the token that the AS should use as its access_token when using the Client-Server API
# This can be anything you want.
as_token: wfghWEGh3wgWHEf3478sHFWE

# This is the token that the HS will use when sending requests to the AS.
# This can be anything you want.
hs_token: ugw8243igya57aaABGFfgeyu

# this is the local part of the desired user ID for this AS (in this case @logging:localhost)
sender_localpart: logging
namespaces:
  users: []
  rooms: []
  aliases:
    - exclusive: false
      regex: "#logged_.*"

You will need to restart the home server after editing the config file before it will take effect.

To test everything is working correctly, go ahead and explicitly create a room with the alias "#logged_test:localhost" and send a message into the room: the HS will relay the message to the AS by PUTing to /transactions/<tid> and you should see your AS print the event on the terminal. This will monitor any room which has an alias prefix of "#logged_", but it won't lazily create room aliases if they don't already exist. This means it will only log messages in the room you created before: #logged_test:localhost. Try joining the room "#logged_test2:localhost" without creating it, and it will fail. Let's fix that and add in lazy room creation:

@app.route("/rooms/<alias>")
def query_alias(alias):
    alias_localpart = alias.split(":")[0][1:]
    requests.post(
        # NB: "TOKEN" is the as_token referred to in registration.yaml
        "http://localhost:8008/_matrix/client/api/v1/createRoom?access_token=TOKEN",
        json.dumps({'{'}
            "room_alias_name": alias_localpart
        {'}'}),
        headers={'{'}"Content-Type":"application/json"{'}'}
    )
    return jsonify({'{'}{'}'})

This makes the application service lazily create a room with the requested alias whenever the HS queries the AS for the existence of that alias (when users try to join that room), allowing any room with the alias prefix #logged_ to be sent to the AS. Now try joining the room "#logged_test2:localhost" and it will work as you'd expect.  You can see that if this were a real bridge, the AS would have checked for the existence of #logged_test2 in the remote network, and then lazily-created it in Matrix as required.

Application services are powerful components which extend the functionality of home servers, but they are limited. They can only ever function in a "passive" way. For example, you cannot implement an application service which censors swear words in rooms, because there is no way to prevent the event from being sent. Aside from the fact that censoring will not work when using end-to-end encryption, all federated home servers would also need to reject the event in order to stop developing an inconsistent event graph. To "actively" monitor events, another component called a "Policy Server" is required, which is beyond the scope of this post.  Also, Application Services can result in a performance bottleneck, as all events on the homeserver must be ordered and sent to the registered application services.  If you are bridging huge amounts of traffic, you may be better off having your bridge directly talk the Server-Server federation API rather than the simpler Application Service API.

I hope this post demonstrates how easy it is to create an application service, along with a few ideas of the kinds of things you can do with them. Obvious uses include build protocol bridges, search engines, invisible bots, etc. For more information on the AS HTTP API, check out the new Application Service API section in the spec, or the raw drafts and spec in https://github.com/matrix-org/matrix-doc/.  The AS API is not yet frozen, so feedback is very welcome!

Last week, we mentioned that we released part of a first implementation of the long awaited Application Service (AS) API as part of the 0.7.1 release. The AS API makes it dead simple to connect your service into the Matrix ecosystem using an existing standard Matrix server.

And today we're very excited that the first implementation using this API has gone live! OpenMarket just announced the OpenMarket Matrix Gateway which lets you chat with non-Matrix users via their phone number: as you send and receive instant messages from your Matrix chat room, they'll receive and send SMSes back to you, which will appear in your Matrix room as IM, extending your reach to any non-Matrix user.

To use the new OpenMarket service just login to the matrix.org webclient and start a chat with your target mobile phone user by identifying him/her with a Matrix ID in the format @+<msisdn>:matrix.openmarket.com (msisdn being the internationally formatted phone number of your contact) - any messages to them will be sent via OpenMarket's SMS service. The SMSes will be sent from dynamically assigned numbers so that the recipient is able to respond to your message(s) - and the user will first receive an "opt-in" message from the OpenMarket Matrix Gateway to invite them to the conversation (just as they would if you invited them to a conversation in Matrix). Note that there are a finite set of these dynamically assigned numbers: OpenMarket reserves the right to recycle contact numbers if they have not been used to send or receive traffic for more than 2 months.

Sending SMS through the OpenMarket Matrix Gateway will be free during the introductory beta testing period, and users will be warned when that changes - although usage is subject to a per-user fair-usage policy. Despite the free service today, you'll have to associate a valid PayPal account to your account in order to send messages for security purposes. OpenMarket will not (and cannot) charge this account without your consent. You can associate your PayPal account via the settings page of any reference Matrix web client which has been configured to be aware of the OpenMarket Matrix Gateway - for example, the matrix.org webclient.

You'll also have to accept the OpenMarket Matrix API End User License Agreement to use the service.

The OpenMarket Matrix Gateway is a great example of how the Application Service API can be used to extend Matrix, we're really happy to see it live and hope it's going to give our community lots of ideas! There are a lot of services that could mutually benefit from being integrated with Matrix, and the AS API makes this much easier to accomplish!

Thus, we strongly urge you to have a look at the AS API - and as always we are happy to answer any questions at #matrix:matrix.org!

Hi everyone,

Just a quick heads up that we'll be attending Mobile World Congress (Mar 2-5) this year, chatting to the telco community about how they can benefit from Matrix; encouraging companies to build gateways, servers and clients and generally trying to grow the Matrix ecosystem. If you're going to be there and are interested in finding out more, please mail us (matrix at matrix.org) to arrange a meeting - we'll be hanging out at the OpenMarket (8.1D113) and the Amdocs (3G10) booths.

Thanks!

Hi all,

We released Synapse 0.7.1 this morning - This release includes more critical federation stability and performance updates - please upgrade as soon as you can!. You can get the code and installation instructions from http://github.com/matrix-org/synapse as normal.

Update: You can also install and run Synapse now via Docker, thanks to a Dockerfile at https://registry.hub.docker.com/u/silviof/docker-matrix/ contributed today by Silvio Fricke. Thanks Silvio!!

Other than the federation improvements, the big new feature that lands here is the long-awaited Application Service API. This is a set of simple extensions to the Client-Server API to make it much easier to build powerful gateways and other application logic on top of Matrix. You can think of it being somewhere between IRC Services, IMS application services and XMPP components - but with the simplicity of an IRC bot. The extensions let you register application services as privileged Matrix clients, and create virtual users and virtual rooms in bulk within Matrix (e.g. bridging an entire IRC network into Matrix). The API also lets your application service receive inbound events as HTTP pushes rather than having to poll. The end result is that it's suddenly become a lot easier to bridge existing communities with Matrix!

We'll post another blog post shortly to give a lot more information; in the interim you can read more about it in the newly updated spec at http://matrix.org/docs/spec/#application-service-api.

Changes in synapse v0.7.1 (2015-02-19)
======================================


Initial alpha implementation of parts of the Application Services API.
Including:

AS Registration / Unregistration
User Query API
Room Alias Query API
Push transport for receiving events.
User/Alias namespace admin control



Add cache when fetching events from remote servers to stop repeatedly
fetching events with bad signatures.


Respect the per remote server retry scheme when fetching both events and
server keys to reduce the number of times we send requests to dead servers.


Inform remote servers when the local server fails to handle a received event.


Turn off python bytecode generation due to problems experienced when
upgrading from previous versions.

We just pushed out a major new release of Synapse 0.7.0, the python reference server for Matrix, and a minor maintenance update for matrix-angular-sdk 0.6.2, the reference web client implementation.

The emphasis here has been on federation performance and stability - with all the recent interest from FOSDEM and LWN and HackerNews we've been getting a lot of traffic on matrix.org and new servers federating up, so we've been busy profiling and fixing performance on some of the hot paths by adding in-memory caches and similar.

This release is highly recommended if you are running a federated server, as it fixes many denial-of-service failure modes in the federation implementation, as well as many performance improvements

Behind the scenes, there's also lots of work going on for v2 of the Client-Server API (which lets you filter the events your client subscribes to in a room, and combines the 'initial sync' and 'eventstream' APIs into a single simplified '/sync' API) - the alpha of this has landed in 0.7.0, but we don't recommend trying to use it yet. Meanwhile the Application Service API is effectively finished, but hasn't landed on the master branch yet. Synapse also finally has initial support for push notifications for the iOS client now via the sygnal APNS gateway, although we need to actually document how to set this up to be usable in general.

Finally, we have switched to recommending that synapse is installed in a virtualenv rather than into ~/.local, due to various problems with how setup.py's dependency management works. Instructions on setting up a virtualenv can be found in the README.

On the clientside: we've improved performance, enabled identicons for unknown users, and now fully support OpenWebRTC for VoIP calling from Safari, Bowser, and other OpenWebRTC-capable browsers!

Thanks to everyone running servers - please upgrade, tell your friends, and help us grow Matrix!

Changes in synapse v0.7.0 (2015-02-12)
======================================

* Add initial implementation of the query auth federation API, allowing
  servers to agree on whether an event should be allowed or rejected.
* Persist events we have rejected from federation, fixing the bug where
  servers would keep requesting the same events.
* Various federation performance improvements, including:
  - Add in memory caches on queries such as:
     * Computing the state of a room at a point in time, used for
       authorization on federation requests.
     * Fetching events from the database.
     * User's room membership, used for authorizing presence updates.
  - Upgraded JSON library to improve parsing and serialisation speeds.
* Add default avatars to new user accounts using pydenticon library.
* Correctly time out federation requests.
* Retry federation requests against different servers.
* Add support for push notifications and push rules.
* Add alpha versions of proposed new CSv2 APIs, including ``/sync`` API.

Changes in Matrix Angular SDK 0.6.2 (2015-02-12)
================================================
Bug fixes:
 - Fixed a bug which caused OpenWebRTC to occasionally fail.
 - Fixed a bug which caused multiple room initial syncs to occur in rapid
   succession.

Features:
 - Display a "Joining Room" dialog when joining rooms.
 - Display identicons for users with no avatar.
 - Display m.notice events with full formatting.
 - Add push notification rules to settings.

Improvements:
 - Modified the red/blue notification colours to be more noticeable on a wider
   range of displays.
 - Highlight room invitations in blue.
 - Calculate room names for rooms of 3+ members.
 - Improved page load performance.
 

A new release of the iOS SDK and the iOS Matrix Console app is available on GitHub: https://github.com/matrix-org/matrix-ios-sdk.

If you use CocoaPods to manage your application dependencies, note that the Matrix SDK pod has been updated too.

The changes since the last release are:

SDK

Improvements:

• MXFileStore stores data on a separated thread to avoid blocking the UI thread.
• MXRestClient: Callback blocks in all MXRestClient methods are now optional.
• MXEvent: Cleaned up exposed properties and added a description for each of them.

Features:

• Added API for registering for push notifications.
• Added generic API methods to make any kind of registration or login flow.
• Added Identity server API: lookup3pid, requestEmailValidation, validateEmail and bind3PID.
• Management of event redaction: there is a new method in the SDK to redact an event and the SDK updates its data on redaction event.

Bug fixes:

• SYIOS-5 - Expose registration API
• SYIOS-44 - Credentials persist across logout
• SYIOS-54 - Matrix Console app slightly freezes when receiving a message
• SYIOS-59 - Infinite loop in case of back pagination on new created room
• MXRoom: Fixed [MXRoom sendTextMessage]

Matrix Console

Improvements:

• When long pressing on a message, the app shows the JSON string of the Matrix event.
• On this screen, the user can redact the event - if he has enough power level.
• Use home server media repository facilities to use lower image size for thumbnails and avatars
• Settings screen: show build version with the app version.
• Settings screen: added an option to hide information related to redacted event.
• Settings screen: added an option to enable reading of local phonebook. The country is required to internationalise phone numbers.

Features:

• Push notifications.
• Added a contacts screen that displays Matrix users the user had interactions with and contacts from the device phonebook.
• Contacts from the device phonebook who have an email linked to a Matrix user id are automatically recognised.

Bug fixes:

• SYIOS-53 - multilines text input that expands as you type mutiplines would be nice
• SYIOS-45 - Need to check the thumbnail params requested by iOS
• SYIOS-55 - High resolution avatars create memory pressure
• SYIOS-57 - Back pagination does not work well for self chat
• SYIOS-56 - add cache size handling in settings
• SYIOS-60 - In a self chat, Console takes ages to paginate back even if messages are in cache
• SYIOS-61 - Chat room : cannot scroll to bottom when keyboard is opened whereas the growing textview contains multi-lines text.
• SYIOS-63 - calculate room names for 3+ members if no room name/alias
• SYIOS-44 - Credentials persist across logout
• SYIOS-64 - Chat room : unexpected blank lines are added into history when user types in growing textview
• SYIOS-65 - IOS8 : in case of search in recents, keyboard is not dismisssed when user selects a room.
• SYIOS-16 Add option in Console to join room thanks to its alias