MSC1862: Presence Capabilities

[Half-Shot]

Rendered

Synapse implementation

Riot implementation

[turt2live]

Seems as though this proposal has become a bit of a cold case. In an effort to incite commentary...

@mscbot fcp merge

[mscbot]

This FCP proposal has been cancelled by #1862 (comment).

Team member @mscbot has proposed to merge this. The next step is review by the rest of the tagged people:

• @dbkr
• @uhoreg
• @turt2live
• @ara4n
• @anoadragon453
• @richvdh
• @erikjohnston
• @KitsuneRal

Concerns:

• what problem are we trying to solve here? (MSC1862: Presence Capabilities #1862 (comment))

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.

[Half-Shot]

@turt2live This is now a thing at matrix-org/synapse#5666

[Half-Shot]

I've added a simple riot implementation too

[erikjohnston]

I'd rather just silently accept tbh, otherwise I think its going to confuse clients who don't know that disabling presence is is a "thing". If we are going to 403 then we should have a non-generic errcode so that clients can handle that case.

[richvdh]

Alternatively: return a 200 but put some indication in the response.

[KitsuneRal]

With the current state of the proposal (not passing presence capabilities across federation) I tend to agree that 200 with the response saying "I don't support presence, actually" would be more consistent.

[erikjohnston]

Forking a thread to respond to @richvdh @Half-Shot

Yes, certainly a lot of this could be solved by listening for receipts/messages and using that as a faux presence system.

This seems like the wrong way to solve the problem.

Specifically I was thinking in terms of member lists. If part of the problem is that with presence disabled the member list is weird (avatars greyed out, actively talking people listed last etc), then I think it makes sense to make the member list take into account non-presence info for things like ordering.

[richvdh]

Moving the rest of this conversation into the thread:

@erikjohnston said:

To echo @richvdh: I'm not sure this solves what we want it to solve. Presumably this is trying to fix the UX of not knowing if we have accurate presence information, but I don't actually think this solves that as we would still have unknown presence due to other servers.

Would this be better solved with having e.g. riot handle unknown presence better? Not greying out avatars and having the room list order incorporate last time we saw an action from a user I think could go a long way to making this proposal redundant.

@Half-Shot said:

Would this be better solved with having e.g. riot handle unknown presence better? Not greying out avatars and having the room list order incorporate last time we saw an action from a user I think could go a long way to making this proposal redundant.

Yes, certainly a lot of this could be solved by listening for receipts/messages and using that as a faux presence system.

The other half to the proposal is giving servers a way to report that PUT will not be handled by the homeserver, and I think there is still some value in reporting something other than success there.

@richvdh said

Yes, certainly a lot of this could be solved by listening for receipts/messages and using that as a faux presence system.

This seems like the wrong way to solve the problem.

The other half to the proposal is giving servers a way to report that PUT will not be handled by the homeserver, and I think there is still some value in reporting something other than success there

Could you enlarge upon this? What is the value of it?

As per #1862 (comment), I think I have progressed today from "why is this needed at all" to "ok, but this feels like the wrong solution". I feel like we can achieve the same effect with minor tweaks to the APIs instead.

@Half-Shot said:

The other half to the proposal is giving servers a way to report that PUT will not be handled by the homeserver, and I think there is still some value in reporting something other than success there

Could you enlarge upon this? What is the value of it?

Certainly. A few clients have experimented with supporting users setting their own presence status at one point or another, where a user had to hit buttons to change their presence state rather than using sync to do it (which is the point of this endpoint).

If I hit buttons to change my presence state in my matrix client and it happily does so, while the actual request is being ignored by the homeserver, that's a rather poor UX. Certainly if you expect "unavailable" to mean "please don't bother me" and then people bother you because the feature doesn't work, that seems pretty awful.

Which brings me back to the capabilities flag. I'd rather disable features like these in clients where the homeserver doesn't support them by way of flag, but failing that I would like for error codes to be returned when a feature doesn't work so that the client can relay that information back to the user.

@erikjohnston said:

Yes, certainly a lot of this could be solved by listening for receipts/messages and using that as a faux presence system.

This seems like the wrong way to solve the problem.

Specifically I was thinking in terms of member lists. If part of the problem is that with presence disabled the member list is weird (avatars greyed out, actively talking people listed last etc), then I think it makes sense to make the member list take into account non-presence info for things like ordering.

[richvdh]

@Half-Shot said:

If I hit buttons to change my presence state in my matrix client and it happily does so, while the actual request is being ignored by the homeserver, that's a rather poor UX. Certainly if you expect "unavailable" to mean "please don't bother me" and then people bother you because the feature doesn't work, that seems pretty awful.
Which brings me back to the capabilities flag. I'd rather disable features like these in clients where the homeserver doesn't support them by way of flag, but failing that I would like for error codes to be returned when a feature doesn't work so that the client can relay that information back to the user.

Yes, I agree that there is value in using a capabilities API for that.

[richvdh]

@erikjohnston said:

Specifically I was thinking in terms of member lists

what exactly are member lists, and how could they be used to solve this problem?

[richvdh]

it's pretty clear that this MSC needs some more attention; for example the thread at #1862 (comment) ends with @Half-Shot agreeing to replace the "should clients show whether users are online" logic with information based on the results of /sync, which doesn't seem to have happened.

meanwhile #1862 (comment) has got a bit confused with conflating the behaviour on the read side and on the send side, possibly with some alternative suggestions about how to proceed?

In any case, it seems we're agreed that capabilities are not the right mechanism for determining how clients should display presence state, so this is back to @Half-Shot to update. It might be best to replace this MSC with alternative proposals which handle the send and read side separately, but I'll leave that to you.

In the meantime I'm going to make an executive decision to

@mscbot fcp cancel