Loading ...
Sorry, an error occurred while loading the content.

4552Re: [rest-discuss] REST for P2P application?

Expand Messages
  • S. Mike Dierken
    Oct 6, 2004
    • 0 Attachment
      For me, once I understand the use cases (alice buys from bob, alice pays bob
      via ted) we could work on identifying resources.
      I actually think it's pretty reasonable and doable to express via REST, even
      with the anonymity and migrating 'nodes'.
      But I understand that it can be pretty difficult to take an existing
      description of an approach & unwind it and re-map to another architecture.

      ----- Original Message -----
      From: "Ryan Fugger" <rfugger@...>
      To: "S. Mike Dierken" <mdierken@...>; <rest-discuss@yahoogroups.com>
      Sent: Wednesday, October 06, 2004 12:33 AM
      Subject: Re: [rest-discuss] REST for P2P application?

      > On Tue, 5 Oct 2004 22:10:10 -0700, S. Mike Dierken <mdierken@...>
      > wrote:
      > > I'm lost. Perhaps if your applications was re-phrased using 'resource'
      > > rather than 'node' and 'object' I'd be able to understand.
      > Gotcha.
      > >
      > >> Due to anonymity requirements, the originating node cannot know where
      > >> all
      > >> the pieces of an object are (for example, a query or a transaction),
      > >> nodes usually cannot know where the object originated.
      > > What is an 'originating node'?
      > Ripple is a P2P trust network of software node-agents living on http
      > servers. To make it more clear, I'll just use the word "hosts" from now
      > on, even though that's not technically what I mean.
      > > Is that an HTTP client?
      > Yes, and server.
      > > To hide the location of the pieces, you have a single identifiable
      > > resource and clients don't
      > > know what lays beyond.
      > No, for example, a transaction involves a chain of hosts, but each host
      > only knows about the host directly before and after it. What I'm
      > struggling with is that it seems so convenient to give the transaction a
      > single name, but I can't identify it with a single host for privacy
      > reasons, and so I can't give it a single URI. Using a proxy doesn't work
      > either, unless everyone used the same one, which is a central point of
      > failure and therefore bad.
      > >> No, different hosts each holding their aspect of distributed objects is
      > >> integral to the application.
      > > Okay, but how can you have different hosts holding aspects of a single
      > > distributed object but not tell any client where those different aspects
      > > are located??
      > They only tell neighbouring host on the trust network, ie, those they
      > trust. All the bits can be found by passing queries down and back up the
      > chain of trusted hosts, without the requesting host ever knowing exactly
      > where the queries go.
      > >
      > >> A server hosts multiple nodes that each communicate with many
      > >> neighbouring
      > >> nodes ("friends" with which they can exchange IOUs).
      > > Okay - each 'node' is a resource. Clients communicate with this 'public'
      > > node. Clients do not know about neighboring nodes. The resource is a
      > > type of aggregating proxy for those other nodes.
      > Sounds about right. It may be informative to say also that clients are
      > the means through which the owner of a node accesses his node and gives it
      > instructions, whether in person (opening an account with another node), or
      > automatically (accepting payments through an ecommerce site).
      > >
      > >> Nodes may also communicate with a strange node to pay or receive
      > > from that node.
      > > Okay - each 'node' may also be a client and can transfer payment to
      > > resources or request payment from other resources. In order to receive
      > > unsolicited transfers, a node needs to have an identifier and the sender
      > > of payment needs to know what that is.
      > Right. The node identifier being a resolvable URI makes perfect sense --
      > until the node moves to a different server!
      > >
      > >> Payments are made by passing IOUs along paths connecting two strange
      > >> nodes
      > > in the network of neighbours.
      > > Ah... a chain of proxies... and this chain is used to obscure the legal
      > > entity requesting a transfer?
      > Not primarily, although that might be a side benefit, I don't know. The
      > chain of intermediaries is literally necessary to make the payment with
      > IOUs. For example, would you ship me something if I paid you with my
      > digitally-signed IOU? Of course you wouldn't. But you might if we could
      > find a common friend who would vouch for my IOU by promising to make good
      > on it himself if I didn't. Ripple works by finding chains of these
      > intermediaries.
      > --------------
      > I'm actually beginning to feel like a bit of a troll on this list, because
      > the more I type about this, the more I become convinced that not only is
      > REST not particularly suited to my application, but HTTP isn't really
      > either. Stateful bi-directional peer connections seem like the right fit
      > (been reading about BEEP - http://beepcore.org/). Ripple really seems to
      > want to be a closed, relatively tightly-coupled private network, despite
      > my best efforts to make it otherwise. So while I'm still open to having
      > my mind changed, I won't ask the list to delve any more into my arcane
      > little project unless it truly interests you as a "hard case"...
      > I very much appreciate the responses. Thanks Mike. I may be back for
      > some help with a RESTful client API, although I think that will be much
      > easier.
      > Ryan
    • Show all 19 messages in this topic