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!
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.
Matthew, Amandine & the team.
Synapse 0.22.0 has just been released! This release lands a few interesting features:
- The new User directory API which supports Matrix clients’ providing a much more intuitive and effective user search capability by exposing a list of:
- Everybody your user shares a room with, and
- Everybody in a public room your homeserver knows about
- New support for server admins, including a Shutdown Room API (to remove a room from a local server) and a Media Quarrantine API (to render a media item inaccessible without its actually being deleted)
As always there are lots of bug fixes and performance improvements, including increasing the default cache factor size from 0.1 to 0.5 (should improve performance for those running their own homeservers).
You can get Synapse 0.22.0 from https://github.com/matrix-org/synapse or https://github.com/matrix-org/synapse/releases/tag/v0.22.0 as normal.
Changes in synapse v0.22.0 (2017-07-06)
No changes since v0.22.0-rc2
Changes in synapse v0.22.0-rc2 (2017-07-04)
- Improve performance of storing user IPs (PR #2307, #2308)
- Slightly improve performance of verifying access tokens (PR #2320)
- Slightly improve performance of event persistence (PR #2321)
- Increase default cache factor size from 0.1 to 0.5 (PR #2330)
- Fix bug with storing registration sessions that caused frequent CPU churn
Changes in synapse v0.22.0-rc1 (2017-06-26)
- Add a user directory API (PR #2252, and many more)
- Add shutdown room API to remove room from local server (PR #2291)
- Add API to quarantine media (PR #2292)
- Add new config option to not send event contents to push servers (PR #2301)
Thanks to @cjdelisle!
- Fix users not getting notifications when AS listened to that user_id (PR
#2216) Thanks to @slipeer!
- Fix users without push set up not getting notifications after joining rooms
- Fix preview url API to trim long descriptions (PR #2243)
- Fix bug where we used cached but unpersisted state group as prev group,
resulting in broken state of restart (PR #2263)
- Fix removing of pushers when using workers (PR #2267)
- Fix CORS headers to allow Authorization header (PR #2285) Thanks to @krombel!
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!
Matthew, Amandine & the team.
Synapse 0.21.0 was released a moment ago. This release lands a number of performance improvements and stability fixes, plus a couple of small features.
For those of you upgrading https://github.com/matrix-org/synapse has the details as usual. Full changelog follows:
Changes in synapse v0.21.0 (2017-05-17)
- Add per user rate-limiting overrides (PR #2208)
- Add config option to limit maximum number of events requested by
/messages (PR #2221) Thanks to @psaavedra!
- Various small performance fixes (PR #2201, #2202, #2224, #2226, #2227, #2228, #2229)
- Update username availability checker API (PR #2209, #2213)
- When purging, don’t de-delta state groups we’re about to delete (PR #2214)
- Documentation to check synapse version (PR #2215) Thanks to @hamber-dick!
- Add an index to event_search to speed up purge history API (PR #2218)
- Fix API to allow clients to upload one-time-keys with new sigs (PR #2206)
Changes in synapse v0.21.0-rc2 (2017-05-08)
- Always mark remotes as up if we receive a signed request from them (PR #2190)
- Fix bug where users got pushed for rooms they had muted (PR #2200)
Changes in synapse v0.21.0-rc1 (2017-05-08)
- Add username availability checker API (PR #2183)
- Add read marker API (PR #2120)
- Enable guest access for the 3pl/3pid APIs (PR #1986)
- Add setting to support TURN for guests (PR #2011)
- Various performance improvements (PR #2075, #2076, #2080, #2083, #2108, #2158, #2176, #2185)
- Make synctl a bit more user friendly (PR #2078, #2127) Thanks @APwhitehat!
- Replace HTTP replication with TCP replication (PR #2082, #2097, #2098, #2099, #2103, #2014, #2016, #2115, #2116, #2117)
- Support authenticated SMTP (PR #2102) Thanks @DanielDent!
- Add a counter metric for successfully-sent transactions (PR #2121)
- Propagate errors sensibly from proxied IS requests (PR #2147)
- Add more granular event send metrics (PR #2178)
- Fix nuke-room script to work with current schema (PR #1927) Thanks @zuckschwerdt!
- Fix db port script to not assume postgres tables are in the public schema (PR #2024) Thanks @jerrykan!
- Fix getting latest device IP for user with no devices (PR #2118)
- Fix rejection of invites to unreachable servers (PR #2145)
- Fix code for reporting old verify keys in synapse (PR #2156)
- Fix invite state to always include all events (PR #2163)
- Fix bug where synapse would always fetch state for any missing event (PR #2170)
- Fix a leak with timed out HTTP connections (PR #2180)
- Fix bug where we didn’t time out HTTP requests to ASes (PR #2192)
- Clarify doc for SQLite to PostgreSQL port (PR #1961) Thanks @benhylau!
- Fix typo in synctl help (PR #2107) Thanks @HarHarLinks!
web_client_location documentation fix (PR #2131) Thanks @matthewjwolff!
- Update README.rst with FreeBSD changes (PR #2132) Thanks @feld!
- Clarify setting up metrics (PR #2149) Thanks @encks!
Synapse 0.20.0 was released a few hours ago – this is a major new release with loads of stability and performance fixes and some new features too. The main headlines are:
- Support for using phone numbers as 3rd party identifiers as well as email addresses! This is huge: letting you discover other users on Matrix based on whether they’ve linked their phone number to their matrix account, and letting you log in using your phone number as your identifier if you so desire. Users of systems like WhatsApp should find this both familiar and useful ;)
- Fixes some very nasty failure modes where the state of a room could be reset if a homeserver received an event it couldn’t verify. Folks who have suffered rooms suddenly losing their name/icon/topic should particularly upgrade – this won’t fix the rooms retrospectively (your server will need to rejoin the room), but it should fix the problem going forwards.
- Improves the retry schedule over federation significantly – previously there were scenarios where synapse could try to retry aggressively on servers which were offline. This fixes that.
- Significant performance improvements to /publicRooms, /sync, and other endpoints.
- Lots of juicy bug fixes.
We highly recommend upgrading (or installing!) asap – https://github.com/matrix-org/synapse has the details as usual. Full changelog follows:
Changes in synapse v0.20.0 (2017-04-11)
- Fix joining rooms over federation where not all servers in the room saw the
new server had joined (PR #2094)
Changes in synapse v0.20.0-rc1 (2017-03-30)
- Add delete_devices API (PR #1993)
- Add phone number registration/login support (PR #1994, #2055)
- Use JSONSchema for validation of filters. Thanks @pik! (PR #1783)
- Reread log config on SIGHUP (PR #1982)
- Speed up public room list (PR #1989)
- Add helpful texts to logger config options (PR #1990)
/sync performance improvements. (PR #2002, #2013, #2022)
- Add some debug to help diagnose weird federation issue (PR #2035)
- Correctly limit retries for all federation requests (PR #2050, #2061)
- Don’t lock table when persisting new one time keys (PR #2053)
- Reduce some CPU work on DB threads (PR #2054)
- Cache hosts in room (PR #2060)
- Batch sending of device list pokes (PR #2063)
- Speed up persist event path in certain edge cases (PR #2070)
- Fix bug where current_state_events renamed to current_state_ids (PR #1849)
- Fix routing loop when fetching remote media (PR #1992)
- Fix current_state_events table to not lie (PR #1996)
- Fix CAS login to handle PartialDownloadError (PR #1997)
- Fix assertion to stop transaction queue getting wedged (PR #2010)
- Fix presence to fallback to last_active_ts if it beats the last sync time.
Thanks @Half-Shot! (PR #2014)
- Fix bug when federation received a PDU while a room join is in progress (PR
- Fix resetting state on rejected events (PR #2025)
- Fix installation issues in readme. Thanks @ricco386 (PR #2037)
- Fix caching of remote servers’ signature keys (PR #2042)
- Fix some leaking log context (PR #2048, #2049, #2057, #2058)
- Fix rejection of invites not reaching sync (PR #2056)