Video: IoT through Matrix

08.04.2015 00:00 — GeneralOddvar Lovaas

Earlier this year we went to FOSDEM - as reported in an earlier blog post.

Both the recording equipment and the video team volunteers were new this year, so some problems were encountered, which means that our lightning talk video unfortunately was lost. However, our talk in the IoT-devroom is now available:

(Click here to download the video)

The slides are also available. You can check out the slides from the lightning talk as well.

As always, questions and comments are very welcome in the #matrix:matrix.org room!

Synapse 0.8.1 is here!

26.03.2015 00:00 — GeneralDavid Baker

Heads up that we released Synapse 0.8.1 a little while back, but we've all been too busy writing software to announce it... you know how it goes. Anyway, here are the changes:

  • Disable registration by default. New users can be added using the included register_new_matrix_user script or by enabling registration in the config.
  • Add metrics to synapse. To enable metrics use config options enable_metrics and metrics_port.
  • Fix bug where banning only kicked the user.
Note that first one in particular: if you set up a new install, you won't be able to register new users using the API by default. This means random people on the Internet can't create accounts on your Home Server unless you actually choose to let them. Also, if you were trying to ban users and noticed that didn't work... yeah, we fixed that.

Okay, back to writing software again!

TADHack-mini London

19.03.2015 00:00 — GSOCOddvar Lovaas

It's competition time! Matrix is sponsoring TADHack-mini London, which is a two-day hackathon with focus on WebRTC technology, happening on April 11 and 12 at IDEA London. We will award a Parrot Bebop Drone (which itself can be hacked via the ARDroneSDK3) to the two best hacks using Matrix, and we can't wait to see what kind of ideas people will come up with! Parrot Bebop Drone We strongly encourage anyone to get involved - have a look at our Development Resources (scroll down a bit) and have a think of what you can create within the 16-hour timeframe. The reference Matrix web client already supports WebRTC - you can play with this by registering a user via the matrix.org web client (or you can check out the reference web client and run it on your own box), inviting a user to a 1-1 chat (click on their avatar and "start chat") and then clicking the microphone or video camera icon in the top right to start a voice/video call.

We brainstormed some ideas for further WebRTC/Matrix work in our GSoC (Google Summer of Code) project proposals, for example "Implementing WebRTC support in Mobile apps" and "Multi-way voice and video conferencing". These are very probably too extensive for the 16-hour hackathon, but might provide some ideas for smaller hacks.

We will be at the event to offer mentoring and help, but you can already start thinking about potential hacks - come talk to us in the #matrix:matrix.org room!

Matrix at Enterprise Connect 2015

14.03.2015 00:00 — EventsMatthew Hodgson

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.

Introducing Matrix Console for iOS (and Android) + Web client 0.6.5

12.03.2015 00:00 — In the NewsMatthew Hodgson

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.

iOS screenshot

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.

push settings 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.

Android 0.2.3 SDK and Application released

10.03.2015 00:00 — TechMatthew Hodgson

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!

Changes in Matrix Android SDK in 0.2.3 (2015-03-10) ===================================================

SDK


Matrix Console

Improvements:

  • Avoid refreshing the home page when it is not displayed.
  • Display a piechart while uploading a media.
  • Refresh the display when some messages are automatically resent (after retrieving a data network connection for example).
  • Update the user rename message to be compliant with the web client.
  • Use the local media files instead of downloading them when they are acknowledged (messages sending).
  • Create a medias management class.
  • Display the offline status in the members list.
  • Avoid creating new homeActivity instance when joining a room from member details sheet.
  • The public rooms list are now saved in the bundle state : it should avoid having a spinner when rotated the device.
  • The animated GIFs are now supported.

Features:

  • Add the rate limits error management. The server could request to delay the messages sending because they were too many messages sent in a short time (to avoid spam).
  • Can take a photo to send it.
  • A chat room page is automatically paginated to fill. It used to get only the ten latest messages : it displayed half filled page on tablet.
  • Add the sending failure reason in the message details (long tap on a message, “Message details”).
  • The user is not anymore notified it the push rules are not fulfilled.
  • Add some room settings (Display all events, hide unsupported events, sort members by last seen time, display left members, display public rooms in the home page).
  • Add various accessibility tweaks.

Bug fixes:

  • The media downloads/uploads were sometimes stuck.
  • The private room creation was broken.
  • SYAND-33 : number of unread messages disappears when entering another room.
  • The RoomActivity creation used to crash when it was cancelled because the Room id param was not provided.
  • The client used to crash when the home server was invalid but started with http.
  • The account creation used to fail if the home server had a trailing slash.
  • SYAND-44 In progress text entry could be saved across crashes.
  • SYAND-38 Inline image viewer in Android app.

Synapse 0.8.0, Android 0.2.2 SDK & App, iOS 0.3.1 SDK & App, JavaScript SDK 0.0.1 released! (oh my!)

09.03.2015 00:00 — TutorialsMatthew Hodgson

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.

Introduction to Application Services

02.03.2015 00:00 — 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!

26.02.2015 00:00 — 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

21.02.2015 00:00 — 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!