Skip to content

Conversation

Johennes
Copy link
Contributor

@Johennes Johennes commented Oct 14, 2025

@Johennes Johennes force-pushed the johannes/resident-public-rooms branch from ef6d5d8 to 49592a2 Compare October 14, 2025 08:25
@Johennes Johennes changed the title MSCXXXX: Resident servers in and around the room directory MSC4366: Resident servers in and around the room directory Oct 14, 2025
@Johennes Johennes force-pushed the johannes/resident-public-rooms branch from 49592a2 to dfcd8b9 Compare October 14, 2025 08:26
@Johennes Johennes force-pushed the johannes/resident-public-rooms branch from dfcd8b9 to c06b704 Compare October 14, 2025 08:27
@Johennes Johennes marked this pull request as ready for review October 14, 2025 08:30
@tulir tulir added proposal A matrix spec change proposal s2s Server-to-Server API (federation) client-server Client-Server API kind:maintenance MSC which clarifies/updates existing spec needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. labels Oct 14, 2025
Copy link
Member

Choose a reason for hiding this comment

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

Implementation requirements:

  • Client
  • Server

- [`POST /_matrix/federation/v1/publicRooms`]

MUST only include rooms from the server's local directory if the server has at least one joined
member in them.
Copy link
Member

@tulir tulir Oct 14, 2025

Choose a reason for hiding this comment

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

This looks like it will completely forbid directory-only servers like https://matrixrooms.info/

I think it'd be better to define a via field in the response entries instead of this proposal. Basically, let the origin server figure out if it can find a route rather than mandating a single allowed route in the spec. The spec could still mandate that vias must be returned

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I was struggling with how to best express this but I had intended it to only apply to rooms from the local directory, meaning the server MAY continue to additionally include rooms from other server's directories like today. That only half-solves the problem of course, as stated under potential issues.

Maybe we should combine both? For any room in the response the server must either be resident or include a via value in the response?

Copy link
Member

Choose a reason for hiding this comment

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

For any room in the response the server must either be resident or include a via value in the response?

Is that any different than just requiring all entries include a via value, which may simply be the server itself?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I guess not. 😄

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Have captured this in #4367.

Signed-off-by: Johannes Marbach <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

client-server Client-Server API hacktoberfest-accepted kind:maintenance MSC which clarifies/updates existing spec needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. proposal A matrix spec change proposal s2s Server-to-Server API (federation)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

room directory does not make it clear how to find a resident server

3 participants