Meanwhile in the last 2 years the Foundation has evolved a lot, in particular with the election of its Governing Board (https://matrix.org/foundation/governing-board/) representing all stakeholders of its ecosystem, and which has an advisory role to ensure the independence of the Foundation. The Governing Board has also set-up several Committees which are hosts to Working Groups which help run the various activities of the Foundation (https://matrix.org/foundation/working-groups/). You will note in particular the existence of the Governance Committee (https://matrix.org/foundation/governing-board/committees/#go...) and its corresponding Working Group which “exists to determine how The Matrix Foundation should be structured. It determines why the Foundation is structured the way it is, or look for alternatives when the Foundation has visible flaws.”.
In terms of the Foundation developing its own software: it has been a deliberate choice to not have any development (beyond moderation tools) within the Foundation. The reasons for it include the fact that the Foundation is already running at loss and can’t afford to pay a team of developers big enough to develop and maintain all the bricks of a Matrix stack. If the Foundation decided to develop everything itself it would need to set up revenue lines which would probably compete with the various vendors in the Matrix ecosystem, so the Foundation would rather support an active ecosystem than cannibalise it. That said, it may change in the future if that is the best choice for the project; or a Matrix vendor may choose to donate the code of their stack, like Element was donating Synapse until freeriders destroyed its business and forced them to fire half their employees to stay alive.
In terms of Synapse’s efficiency, it has improved lately despite losing some of the team, and thanks to having stopped dispersing the resources across two server implementations in parallel, and focused on one. As you say Continuwuity is an alternative implementation to look at if you are unhappy with Synapse.
You can disable e2e on your server if you wish so. The option already exists in Synapse and it is part of Element Matrix Services customers.
For those who are legally required to be on record, there are other ways to keep track of the conversations for audit purposes without compromising the e2e encryption. For example, every room could have an audit bot invited by default, visible by the users, and which would record everything being said. Then you can setup the access to the logs from the audit bot to only be unencrypted in certain conditions, e.g. if the 2 halves of a key giving access to the account are put together. It's secure, clear for the users and legally compliant.
Yup planning to get it on in the coming months. As a data point e2e by default is on for the French government deployment and we haven't seen huge drama, so we're mostly waiting to get the UX out. We'll be sharing our work for insights this week.
We're still aiming for a full redesign of Riot.im to be out before end of the year, there should be things to look at at the end of the month, all crafted for the non-techy friends, so watch de the space!
And yes, the backend is not helping neither, although we've also done good progress on perf improvement there in the last months and still rolling new ones (e.g. Py3 being deployed as we speak and reducing server RAM by 3). Switching away from matrix.org can help, and agreed that a directory of public servers à la Mastodon could be interesting (although we would need to find a non-scary way to do so, lots of non-tech people would run away from it: they just want one click onboarding without having to understand what's happening behind the scenes).
We've also soft launched a paid hosted offering, for 50-100 people teams who could do with their own DNS and faster servers at http://modular.im
The spec only states the use of JSON over HTTP as a baseline so anyone is welcome to implement more efficient transports like CBOR/COAP or MQTT or whatever :)
But yes the goal of the reference implementations was to showcase the simplest transport: one PUT to send and one GET to retrieve it.
Meanwhile we’re working on improving the performance of the servers with some rather nice breakthroughs on the horizon.
Within Riot, polishing e2e is already top of our priority list, but yes it definitely doesn’t harm having high profile entities like this expecting it.
Because Signal is centralized. With Matrix they can deploy different servers across the gouvernement which interoperate. And potentially open it to the wider Matrix ecosystem
Indeed, trying to find the balance between "accessible for your average WhatsApp user" and "powerful for more advanced users" is still something we're working on. Nothing deliberate here.
There is no acquisition here, nor any expectation to use Status token. The only idea is for both projects to help each other, and if Status can help financially Matrix might help otherwise (e.g. provide a bridge to Whisper, Ethereum’s own real-time communication protocol and as such exposing all of the Matrix ecosystem into Ethereum and vice versa; continue working on Olm/Megolm such that it could be used for E2E encryption in Status etc).
As Jarrad says in their blog, we are all trying to provide a decentralised Web and no one knows today how it will look like in the future. By supporting other opensource projects Status is only trying to move the needle and promote open solutions rather than proprietary ones.
We at Matrix are very glad that some projects use their ICO money for the greater good, and in this case it will allow us to spend all our time and focus on polishing Riot, getting Matrix out of beta, finalising end-to-end crypto, rather than open yet another battle front by doing an ICO, or getting distracted by raising more funds or doing too much consulting work.
Matrix might get to an ICO some day, and/or New Vector might get enough revenues to be sustainable and able to support both Riot and core devs for Matrix. But these are later steps.
Going out of beta we had to decide on something which was really carrying what the app is, we loved Vector but it has always been a code-name and a nice pun on Matrix :)
Riot is more representative of what the app can do and its ambitions! Break the barriers between apps, give the control back to the user to choose their client, if they want to encrypt, host themselves, tune the notifs, the fact it's open, built on the open ecosystem of Matrix and thus benefiting of all the integrations and bridges built for Matrix.... Sounds pretty revolutionary to me ;)
Worth noting that only the name changed: the app and the team and the openness are still the same (modulo new features)!
Precisely: just setup the server and off you go, you don't have to federate, although as you say that would be missing part of the fun ;)
The Vector app on Android (using GCM) has pretty good perf battery consumption-wise. Unsure how it compares with other apps but we haven't had any particular complaints about it.
Meanwhile in the last 2 years the Foundation has evolved a lot, in particular with the election of its Governing Board (https://matrix.org/foundation/governing-board/) representing all stakeholders of its ecosystem, and which has an advisory role to ensure the independence of the Foundation. The Governing Board has also set-up several Committees which are hosts to Working Groups which help run the various activities of the Foundation (https://matrix.org/foundation/working-groups/). You will note in particular the existence of the Governance Committee (https://matrix.org/foundation/governing-board/committees/#go...) and its corresponding Working Group which “exists to determine how The Matrix Foundation should be structured. It determines why the Foundation is structured the way it is, or look for alternatives when the Foundation has visible flaws.”.
In terms of the Foundation developing its own software: it has been a deliberate choice to not have any development (beyond moderation tools) within the Foundation. The reasons for it include the fact that the Foundation is already running at loss and can’t afford to pay a team of developers big enough to develop and maintain all the bricks of a Matrix stack. If the Foundation decided to develop everything itself it would need to set up revenue lines which would probably compete with the various vendors in the Matrix ecosystem, so the Foundation would rather support an active ecosystem than cannibalise it. That said, it may change in the future if that is the best choice for the project; or a Matrix vendor may choose to donate the code of their stack, like Element was donating Synapse until freeriders destroyed its business and forced them to fire half their employees to stay alive.
In terms of Synapse’s efficiency, it has improved lately despite losing some of the team, and thanks to having stopped dispersing the resources across two server implementations in parallel, and focused on one. As you say Continuwuity is an alternative implementation to look at if you are unhappy with Synapse.