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

Some updates on the conferences Matrix attended over the last 3 weeks: WebRTC Summit in Santa Clara, TAD Summit in Istanbul, WebRTC World West in San José and fOSSa in Rennes. Great shows, ending in lots of interesting discussions and new excitement in Matrix!

🔗WebRTC Summit (Santa Clara, November 4-6)

Matrix was a sponsor at the Santa Clara WebRTC Summit at CloudExpo, and opened the WebRTC track alongside our friends at Open Peer / Hookflash. Matthew presented Matrix as the missing signalling layer for WebRTC and as a good federated complement to MQTT and COAP for IoT use cases: you can find his presentation here.

Great techie discussions and debates down there, the stand was flooded with interested people and John had a hardtime answering everyone by himself on day 2!

But he still found a few minutes to do a TV interview for SYSCon TV on Tuesday evening! :)

[embed]http://youtu.be/JVq6S9V1Jcg[/embed]

🔗TAD Summit (Istanbul, November 12-13)

Matrix was a partner at TAD Summit in Istanbul this year, a great opportunity to meet a very good mix of developers, industry players and mobile networks! TAD mixes conferences and technical workshops where everyone gets involved to create a vibrant ecosystem for Telecom Application Developers. Again really productive discussions and meetings as we continue our search for partners to help support the uptake of Matrix.

Matthew's talk was fully recorded so just watch the video to get the real pitch!

[embed]http://youtu.be/ER3g4-4bFYk?list=PLO-gJ4-4x_IIYVTuLmVr8iUedvVdduYY4[/embed]

[embed]https://www.youtube.com/watch?v=As-5vVdXhu0[/embed]

🔗WebRTC World (San Jose, November 18-20)

Matrix's attendance at WebRTC World in San Jose was more rewarding than expected! The team was ready to be part of the expo and give a talk on FOSS WebRTC options... but didn't hesitate to jump at the opportunity when a demo slot opened up! And that was a worthwhile decision as Matrix ended up winning not one but TWO awards from the demo: The Audience Choice Award as the audience's favourite demo of the 10 shown on Tuesday, and also the overall Best Social Integration Award from the Jury! So a big congrats to the dev team who were rushing to get the fine details ready in time and to Matthew for getting the audience's attention! And of course a even bigger thank you to everyone who voted for us, including in the Jury!

Of course this drew lots of interest, and WebRTC Expo ended up the busiest show ever for the team who pitched solidly at the booth for 2 days in a row!

🔗fOSSa (Rennes, November 20)

And eventually, while Matthew and John were celebrating in San José (or flying home, more accurately), Amandine was also evangelising at home in Rennes (France), where fOSSa was gathering experts from the opensource world for 3 days. Matrix was presented within the Serendipity section on the conférence, "Le Carrefour des Possibles": 6 minutes to pitch an open project that making dreams possible.

So if you speak French or are not afraid to only read from the slides, check out the video the team made of the pitch. The official one should be available soon!

[embed]http://youtu.be/DyL9Ue0KlBU[/embed]

Crazy session tonight at 5pm UK time (12 Noon Eastern Time; 9AM Pacific) on VUC as Matrix, Truphone and Jitsi were crazy enough to hack a federated demo in 48h!

Join us live for the demo from the inside by using Matrix to attend the conference (see steps below)! No browser supporting WebRTC at hand but still willing to play with Matrix? You can also follow the chatroom (bridged to IRC) by entering #vuc:matrix.org.

For other connection means:

• Live video http://live.vuc.me or http://vuc.me
• Live audio: http://vuc.audio
• sip:[email protected]
• Skype:vuc.me
• Or from a regular telephone or cell call ZipDX (+1 (646) 475-2098) or see the Voxbone International Dial-in List.

Steps to join the call from Matrix:

1. Register on Matrix from Chrome if not already done :)
2. Start a chat with @vucbot:matrix.org by entering the ID in the appropriate textfield at the bottom of the public rooms list on http://matrix.org/beta and click on "Message User"
3. In the chat room start a voice call by clicking on the mic icon in the top right corner. Don't forget to allow your browser to access your mic and speakerphones!

Hi all,

There's been loads of work going on in various branches on Synapse (federation_authorization and event_signing) as we land the final features needed for Synapse to be used in production as a Matrix reference server.  Meanwhile the iOS demo client and SDK has been coming on leaps and bounds too over at https://github.com/matrix-org/matrix-ios-sdk.

However, stuff has also been happening on the main Synapse development branch too, and we've just released 0.4.2 onto master for lots of various goodies - see release notes below.

Please upgrade your homeservers and play with the new client - the new JSON viewing/editing features are particularly useful and interesting for powerusers and developers!

Matthew

Changes in synapse 0.4.2 (2014-10-31)
=====================================

Homeserver:

 * Fix bugs where we did not notify users of correct presence updates.
 * Fix bug where we did not handle sub second event stream timeouts.

Webclient:

 * Add ability to click on messages to see JSON.
 * Add ability to redact messages.
 * Add ability to view and edit all room state JSON.
 * Handle incoming redactions.
 * Improve feedback on errors.
 * Fix bugs in mobile CSS.
 * Fix bugs with desktop notifications.

It's been an incredibly busy few weeks in Matrixland - we've had our heads down rushing to get new stuff ready for today's TechCrunch Disrupt London hackathon.

The big news is that we have our first alpha releases of native Mobile SDKs available today for Matrix for iOS & Android! These are entirely new projects - you can check out the SDKs and demo apps (which implement a basic Matrix chatroom client similar to the webclient demo at:

• http://github.com/matrix-org/matrix-ios-sdk
• http://github.com/matrix-org/matrix-android-sdk

We still have a lot of polishing and lipstick to apply to these, but it should be a good starting point for folks who'd like to hack on mobile apps for Matrix! We haven't had a chance to generate appledoc/javadoc for these yet, but we'll post them on matrix.org shortly.

There's also been some work going into restructuring our documentation and finalising the spec - all Matrix generic documentation now lives in a new git project at http://github.com/matrix-org/matrix-doc. We're still working on wrapping all the details of the spec into a single canonical document, but it's getting there and should be locked down shortly.

Meanwhile, we're also pleased to announce the new Synapse 0.4 release series of the reference Matrix homeserver. Our focus on Synapse over the last few weeks has been on implementing the remaining pieces of the Matrix security model and getting the server to the point where folks can deploy it properly in production environments.

Synapse 0.4 deliberately breaks backwards compatibility on the server-server federation protocol, as we now cryptographically sign all federation traffic at the HTTP layer (using Authorization headers) in order to have a strong assertion to the identity of the servers which exchange traffic. We can't really use SSL client/server certificates for this as it's incompatible with Synapse deployments which are hosted behind generic SSL loadbalancers.

Meanwhile we have two other major development branches on Synapse which will land shortly - one of which cryptographically signs all events, thus preventing tampering with room history, and the other of which performs strict authorization on all traffic received through federation to avoid malicious events being injected and breaking the consistency of the distributed room. These should be landing shortly - at which point the full security model of Matrix will be implemented in Synapse and we can finally remove the "don't use this in production!" warnings!

API developers: be aware that this release also fixes the confusion over timestamps in the client-server (and server-server) API. Events now have only one well-defined timestamp - event.origin_server_ts; the localtime on the homeserver which first receives a message. This replaces the previous confusing event.ts and event.content.hsob_ts timestamps. This should be a trivial change to implement.

Finally, we've also had a detour into robotics to build our new mascot (Sentinel)... pictures forthcoming shortly!

Thanks for supporting Matrix - please let us know how you get on with the new releases at #matrix:matrix.org!

Changes in synapse 0.4.1 (2014-10-17) ===================================== Webclient:

• Fix bug with display of timestamps.

🔗Changes in synpase 0.4.0 (2014-10-17)

This release includes changes to the federation protocol and client-server API that is not backwards compatible.

The Matrix specification has been moved to a separate git repository: http://github.com/matrix-org/matrix-doc

You will also need an updated syutil and config. See UPGRADES.rst.

Homeserver:

• Sign federation transactions to assert strong identity over federation.
• Rename timestamp keys in PDUs and events from 'ts' and 'hsob_ts' to 'origin_server_ts'.

Matrix.org is a team of around 10 developers working together on the Matrix project, defining the Matrix open standard and developing the opensource reference client and server implementations. Most of the team has day jobs at Amdocs or OpenMarket (who kindly sponsor us to work on Matrix), and we gladly welcome contributors from the wider open source community.

Matrix was started by Matthew Hodgson and Amandine Le Pape whilst building Amdocs Unified Communications, on realising that traditional VoIP and IM standards were insufficient to power featureful apps which can openly federate with one another. Matrix is designed to support open federation for the current and future state-of-the-art in communication apps using a simple web-friendly HTTP API standard. Our dream is to break down the walls between today's communication silos, and make VoIP and IM as ubiquitous and open as email.

🔗Matthew

Matthew Hodgson is technical co-founder of matrix.org, responsible for defining Matrix's vision with Amandine and moving obstacles out of the way of the team in order to build it. Matthew has spent the last 15 years mainly designing and building various communication solutions on top of an alarming array of different technologies (IRC, IM, NNTP, IMAP, IAX, SIP/RTP, RTMP, XMPP... and now Matrix).

Matthew's day job is running the Unified Communications team at Amdocs, creating communication apps for large mobile network operators (e.g. Blah for TIM Brasil). Previously he ran "The Next Generation" telephony/media team at MX Telecom (acquired by Amdocs in 2010), building a highly distributed SIP softswitch and mobile-optimised WebRTC-compatible graph-based media framework and VoIP stack to power MX's voice and video services. Matthew has also been known to dabble in sysadmin (running MX Telecom's sysadmin team), dubious graphic design and CGI, and wishes he had more time to play piano. He has a degree in Computer Science and Physics from the University of Cambridge, and has previously worked at Accenture, the Rutherford Appleton Laboratory, TheOneRing.net as well as misguidedly co-founding a digital marketing startup in Bahrain. [LinkedIn]

🔗Amandine

Amandine Le Pape is business co-founder of matrix.org, responsible for defining the Matrix vision with Matthew and then organising the non-technical activities required to support and promote it and make it successful.

Amandine has spent the last 2 years setting up and leading the Unified Communications line of business within Amdocs as a Product Manager, and has more than 10 years of experience in mobile services and telecommunications. She has a degree in telecommunications engineering from Ecole Supérieure de Chimie, Physique et Electronique de Lyon and an EMBA from ESC Rennes. [LinkedIn]

Hey,

We realized we're missing a high level overview highlighting the key points of the specifications and architecture of Matrix, which could be useful for those who don't feel like going straight into the specs. So here is a quick presentation to fill in some of the gaps!

Please fire away with any questions :)

Hi all,

We just pushed our first major update since matrix.org launched for Synapse, the reference Matrix homeserver:

🔗Changes in synapse 0.2.2 (2014-09-06)

Webclient:

• Fix desktop notifications
• Add support for captchas on registration
• Handle m.room.aliases events.
• Implement local echo when sending message
• Inform the UI when a message failed to send.
• Only autoscroll on receiving a new message if the user was already at the bottom of the screen.
• Add support for ban/kick reasons.
• Add /join support for IRC acolytes
• Make IRC-style commands a little more forgiving

Homeserver:

• Validate m.room.power_level events.
• When the server returns state events it now also includes the previous content if any to aid pagination
• Add support for inviting people when creating a new room.
• Make the homeserver inform the room via m.room.aliases when a new alias is added for a room.

The matrix.org homeserver & webclient has already been updated to the latest version - if you're running your own homeserver, please update. v0.2.2 retains backwards compatibility with previous homeserver releases.

Get the code from http://github.com/matrix-org/synapse!

I'm Matthew, and I'm responsible for the techie side of what we're up to with Matrix.

Matrix is the result of a lot of work my team's done over the last 10 years or so (first at MX Telecom, then OpenMarket, and then Amdocs) in developing next-generation IP communication solutions.  First we started with an Asterisk-based platform running basic PSTN IVR services, and then shifted to an in-house IAX-based IVR platform built in Java, and then added circuit-switched (3G-324M) video calling, then switched to SIP/RTP, C++ and a massively-distributed softswitch architecture affectionately called 'The Next Generation'.  Then the iPhone and Android came along, and we realised we didn't have to be constrained by built-in phone capabilities and ported our whole C++ SIP/RTP VoIP stack over to iOS/Android and got writing Video/VoIP calling apps.  This evolved to developing full-blown unified communication apps (e.g. Blah), using XMPP at first for messaging before switching to our own HTTP-based messaging APIs.

Somewhere along the way it became painfully obvious that VoIP and IM hasn't really evolved as well as the rest of the internet.  Back when SIP/RTP first emerged, it simply wasn't mature enough to work on the open internet as well as HTTP or SMTP or even FTP - it needed STUN, ICE, TURN, Opus and many other refinements to be really usable in the wild.  And similarly XMPP hasn't taken over the world quite as much as we once hoped.  Meanwhile, many folks went and built their own proprietary walled-garden solutions (be it Skype, FaceTime, Viber, WhatsApp, or even our own efforts) and we've ended up in the current horrible situation where our online communication is fragmented across hundreds of isolated apps and websites.  It's like a world where email was never unified, and half the world is still stuck on Compuserve.  And it's counter to the whole ethos of the internet as an open platform for collaboration and communication.

We decided that we want to fix this and so we have built and published a new open standard, together with open source (ASLv2) reference server (Python/Twisted) and client (JS/Angular, Python, Perl) codebases, and so provide new building blocks that can be used to build truly interoperable federated IM and VoIP functionality. We consider this effectively an investment in the industry: by creating a strictly non-profit initiative like Matrix, we both make the world a better place for end users - as well as creating new business opportunities (both opensource and commercial) for the telecoms industry as a whole.

The standard and code are all brand new and very much still in creation at this point, but we're releasing it early to get as much feedback and input from the community as early on as we possibly can. Right now our focus is on fully decentralised federated group messaging, but VoIP and identity management is coming together well too.  You can think of it as "making VoIP/IM as interoperable and flexible as email", or perhaps "the missing signalling layer for WebRTC", "XMPP for an HTTP world", or “what would happen if IRC, XMPP, SIP, SMTP, IMAP and NNTP had kids?” Here are some reasons we think that you should use Matrix:

• Simple pragmatic RESTful HTTP/JSON APIs.  No more XMPP or SIP stacks and wrestling XML streams or torture-testing SIP parsers.
• No single points of control for channels of communication (unless you really want it for moderation or similar). Room state for a room is synchronised with eventual consistency over all participating Matrix servers - no single server controls the room.
• No more netsplits - history re-heals itself if the matrix fractures
• All communication is group by default: 1:1 chat is just a subset of group chat.
• Multi-device aware: all state is stored and synchronised in realtime across all devices, and away-state and notifications are aware of multiple devices.
• Uses arbitrary 3rd party identifiers - doesn't rely on JIDs or SIP URIs for identity.
• Share the same simple HTTP signalling channel for messaging and VoIP
• Support more efficient transports if you want (e.g. low-bandwidth/low-roundtrip sync on mobile)
• Built for mobile - e.g. support push notification and low-bandwidth/low-latency client-server transports if needed (in progress)
• TLS (HTTPS) by default, either with self-signed certs with published public keys or proper SSL CA signed certs (in progress)
• End-to-end PKI encryption (in progress)
• Trusted federation of public identity servers available for publishing your PKI public keys and tracking your validated 3rd party IDs

If this sounds good to you, then please take a look at the spec, or our tutorials, or jump straight into playing with the APIs, or try running your own Matrix homeserver, or sign up to our mailing lists - and whatever else, come swing by #matrix:matrix.org and say hi!