Matthew Hodgson

162 posts tagged with "Matthew Hodgson" (See all authors)

Bridging Matrix & SIP via Verto

2014-11-30 — TutorialsMatthew Hodgson

One of the final remaining missing bits of Matrix today is specifying and implementing the Application Service (AS) APIs which allow you to easily extend Matrix with custom server-side functionality. The AS APIs should let you perform any arbitrary manipulation on chatroom contents, modulo end-to-end encryption constraints - e.g. machine translation; archiving/searching contents; interactive automated services; conferencing; firing push notifications and other hooks; etc. If you really want to look behind the curtain, the bug tracking the development (somewhat out-of-date) is at SPEC-34.

However, the most obvious use case for this is gatewaying Matrix rooms through to existing communication platforms (XMPP, SIP, non-standardised systems) - which is obviously key to Matrix's overall goal of defragmenting communication.  And the good news is that even though the AS APIs don't yet exist, we can still make good progress here through the existing client-server API.  Anyone who's hung around chat systems like IRC should be familiar with the idea of bots - non-human users who participate in chatrooms and but perform arbitrary automated functionality - and you can go quite a long way in using the 'bot' idiom to add automatic functionality to Matrix.

[In fact the first AS API we'll be adding will probably be simply extending the client-server API with some additional privileges to allow homeserver admins to hook up services to their server which are essentially privileged bots (e.g. ability to autojoin rooms created on that server with high power-level; ability to flag themselves as an invisible 'service bot'; ability to monitor events from rooms without joining them: useful for read-only services such as sending push notifications, adding search/archive functionality; etc).  This should also be familiar to IRC users, as it's similar to the model that IRC Services uses.]

So, we already have a few bots hanging around prototyping out bridging to other systems, which hopefully should evolve into full Application Services (where it makes sense; sometimes a bot is good enough).  For instance, we have the Matrix/IRC Bridge thanks to tm604 and LeoNerd.  The way this works is simply a bot which joins IRC channels and their Matrix room equivalents; watching the messages on both sides of the bridge and relaying them to the other side, creating virtual users as required.  In future we can be smarter about having the bridge talk on behalf of actual users, or letting actual users control their virtual users, but it's good enough as a first cut.

So for Friday's VUC 517, we decided at the last minute (on Tuesday) to make as much of VUC accessible via Matrix as possible.  One side of this was hooking up the Jitsi Video Bridge to be accessible by talking to the underlying XMPP server - the other side was hooking up via SIP to the ZipDX audio bridge that is used for audio-only participants in the conference.  Both of these would be done as Matrix bots - a virtual user that you could voice/video call 1:1 over Matrix which would then route your call into VUC appropriately.

By Thursday, the Jitsi bot got to the point of being able to place calls and see a single video stream (picked at random), but the video uplink wasn't getting through and actually selecting the right stream to watch (or viewing multiple streams) wasn't in place either.  I'm sure there'll be a similar blogpost once it's finished, so I'm not going to talk about it further here.  Meanwhile, on Thursday night we hacked together a separate bot to jack into the ZipDX bridge via SIP.  Tim Panton's suggestion was to use FreeSWITCH's mod_verto for this, and after Anthony Minesalle and Mike Jerris from FreeSWITCH had popped up on #matrix:matrix.org on Tuesday to find out what we're up to, this seemed like serendipity.

We hadn't played with mod_verto before, although had been pointed at it by someone on IRC shortly after we released Matrix - it's a cool project from the FreeSWITCH dev team that exposes a simple JSON-RPC interface for call signalling over websockets, providing a much more suitable way for WebRTC developers to get calls in and out of FreeSWITCH than shoehorning a SIP stack into their browser.  In this respect it's quite similar to Matrix, but there are some huge differences:

  • Verto doesn't (yet) do federation - either for message-passing (like XMPP) or history-replication (like Matrix or XMPP FMUCs).  In fact, Matrix fundamentally competes more with JSON-RPC at OSI layer 5 by defining a standardised RESTful API for federated state synchronisation - which so happens to define some datatypes for VoIP signalling; whereas Verto currently seems to be focused solely on the application-layer problem of VoIP signalling.
  • Verto is a generic RPC API with method names like verto.invite, verto.answer, verto.media, verto.bye etc. for handling call signalling.  It's obviously readily extensible to any other functionality expressed as an RPC invocation.  The Matrix client-server API however passes around event objects within the context of a room - it's message passing rather than RPC.
  • Matrix's VoIP events support trickle-ICE; announcing ICE candidates from WebRTC as and when they become available.  This good is for speedy call-setup (you don't have to wait for all ICE to complete before setting up the call) and to support call continuity when roaming between different IP networks (in theory).  However, Verto currently requires ICE candidates to be presented monolithically - it hasn't made sense to implement trickle-ICE as FreeSWITCH's core engine doesn't support it yet.
  • Verto looks to be wired to speak JSON-RPC over Websockets, whereas Matrix deliberately uses plain old HTTP as its baseline for maximum simplicity and compatibility in PUTting and GETting JSON events around
  • Verto could be an interoperable standard but the API hasn't been documented yet (unless I've totally missed it) - to build the bot we looked at the websockets tab in Chrome's network inspector and drew some inferences from the JSON seen in a call placed using the FreeSWITCH Verto demo site, which was very intuitive and almost self-documenting.  Meanwhile, the (minimal) doc for Matrix's events is up at http://matrix.org/docs/spec/#voice-over-ip.
Verto has a huge advantage however, in that FreeSWITCH has a mod_verto today, and doesn't have a mod_matrix - so one can use mod_verto right now as an easy way to get VoIP calls in and out of FreeSWITCH from the web and bridge them to SIP!  So, when writing a Matrix<->SIP bridging bot for VUC, Verto turned out to be a really nice way to quickly get something up and running.  The end result is at https://github.com/matrix-org/synapse/blob/develop/contrib/vertobot/bot.pl - a (precisely!) 300 line perl script built on LeoNerd's Net-Async-Matrix and Net::Async::Protocol::WebSocket which logs into Matrix and routes any 1:1 audio calls it receives through to the defined mod_verto service.  Currently it gleefully hardcodes in the destination extension it calls and the caller-ID, but this could trivially be extended.  It also chokes on SSL WebSockets, so your mod_verto needs to be listening unencrypted on port 8081.

The task of mapping between Matrix m.call.* VoIP events and Verto verto.* RPC methods was almost entirely trivial (although I hasten to add that Matrix's and Verto's were developed completely independently - it's just that there are only so many ways to express VoIP signalling in JSON!)

  • Matrix's m.call.invite is equivalent to the combination of verto.invite + verto.media (but may lack ICE candidates)
  • Matrix's m.call.candidates has no direct equivalent, so has to be coalesced and merged into verto.media
  • Matrix's m.call.answer is equivalent to verto.answer (but may lack ICE candidates)
  • Matrix's m.room.displayname is equivalent to verto.display (assuming I understand verto.display)
  • Matrix's m.call.hangup is equivalent to verto.bye
  • …and these are the only verto RPCs we mapped.
For the demo itself, we obviously needed a FreeSWITCH with mod_verto all up and running to hook into the ZipDX bridge: our friends at Truphone were good enough to provide one at zero notice (Thanks James, Andy, Giacomo!), and we were up and running.

Unfortunately we did hit some problems: Net::Async::Matrix has a few quirks which LeoNerd is working out currently; the bot doesn't coalesce the trickle-ICE properly currently causing a race-condition that means ICE setup may fail; Matthew's use of IO::Async was a bit buggy; and moreover we didn't have time to implement DTMF… which was a bit of a shame as you can only unmute yourself on the ZipDX bridge via DTMF *5!

But in general, the mini-hackathon was a success and it was great fun to be able to listen into VUC via the bridge and demonstrate the first ever Matrix<->SIP call!  The bot ran as @vucbot:matrix.org, although is turned off now as there's no VUC to listen to, and the FreeSWITCH & bot were only deployed temporarily.  Once the kinks mentioned above are sorted out we'll hopefully set it running again permanently!  And hopefully this little bot is an exciting precursor to more robust Matrix bridges and application services in the months to come...

If you're crazy enough to want to try to run the bot yourself, then it should actually be quite simple to get up and running:

# grab synapse if you don't have it already git clone https://github.com/matrix-org/synapse.git synapse-develop cd synapse-develop

🔗you'll need the develop branch, as we haven't released a build with vertobot in it yet

git checkout develop cd contrib/vertobot

🔗you'll need cpanm to install the perl dependencies

cpan -i App::cpanminus cpanm --installdeps .

🔗manually install a develop version of Net::Async::Matrix as cpanm can't figure it out, seemingly

cpanm --force PEVANS/Net-Async-Matrix-0.11_002

🔗(you may need to also replace the 'croak' for the "Already have a room with ID" error with 'warn' in Net::Async::Matrix if the bot crashes with this error)

🔗create a username account for your bot on a Matrix homeserver somewhere at this point

🔗set up a config file

cp config.yaml mybot.yaml

🔗edit mybot.yaml to taste - at the least you must specify the login & password & homeserver for your bot!

🔗run it!

./bot.pl -c mybot.yaml

Finally, huge thanks to everyone to helped make the VUC bridging escapade work out - Emil Ivov at Jitsi, James Body, Andy Smith and Giacomo Vacca at Truphone, Anthony Minesalle & Mike Jerris & Brian West at FreeSWITCH for writing freeswitch and mod_verto, Tim Panton for the VUC intro and suggestion of mod_verto, Randy Resnick & Michael Graves at VUC itself, and of course the Matrix team for glueing our side of it together!

Looking forward to lots more ambitious cross-protocol gatewaying and federation in future!

Synapse 0.5.3a released!

2014-11-29 — TechMatthew Hodgson

Since we exited alpha and released Synapse 0.5.0 last week there's been a flurry of bug fix releases as we ran around firefighting some of the more exciting problems which popped up thanks to merging the federation-auth and event-signing branches.

We released 0.5.3a on Nov 27, which seems to now be pretty stable - if you were holding off on upgrading your homeserver and trying to federate with the new 0.5 release branch, now would be a great time to press the button!

Most excitingly, we believe we have finally fixed the PyNaCL dependency problems which have plagued pretty much anyone setting up a homeserver. This was a problem in PyNaCL itself - huge thanks to Mark for hunting it down and sending the PyNaCL team pull requests to get it fixed. As a result, installing synapse as of 0.5.3a really should be a one-liner at last (please let us know if it isn't!):

pip install --user --process-dependency-links https://github.com/matrix-org/synapse/tarball/master

The full changelog of what's been going on since 0.5.0 is as follows:

Changes in synapse 0.5.3a (2014-11-27)
=====================================

 * Depend on a fixed version of PyNaCL
 * Fix bug that caused joining a remote room to fail if a single event was not
   signed correctly.
 * Fix bug which caused servers to continuously try and fetch events from other
   servers.

Changes in synapse 0.5.2 (2014-11-26)
=====================================

 * Fix major bug that caused rooms to disappear from people's initial sync.

Changes in synapse 0.5.1 (2014-11-26)
=====================================
See UPGRADES.rst for specific instructions on how to upgrade.

 * Fix bug where we served up an Event that did not match its signatures.
 * Fix regression where we no longer correctly handled the case where a
   homeserver receives an event for a room it doesn't recognise (but is in.)

Synapse enters beta with the release of v0.5.0!

2014-11-20 — TechMatthew Hodgson

We're really excited to release the biggest update yet to Synapse (the python/twisted reference Matrix homeserver implementation) - version 0.5.0 is out!

This effectively concludes our alpha testing phase - Synapse's security model is now feature complete and we are now cautiously encouraging people to run their own Synapse installation on the 'net; federate up; and help us squash all and any bugs as we get beta testing.

Synapse 0.5.0 has huge database schema changes from previous versions as we have landed both the event-signing and federation-authorisation branches and so added full cryptographic signing of all matrix events and unified the client-server and server-server model of events/PDUs.  As a result, migrating history is Hard - we recommend a clean start if possible; if not, come talk to us in #matrix:matrix.org.  UPGRADE.rst has the details.

The full changelog is as per below - please upgrade your homeserver or install a new one if you're new here and join Matrix and help us create a robust open distributed messaging fabric for the web!

Changes in synapse 0.5.0 (2014-11-19)
=====================================
This release includes changes to the federation protocol and client-server API
that is not backwards compatible.

This release also changes the internal database schemas and so requires servers to
drop their current history. See UPGRADES.rst for details.

Homeserver:
 * Add authentication and authorization to the federation protocol. Events are
   now signed by their originating homeservers.
 * Implement the new authorization model for rooms.
 * Split out web client into a separate repository: matrix-angular-sdk.
 * Change the structure of PDUs.
 * Fix bug where user could not join rooms via an alias containing 4-byte
   UTF-8 characters.
 * Merge concept of PDUs and Events internally.
 * Improve logging by adding request ids to log lines.
 * Implement a very basic room initial sync API.
 * Implement the new invite/join federation APIs.

Webclient:
 * The webclient has been moved to a separate repository.

Synapse 0.4.2 released!

2014-10-31 — GeneralMatthew Hodgson

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.

Alpha builds of native mobile Matrix SDKs available... and Synapse 0.4.1 released!!

2014-10-18 — GeneralMatthew Hodgson

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:

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

Synapse 0.3.4 released!

2014-09-25 — TechMatthew Hodgson

Hi all,

Synapse 0.3.4 is out! The main changes here are a huge fleet of bugfixes to the webclient, and the addition of TURN support for VoIP relaying. This makes VoIP/Video call setup much more reliable (although the UI still needs some love).

Meanwhile, we set an IRC bridge (https://github.com/tm604/Matrix-IRCBridge) running linking #matrix:matrix.org and #matrix-dev:matrix.org to their Freenode counterparts (#matrix & #matrix-dev respectively) - much fun to see innocent IRC users assimilated up into Matrix, and for us to now be using Matrix for /all/ our development chat and interaction (whether it's through a Matrix client or an IRC client).

To upgrade to the latest homeserver, just git pull && ./synctl restart. If you want to start playing with VoIP in earnest on your own homeserver, you'll need to install a TURN server - see docs/turn-howto.rst for details on how to set one up.

http://matrix.org/alpha has already been upgraded to 0.3.4, so feel free to play with all the new stuff there.

thanks,

Matthew

🔗Changes in synapse 0.3.4 (2014-09-25)

This version adds support for using a TURN server. See docs/turn-howto.rst on how to set one up.

Homeserver:

  • Add support for redaction of messages.
  • Fix bug where inviting a user on a remote home server could take up to 20-30s.
  • Implement a get current room state API.
  • Add support specifying and retrieving turn server configuration.

Webclient:

  • Add button to send messages to users from the home page.
  • Add support for using TURN for VoIP calls.
  • Show display name change messages.
  • Fix bug where the client didn't get the state of a newly joined room until after it has been refreshed.
  • Fix bugs with tab complete.
  • Fix bug where holding down the down arrow caused chrome to chew 100% CPU.
  • Fix bug where desktop notifications occasionally used "Undefined" as the display name.
  • Fix more places where we sometimes saw rooms as IDs rather than aliases.
  • Fix bug which caused lag when entering text in the text box.

Synapse 0.3.3 released

2014-09-22 — TechMatthew Hodgson

Hello world,

Synapse 0.3.3 was released today, concentrating on both feature & stability improvements on the webclient. The big news is that 1:1 video calling via WebRTC is implemented (although we're still working on some stability issues, and Synapse doesn't support TURN yet. This will be coming in the next few days however!).

Play with the demo server at http://matrix.org/alpha, or update your own homeserver with a git pull && ./synctl restart or by cloning a new checkout with git clone https://github.com/matrix-org/synapse.git

--Matthew

🔗Changes in synapse 0.3.3 (2014-09-22)

Homeserver:

  • Fix bug where you continued to get events for rooms you had left.

Webclient:

  • Add support for video calls with basic UI.
  • Fix bug where one to one chats were named after your display name rather than the other person's.
  • Fix bug which caused lag when typing in the textarea.
  • Refuse to run on browsers we know won't work.
  • Trigger pagination when joining new rooms.
  • Fix bug where we sometimes didn't display invitations in recents.
  • Automatically join room when accepting a VoIP call.
  • Disable outgoing and reject incoming calls on browsers we don't support VoIP in.
  • Don't display desktop notifications for messages in the room you are non-idle and speaking in.

Synapse 0.3.2 released

2014-09-18 — TechMatthew Hodgson

We just pushed out a major new release (0.3.0) of Synapse: the current reference Matrix homeserver, swiftly followed by some hotfixes (0.3.1, 0.3.2).

The big changes are:

  • Change the VoIP setup API to be more efficient (bundling together media stream candidates into a single setup object). API breaking change!
  • Change the Registration API to be more consistent. API breaking change!
  • Lots of nice usability refinements to webclient - e.g. per-message notifications; cursor-key history navigation; faster room loading
  • More bugfixes and stability fixes on the homeserver

Please reload the page if you're lurking on http://matrix.org/alpha to pull in the new webclient.

If you're running a homeserver - please upgrade with a quick git pull && ./synctl restart.

If you're not running a homeserver... why not? ;D

--Matthew

🔗Changes in synapse 0.3.2 (2014-09-18)

Webclient:

  • Fix regression where an empty "bing words" list in old accounts didn't send notifications when it should have done.

🔗Changes in synapse 0.3.1 (2014-09-18)

This is a release to hotfix v0.3.0 to fix two regressions.

Webclient:

  • Fix a regression where we sometimes displayed duplicate events.
  • Fix a regression where we didn't immediately remove rooms you were banned in from the recents list.

🔗Changes in synapse 0.3.0 (2014-09-18)

See UPGRADE for information about changes to the client server API, including breaking backwards compatibility with VoIP calls and registration API.

Homeserver:

  • When a user changes their displayname or avatar the server will now update all their join states to reflect this.
  • The server now adds "age" key to events to indicate how old they are. This is clock independent, so at no point does any server or webclient have to assume their clock is in sync with everyone else.
  • Fix bug where we didn't correctly pull in missing PDUs.
  • Fix bug where prev_content key wasn't always returned.
  • Add support for password resets.

Webclient:

  • Improve page content loading.
  • Join/parts now trigger desktop notifications.
  • Always show room aliases in the UI if one is present.
  • No longer show user-count in the recents side panel.
  • Add up & down arrow support to the text box for message sending to step through your sent history.
  • Don't display notifications for our own messages.
  • Emotes are now formatted correctly in desktop notifications.
  • The recents list now differentiates between public & private rooms.
  • Fix bug where when switching between rooms the pagination flickered before the view jumped to the bottom of the screen.
  • Add support for password resets.
  • Add bing word support.
  • Update VoIP implementation to use new API

Registration API:

  • The registration API has been overhauled to function like the login API. In practice, this means registration requests must now include the following: 'type':'m.login.password'. See UPGRADE for more information on this.
  • The 'user_id' key has been renamed to 'user' to better match the login API.
  • There is an additional login type: 'm.login.email.identity'.
  • The command client and web client have been updated to reflect these changes.

Synapse v0.2.3 released

2014-09-13 — TechMatthew Hodgson

We're back home from TechCrunch where we had a great time arguing the pros and cons of Matrix versus XMPP with anyone and everyone - thanks to all who came to talk to us!

Meanwhile, Synapse v0.2.3 was released yesterday: the emphasis this week has been on improving stability issues on the server, and lots of cosmetic and functionality fixes on the webclient.

If you're running a homeserver, please upgrade asap - upgrading has never been easier - assuming you've checked out the master branch, simply:

git pull
./synctl restart

...and you will be up and running on 0.2.3. We keep the master branch tracking the latest release.  http://matrix.org/alpha is already on the latest release should you wish to experiment first!

Alternatively, if you're installing from scratch, try:

git clone https://github.com/matrix-org/synapse.git
python setup.py develop --user
./synctl start # to generate a default config
./synctl start # to actually set it running

and then head over to http://localhost:8008 to play with your very own Matrix homeserver!

🔗Changes in synapse 0.2.3 (2014-09-12)

Homeserver:

  • Fix bug where we stopped sending events to remote home servers if a user from that home server left, even if there were some still in the room.
  • Fix bugs in the state conflict resolution where it was incorrectly rejecting events.
  • Many stability fixes

Webclient:

  • Display room names and topics.
  • Allow setting/editing of room names and topics.
  • Display information about rooms on the main page.
  • Handle ban and kick events in real time.
  • VoIP UI and reliability improvements.
  • Add glare support for VoIP.
  • Improvements to initial startup speed.
  • Don't display duplicate join events.
  • Show message sent/sending state via opacity
  • Multiline message sending support
  • Many other bug & stability fixes

Techcrunch Update!

2014-09-09 — EventsMatthew Hodgson

The Matrix team is at TechCrunch Disrupt SF 2014 this week - we had a great time at the hackathon on Saturday/Sunday where we were really excited to see several teams building their hacks on Matrix APIs - we stayed the night to support whilst building out our own hack (experimenting with sending collaborative 3D animations over Matrix as JSON)! Huge thanks to everyone who built on top of Matrix - hope you had as much fun as we did :)

Please come talk to us in person in Startup Alley (next to the Brazilian Pavilion) if you're attending Disrupt and find out all about Matrix first hand!

6am Hackathon...

(Photo shows us somehow surviving in the 6am slot. Mental note to never try to do raycasting vector maths after being up for 24 hours again...)