Matrix & Riot for Cryptocurrency Communities

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


The Librem 5 from Purism: A Matrix Native Smartphone.

Hi folks,

This is a big news week in Matrixland: hot on the heels of releasing Matrix Widgets and Riot 0.12, we have another massive announcement to make!

We’ve been approached by Purism to partner up to provide the communications subsystem for their upcoming Librem 5 smartphone – for which they are launching a crowdfunding campaign starting today! The whole idea of the phone is to provide unprecedented privacy, security and autonomy by running an entirely FOSS Debian-based GNU/Linux stack (even including CPU & GPU drivers!), and we are incredibly proud and overexcited that the folks at Purism have asked the Matrix core team to provide the native dialler and messaging app for the phone.  Yes, this means that the phone will literally boot by default into Matrix for all its primary communications (although, being FOSS, you could of course use a different dialler if you wanted).  The intention is to be a very usable and flexible phone for folks who value freedom, privacy and simplicity over the (relative) quagmire of iOS or Android – and of course jumping way ahead of where Apple or Google are in terms of integrating next-generation communications into the very heart of the device.

This is unbelievably exciting, as Matrix’s vision from the outset has been to provide an open, decentralised and encrypted alternative to the Public Telephone Network – and the idea of devices emerging which are native to Matrix is a dream come true. It also gives us the excuse that we’ve been looking for to produce a truly excellent lightweight native Matrix client, built to run on both handset and desktop devices, complete with end-to-end encryption.  We’re not sure whether this is going to end up being Qt or GTK based yet, but expect to see the Matrix team getting a lot more involved in the current native Matrix client projects (nheko, Quaternion, ruma-gtk, matrix-glib-sdk, qmatrixclient etc) in future!

Depending on the success of the crowdfunding campaign, it may also give us scope to finally build out proper carrier-grade Matrix<->PSTN bridges: letting Matrix clients terminate and originate VoIP calls on the public phone network.  It’s long been an embarrassment that Matrix hasn’t had this given that pre-Matrix we spent our lives building commercial SIP gateways and softphones for telcos, and the ability to use Matrix as a proper VoIP softphone on dedicated hardware is incredibly appealing.  Obviously the phone will also support GSM calling, but the intention is to default to WebRTC calling using Matrix whenever the phone has good IP connectivity – making it truly an IP-first smartphone.

Now, this is obviously a very ambitious project, but we believe that Purism is able to deliver based on the work they’ve done already with crowdfunding and shipping Librem 15 and 13 laptops, shipping with as open a FOSS stack as is possible on contemporary hardware, complete with unique privacy features such as hardware kill-switches for Camera, Wifi, Bluetooth etc.  We met with them at GUADEC 2017 and subsequently heard trusted reports from DebConf 2017 of the quality of the hardware.  It seems that as the company has gathered experience their ambitious goals have become more and more attainable – and it’s also interesting that their dev team is significantly made up of core Debian developers (including Chris Lamb, the Debian Project Leader for 2017).  We’re particularly excited from a philosophical perspective that the Librem 5 is targeting the NXP (Freescale) i.MX6 or i.MX8 ARM-based processor and Vivante GPU – both of which can be run without any proprietary microcode or proprietary drivers.  From everything we’ve heard, this is going to be a spectacularly FOSS-friendly device.

So, if you’re interested in being first to own the world’s first ever Matrix-native phone, or if you want to support the creation of a kick-ass native Matrix desktop/handset client, or perhaps if you want carrier-grade VoIP in Matrix… then please head over to and join the campaign!  Needless to say, if the campaign is successful it will also significantly help Matrix’s current funding situation.

Finally, for more context, here’s a special mid-week episode of Matrix “Live”, featuring Matthew and Todd Weaver, the CEO of Purism, discussing the Librem 5 and what it means for both Purism and Matrix!

As always, feedback on this project is very welcome – come tell us in what you think!  And thank you, if you choose to support this campaign :)

Matthew, Amandine & the team.

Introducing Matrix Widgets – including Jitsi video conferencing!

Hi all,

We’ve been working hard over the last few months on the brand new concept of Matrix “widgets” (sometimes called “apps”, but we’ll call them “widgets” here to be marginally less ambiguous) – and we’re super excited to see an initial implementation of them land today in Riot/Web 0.12 (alongside always-on Rich Text Editor – the culmination of huge amounts of work by Aviral Dasgupta in his GSoC 2016 project and Luke from the core Matrix team).  For user-focused details about Riot 0.12 you should probably head over to the Riot blog; meanwhile we’ll focus here on widgets from the developer perspective.

Widgets are a deceptively simple idea: the ability to pin small form-factor webapps (called widgets) into a given Matrix room, letting admins build up a dashboard of functionality which is then in common and automatically available to everyone who views that room.  You can think of it as being similar to installing an app onto a smartphone, but instead pulling it into a Matrix conversation.  This could be a Jitsi video conference, or a collaborative document editor, or a Grafana dashboard, or anything you can imagine really (assuming its security headers support embedding).  Here’s an example of a room with an ongoing Jitsi conference coupled with a Grafana graph, as you might use for a devops war room:

The URLs of the widgets are stored in the state of the room with some high-level layout hints, and the idea is that any Matrix client will be able to expose the widgets for the current room to a user.  For a simple command-line client this could just be listing the URLs of the widgets so the user can open them in a browser; for a web client like Riot/Web they’re embedded via iframes; for a native client like Riot/iOS they could be shown via a WebView – or there’s always the chance of the native client recognising the URL being requested and swapping it out for an optimised local native implementation instead.  For now, widgets don’t really have a way of communicating with the host Matrix client (other than by speaking Matrix to the homeserver!), although we’re looking at adding a PostMessage API to improve this.

Now, in an ideal world we would have enough bandwidth to have formally added widgets to the Matrix spec, but unfortunately we are way behind on spec work currently, thanks in part to our current funding problems. (Remember, if you like Matrix, please donate or get your company to donate otherwise we are at real risk of hitting a very big funding wall).  Rather than formal spec, we’ve focused on rushing an initial implementation out the door in matrix-react-sdk (and thus riot-web) to see how they work first in reality.  Riot/iOS and Riot/Android are coming soon – although we’ve special-cased the Jitsi video conferencing widget in iOS to be implemented natively, which is actually available already on develop(!)

Right now the widgets supported by Riot are prefixed behind the im.vector.modular.widgets state event, whose format is something like:

	type: "im.vector.modular.widgets",
	state_key: "widget1",
	content: {
		type: "grafana",
		url: "",
		name: " bridges dashboard"
	room_id: "!",
	sender: ""

Currently the only layout hint is that the order of the event determines the order in which the widget should be displayed on the page.  Riot/Web’s initial implementation is very naive and shows only up to two widgets per page, although we’re hoping to make this much more generic and flexible in future.  To add widgets in Riot/Web you can now hit the new widget manager button in the top right – and to show/hide existing ones in the room you can hit the show/hide app drawer button in the bottom right.

The UI for adding widgets to a room in Riot is currently via Modular – the new name for Riot’s SaaS integration hosting platform, formally codenamed Scalar.  This is a separate webapp loaded in an iframe which guides you through choosing widgets to embed which are hosted by Modular, although in the near future we’ll also add UI to let you specify widget URLs directly.  If you need this today, you’ll need to manually inject a state event like the one above into the room to provision the widget.

This is very much the minimum viable implementation of widgets: the stuff left to do includes:

  • Adding them to the spec, and getting clients other than Riot using them!
  • Supporting better layouts (especially to allow for more screen real-estate) and more than 2 widgets
  • Ability to add widgets directly, for situations where Modular isn’t available
  • Speccing APIs for widgets to interact directly with the host client – with the appropriate permissions model
  • Adding lots more prepackaged widgets to the Modular store!

Modular comes with 6 widgets ready to go: Grafana, Jitsi, Etherpad, YouTube, Google Docs and Custom Widget (which lets you add any arbitrary URL into the room). The most exciting of these is probably Jitsi, which provides Hangouts-style video conferencing into any room.  This provides a welcome alternative to our ‘native’ conferencing functionality which sadly got stuck in a permanent early beta – and includes full screensharing as well!  The only catch is that it hasn’t been released on iOS yet, and Android is still be to be implemented – but the experience is a still massive improvement over what we’ve had historically.  Here’s a screenshot of some of the core team doing a 6-way conference with the native Jitsi functionality now included in Riot/iOS!

Finally, if you want to write your own widget, just create a webapp and play with it via the Custom Widget interface.  If it’s something useful for other people then please ping us on and we’ll see about getting it added as a preset application in Modular.

We think widgets are an awesome example of how Matrix can be used to coordinate collaboration between users in a room – for now it’s just simply ensuring that users are looking at the same set of webapps when in a room, but in future you can see how it could extend to co-browsing, co-editing, payment functionality, or generally using Matrix to coordinate things other than textual/voip chat.  The sky’s the limit, and we’re hoping the Modular store (and other app stores) will start overflowing with apps in the near future!

As always, feedback is very welcome on new experimental stuff like this – so please come tell us what you think in!  And finally: huge kudos to Rick, Kegan, Rob, and everyone else who have been working away bringing Widgets to life.  It’s the beginning of a new era :D


Thoughts on cryptocurrencies

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 “ 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 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 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 – 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. status update – July 2017

Hi folks,

Thought it was worth giving a quick status update on what’s going on since our last blog post, which explained the funding situation Matrix has found itself in.  The TL;DR is that we’re still here; things are moving faster than ever (not least as we refocus on getting everything needed to get Matrix funded and sustainable in the longer term), but we still need concrete support from the community (both company sponsorship and personal donations) to ensure things keep going at the current rate.


Funding Status

So, the good news is that we had a great initial response to last week’s call to help – right now we have 199 people signed up on Patreon (go on, be the 200th! you know you want to :D), ~30 on Liberapay, and 14 bitcoin donations.  This sums up to just over $2000/month – which is getting close to our initial Patreon goal of $2500/month to helping support half the cost of the less senior devs working on Matrix. Endless thanks to everyone who has donated – especially the 19 folks (18 on Patreon, one on Liberapay) who have so generously pledged $50 or more a month!! Meanwhile, if you’re reading this and you haven’t pledged support yet – *please* consider heading over to Patreon or Liberapay or Bitcoin 1LxowEgsquZ3UPZ68wHf8v2MDZw82dVmAE and helping keep the project running.  Literally every dollar counts.

Meanwhile, while Patreon & friends are headed in the right direction to support one developer, we still have another 10 people working on all the various core components of Matrix itself who need to be supported in the near future.  (We look to be safe for the next month or two, but beyond that we’re counting on having solved this problem ;).  Right now we are hoping that companies who believe in Matrix and/or are building services on top will step up to sponsor development – as it’s pretty obvious that accelerating Dendrite, final E2E, Groups etc will improve professional Matrix-based services immeasurably.  If this sounds like you, please get in touch asap.

We’re also able to provide paid consulting and development (and prioritised development) services on Matrix (through Vector, the for-profit company responsible for Riot) for large pieces of work – for instance, if you’re anxious to see enterprise-focused Matrix features land sooner than later, please reach out.

Exciting news is that we already have one concrete offer of paid consulting work from a very major company who happens to love Matrix, building out Integrations capabilities which should directly benefit the wider Matrix ecosystem – and we also are very proud to announce our very first official corporate sponsor (see the next section for details)!  However, we still have a long way to go, so don’t be shy about getting in touch: we need your support!

Heads up that we’ve also started our various reward schemes for supporters – folks donating more than $5 on Patreon will have already heard most of this update in the first episode of the video blog that Amandine & I posted last Friday; and folks donating more than $10 will have heard some of the other details first hand through the broadcast of the global team weekly sync on Monday!  We’re still figuring out how to get these rewards over to liberapay & bitcoin supporters (not helped by both services being anonymous…).  We haven’t yet opened up the room as maintaining the accesslist is effectively blocked on Groups landing.  We also want to use Groups to manage the various lists of supporters around the place, so apologies that we haven’t got the lists published yet!

Finally on the funding side of things: we’re setting up the Foundation non-profit legal entity this week, letting us accept donations and sponsorship in a way which can directly fund the core developers (more details as we have them).  As soon as it’s incorporated, we’ll be able to sign up fully on Liberapay to accept donations there.


Announcing UpCloud: our very first official Corporate Sponsor!

As hinted above, we’re incredibly excited and happy that UpCloud have signed up as our first official corporate sponsor.  UpCloud has already been hosting all of’s infrastructure for the last 6 months (no mean feat, given the scale of the synapse & postgres!) – and last week they committed to extend their sponsorship further to help the project out in our time of need.

We’ve been very impressed with UpCloud’s service since migrating over back in February – particularly their spectacularly fast block IO (~350MB/s write, 92,000 IOPS, and over 5GB/s read!!) which is incredibly useful for running a huge synapse deployment like’s – and they have a great footprint of datacentres around the world.

They also like Matrix so much that they’ve written this great tutorial for getting Synapse up and running on their hosts – and best of all, they have a special $25 discount for anyone in the Matrix community who wishes to use them: check out for the details!

We’d like to thank them profusely for being first in line to support us – and we look forward to seeing how far we can push their hardware over the coming months! :D


Development Status

Finally, loads and loads of stuff is happening on Matrix itself.  The main headlines are:

  • Groups.  Work in Synapse and matrix-react-sdk is happening at breakneck speed to get Groups out the door as soon as possible, so we can use them both to support the funding drive and in general to implement one of the most asked-for features of Matrix: the ability to group rooms together into a well-defined community (similar to Slack Teams or Discord Servers etc).  The way Groups work is to let users define groupings of both users and rooms; you can also define a metadata for the group to let you build homepages similar to the one which Riot/Web sprouted a few months ago.  You can then refer to the group of users when inviting/banning/kicking etc – or when managing your own roomlist.  We think it’s going to completely change how people use Matrix, and can’t wait to see it land on, although it’s still a few weeks away.
  • E2E Crypto.  We have three main things remaining here, after which E2E should be much much more usable for day-to-day purposes:
    1. Fixing the matrix-js-sdk to store crypto state in indexeddb rather than localstorage, to prevent multiple browser tabs racing and corrupting localstorage (which provides no locking mechanism).  This turns out to be much more of an epic than we thought, as indexeddb’s APIs are all strictly async, resulting in a whole bunch of previously synchronous APIs in matrix-js-sdk needing to become async too, as well as requiring us to switch promises library at least from Q to Bluebird.  However, most of this is now done so hopefully the new storage layer will land shortly. is the bug tracking this one…
    2. Fixing the overall UX of managing devices in a room (including key shares). is the bug for this one :)  Relatedly we also need to ensure invitees can decrypt messages in e2e rooms before they join (if history visibility allows it) – this is
    3. Fixing the UX of verifying devices (including cross-signing devices), to minimise the pain in verifying device ownership. is the master bug for this.
  • Integrations.  A large slice of the team is working on our next-generation integration hosting platform, which is starting to look unspeakably awesome.  We’ll be yelling loudly about this once there’s something to see and play with…

  • Rich Text Editor.  This was originally a GSoC project from last year, but is finally on by default now in matrix-react-sdk – letting users author their messages with full WYSIWYG behaviour and critically have a radically improved autocompletion UI/UX, including emoji, user names, room names, etc.  You can check it out at already :)
  • Mentions.  We’re finally semantically tagging references to users in messages so that they can be displayed nicely in the UI, and help with highlighting notifications!  This is due as soon as the Rich Text Editor work has finished.
  • Mobile SDKs.  The iOS & Android teams are currently on a mission to get parity between the iOS & Android SDKs and matrix-react-sdk.  This is stuff like implementing the new User Search API; Membership Event List Summaries; Dark theme(!); Translations; etc.  Progress is looking good!
  • Synapse performance.  Many many optimisations when calculating push rules when sending messages, which was taking up a substantial amount of the send path time.  Synapse develop looks to have reduced this significantly now – and as of Monday we’re running the new optimisations on
  • Dendrite.  Lots of work going into implementing Invitations currently, including improvements to the overall append-only log architecture to support them nicely.
  • Riot-Static.  This is one of our GSoC projects this year, written by Michael Telatynski (t3chguy) – providing a full static (no-JS) read-only view of Matrix, suitable for dumb web browsers and search engines.  It’s looking really exciting (although needs CSS) – there’s a copy currently deployed over at

Meanwhile, there’s a tonne of stuff happening in the community – an excellent summary may be found at this Community Round Up blog post by uhoreg!

So: this is where things stand right now – the team is sprinting away getting all the stuff above landed, and meanwhile I’m spending most of my life worrying about funding.  We’ll try to keep blogging more regularly to give better visibility on progress on both the funding & development situation, as well as to ensure there’s a written public record as well as the regular supporter-only updates.  However, for the latest realtime updates and sneak previews and tidbits you’ll probably want to sign up on Patreon or Liberapay :D


[EDIT: I got the UpCloud stats completely wrong – they are even faster (by 10x!) than I quoted; the figures are now updated :)]