MSC3032: Thoughts on updating presence

[dbkr]

Rendered

[Sorunome]

This sounds like turning presences into PDUs? Something like this has been suggested before and has not left many happy, soru still does not think this is the right approach for presences

[dbkr]

hah, yes - good point. Maybe they could be ephemeral events tied to the user profile room?

[Sorunome]

EDUs can't be peaked, though. Not sure how to tackle this / if this should be tackled at all. Like, an effective presence does make sense, but does its transport method have to be changed? Not sure.

[Sorunome]

One issue AS's face with presences is that when setting presences for ghosts they can't set any timeout. What these thoughts are lacking, in sorus opinion, is adding a timeout query parameter to the setting presence endpoint

[dbkr]

Yeah, I hadn't even considered ASes - in fact, ASes probably ought to just be another client and use the same endpoint, except of course that endpoint is /sync... maybe ASes should get their own presence endpoint?

[Sorunome]

No need for a new endpoint if you can just re-use the /status one with a timeout parameter that can be up to e.g. 24h, that would actually fix all the AS issues

[Sorunome]

publishing statuses as state events means that all servers have a cleartext history of all presences stored permanently. This might not be desirable from a privacy point of view.

Soru really gets the benefits of making this a state event, so she isn't sure how to fix this problem.

[artkoenig]

IMHO the status message should be decoupled from the user's presence state. E.g. if I set an "I'm away from x till y" status message, it should be valid regardless of my presence state and if I a have any active sessions or not.

Why not take it one step further and abstract it to any kind of data, storable at the account level? There is already a /user/{userId}/account_data/{type}/ resource for private data. What about /user/{userId}/public_account_data/{type}/ for storing data, which can be read by others? "status_msg" could be the type of the stored status message. You can even store a whole calendar information or whatever you think other users may be interested in.