MSC3266: Room summary API #3266
Conversation
Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de>
deepbluev7
force-pushed
the
room-summaries
branch
from
855306e to
642f4e1
Compare
turt2live
added
client-server
Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de>
Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de>
…est of the path separate Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de>
That way the requesting server knows, if any user would have access to that room and it can forward the room to the user. Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de>
proposals/3266-room-summary.md
Outdated
| These are the same fields as those returned by [`/publicRooms`](https://spec.matrix.org/v1.13/client-server-api/#get_matrixclientv3publicrooms) or | ||
| [`/hierarchy`](https://spec.matrix.org/v1.13/client-server-api/#get_matrixclientv1roomsroomidhierarchy) | ||
| , with a few additions: `membership`, `room_version`, | ||
| `encryption` and `allowed_room_ids`. |
There was a problem hiding this comment.
allowed_room_ids isn't mentioned in the format.
There was a problem hiding this comment.
You mean in the example above? Yes, because the join_rule is public. It is explained in the table below though, which also says that the field is optional. Does this need an example specifically with the room_ids, if the /hierarchy API already uses that field?
There was a problem hiding this comment.
In the JSON object above, yep, but the text says, "in the following format" rather than, "for example" so I was reading that as a canonical definition rather than an example. This might just be a case of misunderstanding and it just needs to be relabelled as an example.
proposals/3266-room-summary.md
Outdated
| Note that rooms the user has been invited to or knocked at might result in | ||
| outdated or partial information, since the the homeserver may not have access | ||
| to the current state of the room. |
There was a problem hiding this comment.
Why? Wouldn't the server just go & get the latest data the same as it would if they weren't invited?
There was a problem hiding this comment.
Great question. @deepbluev7: can you shed any light here?
Looking at the synapse implementation, the logic goes:
- If the server has at least one user whose membership is
join, generate the summary locally - Otherwise, call out to
GET /_matrix/federation/v1/hierarchy/{roomId}(or the local cache).
I don't see any reason that rooms the user has been invited to or knocked at would be special here.
There was a problem hiding this comment.
There is no way to fetch a room summary over federation, that isn't publicly joinable and a user has been invited to. How would it fetch a more up to date state? That is not how invites currently work on Matrix.
There was a problem hiding this comment.
Mmhmm. So, in the current implementation: if you you have been invited to a remote room that isn't publicly joinable, /summary will return an 404 M_NOT_FOUND for that room, right?
Which I guess is kinda "outdated or partial information".
There was a problem hiding this comment.
Oh, because it's using the /hierarchy API over federation which doesn't allow fetching state of rooms you're not joined to? I hate to say it knowing you've already switched away from adding a federation part to the API, but possibly this would be a good reason to have one, then it could allow servers to view the summary if they had a user that had been invited. Potentially it could be left to a separate MSC but I'd certainly like if it were explained a lot better in the meantime.
| ### The `sync` API | ||
|
|
||
| For joined rooms, the `/sync` API can be used to get a summary for all joined | ||
| rooms. Apart from not working for unjoined rooms, like knocks, invites and space | ||
| children, `/sync` is very heavy for the server and the client needs to cobble | ||
| together information from the `state`, `timeline` and | ||
| [`summary`](https://github.com/matrix-org/matrix-doc/issues/688) sections to | ||
| calculate the room name, topic and other fields provided in this MSC. | ||
|
|
||
| Furthermore, the membership counts in the summary field are only included, if | ||
| the client is using lazy loading. This MSC provides similar information as | ||
| calling `/sync`, but to allow it to work for unjoined rooms it only uses information | ||
| from the stripped state. Additionally, it excludes `m.heroes` as well as membership | ||
| events, since those are not included in the stripped state of a room. (A client | ||
| can call `/joined_members` to receive those if needed. It may still make sense | ||
| to include heroes so that clients could construct a human-friendly room display | ||
| name in case both the name and the canonical alias are absent; but solving the | ||
| security implications with that may better be left to a separate MSC.) |
There was a problem hiding this comment.
I'm not sure this is really an alternative, or at least not one that needs 2 paragraphs of discussion. It's not a problem that it's here, but just as feedback for the future.
There was a problem hiding this comment.
It is mentioned as an alternative, because people brought up "just call sync" when I initially discussed this MSC with people. This section is an argument in that discussion. It obviously isn't a good alternative, but people needed that spelled out at the time and I didn't want to have this argument multiple times.
|
@mscbot concern should unauthenticated access be enabled by default? |
mscbot
added
the
unresolved-concerns
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Co-authored-by: Johannes Marbach <n0-0ne+github@mailbox.org>
|
I have given this another round of updates. SCT members who had previously ticked their boxes may wish to give this another round of review; however I hope there is nothing that will be controversial here. @deepbluev7 likewise: I hope you don't object to any of my changes here. I think there are only two material changes:
There have been a number of other changes, but I believe they are all clarifications, rather than material changes. |
|
@mscbot resolve should unauthenticated access be enabled by default? |
mscbot
removed
the
unresolved-concerns
richvdh
requested review from
dbkr,
t3chguy and
erikjohnston
and removed request for
t3chguy
Co-authored-by: Johannes Marbach <n0-0ne+github@mailbox.org>
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
mscbot
added
final-comment-period
Rendered.
Somewhat related to MSC2946 this provides an API to get a summary for a specific room either from the local server or over federation.
Useful for a few cases, where you need to show a summary for a room like matrix.to, traveler bots, showing spaces, lightweight clients, etc.
Open design questions looking for feedback: see this comment chain: #3266 (comment)resolved as of 2021/10/06Implementations:
allowed_room_idspart is implemented here: deepbluev7/synapse@37f4253.Signed-off-by: Nicolas Werner nicolas.werner@hotmail.de
SCT stuff:
Shepherd: @richvdh
FCP tickyboxes
Checklist: #3266 (comment)