MSC3883: Fundamental state changes #3883
Conversation
timokoesters
changed the title
| @@ -0,0 +1,27 @@ | |||
| # MSC3883: Fundamental state changes (Draft) | |||
There was a problem hiding this comment.
Ok so Initial Review from me.
Resolved Meta issues: Rendered is missing from the PR descript.
Onto actual review.
So if i read this right this is working on the concept of making the servers be the members of the room and then having them track their own users? So in the case of Synapse admins the state complexity should land somewhere at the 2300 mark instead of the 20143 it is at now according to Synapse Admin on feline.support.
Like i assume we will still have to track server memberships in state but still that is way less events. For the Synapse admins room we are talking 2000 users from matrix.org that wont contribute to the state. Tho Synapse Admins is a special case i would say due to that its a worst case for this since the room is well very decentralised and the fact that even in a room like that it will help shows why this is a good idea.
I say that if this can be executed correctly i say that this plus Fed peek for Profiles as Rooms is a realistic step forward for matrix. It would also work as an option to keep membership in the room a secret for homeservers that dont have access to history where a particular member interacted. If you only need to track server membships the users can come and go as they please without leaving a trace that is permanently vissible.
There was a problem hiding this comment.
Thanks for the review!
still have to track server memberships in state
I hope to get rid of that too because:
- In a p2p future we would have many state events again
- A spammer could set up thousands of servers and spam room state that way.
- State can not be removed
I think it's possible to send the list of participating servers in make/send_join and then keep it up to date using edus.
There was a problem hiding this comment.
this seems like it might be interesting for matrix-org/matrix-spec#840, since if servers can track their own users in a room then they can unilaterally join or send messages with any user for a room they are already part of.
timokoesters
force-pushed
the
patch-1
branch
from
01075d5
to
d390ed4
Compare
turt2live
added
proposal
| Each server is responsible for tracking kicks, bans etc. of its own users. | ||
| If a server abuses this, the server should be banned as a whole. | ||
|
|
||
| - Displayname/Avatar updates should be EDUs that trigger a /profile query. While servers still fetch the picture, at least it is not in the timeline. |
There was a problem hiding this comment.
I think factoring out profiles from the room state to a more central "object" is a generally a good idea. The room only retains a link to the user's chosen profile, in case the user has multiple (e.g. space-local nick/avatar). I think that proposal or issue exists somewhere. @ShadowJonathan we talked about this, do you have something handy?
There was a problem hiding this comment.
no, but the general concept is that the membership state event refers to another room, which can then be peeked by servers/clients to get up-to-date information on profiles.
profiles can be logically separated this way, a membership state event updated to a new room to follow a new profile room
the problem right now is that peeking over federation does not exist (even though a proposal exists for it, which hasn't had attention for a long while), which prevents this being viable
Rendered
This is a draft. I plan to explain everything in more detail later, but if you have comments already, please share them