MSC3429: Individual room preview API #3429
Conversation
turt2live
changed the title
turt2live
added
client-server
There was a problem hiding this comment.
Taking a glance at this, and the mention of MSC3266 and the comparison, I think it's interesting to see what users of MSC3266 can say about this, and if this fits their usecase.
I say this, because i think stripped-state (which is used in multiple places), compared to the summary mechanism (which is only used in MSC3266, and is its own mechanism), would allow for code re-use and a more standard way to approach this.
This approach seems also easily expandable (by simply allowing more state event types), whereas the summary approach does not.
MSC3266 is based on MSC2946, which attempts to re-use the response format of Stripped state is only used for invites/knocking IIRC. Please use threads. :) |
| changes, the suggestion from the author is to use the same caching semantics as the room directory. | ||
| If a room becomes non-public, it should be evicted from the cache. | ||
|
|
||
| ## Alternatives |
There was a problem hiding this comment.
What if we just use the spaces summary? #3266 (comment)
There was a problem hiding this comment.
As a client author, I like #3266 shape more - as its author states, it is easier to extract data specifically for the room preview case, even if at the expense of having to add fields to yet another endpoint whenever the stripped state definition gets extended. Compared to that MSC, the current MSC looks like half-way to room peeking. I'd rather use peeking to get a richer/live preview if that provided by #3266 (or hereby) is not enough; but I don't see a lot of value in full-blown stripped state events to address a simpler preview case. The wider interface calls for unneeded questions like whether it's the same stripped state returned by /sync for invited rooms and if yes, should unsigned/prev_content also be returned - all those rather answered by the peeking MSC.
There was a problem hiding this comment.
As a client author, I like #3266 shape more - as its author states, it is easier to extract data specifically for the room preview case, even if at the expense of having to add fields to yet another endpoint whenever the stripped state definition gets extended. Compared to that MSC, the current MSC looks like half-way to room peeking. I'd rather use peeking to get a richer/live preview if that provided by #3266 (or hereby) is not enough; but I don't see a lot of value in full-blown stripped state events to address a simpler preview case. The wider interface calls for unneeded questions like whether it's the same stripped state returned by /sync for invited rooms and if yes, should unsigned/prev_content also be returned - all those rather answered by the peeking MSC.
Update: copied to the relevant thread.
|
@KitsuneRal can we get that as a thread for consideration please? |
|
Given that MSC3266 is in production and generally seems preferred... can we just close this? |
|
Sure. |
turt2live
added
the
obsolete
Rendered