Implementing Ripple with the Web
Melvin Carvalho
the latest web standards.
Would I be right to say that the 40 points here define the high level protocol?
http://ripple-project.org/requirements.html
If I go through the 40 points and translate them to web standard
language perhaps we can extend ripple to the web.
Example
========
1.1. Nodes are software agents for parties participating in Ripple.
Nodes may act automatically on behalf of their owners.
> There is an existing agent description in the FOAF syntax -- http://xmlns.com/foaf/spec/#term_Agent
1.2. Nodes exist on internet-connected servers.
> Done
1.3. A node must have an address where other nodes can send
communications (or at least discover how to send communications).
> This would involve linking an agent to a ripple enabled endpoint
1.4. Nodes must be active (on) at all times, barring external circumstances.
> This is not promised on the Web, but can be a requirement of the endpoint.
1.5. Ripple nodes must be able to immediately acknowledge and, where
possible, act upon communications from other nodes.
> Should be possible to write up the message formats.
1.6. Nodes must be capable of performing all Ripple functions with any
node on the same server or a different server.
> Should follow from (1.3 & 1.5)
1.7. The owner of a node may be a person or a group of people.
> Done
1.8. There must be a way for a node to prove the identity of its owner.
> Done verified by lookup on the webpage (DNS)
1.9. A node must be able to authenticate and encrypt its
communications to other nodes.
> Auth is a hard problem on the Web with many possible solutions. Perhaps we can select one, e.g. PKI
1.10. A node must be able to move to a different server.
> This is a given on the web via DNS but perhaps need to look at data portability
It may be possible I can go through all 40 points, build up an analogy
and reference implementation then release it as open source.
Ryan et al. Do you think this approach is feasible?
Melvin Carvalho
> This may not be directly inherent, but there is an effort underway to
> define what I think may become a high level standard for using the
> internet as a payment system...
Sure web credits is a very simple 1-2 page spec defining an IOU.
To build something like ripple and clearing is a bigger project.
Essentially all it comes down to design wise is to make internal
ripple identifier into web identifiers. Eg a user can become a user
URI for that server or email address.
Then we just try and map out the components and connect it all together ...
>
> Melvin Carvalho wrote:
>
> I've started to develop a network architecture for the exchange of
> tokens between agents, hopefully to be standarized in the W3C Web
> Payments group. Codename "Web Credits".
>
> http://webcredits.org/
>
> On Feb 10, 11:17 am, Melvin Carvalho <melvincarva...@gmail.com> wrote:
>> I'm interested making a parallel system to ripple to integrate with
>> the latest web standards.
>>
>> Would I be right to say that the 40 points here define the high level protocol?
>>
>> http://ripple-project.org/requirements.html
>>
>> If I go through the 40 points and translate them to web standard
>> language perhaps we can extend ripple to the web.
>>
>
>> It may be possible I can go through all 40 points, build up an analogy
>> and reference implementation then release it as open source.
>>
>> Ryan et al. Do you think this approach is feasible?
>
> --
> You received this message because you are subscribed to the Google Groups "Ripple Project" group.
> To post to this group, send email to rippl...@googlegroups.com.
> To unsubscribe from this group, send email to rippleusers...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/rippleusers?hl=en.
>
Apostolis Xekoukoulotakis
Sincerely yours,
Apostolis Xekoukoulotakis
Ryan Fugger
thinking was definitely along those lines. (I forgot that
requirements page even existed, thanks for finding it!) The reason I
chose not to use HTTP in my protocol designs ultimately was that HTTP
is fundamentally a client-server protocol, not a peer-to-peer
protocol. The client requests something, the server delivers it. I
saw Ripple connections more long-lasting data connections between peer
servers, with requests and responses going in both directions. Now,
certainly, we could use separate HTTP connections in each direction,
but that seemed inefficient.
Furthermore, HTTP seems built for serving data that is meant to be
universally accessible and usable in many ways. A Ripple protocol, it
seems to me though, would be a fairly rigid set of interactions with
data that is meant to be private and used explicitly only for that
purpose. If a server wanted to make its account data accessible over
HTTP for other uses by its clients, then it could do that separately
from the Ripple protocol. HTTP is for data sharing and mashing-up;
Ripple is for performing multi-hop value transfers. There doesn't
seem to be a lot of added value there. I could be wrong, though.
Ryan