This is an interesting idea, but it's not clear to me that this is going to work at sufficient scale. This isn't clear to me because instead of getting a decent white paper on the implementation, we need to learn how this protocol works through what amounts to a PowerPoint. Sure, the slides are nice and simple, but I need more concrete answers on things like how consensus is determined and how available nodes recover from a disaster.

The slides suggest that a sufficiently complex system will almost immediately get out of sync. The dependency on upstream nodes asserting state about objects before they are acknowledged and successfully applied by the "owner" node means that some subset of nodes will be working on assumptions that haven't been validated by objects they don't in fact own. This seems to conflict with what prior slides say about who can mutate objects.

I think distributed object management is a useful concept, but instance state needs to be owned and managed by multiple nodes for redundancy in anything remotely approximating a production-level system. That doesn't seem to be readily addressed anywhere, either. I'd love to read more about this with the level of detail you'd need from a system that readily has use cases and reference architectures instead of possibilities.

This looks really pretty but the protocol seems not to be well-thought-out from a cursory glance. The example itself shows a case where the non-owning nodes are out of sync with the owner node (and sitting happily in a stable state!!!) and yet actions taken (possibly based off of the out-of-sync data...) are designed to propagate into mutations for the owned state which might be completely different to begin with! Instead of discarding alterations that are made on potentially bad/stale information, the system is designed to just accept any and all changes. There isn't even a rudimentary attempt at versioning to deal with conflicts and race conditions. Instead of dealing with errors from conflicts, they're swept under the rug and mutations are applied. Anything goes!

For a simple example of why that's a big problem imagine you have a state which has some boolean and an rcp that toggles that boolean which you fire based on that state (where both just want to turn it off). If two non-owning nodes say to toggle before the state has propagated from the other's change, it would turn off and back on again, cancelling each other out.

If this is just meant for toy projects where the worst case scenario has no real consequences that may be fine, but the polished look of the project is what's a little scary. It looks too professional for something that simply won't work.

From the website it's unclear how nodes are authenticated. How can one node enforce access control over objects if its connection is proxied?

Where does this system of distributed objects improve from what CORBA did?

Really nice implementation. I once tried to do something similar with V (npm i v) but lacked the time to continue. Hope this project grows!

Is that you, CORBA? Is this me?

Flashbacks to CORBA.