Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Federation: /send_join response is unclear #2467

Closed
kegsay opened this issue Mar 21, 2020 · 0 comments · Fixed by #2575
Closed

Federation: /send_join response is unclear #2467

kegsay opened this issue Mar 21, 2020 · 0 comments · Fixed by #2575
Assignees
@turt2live
Labels
clarification An area where the spec could do with being more explicit s2s Server-to-Server API (federation)

Comments

@kegsay
Copy link
Member

kegsay commented Mar 21, 2020

It has a field auth_chain, which only has the docs:

Required. The auth chain. Note that events have a different format depending on the room version - check the room version specification for precise event formats.

It is not clear what events should be in here. The endpoint GET /_matrix/federation/v1/event_auth/{roomId}/{eventId} does better and says:

Required. The full set of authorization events that make up the state of the room, and their authorization events, recursively.

Which is still unclear for /send_join because is it:

  • the auth chain for the join event being submitted in the request?
  • the auth chain for the entire current room state?

Apparently it's the latter, but the spec should be clearer on this.
@kegsay kegsay added clarification An area where the spec could do with being more explicit s2s Server-to-Server API (federation) labels Mar 21, 2020
@turt2live turt2live self-assigned this May 25, 2020
turt2live added a commit that referenced this issue May 25, 2020
@turt2live
Clarify the auth_chain and state for send_join
67d46fa 
Fixes #2467
Fixes #2464

This is based on looking at Synapse, not actually testing it. Within the send_join handling functions, an "event context" is acquired [here](https://github.com/matrix-org/synapse/blob/d14c4d6b6d02e8c55a6647ce0f0b3b44356d6173/synapse/handlers/federation.py#L1472) which then later uses the previous state (populated [here](https://github.com/matrix-org/synapse/blob/d14c4d6b6d02e8c55a6647ce0f0b3b44356d6173/synapse/state/__init__.py#L286-L289) in the event context) [here](https://github.com/matrix-org/synapse/blob/d14c4d6b6d02e8c55a6647ce0f0b3b44356d6173/synapse/handlers/federation.py#L1494-L1501) to return a response. Within the event context, the previous state IDs are populated [here](https://github.com/matrix-org/synapse/blob/d14c4d6b6d02e8c55a6647ce0f0b3b44356d6173/synapse/state/__init__.py#L351).
@turt2live turt2live mentioned this issue May 25, 2020
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@turt2live turt2live

Labels
clarification An area where the spec could do with being more explicit s2s Server-to-Server API (federation)
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Clarify the auth_chain and state requirements for /send_join matrix-org/matrix-spec-proposals
2 participants
@turt2live @kegsay