Thoughts

A few years ago, back when Matrix was originally implementing end-to-end encryption, we asked Moxie (the project lead for Signal) whether he’d ever consider connecting Signal (then TextSecure) to Matrix. After all, one of Matrix’s goals is to be an interoperability layer between other communication silos, and one of the reasons for us using Signal’s Double Ratchet Algorithm for Matrix’s encryption was to increase our chances of one day connecting with other apps using the same algorithm (Signal, WhatsApp, Google Allo, Skype, etc). Moxie politely declined, and then a few months later wrote “The ecosystem is moving” to elaborate his thoughts on why he feels he “no longer believes that it is possible to build a competitive federated messenger at all.”

At the time we didn’t respond via a blog post; instead we ended up talking it through a few times in person to see how misaligned we really were. The conclusion was that we agreed to disagree and Moxie said he’d be happy to be proved wrong, and wished us good luck. However, the subject has come up again thanks to Moxie’s talk on the same subject at 36C3 last week, and we keep getting asked to write a formal response on the Matrix side. So, here’s an attempt to do so. (Moxie didn’t want the 36C3 talk recorded, and I haven’t watched it, so this is responding to the original blog post).

From my perspective, the main points proposed in ‘The ecosystem is moving’ boil down to:

• Decentralised systems are harder to design and build than centralised ones, as coordination is harder if you don’t have a single authority to trust.

• Decentralised systems are harder and slower to evolve than centralised ones, as you can’t force participants to rapidly roll out (or even agree on) new features.

• Users in federated systems tend to coalesce around the best/biggest server that the bulk of people use - which means that server typically gets to see a disproportionate amount of communication metadata (who’s talking to who, and when), and has disproportionate power over the network, which could bully others away from running their own deployments.

• If users don’t trust their app provider, they can always go switch apps, which gives them freedom.

• Open systems are less secure because you have no control over the quality of the implementations - if anyone can bring their own client or server to the table, all it takes is one bad implementation to compromise everyone in the vicinity.

Now, all of these points are valid to some extent.

It’s absolutely true that decentralised systems are harder than centralised ones. Prior to Matrix we built centralised comms systems - we literally can do a side-by-side comparison for the same team to see how easily and fast we built our centralised comms system relative to Matrix. Empirically It took us around 6 times longer to get to the same feature-set with Matrix.

It’s also true that decentralised systems are harder to evolve than centralised ones - you can’t just push out a given feature with a single app update, but you have to agree and publish a public spec, support incremental migration, and build governance processes and community dynamics which encourage everyone to implement and upgrade. This is hard, but not impossible: we’ve spent loads of time and money on Matrix’s governance model and spec process to get it right. It’s still not perfect, but we haven’t seen much fragmentation so far, and when we’re pushing out a feature empirically we can and do go just as fast as the centralised alternatives. (E2E by default is a bit of a special case because we’ve had to go and reimplement many features users take for granted today in an E2E-capable manner, but we’re sprinting to get it done in the coming weeks). A bigger problem is that there are hundreds of spec change proposals which folks would like to see in the protocol, and finding a way to manage expectations and parallelise spec progress is hard - something we’re looking to improve in 2020 (although still figuring out how!)

It’s also fair that in a multi-server federated model, users naturally tend to sign up on the most prominent server(s) (e.g. the matrix.org homeserver in the case of Matrix). In practice, the matrix.org homeserver currently makes up about 35% of the visible Matrix network by active users. It’s also true that Matrix servers currently store metadata about who’s talking to who, and when, as a side-effect of storing and relaying messages on behalf of their users. And without an adequate protocol governance system in place, a large server could start pushing around smaller ones in terms of protocol behaviour. In practice, we’re looking into solving metadata protection in Matrix by experimenting with hybrid P2P / Client Server models - letting users store their metadata purely clientside if they so desire, and potentially obfuscating who’s talking to who via mixnets of blinded store & forward servers (more about this coming up at FOSDEM). Combined with nomadic accounts, this would let us eventually turn off the matrix.org server entirely and eliminate the pseudo-centralisation effect - the default ‘server’ would be the one running on your client.

It’s true that if a user doesn’t trust (say) Telegram, they are free to go switch to Signal or WhatsApp or whatever instead… at the massive expense of having to persuade all their friends to install yet another app, and fragmenting their conversation history across multiple apps.

Finally, it’s also true that because anyone can develop a Matrix client or server and connect to the global network, there’s a risk of bad quality implementations in the wild. There are many forks of Riot on the app stores - we simply can’t vouch for whether they are secure. Similarly there are Matrix clients whose E2E encryption is partial, missing, or unreviewed. And there are a wide range of different Matrix servers run by different people with different agendas in different locations, which may be more or less trustworthy.

HOWEVER: all of this completely ignores one critical thing - the value of freedom. Freedom to select which server to use. Freedom to run your own server (perhaps invisibly in your app, in a P2P world). Freedom to pick which country your server runs in. Freedom to select how much metadata and history to keep. Freedom to choose which apps to use - while still having the freedom to talk to anyone you like (without them necessarily installing yet another app). Freedom to connect your own functionality - bots, bridges, integrations etc. Freedom to select which identifiers (if any) to use to register your account. Freedom to extend the protocol. Freedom to write your own client, or build whole new as-yet-unimagined systems on top.

It’s true that if you’re writing a messaging app optimised for privacy at any cost, Moxie’s approach is one way to do it. However, this ends up being a perversely closed world - a closed network, where unofficial clients are banned, with no platform to build on, no open standards, and you end up thoroughly putting all your eggs in one basket, trusting past, present & future Signal to retain its values, stay up and somehow dodge compromise & censorship… despite probably being the single highest value attack target on the ‘net.

Quite simply, that isn’t a world I want to live in.

We owe the entire success of the Internet (let alone the Web) to openness, interoperability and decentralisation. To declare that openness, interoperability and decentralisation is ‘too hard’ and not worth the effort when building a messaging solution is to throw away all the potential of the vibrancy, creativity and innovation that comes from an open network. Sure, you may end up with a super-private messaging app - but one that starts to smell alarmingly like a walled garden like Facebook’s Internet.org initiative, or an AOL keyword, or Google’s AMP.

So, we continue to gladly take up Moxie’s challenge to prove him wrong - to show that it’s both possible and imperative to create an open decentralised messaging platform which (if you use reputable apps and servers) can be as secure and metadata-protecting as Signal… and indeed more so, given you can run your server off the grid, and don’t need to register with a phone number, and in future may not even need a server at all.

--Matthew

(Comments over at HN)

Hi all, Ben here.

Since joining the core team as Developer Advocate last year it's been quite a ride. One of the best things about the job is getting the chance to talk to so many people about their projects and what they would like to see happen in the matrix ecosystem. With so much going on, I just want to say thanks to everyone who has been so welcoming to me and share some of my personal highlights, as I recall them, from 2018!

🔗Clients

Fractal was featured in the very first TWIM, announcing v1.26. Since then, the team have hosted two IRL hackfest events (Strasbourg and Seville - where to next, Stockholm? Salisbury?), engaged two GSOC students and continued to push out releases. At this point, Fractal is a full-featured Matrix client for GNOME.

Matrique became Spectral, and is generally awesome. Apparently the name "Matrique" was chosen because it sounds French, but those who speak the language well revealed that this name was not ideal! The project was re-named "Spectral", and is going strong. I really appreciate the multi-user facility! It's a great looking client, and runs great on macOS too (protip: get more attention from /me by providing a macOS build…)

On which subject, Seaglass is a native macOS client. First announced in June, this client supports E2EE rooms (via matrix-ios-sdk), and is also available on homebrew.

Ubuntu Touch has the most Matrix clients per-user of any platform. UT epitomises the resilience and collaborative spirit of Open Source. It's a true community maintenance effort, and is as friendly a community as you might meet. uMatriks came first, but it's FluffyChat that prompted me to install it on my battered old OnePlus One. FluffyChat is now extremely full-featured, with E2EE support being actively discussed.

In the command line, gomuks appeared and quickly became a competent client, but in terms of sheer enthusiasm and momentum, I must give commendation to matrix-client.el, a newly revived mode for Emacs which turns your editor/OS into a great Matrix Client. I enjoyed using it enough that it began to change my mind about using emacs. Laptops have more than 8mb memory these days anyway.

🔗A culture of bots

There is a tendency in the community to build a bot for everything and anything. This has reached the point where there are multiple flairs available depending on what bots you like to make (silly vs serious.)

TravisR was perhaps the first person I saw to get the obsession, creating

• matrix-monitor-bot
• matrix-trello-bot
• matrix-alias-bot
• hashtag bot (perhaps the most absurd!)

and more…

Cadair even made twimbot, designed to make it easier to consume and produce This Week in Matrix itself.

In June tulir started maubot, a plugin-based bot system built in Python, which now also has a management UI.

🔗All bridges lead to Matrix

Or from Matrix, depending on which way you want to send the message.

Around May, I started to notice another obsession brewing in the community. Bridging is a core part of the Matrix mission, but it was around this time I started seeing it in the wild.

Summer 2018 Half-Shot began working in the Matrix core team, and was hugely productive in maintaining and developing the bridge infrastructure for matrix.org. IRC bridging is far more stable and reliable now than it was a year ago. And yet there are still more bridges - too many to list, so I'm picking the ones I've used and enjoyed.

Discord is bridged by matrix-appservice-discord, handled by Half-Shot, aided and abetted by anoa but with a new maintainer this year, Sorunome. This bridge is now feature-rich and sits at v0.3.1.

tulir's suite of bridges including mautrix-telegram and mautrix-whatsapp are extremely stable and useful - big thank you to TravisR for maintaining t2bot.io and hosting the Telegram bridge too.

SMSMatrix, a phone-hosted bridge is simple and works great for SMS bridging.

🔗Libraries, SDKs, Frameworks

I enjoyed using matrix-bot-sdk for building elizabot (more coverage needed for that!), and the SDK recently received support for application services.

In April, kitsune announced v0.2 of libqmatrixclient describing it as “the first one more or less functional and stable" - confidence! This library now powers both Quaternion and Spectral. QMatrixClient has continued to get updates, plus features including lazy loading and VoIP signalling.

There are a few libs I want to pay more attention to this year, starting with tulir's maubot now that it has been rewritten in Python. I'm also excited to see jmsdk, part of ma1uta's broader ecosystem of Matrix tooling - a Java-based SDK.

🔗Ruma Resurrection

Until around June, Ruma was receiving regular updates. There was a pause as the team waited for Rust async/await to land, and also to get some stability in the Matrix Spec. Still waiting on Rust, but now that the Matrix Spec is stabilising, Ruma is showing signs of life too. I have also been watching other homeserver projects begin to restart, which makes for a great start to 2019.

🔗DSN Traveller by Florian

Matrix was featured as part of a Master's thesis by Florian Jacob.

DSN Traveller tries to get a rough overview of how the Matrix network is structured today. It records how many rooms it finds, how many users and servers take part in those rooms, and how they relate to each other, meaning how many users a server has and of how many rooms it is part of.

Florian's thesis was handed in last August. Source code is available.

All details at https://dsn-traveller.dsn.scc.kit.edu/, room at #dsn-traveller:dsn-traveller.dsn.scc.kit.edu.

🔗Still more

Synapse dominates the homeserver space right now, so if you want to host your own homeserver today it's the obvious choice. Too great a variety of installation guides was doing more harm than good, so Stefan took the initiative to create a definitive community-driven Synapse installation guide, including a room to discuss and improve the text. Find the guide linked from here, and chat about the guide in #synapseguide:matrix.org.

I want to use Matrix, and I want to host my own homeserver. As such, matrix-docker-ansible-deploy is a project I absolutely love. It uses Synapse docker images from the Matrix core team, and combines them with Ansible playbooks written and organised by Slavi. It lets you quickly deploy everything needed for a Synapse homeserver, and it's simple enough that even I can use it.

Construct, a homeserver implementation in C++ began successfully federating with Matrix, work progressed from around April/May.

Having a Matrix-native mode for shields.io (those counter/indicator images you often see at the top of repos) seems like something petty at first, but it's actually a great indicator of the importance of Matrix from the outside. Plus, I love seeing the images at the top of different repos. Thanks Brendan for helping this along.

Two students worked on Matrix-related projects during GSOC 2018.

• Zil0 created E2EE bindings for matrix-python-sdk
• APwhitehat worked on the federation APIs in Dendrite

Something which came in super-helpful for me when testing homeserver installations was f0x's fed-tester. Source code available (obv.)

🔗Thanks for all the projects

Thanks for a great 2018. There was so much to learn about, so much to write about, and so many great community members to meet and chat to! If I didn't mention your project, I'm sorry to have been either forgetful or to not be able to include everything.

If you think I've missed something, or if there's a project I should have included rather than another, or even if you just disagree with my choices, let's discuss it in #twim:matrix.org. See you there, and let's all parade ahead to a productive, open, interoperable 2019!

Thank you to Half-Shot for all your work on Bridges over the last months and beyond. Today is your last day, but I'm sure we'll see you again before long. Text below is from Half-Shot.

---

Today marks my last day of my 3 month internship at New Vector (the startup which hires many of the core Matrix team). For those of you who haven't been reading Ben's fabulous blog posts, I've been working exclusively on bridges; in particular the IRC bridge.

Tasked with the goal of making it crash less and run faster, I hope that the evidence is visible and people are generally having a better experience on it!

Some stats pulled from the matrix-appservice-irc repo:

• 39 PRs closed (4 remain open)
• 27 issues closed, 27 issues opened.
• 334 commits, averaging 7.6 commits a PR.

Commits this year:

---

But aside from showing off some stats, I wanted to mention all the new features:

• Replies on Matrix translate well to IRC, or as well as IRC allows.
• People mentioning your IRC nick now ping your matrix user, finally!
• So. Many. Metrics. Everything you wanted to know about the internals of the bridge, but were too afraid to --inspect.
• Not spamming homeservers with join requests on startup (it makes for a happy ops team).
• No longer are IRC users shackled to a "(IRC)" extension on their displayname, you can be who you want with group flairs!
• Support for node 4 has been dropped, and support for 6,8 and 10 has been assured.

On the matrix-appservice-bridge side, I optimised some calls to cache locally and avoid hitting the homeserver too often, and disabling presence for homeservers that don't support it.

There are future plans to make bridging more visible to Matrix Clients as a first class citizen. Ideas like speccing a state event (MSC1410) so that bridges can interact with each other properly and clients can create full bridge management views which are still decentralised from an integration manager.

I'd like to give a shoutout to Travis who has reviewed nearly all my changes that have made their way into the bridge, on top of all the other tasks he has on his plate. And of course a thank you to all of the Matrix team who have been very supportive during my time here.

Hi folks,

Over the last few weeks there's been a huge movement in the cryptocurrency communities over needing to find a better communication medium than Slack.  Some of the biggest communities for projects like Status, Aragon, TenX, Tezos, OmiseGo, Polkadot and many others are getting overrun by phishing attacks where malicious users have set up bots which auto-DM users joining the room in order to try to extract private keys to steal funds.  Slack has very limited support for avoiding this sort of abuse (especially at the free service tiers), so the search is on for an alternative solution.  There seems to be some confusion over what Matrix & Riot can and can't do to help the situation, so we thought we'd write a blog post about it (especially after we had so much fun at the ETHLDN meetup last week!).

To be clear: we see Ethereum, Bitcoin, Ripple, Stellar and all the other decentralised currencies as being very closely related to Matrix.  Just as distributed ledgers disrupt the fragmented oligopoly old-school banking industry, we want Matrix to disrupt the relatively old-school communications systems of today. And so we'd really rather like that Matrix and Riot rocked when it comes to supporting cryptocurrency communities, and this is something we intend to dedicate resources to long term: we've got some big plans.

🔗Things Matrix provides:

Decentralisation. Rather than each community having its own silo, with users having to juggle accounts over all of them, Matrix decentralises rooms over all the different servers. Users can have a single account and still jump into all the other communities (as well as the rest of the Matrix universe). However, each community can run its own server instance (if they want to) and have complete control over its behaviour.

Encryption. Matrix has first-class end-to-end encryption (although the UX in Riot needs refinement and is technically still beta).  This is great for encrypting rooms which need privacy - although it does come at the expense of being able to do server-side content filtering, which is desirable for fixing phishing attacks. So you probably don't want to turn on encryption for rooms which need phish filtering (or you could use a bot to decrypt and autoremove malicious content).

A standard real-time API. One bit of feedback we've heard recently is that “Riot has no realtime API”.  This is spectacularly untrue; Riot is a client for the Matrix protocol, which is in and of itself an open standard realtime API for messaging, which you can use for writing whatever bots and extensions your heart desires.

Finely grained permissions per room. Likewise there seems to be some confusion over Matrix's access control model.  In Matrix, each user in a room has a ‘power level' - typically a number between 0 and 100.  By convention, normal users who have just joined the room have 0; the room creator and ‘admins' have 100; and ‘moderators' have 50.  Pretty much every access you can do in a room then has a threshold which defines how much power a user needs to perform the action.  It doesn't get much more finely grained than this!

Ability to disable DMs and room invites. Architecturally Matrix lets you prevent users who use a given server from receiving invites (the homeserver can just autoreject the invites, based on some set of rules). We're currently putting together a quick demo to show this off in the Synapse server implementation, but it boils down to having an option to cancel invites here (federated) and here (local). Check out the demo below!

Ability to filter content. Similarly, Matrix architecturally lets a given server filter out messages based on content or some other pattern from being received by its users. We're also putting together a demo of this too in Synapse, which boils down to redacting inappropriate events here (federated) and here (local). The demo isn't quite ready yet but we'll update this & yell when it is. Check out the demo below!

UPDATE

the DM/invite disabling and spam/phish filtering code has now landed on the develop branch of Synapse, and we've deployed an demo example of it at https://phishfree.riot.im.  Messages containing the word 'SPAM' are filtered, and invites are disabled (unless you are the local server admin).

Other stuff. Matrix and Riot give loads of other fun stuff too:

• Widgets - the ability to embed arbitrary apps into your rooms (video conferences; currency tickers; DApps; wallets; monitoring dashboards; etc.).
• 100% Native clients on iOS & Android (including Jitsi video conferencing & Widgets, as of the develop branch!)
• Read receipts! (how can you live without them on Slack?!)
• Internationalised to 20+ languages (thanks to the community! :)
• Bridges through to IRC, Slack, Gitter, and more.
• All sorts of alternative clients (e.g. nheko, quaternion) and SDKs
• Insanely scalable and performant next-generation server ( Dendrite) on the horizon
• An open spec for the protocol.
• 100% Apache-licensed FLOSS.  Riot/Web is particularly easy to hack on and theme & customise as needed.
• Ability to disable federation for a room if you really want to lock it down to the users & rules of a single server.

🔗Things we need to improve:

**Groups (aka Communities):  **One of the biggest missing features in Matrix is the ability to define groups of users & rooms, similar to a Slack team or Discord server, which can be used to organise together a set of discussions and generally give a feeling of community.  We've been working hard at this and expect to see it land in Riot/Web in the next few weeks.  In the meanwhile, you can see some of the UX we're aiming for here!

**E2E UX (and Riot UX in general):  **While the underlying encryption of Matrix is solid, the UX exposed by Riot needs considerable work - specifically to improve the device verification flow and automatically share keys between trusted devices.  We're continuing to work on this over the next few months.  Likewise there are many areas for possible improvement in Riot's overall UX and design that we're working through as urgently as we can.

Active Application Services: The per-server filtering described above is good if you just want to protect users on a given server (e.g. the server you point your community at).  However, if you want to filter all the messages for a given room which may be federated over multiple servers, you need a way to define a centralised chokepoint to define the filtering rules.  Architecturally this is meant to be performed by an ‘Active Application Service' in Matrix, but we've not yet defined or implemented this API.  The idea for the room to define a list of services that messages are filtered through by all servers before they may be accepted for the room.  This would be the ideal solution to the phishing-filtering problem, but in practice filtering just local users (and perhaps disabling federation for particularly sensitive rooms or servers) is probably good enough for the immediate problem here.

Hope this provides some much-needed clarity to the debate! If there are other features cryptocurrency communities need to thrive please let us know, as we'd like to actively help to support decentralized communities.   #matrix-dev:matrix.org is probably the best place for further questions :)

Finally: one thing that has come up a few times in this discussion has been “Matrix's funding crisis means they may not be here to stay”.  All I can say is that Matrix is here to stay. Even if the core team ended up just being Matthew hacking away by himself funded by Patreon/ Liberapay, we have a large and passionate wider dev community who aren't going anywhere.  But more importantly (and not wishing to jinx it), in the last few weeks we have received offers of significant funding which may hopefully resolve the funding crisis for the foreseeable.  Nothing is signed yet, but watch this space, and meanwhile I strongly suggest betting on Matrix being here to stay!

--Matthew

Hi folks,

Something that has kept coming up since we ran into funding problems in July is the idea that Matrix could launch a cryptocurrency - a token for use when exchanging items of value within Matrix. This isn't such a far-fetched idea: folks are already starting to look at how to sell content/services within Matrix, and the idea of using a Matrix-specific currency rather than credit card, PayPal, or an existing cryptocurrency could have some major advantages. Specifically:

• It would let the value of the currency (in terms of its exchange rate relative to other currencies) grow in value directly linked to the growth and success of the Matrix ecosystem as a whole.
• In future it could help us reward folks who run Matrix infrastructure (homeservers, identity servers, etc) by "mining" or "farming" style allocations of currency
• It could also be a very useful tool for helping fight spam in future.  One way of proving that a user should be allowed to contact strangers (other than a vouching system) could be to spend some money.
• An "token generation event" or "initial coin offering" where we sell initial allocations of the currency to the Matrix & cryptocurrency community could be a rather useful way to raise enough money to fully support the core Matrix team going forwards.

Meanwhile, Matrix itself is obviously already a fairly successful decentralised application ecosystem, and we believe that the above points give us a much better reason than average to actually launch a currency.  It's important to note that we don't have plans at this point to evolve the Matrix protocol itself into being able to support cryptocurrencies - we'd instead piggyback on top of an existing established distributed currency ledger.  (Later on, rewarding folks who run Matrix infrastructure by mining would require more interesting integration with Matrix, of course).

However (and this is the important bit), whilst we've been thinking about this a lot over the last few months, we have not yet announced anything concrete.  Over the last few days it's come to our attention that there are some people advertising a "Matrix.org ICO Presale".  This is not legitimate - we are not yet running an ICO or presale, and if/when we do the only place you will hear about it is here on the Matrix.org website.  It looks possible that this is a scam to try to steal Ethereum.  We have not yet authorised anyone to sell hypothetical Matrix currency.  If you see this rumour around please let us know so we can try to understand where it's coming from and set the record straight.

Anyway, we thought it was worth giving an update on our thoughts about cryptocurrencies - and to publicly clarify that anyone claiming that they are running a Matrix.org ICO is lying.

We'd genuinely be very interested to hear feedback from the community on whether an ICO for Matrix would be a good idea or not - #matrix:matrix.org is probably the best place to discuss it.  It's important to understand that our core focus will always be on Matrix itself, where we still have a lot of work to get through - and if we do an ICO it'll be in partnership with specialist cryptocurrency experts, and hopefully minimise the impact to the core Matrix project itself.  But right now, we would be foolish not to be seriously considering the option.

thanks,

Matthew, Amandine & the team.

Hi all,

We're currently looking into different ways that Matrix is being used in the wild, and an important question that has come up is whether anyone is using Matrix yet for decentralised communication in parts of the world where centralised communication poses a problem - due to bad connectivity or privacy concerns.  Similarly we'd love to hear from anyone who is seriously trialling Matrix's end-to-end encryption for use in geographies where privacy is a particularly big issue for human rights.

So, if anyone has stories (anecdotal or otherwise) about how they're using or planning to use Matrix to make the world a better place, in a location where that's particularly critical, please can you let us know as soon as possible (@matthew:matrix.org or @Amandine:matrix.org).  This is fairly urgent because we're currently looking at various options for how to prioritise effort and funding for Matrix, and if there are people out there who are depending on Matrix in this manner it would significantly help us support them!

thanks,

Matthew, Amandine & the team.

As part of our semi-regular series of having Matrix core team members write about how they see the overall project, here's Oddvar Lovaas' view.  Oddvar helps out with project management and promoting Matrix.

According to the homepage, Matrix is "a new open standard for interoperable Instant Messaging and VoIP, providing pragmatic HTTP APIs and open source reference implementations for creating and running your own real-time communication infrastructure. "

That's all good - but you might be asking yourself "sure, but what can it do?" And more importantly, "what can it do for me?"

The original inspiration for Matrix was to fix the problem of fragmented IP communications, by creating a standard for creating and running your own real-time communication infrastructure. This means that if you want your app or program or website to be able to communicate user to user for example, you can use Matrix. Matrix is the protocol through which your communication packets are sent and received, and we provide HTTP APIs to make it easy to make use of this protocol in your code.

The nice thing here is that the user can to talk to any other user anywhere in the Matrix ecosystem, much like email or the web. For example, let's imagine I have an app whose goal is to keep the user updated on anything happening in the football world. Whenever any news drops in, the app is notified and thousands of users check the app for the news. This app could have a communication element where the users can talk in rooms (maybe a #general room and rooms for each football club) - or even between themselves or in groups of friends. Today, a lot of people would use an IM-client to do this, but with Matrix it wouldn't matter if you use a dedicated IM-app or talk inside the football app - since you are using the same Matrix account, you will get the same conversations in both clients!

In fact, imagine that later on you are chatting with some (non-football) friends on your Matrix-supporting chat-application. You can then easily check the previous conversation to see if anyone's appreciated the great joke you made earlier - without having to go back into the football app.

But Matrix's real potential and ultimate mission is to be a generic messaging and data synchronisation system for the web - allowing people, services and devices to easily communicate with each other with full history. It's easier to visualise the chat-application because we are used to chat-messages going back and to, but there's nothing stopping you from putting other data instead of chat-messages. For example, you could use the Matrix protocol to exchange moves - encrypted and secured, of course - in your Chess-game. In fact, your Chess-game could use Matrix both for chatting and exchanging payloads of data.

Imagine if you open up your favourite chat-application, and your contacts there include other users of the same app and also other Matrix-users (so the app has exposed itself to Matrix). Your friend, however, much prefers a different app, but he can still talk to you over the Matrix protocol. And if he ever moves to the other app (or any other Matrix-supporting app) - he would still have all the backlog and history of the conversation!

Obviously the problem here is that we can't instantly make the various chat-applications support Matrix. We believe if we can encourage and grow a truly open communication ecosystem, users will get used to the availability and benefits of interoperable services and they will demand it everywhere.