[messaging] Matrix.org: Decentralized group chat

[Ximin Luo]

On 11/03/15 00:51, Matthew Hodgson wrote:
> On Tue, 10 Mar 2015, Ximin Luo wrote:
> 
>> On 10/03/15 21:39, Matthew Hodgson wrote:
>>> So in terms of state merge resolution: yes, this is obviously a hard 
>>> problem to get right.  Hopefully we haven't underestimated it.  The WIP 
>>> draft documentation for it is at 
>>> https://github.com/matrix-org/matrix-doc/blob/master/drafts/erikj_federation.rst#state-resolution.  
>>> Meanwhile the reference python server implementation actually implements 
>>> this, and hasn't exploded yet.
>>>
>>
>> I haven't yet read the full thing, but this feels a bit naive. In a 
>> situation where your state can be said to have a "removal" operation, 
>> then the properties stated currently don't work.
>>
>>    {abc}
>>    /   \
>>   /     \
>> {ab}   {bc}
>>
>> The result of merging the two children should be {b}. Note that the 
>> history is important - if the parent state were different in the above 
>> case, e.g.:
>>
>>     {b}
>>    /   \
>>   /     \
>> {ab}   {bc}
>>
>> then the merge result should be {abc} - i.e. the "time-reversed" form of 
>> the first case. "Removal" is abstract; I think this results applies for 
>> any state that can be said to admit "inverse" operations.
>>
>> But perhaps you've architected your state such that "inverse operations" 
>> don't exist? (c.f. what Trevor said before about "If group membership 
>> can be added but not deleted, then merging is easy (union of group 
>> members).")
> 
> Correct - currently we don't allow removal.  In the scenario of room 
> membership, we simply switch members' state to 'left' when they leave, so 
> currently state accumulates increasingly over time.  (For instance, the 
> #matrix:matrix.org room currently is aware of 693 users, of which around 
> 200 are currently in state 'left', as opposed to 'invited' or 'joined').  
> We haven't seen this to be a major problem in practice so far, although 
> obviously we will need to revisit this in the scenario of join-spam 
> attacks.
> 

This is equivalent to encoding the entire history of join/part operations in each event/message. We did explore this as well, but in the context of "private group chat" it is a potential privacy violation since it reveals previous members of the session. You should be aware of this, and users should be aware that the system does this.

Thanks for the explanations regarding the other points, I will have a more detailed read tomorrow.

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git