-
Notifications
You must be signed in to change notification settings - Fork 382
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MSC3026: "busy" presence state #3026
base: old_master
Are you sure you want to change the base?
Conversation
d23c63f
to
8fcecdc
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Presence right now is fairly basic, and it's also unclear how it might interact with user profiles, ie. if some of it might move there (the status_msg in particular?) but it certainly seems like the semantics of 'busy' being something that will be auto-set by clients lend it to being in the presence enum. However presence ends up evolving, I think it having a busy state included allows for clients to set it automatically and server to derive a sensible value from the various automatic updates from clients.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the proposal as-is (on commit 69c273c) will break the presence system as it works today, I think we need a more expansive presence MSC that can incorporate "extra" presence (such as busy
proposed here), instead of the "cumulative" presence we have today (that this proposal will not fit into, for multiple reasons).
Edit: This review is now outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As per discussion in #matrix-spec
, I've realised that this spec does indeed try to do (what i called) "cumulative" presence, with 2 important points i think should be clarified in this document;
-
the
busy
presence is more exclusively seen as a "active temporary" state, i.e. it is not seen as analogous to the generic "do not disturb" status we see in many apps today, but it is meant as a marker to presence-receiving users that the user is currently busy in specifically-engaging activities such as calls. Important note then; this presence should immidiately be dropped when the user is seen as not actively engaging (not in a call) or not present (thenunavailable
/"idle" should be broadcasted. -
With the previous, the
busy
state is seen as "above" anyonline
state, making it so that only one client has to broadcast it to have it be the defacto "user presence" then, this is similar toonline
withunavailable
, andunavailable
withoffline
.
I think clarifying these two things explicitly in this document (if they arent already) would make this MSC non-conflicting with how matrix works today, assuming that clients honor point 1.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideally we'd rework the entire presence system so that things like unavailable
make sense, but this is probably the best we can do for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally looks fine, just a couple of points really.
…matrix-doc into babolivier/msc_presence_busy
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This lgtm on the whole!
Synapse 1.32.2 (2021-04-22) =========================== This release includes a fix for a regression introduced in 1.32.0. Bugfixes -------- - Fix a regression in Synapse 1.32.0 and 1.32.1 which caused `LoggingContext` errors in plugins. ([\#9857](matrix-org/synapse#9857)) Synapse 1.32.1 (2021-04-21) =========================== This release fixes [a regression](matrix-org/synapse#9853) in Synapse 1.32.0 that caused connected Prometheus instances to become unstable. However, as this release is still subject to the `LoggingContext` change in 1.32.0, it is recommended to remain on or downgrade to 1.31.0. Bugfixes -------- - Fix a regression in Synapse 1.32.0 which caused Synapse to report large numbers of Prometheus time series, potentially overwhelming Prometheus instances. ([\#9854](matrix-org/synapse#9854)) Synapse 1.32.0 (2021-04-20) =========================== **Note:** This release introduces [a regression](matrix-org/synapse#9853) that can overwhelm connected Prometheus instances. This issue was not present in 1.32.0rc1. If affected, it is recommended to downgrade to 1.31.0 in the meantime, and follow [these instructions](matrix-org/synapse#9854 (comment)) to clean up any excess writeahead logs. **Note:** This release also mistakenly included a change that may affected Synapse modules that import `synapse.logging.context.LoggingContext`, such as [synapse-s3-storage-provider](https://github.com/matrix-org/synapse-s3-storage-provider). This will be fixed in a later Synapse version. **Note:** This release requires Python 3.6+ and Postgres 9.6+ or SQLite 3.22+. This release removes the deprecated `GET /_synapse/admin/v1/users/<user_id>` admin API. Please use the [v2 API](https://github.com/matrix-org/synapse/blob/develop/docs/admin_api/user_admin_api.rst#query-user-account) instead, which has improved capabilities. This release requires Application Services to use type `m.login.application_service` when registering users via the `/_matrix/client/r0/register` endpoint to comply with the spec. Please ensure your Application Services are up to date. If you are using the `packages.matrix.org` Debian repository for Synapse packages, note that we have recently updated the expiry date on the gpg signing key. If you see an error similar to `The following signatures were invalid: EXPKEYSIG F473DD4473365DE1`, you will need to get a fresh copy of the keys. You can do so with: ```sh sudo wget -O /usr/share/keyrings/matrix-org-archive-keyring.gpg https://packages.matrix.org/debian/matrix-org-archive-keyring.gpg ``` Bugfixes -------- - Fix the log lines of nested logging contexts. Broke in 1.32.0rc1. ([\#9829](matrix-org/synapse#9829)) Synapse 1.32.0rc1 (2021-04-13) ============================== Features -------- - Add a Synapse module for routing presence updates between users. ([\#9491](matrix-org/synapse#9491)) - Add an admin API to manage ratelimit for a specific user. ([\#9648](matrix-org/synapse#9648)) - Include request information in structured logging output. ([\#9654](matrix-org/synapse#9654)) - Add `order_by` to the admin API `GET /_synapse/admin/v2/users`. Contributed by @dklimpel. ([\#9691](matrix-org/synapse#9691)) - Replace the `room_invite_state_types` configuration setting with `room_prejoin_state`. ([\#9700](matrix-org/synapse#9700)) - Add experimental support for [MSC3083](matrix-org/matrix-spec-proposals#3083): restricting room access via group membership. ([\#9717](matrix-org/synapse#9717), [\#9735](matrix-org/synapse#9735)) - Update experimental support for Spaces: include `m.room.create` in the room state sent with room-invites. ([\#9710](matrix-org/synapse#9710)) - Synapse now requires Python 3.6 or later. It also requires Postgres 9.6 or later or SQLite 3.22 or later. ([\#9766](matrix-org/synapse#9766)) Bugfixes -------- - Prevent `synapse_forward_extremities` and `synapse_excess_extremity_events` Prometheus metrics from initially reporting zero-values after startup. ([\#8926](matrix-org/synapse#8926)) - Fix recently added ratelimits to correctly honour the application service `rate_limited` flag. ([\#9711](matrix-org/synapse#9711)) - Fix longstanding bug which caused `duplicate key value violates unique constraint "remote_media_cache_thumbnails_media_origin_media_id_thumbna_key"` errors. ([\#9725](matrix-org/synapse#9725)) - Fix bug where sharded federation senders could get stuck repeatedly querying the DB in a loop, using lots of CPU. ([\#9770](matrix-org/synapse#9770)) - Fix duplicate logging of exceptions thrown during federation transaction processing. ([\#9780](matrix-org/synapse#9780)) Updates to the Docker image --------------------------- - Move opencontainers labels to the final Docker image such that users can inspect them. ([\#9765](matrix-org/synapse#9765)) Improved Documentation ---------------------- - Make the `allowed_local_3pids` regex example in the sample config stricter. ([\#9719](matrix-org/synapse#9719)) Deprecations and Removals ------------------------- - Remove old admin API `GET /_synapse/admin/v1/users/<user_id>`. ([\#9401](matrix-org/synapse#9401)) - Make `/_matrix/client/r0/register` expect a type of `m.login.application_service` when an Application Service registers a user, to align with [the relevant spec](https://spec.matrix.org/unstable/application-service-api/#server-admin-style-permissions). ([\#9548](matrix-org/synapse#9548)) Internal Changes ---------------- - Replace deprecated `imp` module with successor `importlib`. Contributed by Cristina Muñoz. ([\#9718](matrix-org/synapse#9718)) - Experiment with GitHub Actions for CI. ([\#9661](matrix-org/synapse#9661)) - Introduce flake8-bugbear to the test suite and fix some of its lint violations. ([\#9682](matrix-org/synapse#9682)) - Update `scripts-dev/complement.sh` to use a local checkout of Complement, allow running a subset of tests and have it use Synapse's Complement test blacklist. ([\#9685](matrix-org/synapse#9685)) - Improve Jaeger tracing for `to_device` messages. ([\#9686](matrix-org/synapse#9686)) - Add release helper script for automating part of the Synapse release process. ([\#9713](matrix-org/synapse#9713)) - Add type hints to expiring cache. ([\#9730](matrix-org/synapse#9730)) - Convert various testcases to `HomeserverTestCase`. ([\#9736](matrix-org/synapse#9736)) - Start linting mypy with `no_implicit_optional`. ([\#9742](matrix-org/synapse#9742)) - Add missing type hints to federation handler and server. ([\#9743](matrix-org/synapse#9743)) - Check that a `ConfigError` is raised, rather than simply `Exception`, when appropriate in homeserver config file generation tests. ([\#9753](matrix-org/synapse#9753)) - Fix incompatibility with `tox` 2.5. ([\#9769](matrix-org/synapse#9769)) - Enable Complement tests for [MSC2946](matrix-org/matrix-spec-proposals#2946): Spaces Summary API. ([\#9771](matrix-org/synapse#9771)) - Use mock from the standard library instead of a separate package. ([\#9772](matrix-org/synapse#9772)) - Update Black configuration to target Python 3.6. ([\#9781](matrix-org/synapse#9781)) - Add option to skip unit tests when building Debian packages. ([\#9793](matrix-org/synapse#9793)) Synapse 1.31.0 (2021-04-06) =========================== **Note:** As announced in v1.25.0, and in line with the deprecation policy for platform dependencies, this is the last release to support Python 3.5 and PostgreSQL 9.5. Future versions of Synapse will require Python 3.6+ and PostgreSQL 9.6+, as per our [deprecation policy](docs/deprecation_policy.md). This is also the last release that the Synapse team will be publishing packages for Debian Stretch and Ubuntu Xenial. Improved Documentation ---------------------- - Add a document describing the deprecation policy for platform dependencies. ([\#9723](matrix-org/synapse#9723)) Internal Changes ---------------- - Revert using `dmypy run` in lint script. ([\#9720](matrix-org/synapse#9720)) - Pin flake8-bugbear's version. ([\#9734](matrix-org/synapse#9734)) Synapse 1.31.0rc1 (2021-03-30) ============================== Features -------- - Add support to OpenID Connect login for requiring attributes on the `userinfo` response. Contributed by Hubbe King. ([\#9609](matrix-org/synapse#9609)) - Add initial experimental support for a "space summary" API. ([\#9643](matrix-org/synapse#9643), [\#9652](matrix-org/synapse#9652), [\#9653](matrix-org/synapse#9653)) - Add support for the busy presence state as described in [MSC3026](matrix-org/matrix-spec-proposals#3026). ([\#9644](matrix-org/synapse#9644)) - Add support for credentials for proxy authentication in the `HTTPS_PROXY` environment variable. ([\#9657](matrix-org/synapse#9657)) Bugfixes -------- - Fix a longstanding bug that could cause issues when editing a reply to a message. ([\#9585](matrix-org/synapse#9585)) - Fix the `/capabilities` endpoint to return `m.change_password` as disabled if the local password database is not used for authentication. Contributed by @dklimpel. ([\#9588](matrix-org/synapse#9588)) - Check if local passwords are enabled before setting them for the user. ([\#9636](matrix-org/synapse#9636)) - Fix a bug where federation sending can stall due to `concurrent access` database exceptions when it falls behind. ([\#9639](matrix-org/synapse#9639)) - Fix a bug introduced in Synapse 1.30.1 which meant the suggested `pip` incantation to install an updated `cryptography` was incorrect. ([\#9699](matrix-org/synapse#9699)) Updates to the Docker image --------------------------- - Speed up Docker builds and make it nicer to test against Complement while developing (install all dependencies before copying the project). ([\#9610](matrix-org/synapse#9610)) - Include [opencontainers labels](https://github.com/opencontainers/image-spec/blob/master/annotations.md#pre-defined-annotation-keys) in the Docker image. ([\#9612](matrix-org/synapse#9612)) Improved Documentation ---------------------- - Clarify that `register_new_matrix_user` is present also when installed via non-pip package. ([\#9074](matrix-org/synapse#9074)) - Update source install documentation to mention platform prerequisites before the source install steps. ([\#9667](matrix-org/synapse#9667)) - Improve worker documentation for fallback/web auth endpoints. ([\#9679](matrix-org/synapse#9679)) - Update the sample configuration for OIDC authentication. ([\#9695](matrix-org/synapse#9695)) Internal Changes ---------------- - Preparatory steps for removing redundant `outlier` data from `event_json.internal_metadata` column. ([\#9411](matrix-org/synapse#9411)) - Add type hints to the caching module. ([\#9442](matrix-org/synapse#9442)) - Introduce flake8-bugbear to the test suite and fix some of its lint violations. ([\#9499](matrix-org/synapse#9499), [\#9659](matrix-org/synapse#9659)) - Add additional type hints to the Homeserver object. ([\#9631](matrix-org/synapse#9631), [\#9638](matrix-org/synapse#9638), [\#9675](matrix-org/synapse#9675), [\#9681](matrix-org/synapse#9681)) - Only save remote cross-signing and device keys if they're different from the current ones. ([\#9634](matrix-org/synapse#9634)) - Rename storage function to fix spelling and not conflict with another function's name. ([\#9637](matrix-org/synapse#9637)) - Improve performance of federation catch up by sending the latest events in the room to the remote, rather than just the last event sent by the local server. ([\#9640](matrix-org/synapse#9640), [\#9664](matrix-org/synapse#9664)) - In the `federation_client` commandline client, stop automatically adding the URL prefix, so that servlets on other prefixes can be tested. ([\#9645](matrix-org/synapse#9645)) - In the `federation_client` commandline client, handle inline `signing_key`s in `homeserver.yaml`. ([\#9647](matrix-org/synapse#9647)) - Fixed some antipattern issues to improve code quality. ([\#9649](matrix-org/synapse#9649)) - Add a storage method for pulling all current user presence state from the database. ([\#9650](matrix-org/synapse#9650)) - Import `HomeServer` from the proper module. ([\#9665](matrix-org/synapse#9665)) - Increase default join ratelimiting burst rate. ([\#9674](matrix-org/synapse#9674)) - Add type hints to third party event rules and visibility modules. ([\#9676](matrix-org/synapse#9676)) - Bump mypy-zope to 0.2.13 to fix "Cannot determine consistent method resolution order (MRO)" errors when running mypy a second time. ([\#9678](matrix-org/synapse#9678)) - Use interpreter from `$PATH` via `/usr/bin/env` instead of absolute paths in various scripts. ([\#9689](matrix-org/synapse#9689)) - Make it possible to use `dmypy`. ([\#9692](matrix-org/synapse#9692)) - Suppress "CryptographyDeprecationWarning: int_from_bytes is deprecated". ([\#9698](matrix-org/synapse#9698)) - Use `dmypy run` in lint script for improved performance in type-checking while developing. ([\#9701](matrix-org/synapse#9701)) - Fix undetected mypy error when using Python 3.6. ([\#9703](matrix-org/synapse#9703)) - Fix type-checking CI on develop. ([\#9709](matrix-org/synapse#9709)) Synapse 1.30.1 (2021-03-26) =========================== This release is identical to Synapse 1.30.0, with the exception of explicitly setting a minimum version of Python's Cryptography library to ensure that users of Synapse are protected from the recent [OpenSSL security advisories](https://mta.openssl.org/pipermail/openssl-announce/2021-March/000198.html), especially CVE-2021-3449. Note that Cryptography defaults to bundling its own statically linked copy of OpenSSL, which means that you may not be protected by your operating system's security updates. It's also worth noting that Cryptography no longer supports Python 3.5, so admins deploying to older environments may not be protected against this or future vulnerabilities. Synapse will be dropping support for Python 3.5 at the end of March. Updates to the Docker image --------------------------- - Ensure that the docker container has up to date versions of openssl. ([\#9697](matrix-org/synapse#9697)) Internal Changes ---------------- - Enforce that `cryptography` dependency is up to date to ensure it has the most recent openssl patches. ([\#9697](matrix-org/synapse#9697)) Synapse 1.30.0 (2021-03-22) =========================== Note that this release deprecates the ability for appservices to call `POST /_matrix/client/r0/register` without the body parameter `type`. Appservice developers should use a `type` value of `m.login.application_service` as per [the spec](https://matrix.org/docs/spec/application_service/r0.1.2#server-admin-style-permissions). In future releases, calling this endpoint with an access token - but without a `m.login.application_service` type - will fail. No significant changes. Synapse 1.30.0rc1 (2021-03-16) ============================== Features -------- - Add prometheus metrics for number of users successfully registering and logging in. ([\#9510](matrix-org/synapse#9510), [\#9511](matrix-org/synapse#9511), [\#9573](matrix-org/synapse#9573)) - Add `synapse_federation_last_sent_pdu_time` and `synapse_federation_last_received_pdu_time` prometheus metrics, which monitor federation delays by reporting the timestamps of messages sent and received to a set of remote servers. ([\#9540](matrix-org/synapse#9540)) - Add support for generating JSON Web Tokens dynamically for use as OIDC client secrets. ([\#9549](matrix-org/synapse#9549)) - Optimise handling of incomplete room history for incoming federation. ([\#9601](matrix-org/synapse#9601)) - Finalise support for allowing clients to pick an SSO Identity Provider ([MSC2858](matrix-org/matrix-spec-proposals#2858)). ([\#9617](matrix-org/synapse#9617)) - Tell spam checker modules about the SSO IdP a user registered through if one was used. ([\#9626](matrix-org/synapse#9626)) Bugfixes -------- - Fix long-standing bug when generating thumbnails for some images with transparency: `TypeError: cannot unpack non-iterable int object`. ([\#9473](matrix-org/synapse#9473)) - Purge chain cover indexes for events that were purged prior to Synapse v1.29.0. ([\#9542](matrix-org/synapse#9542), [\#9583](matrix-org/synapse#9583)) - Fix bug where federation requests were not correctly retried on 5xx responses. ([\#9567](matrix-org/synapse#9567)) - Fix re-activating an account via the admin API when local passwords are disabled. ([\#9587](matrix-org/synapse#9587)) - Fix a bug introduced in Synapse 1.20 which caused incoming federation transactions to stack up, causing slow recovery from outages. ([\#9597](matrix-org/synapse#9597)) - Fix a bug introduced in v1.28.0 where the OpenID Connect callback endpoint could error with a `MacaroonInitException`. ([\#9620](matrix-org/synapse#9620)) - Fix Internal Server Error on `GET /_synapse/client/saml2/authn_response` request. ([\#9623](matrix-org/synapse#9623)) Updates to the Docker image --------------------------- - Make use of an improved malloc implementation (`jemalloc`) in the docker image. ([\#8553](matrix-org/synapse#8553)) Improved Documentation ---------------------- - Add relayd entry to reverse proxy example configurations. ([\#9508](matrix-org/synapse#9508)) - Improve the SAML2 upgrade notes for 1.27.0. ([\#9550](matrix-org/synapse#9550)) - Link to the "List user's media" admin API from the media admin API docs. ([\#9571](matrix-org/synapse#9571)) - Clarify the spam checker modules documentation example to mention that `parse_config` is a required method. ([\#9580](matrix-org/synapse#9580)) - Clarify the sample configuration for `stats` settings. ([\#9604](matrix-org/synapse#9604)) Deprecations and Removals ------------------------- - The `synapse_federation_last_sent_pdu_age` and `synapse_federation_last_received_pdu_age` prometheus metrics have been removed. They are replaced by `synapse_federation_last_sent_pdu_time` and `synapse_federation_last_received_pdu_time`. ([\#9540](matrix-org/synapse#9540)) - Registering an Application Service user without using the `m.login.application_service` login type will be unsupported in an upcoming Synapse release. ([\#9559](matrix-org/synapse#9559)) Internal Changes ---------------- - Add tests to ResponseCache. ([\#9458](matrix-org/synapse#9458)) - Add type hints to purge room and server notice admin API. ([\#9520](matrix-org/synapse#9520)) - Add extra logging to ObservableDeferred when callbacks throw exceptions. ([\#9523](matrix-org/synapse#9523)) - Fix incorrect type hints. ([\#9528](matrix-org/synapse#9528), [\#9543](matrix-org/synapse#9543), [\#9591](matrix-org/synapse#9591), [\#9608](matrix-org/synapse#9608), [\#9618](matrix-org/synapse#9618)) - Add an additional test for purging a room. ([\#9541](matrix-org/synapse#9541)) - Add a `.git-blame-ignore-revs` file with the hashes of auto-formatting. ([\#9560](matrix-org/synapse#9560)) - Increase the threshold before which outbound federation to a server goes into "catch up" mode, which is expensive for the remote server to handle. ([\#9561](matrix-org/synapse#9561)) - Fix spurious errors reported by the `config-lint.sh` script. ([\#9562](matrix-org/synapse#9562)) - Fix type hints and tests for BlacklistingAgentWrapper and BlacklistingReactorWrapper. ([\#9563](matrix-org/synapse#9563)) - Do not have mypy ignore type hints from unpaddedbase64. ([\#9568](matrix-org/synapse#9568)) - Improve efficiency of calculating the auth chain in large rooms. ([\#9576](matrix-org/synapse#9576)) - Convert `synapse.types.Requester` to an `attrs` class. ([\#9586](matrix-org/synapse#9586)) - Add logging for redis connection setup. ([\#9590](matrix-org/synapse#9590)) - Improve logging when processing incoming transactions. ([\#9596](matrix-org/synapse#9596)) - Remove unused `stats.retention` setting, and emit a warning if stats are disabled. ([\#9604](matrix-org/synapse#9604)) - Prevent attempting to bundle aggregations for state events in /context APIs. ([\#9619](matrix-org/synapse#9619))
We are testing this and it's working fine for us on productive systems, when will it be "merged"? |
@turt2live was the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This still lgtm.
@mscbot fcp merge
@mscbot fcp merge |
This FCP proposal has been cancelled by #3026 (comment). Team member @mscbot has proposed to merge this. The next step is review by the rest of the tagged people: Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for information about what commands tagged team members can give me. |
|
||
## Proposal | ||
|
||
A new presence state is added, `busy`, which describes a state where the user is |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While I don't have an objection to adding busy
in particular, this raises the larger question of what presence states we should have. Is it sufficient to just add busy
, or do should we be adding more? For example, XMPP defines 6 states (4 states with names, plus a non-specific "online" state when the show
element is not present, and a state where the client is offline.) Are we eventually going to want equivalents for XMPP's other states that we're missing? How do we decide where to draw the line?
FWIW, I think that adding a 4th busy
state is probably OK. Adding much more than that would be of questionable value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, this was basically my feeling too. How is busy
different from unavailable
? Should we use status messages instead?
presence state to `unavailable`, which is the closest state to `busy` | ||
semantically. | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The spec says that the server aggregates presence data across devices, which I assume means that, e.g. if a user has one device that's online
and another that's offline
, then the user is marked as online
. How does busy
fit into this? If a user has a device that's online
, and one that's busy
, what m.presence
event should be sent to others? I think that my expectation would be that busy
would take precedence over online
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm pretty sure it does in the current implementation. There seems to be one api end point for presence that was overlooked so we disabled it on our forks but when the online state comes through a sync it is ignored by synapse - matrix-org/synapse#12213
Co-authored-by: Hubert Chathi <[email protected]>
Thanks for the comments, I'll try to make some time to address them soon. |
After talking to the author, this isn't the author's current priority. It's hard to make progress on this from the SCT side in this state, so removing from FCP for now - we can always restart FCP when someone is able to pick this up :) @mscbot fcp cancel |
implementations to not implement a timer that would trigger an update to the | ||
`unavailable` state (like most implementations do when the user is in the | ||
`online` state). This is because there are some valid use cases for the user not |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even though it's obvious, we may also want to explicitly state that homeservers shouldn't update a user's presence state to "online" if activity is detected.
For backwards compatibility, servers implementing this MSC must expose a flag in | ||
`/_matrix/client/versions` responses, under `unstable_features`, named | ||
`org.matrix.msc3026.busy_presence`, which is set to `true`. Before setting a | ||
user's presence to `busy`, clients must check the presence of this flag and that | ||
it's set to `true`. If it's not, clients should fall back to setting the user's | ||
presence state to `unavailable`, which is the closest state to `busy` | ||
semantically. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sort of backwards compatibility would go in the unstable prefix section - clients (now) can use spec versions to detect support otherwise.
If a user's presence is set to `busy`, it is strongly recommended for | ||
implementations to not implement a timer that would trigger an update to the | ||
`unavailable` state (like most implementations do when the user is in the | ||
`online` state). This is because there are some valid use cases for the user not | ||
triggering any event in the client but still being online and active, e.g. if | ||
they're on a call, and because such automation while taking the specific | ||
semantics of the `busy` state into account is complex when the user is using | ||
multiple devices. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Synapse (at least) also transitions users to offline
in some situations (e.g. if the user stops syncing and enough time has passed). This still seems somewhat valid (e.g. if a device just disappears forever without transition off busy
then you at some point want to transition the account to something else).
It is left to the implementation to decide how to update a user's presence to | ||
the `busy` state (and from this state to another); suggestions would include | ||
allowing the user to set it manually, setting it automatically when the user | ||
joins a call or a Jitsi group call, etc.. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
matrix-org/synapse#12213 asserts that only the /presence
API can be used to set busy and that subsequent /sync
calls after a user is set to busy
should not revert a user to online
automatically. I don't think this makes sense and it would be a lot clearer for a client to sync with set_presence=busy
if it is still busy. This would give /sync?set_presence=?
and /presence
the same "power" and not different behavior.
I don't think this MSC could be merged without either documenting the Synapse implementation or a clarification of the MSC.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think this probably does make sense - my basic understanding of it was that the presence API is the 'user level' presence and the sync is the 'device level' presence, so previously the user is busy rather than a device, but this would just be switching to say that a device is busy (which perhaps makes more sense: the user is on a call on a specific device).
Rendered
Synapse implementation: matrix-org/synapse#9644
Element Android implementation: element-hq/element-android#6047
Element Web implementation: matrix-org/matrix-react-sdk#8043
FCP proposal: #3026 (comment)