The matrix.org IRC bridge now bridges all of Freenode!

by Matthew Hodgson | Jun 22, 2015 | Tech | 4 comments

We’ve been running an IRC gateway from Matrix to Freenode almost since day 1 – originally it was a simple perl bot written by tm604 using Net::Async::Matrix; later it was rewritten by LeoNerd to be a bit more modular, and nowadays it’s a full IRC/Matrix Application Service written in Node.js by Kegan.

Up until the end of last week the bridge was limited to synchronising a fixed number of channels between Freenode and Matrix (#matrix, #matrix-dev, #openwebrtc, #vuc and #hypothes.is, to be precise), as well as any PMs. But as of Friday, with huge thanks to the admins over at Freenode, we can now bridge *any* channel in Freenode through to Matrix.

Doing this is trivial – you just /join #freenode_#channelname:matrix.org from a typical Matrix client – e.g. /join #freenode_#Node.js:matrix.org will give you access to all of #Node.js via Matrix, effectively using Matrix as a great big distributed IRC bouncer in the sky ;)

There are a few limitations in the current setup:
* We only incrementally synchronise the membership lists when folks speak in either IRC or Matrix. This is to avoid flooding either IRC or Matrix with lurkers when the bridge initially joins a channel. We have some plans to improve this in future – see BOTS-53 for some of the sordid details.
* We don’t synchronise joins/parts currently to avoid flooding Matrix with lots of IRC join/part spam. Again, this will improve in future.
* You can’t join +k channels.
* Kicks/bans/invites and other ACLs currently don’t propagate between IRC & Matrix. (I.e. a Matrix user can be kicked from IRC, but it’ll continue to sit in Matrix unless also kicked for there). +i chanmode supported however.
* Bridged public IRC rooms are not yet advertised in the public room list on matrix.org.
* It should be possible to change the nickname of your IRC user by messaging !nick irc.freenode.net MrFlibble to @appservice-irc:matrix.org. (This isn’t actually turned on right now, but should be fixed shortly. See https://github.com/matrix-org/matrix-appservice-irc/blob/master/HOWTO.md#changing-nicks for details.

We’ll keep chipping away at making the IRC<->Matrix mapping perfect, but in its current state it’s still really usable. It’s obviously beta still, but please give it a go and let us know in #matrix:matrix.org how you get on with it!

Introducing all new matrix-js-sdk v0.1.0

by Matthew Hodgson | Jun 12, 2015 | Tech | 0 comments

Hi all,

If things seem a bit quiet here at the moment it’s because most of the Matrix team is in the ‘build’ phase across the board on a bunch of major new projects – including the long-awaited reusable UI component library for the Web, end-to-end encryption support, stable VoIP on mobile and a few other surprises. The first wave of all this new work landed today in the form of a new major version release (0.1.0) of matrix-js-sdk: our javascript SDK library.

The history of JS client support on Matrix is that in the original rush to get a PoC webclient out the door back in September, we jumped straight to talking to the Matrix HTTP API from Angular controllers in ‘syweb’. This then got split into an Angular SDK (matrix-angular-sdk) containing a bunch of services for handling the Matrix client state with the actual webapp sitting alongside as an example of the SDK. This then in turn got split into a basic matrix-js-sdk (wrapping the Matrix client-server HTTP API) and matrix-angular-sdk (handling the clientside state and exposing it as Angular services) – and this is how the current demo Angular webapp works at http://matrix.org/beta.

However, this poses a major problem if you want a richer client SDK but don’t want to use Angular – e.g. if you prefer another framework (or no framework at all), or are using the SDK in an Application Service or similar. So, this has prompted a major upgrade to the matrix-js-sdk in order to extend it to act both as a simple wrapper of the Matrix Client-Server HTTP API, but also expose a full object and event model to describe the state of a Matrix client together with all the higher level functions to drive it. To quote from the README:

This SDK provides a full object model around the Matrix Client-Server API and emits events for incoming data and state changes. Aside from wrapping the HTTP API, it:

• Handles syncing (via /initialSync and /events)
• Handles the generation of “friendly” room and member names.
• Handles historical RoomMember information (e.g. display names).
• Manages room member state across multiple events (e.g. it handles typing, power levels and membership changes).
• Exposes high-level objects like Rooms, RoomState, RoomMembers and Users which can be listened to for things like name changes, new messages, membership changes, presence changes, and more.

Later versions of the SDK will:

• Automatically retry requests to send messages due to network errors.
• Automatically retry requests to send messages due to rate limiting errors.
• Mark events’ sent status (e.g. ‘not sent’).
• Handle “local echo” of messages sent.
• Handle queueing of messages.
• Handle pagination.
• Expose a RoomSummary which would be suitable for a recents page.
• Provide different pluggable storage layers (e.g. local storage, database-backed)

It also is designed to provide an API that abstracts both version 1 of the client-server API and the upcoming version 2 (which fixes various thinkos we’ve discovered along the way in v1).

This is incredibly exciting stuff as it now gives a really robust yet lightweight API for client-side and application-service development in JavaScript. Predictably enough we’re using it to develop our new reusable web UI components, and I suspect we’ll see new Node-based application services making use of in the near future. Meanwhile, it’s more than topical as it should run straight on top of the Tessel JavaScript hardware modules we’re giving away this weekend as our prize for the best hack built on Matrix at TADHack – letting the little Tessel ARM system-on-a-chip speak a very rich and native Matrix dialect!

The new matrix-js-sdk comes with comprehensive jsdoc detailing the new API which you can find at http://matrix-org.github.io/matrix-js-sdk/global.html. There are also some basic examples available, including a new simple node-powered command-line client designed for testing the SDK. Finally, if you’re interested in reading the design process by which we’ve converged on the current API, all the details may be found in JIRA on SYJS-5.

So: if you’ve been itching to get your hands on a much more powerful pure-JS Matrix SDK, now’s your chance! It’s very early days for the new API so we expect to see a few incompatible changes on the horizon, but we encourage you to have a play and tell us what you think!.

To find out more, go check out the project at http://github.com/matrix-org/matrix-js-sdk, or if you’re feeling daring just grab the library with npm install matrix-js-sdk and get hacking!

Synapse 0.9.1 released

by Matthew Hodgson | Jun 1, 2015 | Tech | 0 comments

In the excitement of KamailioWorld last week we completely forgot to mention that we released Synapse 0.9.1.

This is a pretty important performance and stability update of all the new stuff that landed in 0.9.0, as well as landing a major new feature in the form of ‘backfill’: we finally have the ability to correctly sync in historical conversation history over federation for newly federated rooms. In other words, if you join a remote room you should be able to navigate its history as intended.

We highly recommend upgrading to 0.9.1 for all the performance improvements and backfill support – get it now from http://github.com/matrix-org/synapse.


Changes in synapse v0.9.1 (2015-05-26)
======================================

* Add support for changing the bind host of the metrics listener via the
``metrics_bind_host`` option.