4552Re: [rest-discuss] REST for P2P application?
- Oct 6, 2004For 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@...>; <firstname.lastname@example.org>
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@...>
> > I'm lost. Perhaps if your applications was re-phrased using 'resource'
> > rather than 'node' and 'object' I'd be able to understand.
> >> 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
> 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
- << Previous post in topic Next post in topic >>