Android 0.2.3 SDK and Application released

10.03.2015 00:00 — Tech Matthew 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 — Tutorials Matthew 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 — Tutorials Kegan 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 — General Oddvar 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 — Events Matthew 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

19.02.2015 00:00 — General Matthew 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!

12.02.2015 00:00 — Tech Matthew 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

05.02.2015 00:00 — Tech Emmanuel 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!

04.02.2015 00:00 — General Oddvar 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!

29.01.2015 00:00 — General Oddvar 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!