TriangleToo

> Maybe make `onElementDataChange` work with `cancelEvent()` instead? If it's easier to do, then why not. Always something more for security > The idea is good nonetheless, but maybe it's...

@tederis You're right, additionally, as part of the persuasion to introduce the `authoritative` parameter, we can add that in case someone uses the subscribe/false synchronization type, when trying to reverse...

> `setElementDataProtected` can do two things (simultaneously): > > * send a lock signal to clients so clients won't be able to send element data changes > * forbid incoming...

> > Such a change of element data has already been sent to the server (can be avoided by the flag from the first point), so we lost time for...

> Fun fact: **80%** of the `setElementData` execution time is `on(Client)ElementDataChange` event processing with just one simple event handler. lol. I would understand it for an event that can be...

> > > I think function `setElementDataSilence(element, key, silent)`(suggest the better name) can be added for blocking element data events. Because in most of the cases those events are not...