
Dop: Distributed Object Protocol - creamyhorror
https://distributedobjectprotocol.org/
======
languagehacker
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.

~~~
creamyhorror
Does anyone have recommendations for node packages that perform similar
client-server pub/sub or even sophisticated syncing?

Besides dop, DerbyJS/Racer seems to be dead, Apollo might be a solution but
seems to require some setup, Meteor is too heavy, and Feathers with RxJS seems
like a possibility. I'd be interested in any tools for getting easy client-
server sync or reactivity.

~~~
toomim
I can toot my own horn here: [https://stateb.us](https://stateb.us).

Statebus can easily synchronize N clients to N servers, and has a very nice
wrapper on top for reactive UI widgets to respond to changes in state. Here's
a hello world example:

    
    
        dom.BODY = ->   # Let's define the body tag as a function
          DIV
            backgroundColor: '#eef'
            'The time is '
            fetch('state://server.com/time').now
            ' and the weather is '
            fetch('state://another.org/weather/oakland,ca').brief
    

This defines the <body> tag as a function that will reactively re-run whenever
the state of the _time_ (fetched from server.com) or the _weather_ (fetched
from another.org) changes.

~~~
creamyhorror
Interesting project with very simple core API. I saw some feedback about more
sophisticated syncing through OT/WOOT/CRDT, though I don't know if that fits
your approach.

If it can be used seamlessly with Vue/React (as mentioned in older
discussions) such that changes are propagated into them, I'd be interested to
try it. (Those libraries are in heavy use already so your solution would have
to work with them for a decent chance at traction, I think.)

~~~
toomim
Thanks! Yes, the API is very simple. And indeed:

(1) It _does_ work with React natively, and in fact the example I gave above
uses React under the hood. Here's how to do the same thing with raw react:

    
    
        <script src="https://stateb.us/client6.js"></script>
        <script>
        var body = statebus.create_react_class({
          render: () => {                          // This function will re-run whenever
            return React.DOM.div(                  // any state fetched below changes
                {style: {backgroundColor: '#eef'}},
                'The time is ',
                fetch('state://server.com/time').now,
                ' and the weather is ',
                fetch('state://another.org/weather/oakland,ca').brief
            )
          },
          displayName: 'body'
        })
    
        setTimeout(_=> React.render(body(), document.body))
        </script>
    

You can put that into a .html file and run it directly in your browser with a
file:// URL.

I would love to help you give it a try and see what you think! Please send me
an email or text (toomim@gmail.com or 510-282-4312) for feedback and
assistance.

2) We _are_ currently OT/CRDT/Version Control into it. We've come up with a
new approach here, which I'm very excited about. I'm also looking for folks to
beta-test or give early feedback on our approach as we polish it up.

I'm also interested in adding Vue support. If you'd like it, I'll add it.

------
0xfffafaCrash
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.

~~~
josemaenzo
The protocol has a versioning system:
[https://github.com/DistributedObjectProtocol/protocol/blob/m...](https://github.com/DistributedObjectProtocol/protocol/blob/master/README.md#example-4)

Is the responsibility of the implementation to apply the patches/mutations in
the correct order of the version.

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

~~~
aaaaaaaaaab
I guess the server could sign the content.

~~~
bastawhiz
Even still, if a node is connected to the owner through another (malicious)
node, how do you prevent the malicious node from making mutation requests on
behalf of the legitimate node?

I can see a number of ways that it can be accomplished that would take a good
amount of work but it begs the question, is this worth the effort? You now
have lots of security concerns, issues with nodes disconnecting, and nodes
becoming overloaded. What benefit does this have over plain old fashioned
AJAX? What problem does this solve?

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

~~~
atombender
This project is just about exchanging JSON data. CORBA "objects" are not pure
data, but addressable RPC interfaces. Much more complex, and ultimately a bad
fit for the modern web.

------
diegorbaquero
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!

------
mstade
Is that you, CORBA? Is this me?

~~~
DonHopkins
JSOAP!

------
bkeroack
Flashbacks to CORBA.

