Open MatMaul opened 5 years ago
My main concern here is that if it is mandatory per spec it blocks the implementation of a new client API endpoint/property that would still be compatible with 1.0.
agreed that we should provide a standard specified way for clients to tell servers not to relay presence information for them (whether or not the client is providing explicit presence info). An MSC for this would be great.
Meanwhile, presence_lists have been removed from the spec in matrix-org/matrix-spec-proposals#1819, but equivalent functionality will reappear in future. I'm not sure it helps your use case, though, which is for a client to say "please don't relay my presence to the general public"
Good so we are not stuck by a too-precise spec great :)
Presence list seems to have been designed so people can request presence from someone right ?
I think it is too complicated, if we have a user-handled list of forbidden and mandatory targets on top of a sensible default (nothing by default, or non-public rooms attendees by default) I don't think we need an invitation-like mechanism.
I think I have seen an issue on element github at some point that is about setting your own status manually, including "invisible" (appear offline, no presence) for privacy. Theoretically between 2 homeservers with enabled presence, anyone from a public room could create a online/offline profile of me, which I consider a substantial privacy problem. However presence is pretty nice with a couple trusted contacts. This may extend to "custom status messages" which I don't know are included with presence, but in principle all I mention here applies for them, too.
Most importantly, presence must be opt-in by the user! It is one of the most sensitive pieces of information on a user! It should only be "exploitable" when consciously opting in.
I would further like some ways to manage my online status for even more privacy. Particularly I would like to be "invisible" by default and then allow sharing my status with/based on
Some scenarios that extend the implied by above list require the same flexibility to exempt ("superseding blocklist") users from these rules:
Yes, these are fairly fine grained and also a lots of knobs to tweak.
UI suggestions based on element:
A related way I have thought about back when my server was to small and suffered from performance issues due to federated presence is a presence router module for synapse, that would accept a list of MXID regex to indicate what federated servers/users will receive presence updates. But I'm not too certain on how presence currently works, nor how to write a synapse plugin module. Homeservers should implement a mechanism that overrides the user setting such that only the intersection set is allowed. This will likely also alleviate performance issues: usefulness of sending presence to big public rooms is questionable imo and a default off would alleviate load unless you opt in.
I haven't dug into it yet, but I expect that presence is some kind of global user profile state, and not room state/timeline event or similar. That means that in principle a malicious homeserver that hosts one of my contacts whom I explicitly share presence with could share that with all of its users or the world. In principle, state could be hidden from homeservers by e2ee it, provided you send it only to contacts you share a e2ee DM with or similar.
Current workarounds: use different accounts for different purposes (possibly on different servers which have presence enabled or disabled). This is pretty bad, I haven't found a client yet which is mostly fully featured and also allows multiple accounts in the same window.
Imo it is pressing that at least default off in profiles with a toggle in client profile settings is implemented asap. A server should ignore presence updates if it is off.
I integrated the points made in https://github.com/matrix-org/matrix-doc/issues/1221#issuecomment-484540398 which were missing from my original idea to create this comprehensive post.
Hi all,
So I just set up my server with presence tracking enabled. However presence tracking is sent to every people I share a room with, and I don't really like that.
I browsed the spec looking for details regarding that, there is a warning regarding this in the spec. However I can't see anything related to the fact that sending presence to all people you share a room with is mandatory.
Can anyone confirm that ?
I was thinking about implementing an option in synapse to NOT share presence with people I only share public rooms with them.
That should probably be an option handled by the client at some point in a later spec version, with some presence_list like mechanism to override the default behavior for a room/person. I was thinking about writing a MSC for that.
Thoughts ?