Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
52 changes: 52 additions & 0 deletions proposals/4042-disabled-presence-state.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,52 @@
# MSC4042: Disabled Presence State

In current matrix we have no way to tell clients that we simply do not have presence data at all
for a given homeserver or user. This proposal addresses this fact by adding a `disabled` state.

By adding a `disabled` state to presence it allows us to kill two birds with one stone. Its used for
[MSC4043](https://github.com/matrix-org/matrix-spec-proposals/pull/4043) and for this proposal. In this proposal its simply used to indicatea lack of information about
a given user. This is going to 9 times out of 10 be because of that presence is disabled somewhere in the
chain and therefore you cant get data. Be that disabled by the other user or their server or your server.
If you are on matrix.org for example all presence will return this value if this proposal is adopted until
they reenable presence. Since they have presence disabled.


## Proposal

This proposal proposes the `disabled` presence state. This makes it the 4th presence state together
with `online`, `offline`, `unavailable`.

Due to `unavailable` being taken for another use `disabled` became the best candidate due to its dual use.

`disabled` presence should be used if data is missing. Be that due to presence being disabled or because of other
mechanisms this state was selected. For example due to the user choosing to put this as their state via
MSC4043 or other mechanism like this.


## Potential issues

The author can not see any significant potential issues arising from this change except that it can cause
clients that are not architected to withstand protocol changes to break.


## Alternatives

The alternatives for this proposal are well not that many if any? Like a way to indicate we don't have any data
is useful. The only change I can think of is splitting intentional lack of data from we just don't have data yet.
But I fail to find that distinction useful.


## Security considerations

Presence should not be security relevant as far as the author is aware. The only exception is the privacy
discussion. This specific proposal should not have any impact on privacy because of the fact that this proposal
does not it self change anything in practice. Presence being disabled is not a secret its a well known fact.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't this weaken the fact that one could mask offline as disabled or vice versa? I think generally for the existing kinds of presence there is deliberate difference in user hands, but this is slightly different.

Copy link
Copy Markdown
Contributor Author

@FSG-Cat FSG-Cat May 31, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This MSC is written for a context where disabled is used for a whole homeserver or for users who dont care about sending that message.

Considering that this MSC is intended to be used together with the ability to force presence states into whatever value you like to use in a perfect world the privacy argument becomes much weaker due to that factor too.

Like presence is not perfect in 2026 and it was not in 2023. This MSC is essentially just one of the parts of a greater presence redesign that Cat actually came to write a proposal for even if its imperfect.

Edit: And i should say that the whole text about that its no secret is more refering to that in practice its trivial to discover that presence is not enabled for a given matrix homeserver or atleast it was in 2023.


## Unstable prefix

Unstable implementations will use the state of `support.feline.msc4042.v1.disabled` in place of `disabled`.

## Dependencies

This MSC does not have any direct dependencies but is paired with MSC4043 due to
this MSC being a semi dependency for it. These proposals can be adopted independently.
Loading