8000 Clarify Behavior When Inviting Non-Existent Users · Issue #2139 · matrix-org/matrix-spec · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
Clarify Behavior When Inviting Non-Existent Users #2139
Open
@Jeff92316046

Description

@Jeff92316046

Description:

Currently, the Matrix specification does not explicitly define the expected behavior when a user attempts to invite a user ID that does not yet exist on the homeserver.

For example, in Synapse, if an invite is sent to a non-existent user ID (e.g., @nonexistent:example.com), the server responds with 200 OK, and if an account is later registered with that user ID, the invite becomes active and the user is automatically added to the room.

It is unclear from the specification whether this is the intended or recommended behavior, or whether servers should reject invites to unknown user IDs at the time of the invite.

Steps to Reproduce (Example in Synapse):

  1. Invite a non-existent user ID:
    /invite @nonexistent:example.com
    
  2. Observe that the server responds with 200 OK.
  3. Later, register a user with @nonexistent:example.com.
  4. The user automatically enters an invited membership state for the room upon registration, without explicit consent or action from the user.

Expected Behavior:

  • The specification should clarify whether inviting a non-existent user ID is allowed.
  • If not allowed, the server should return an error (with an error code and message) indicating that the user ID does not exist at the time of the invite.
  • If allowed, it should be explicitly documented that the invite will remain pending until such a user is registered.

Actual Behavior (Example in Synapse):

  • The server returns 200 OK even though the user ID does not exist.
  • If a user registers later with that ID, they are automatically invited into the room.

Additional Context:

This behavior may cause confusion for clients and users, since an invite appears successful even if the user does not exist at the time. It may also have implications for security and invitation semantics.

Proposed Solution:

  • Clarify in the specification whether inviting a non-existent user is valid.
  • If not valid, require servers to return an appropriate error code and message in a machine-readable format (e.g., JSON).
  • If valid, define explicitly what happens to such an invite, how long it remains pending, and how clients should handle it.

Metadata

Metadata

Assignees

No one assigned

    Labels

    clarificationAn area where the expected behaviour is understood, but the spec could do with being more explicit

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      0