WIP: MSC1772: Matrix spaces #1772
Conversation
|
looks good |
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
|
Trust issue wrt flairs |
These should have been part of MSC2962.
if/when we need it, we should follow MSC2875
I think the peeking thing is specific to access control.
we're not doing this bit yet.
| XXX: we need to deterministically specify where the cycles get cut. | ||
| I think kegan found a solution for this when implementing MSC2946 in Dendrite. |
richvdh
Mar 18, 2021
Member
the original thread got hijacked, so once again:
@ara4n why do you think this needs to be deterministic, and why does it need to be specified here?
the original thread got hijacked, so once again:
@ara4n why do you think this needs to be deterministic, and why does it need to be specified here?
t3chguy
Mar 18, 2021
Member
If it isn't deterministic & specced then different clients will cut differently and thus show different "top level" spaces
E.g in an A -> B -> A space hierarchy, client A might show A -> B, the other B -> A and this would on the surface look very broken
If it isn't deterministic & specced then different clients will cut differently and thus show different "top level" spaces
E.g in an A -> B -> A space hierarchy, client A might show A -> B, the other B -> A and this would on the surface look very broken
richvdh
Mar 18, 2021
Member
E.g in an A -> B -> A space hierarchy, client A might show A -> B, the other B -> A and this would on the surface look very broken
right, yes. I don't think that the solution in MSC2946 (which is simply to stop walking once you find a repeat) is going to help here, because it all depends where you start from.
E.g in an A -> B -> A space hierarchy, client A might show A -> B, the other B -> A and this would on the surface look very broken
right, yes. I don't think that the solution in MSC2946 (which is simply to stop walking once you find a repeat) is going to help here, because it all depends where you start from.
richvdh
Mar 18, 2021
Member
The alternative seems to be to specify a way that clients can agree which is the rootmost space in a loop. For example, you might say "the lexicographical lowest room id in the loop is the root". But then you still encounter effects which look very broken when a space that was the root suddenly becomes several levels down the hierarchy because someone introduced a cycle.
The alternative seems to be to specify a way that clients can agree which is the rootmost space in a loop. For example, you might say "the lexicographical lowest room id in the loop is the root". But then you still encounter effects which look very broken when a space that was the root suddenly becomes several levels down the hierarchy because someone introduced a cycle.
t3chguy
Mar 18, 2021
Member
the lexicographical lowest room id in the loop is the root
Yup, that is what was proposed internally at one point (and is what I implemented in EleWeb iirc)
the lexicographical lowest room id in the loop is the root
Yup, that is what was proposed internally at one point (and is what I implemented in EleWeb iirc)
clokep
Apr 6, 2021
Member
Does this make sense to include in here then or does it make sense to leave this up to implementations?
Does this make sense to include in here then or does it make sense to leave this up to implementations?
richvdh
Apr 7, 2021
Member
I think it probably does make sense to make a recommendation here, yes.
I think it probably does make sense to make a recommendation here, yes.
This comment has been hidden.
This comment has been hidden.
| ```js | ||
| { | ||
| "type": "m.space.child", | ||
| "state_key": "!abcd:example.com", |
Cadair
Mar 31, 2021
Contributor
It's worth noting here that once a room id is added to a space in the state key it can't ever be removed again. While this is a very minimal metadata leak (only really showing the existence of a room with that id) is it worth considering some method of obfuscating the ids in the state key? So that the actual room id could be redacted with the content?
It's worth noting here that once a room id is added to a space in the state key it can't ever be removed again. While this is a very minimal metadata leak (only really showing the existence of a room with that id) is it worth considering some method of obfuscating the ids in the state key? So that the actual room id could be redacted with the content?
richvdh
Apr 7, 2021
Member
yeah, one solution here would be to make the state_key a hash of the room id, and embed the unhashed room id in the body of the event - so that the event could be redacted leaving only the hashed id behind.
For me, that feels a bit overengineered given the scope of the information leak (room IDs aren't really that sensitive). It's maybe something we could come back to in future.
yeah, one solution here would be to make the state_key a hash of the room id, and embed the unhashed room id in the body of the event - so that the event could be redacted leaving only the hashed id behind.
For me, that feels a bit overengineered given the scope of the information leak (room IDs aren't really that sensitive). It's maybe something we could come back to in future.
ShadowJonathan
Apr 7, 2021
Contributor
Maybe a future MSC could define a "paranoid" setting which'd enable this, either by default or optionally, to indeed make statekeys hashed?
Maybe a future MSC could define a "paranoid" setting which'd enable this, either by default or optionally, to indeed make statekeys hashed?
Rendered
N.B. group access control has been split out into #2962
Obsoletes #1215