You are then suggesting I did a terrible job in sharing my thoughts in an understandable way, ok fair enough I take it 
14 Likes
Lol no not at all. That comment was in response to the word causality.
7 Likes
Hmhmm - is this an additional attack vector? (node lying about access rights which hinders convergence of network state) or does this simply fall under misbehaviour and is therefore already taken care of?
3 Likes
A node (if you mean a vault) cannot really lie as they don’t have the private keys for signing requests on behalf of the content’s owner, a mutation request can be generated only by the owner or app with rights. A node could perform a replay attack if you will, but CRDT ops have to be idempotent so we should be covered there.
On the other hand, an app with old/outdated rights to perform a mutation may be able to send this type of requests, but I think we should be able to stop those as the Dot (req counter for that client) used for such requests would be already used and therefore the req discarded/ignored by vaults. At least that’s how I think we will be able to differentiate a concurrent request from an invalid request due to an old counter/Dot.
10 Likes
Are you explaining about possible solution of CRDT permission problem?
4 Likes
Yes, we are currently researching and working on that. In summary, when you don’t have permissions for a CRDT you can just apply each operation in each replica, but with permissions you have new problems, as permissions rules can also change and the order in which these changes arrive to each replica may affect how concurrent data requests received by the replicas are treated.
8 Likes
Yes, there are some options available, we just need to see the pros and cons and then test them in our environment and context, apart from the paper linked from the OP which proposes a solution, this other one also gives a lot of insight and details about the problematic and different options: https://www.researchgate.net/profile/Asma_Cherif3/publication/278826644_Access_Control_Models_for_Collaborative_Applications/links/5ce3e73192851c4eabb1a787/Access-Control-Models-for-Collaborative-Applications.pdf
11 Likes
Here you can find a German translation of this weeks dev update
16 Likes
thank you very much for your explanation @bochaco! Sorry … i didn’t manage to say anything earlier … my time sadly is super limited atm … -.-"
glad this isn’t a show stopper - the latest comments from you and @oetyng make me feel we are really getting very close now! =D
11 Likes
Thank you for the heavy work team MaidSafe! There is nothing you can’t do! 
I add the translation into Bulgarian in the first post 
9 Likes
Sounds like it’s coming along nicely. Maybe I’m off-base here, but seems like the issue of making sure user permissions are applied in the proper order in each replica is, on some level, impossible to satisfy entirely. Because of fact that a message can’t propagate instantly through the network and that permission changes can arrive out of order with a modification potentially coming from another source, there’s no way to provide any ground truth as to which occurred first.
Certainly, the network can reach consensus about what order it decides to go with. But at the end of the day, am I correct in concluding that the strongest guarantee that can be made is that issuing a permission change will eventually propagate to all nodes (without any guarantees on the ordering between that permission change and any potential modifications being issued around the same time)?
6 Likes
That’s correct, the only thing the network can do deterministically decide the order in which a policy and concurrent data operations are applied to assure data convergence.
6 Likes