We are happy to launch The Matrix Conference on Oct 15-18 in Strasbourg, France. Learn more about it, buy a ticket!

Introduction to Application Services

2015-03-02 — TutorialsKegan Dougal

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!

Welcoming the OpenMarket Matrix Gateway!

2015-02-26 — GeneralOddvar Lovaas

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!

Matrix at Mobile World Congress 2015

2015-02-21 — EventsMatthew Hodgson

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!

Synapse 0.7.1 released - with Application Service API

2015-02-19 — GeneralMatthew Hodgson

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.

Synapse 0.7.0 and matrix-angular-sdk 0.6.2 released!

2015-02-12 — TechMatthew Hodgson

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.
 

iOS: SDK and Matrix Console 0.2.2 released

2015-02-05 — TechEmmanuel Rohee

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

Back from FOSDEM!

2015-02-04 — Events, FOSDEMOddvar Lovaas

FOSDEM was great fun! Two days full of conferences and demos; lots of interesting technologies and interested people - and most of all: talking to so many new faces about Matrix and potential uses and integration ideas.

Both our lightning talk and IoT-devroom talk were completely filled up with huge queues outside (sorry folks), and our demos seemed to go down fairly well. In fact several people set up their own homeserver and joined the federated network of Matrix servers during FOSDEM itself!

Here's a view from our stand, from our lightning talk and from our IoT-devroom talk.

If you missed the talks, recordings will (soon) be available from the FOSDEM site (links will be added here once available) - in the meantime you can check out the slides here: lightning talk and IoT-devroom talk.

Thanks to everyone who came to have a chat about Matrix and/or help with setting up their own homeserver (or to play with Sentinel, our mascot) - please do reach out to us via our Matrix HQ room or IRC (#matrix on freenode) if you have any problems - or want to help us fix our python packaging ;) Now is a great time to get involved as we are currently landing new APIs and soon will be offering an Application Server API to ease bridging to other services.

Looking forward to FOSDEM!

2015-01-29 — Events, FOSDEMOddvar Lovaas

This weekend, Matrix is heading to FOSDEM (Free and Open Source Software Developers' European Meeting) in Brussels, Belgium. We will be hosting two events: a lightning talk on Saturday at 16:30 in room H.2215 (Ferrer), and an IoT devroom talk on Sunday morning at 11:00 in room H.2213.

FOSDEM's schedule is looking very interesting and varied, and we hope we can learn about interesting projects - and of course show how and where Matrix can be used to lots of FOSDEM-attendees. Please come over and have a chat if you are interested; we have a stand on the second floor in the K building - just take a right after coming up the stairs and say hi!

We have also set up a Matrix <-> IRC bridge on the #fosdem channel on freenode, which means that any conversation happening there will be copied over to #fosdem:matrix.org - and vice versa. Making bridges to other services is currently being worked on as part of the Application Services API - we want to be able to connect different services together via Matrix.

Finally, we are always available in the official Matrix HQ room - please join and say hi!

Synapse 0.6.1 released and other news!

2015-01-07 — TechMatthew Hodgson

Happy 2015 from everyone at Matrix.org!

We're excited to kick off the new year with a major performance upgrade for Synapse: having had a chance to do some profiling over the Christmas break, Synapse 0.6.1 improves performance by up to an order of magnitude thanks to optimising the way events are constructed and manipulated, DB optimisations, etc. Suddenly things are feeling much more snappy and less of a PoC and more of a real system, which hopefully bodes well for 2015! Please upgrade if you're running a homeserver, or install one if you're not - grab the code from http://github.com/matrix-org/synapse.

The iOS SDK and demo app has also been improving lots in the last few weeks - grab the latest code from http://github.com/matrix-org/matrix-ios-sdk. We have zoomable image support; full support for the new media repository in Synapse 0.6.0; file transfer status UI; offline support; snappy message synchronisation and more...

We also released a new simple Python SDK client library for Python called matrix-client, which is now being used by NEB (our general-purpose Matrix helper bot).

Meanwhile, our (constantly evolving) plan for the beginning of 2015 is:

  • Finish v2 of the client-server API based on all the lessons learnt since launch: draft in progress here
  • Finish the Application Services API to allow proper gateways and services in and out of Matrix at last:draft in progress here
  • Re-release the spec based on the above
  • Build robust gateways (IRC, XMPP, SIP and more) on top of the AS API
  • Polish and release the iOS, Android demo clients - including push notification and VoIP support!
  • Overhaul the identity server architecture and add end-to-end crypto

Given the rate at which Matrix is maturing, the next few months should be really exciting - please come join us on #matrix:matrix.org and get involved!

Changes in synapse 0.6.1 (2015-01-07) =====================================
  • Major optimizations to improve performance of initial sync and event sending in large rooms (by up to 10x)
  • Media repository now includes a Content-Length header on media downloads.
  • Improve quality of thumbnails by changing resizing algorithm.

Matrix wins Best Innovation Award at WebRTC Paris!

2014-12-24 — Events, NewsMatthew Hodgson

Last week we had a great time attending WebRTC Conference Expo Paris 2014 - chatting to lots of new folks about Matrix; speaking in the "To Build or Not To Build" panel discussion; giving a general presentation on Matrix, and participating in the Demo shoot-out.

And we're very proud to say that we won the Best Innovation Award for a slightly frantic demo, showing an iPad mounted on our pet Trossen Robotics PhantomX Hexapod being used for robot telepresence by streaming video and audio to an Oculus Rift VR headset. This was using our proprietary in-house WebRTC stack, but once Matrix has fully taken off we hope to share our WebRTC stack with the world too :) This was a very last minute demo - we wanted to show something different to normal browser-to-browser IM/Video calling via Matrix and had the idea to use the Rift at the last minute - and in fact it still wasn't working when we went on stage (turns out that iOS 8.1 introduces some quirks in the video capture API which were producing corrupt video). By switching from an iPhone 5S running iOS 8.1 to an iPad running iOS 6 we were able to turn the demo around in the nick of time and get it working live on stage (modulo a RGB<->BGR colourspace bug) just in time to win the award. Huge thanks to the jury for voting for us against the odds :D For those interested in displaying raw video straight onto the Oculus Rift (without using any head-mounted tracking), there's an OpenGL code snippet up at https://gist.github.com/ara4n/875b5e8b66be3617efb7.

iOS to Oculus Rift Telepresence

(Image credit to Victor Pascual Avila at Quobis)

Also, huge congratulations to Vladimir Beloborodov who won the Best Data Channel Award for hacking his Romotive telepresence robot to rendezvous via Matrix with his iPad, stream video via Google's WebRTC stack and control the robot's motion via the WebRTC Data Channel:

Vladimir Beloborodov

We're really excited to see other folks' Matrix projects out there winning prizes!