Diagram: Distributed architectures comparison

[Romualdo Grillo]

I have created two new diagrams, I want to discuss them end eventually
put them in the wiki.

1) "Central server" vs Cluster vs P2P:

https://docs.google.com/drawings/edit?id=1QOPSGzuxbtzvsPWYEmabuNn3p7lDXjanggeYM3eCPGI&hl=en

2) Direct vs API vs Embedded:

https://docs.google.com/drawings/edit?id=1Q2xBbgtsIp5oPL4p8Kb41t_qOTBINcnpf3v4BWJdXUU&hl=en

Improvements and comments are welcome.

Ciao

[Thomas Sherlock]

I appear not to have access to these diagrams.

> --
> You received this message because you are subscribed to the Google Groups "Ripple users" 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.
>

[Romualdo Grillo]

On 29 Nov, 18:03, Thomas Sherlock <T...@Ramruva.com> wrote:
> I appear not to have access to these diagrams.

Sorry, I forgot to share.
Now should work!

[Ryan Fugger]

On Mon, Nov 29, 2010 at 8:38 AM, Romualdo Grillo <rg...@tin.it> wrote:
> I have created two new diagrams, I want to discuss them end eventually
> put them in the wiki.
>
> 1) "Central server" vs Cluster vs P2P:
>
> https://docs.google.com/drawings/edit?id=1QOPSGzuxbtzvsPWYEmabuNn3p7lDXjanggeYM3eCPGI&hl=en
>

Cool. P2P is problematic in that the user most likely won't be able
to maintain a constant network connection, nor maintain their own data
reliably (backup, etc.). So, while technically possible, I don't see
much of a case for it in a serious Ripple network.

> 2) Direct vs API vs Embedded:
>
> https://docs.google.com/drawings/edit?id=1Q2xBbgtsIp5oPL4p8Kb41t_qOTBINcnpf3v4BWJdXUU&hl=en
>

I would distinguish between the following two types of APIs:

1. A merchant API, like paypal's API, that allows merchants to accept
Ripple payments from their sites. This is what you are illustrating
in the second case. An example would be if Ripplepay implemented
OpenTransact. I don't think I would call this a "Ripple API", since
there is probably not much Ripple-specific about it.

2. A Ripple transaction API that allows multiple client applications
to create and/or register mutual-credit accounts on a Ripple
transaction server that processes payments initiated by those clients
(or possibly others, although that might not be very useful) and
returns the results to the clients whose users were involved in the
transaction. This would probably be the easiest way to allow users of
different Ripple implementations to make accounts with and pay each
other -- get them all to use the same transaction server. Ripplepay
could be a client of such a server.

I'm not sure where Rivulet fits into this scheme, or if it disrupts it
somehow...

Ryan

> Improvements and comments are welcome.
>
> Ciao
>

[Thomas Hartman]

I agree that p2p seems like a bit of a pipe dream / energy suck at the moment, versus concentrating on things with a more immediate payoff.

However, I do see a potential for p2p at some nebulous future point, with the following use case.

Which is basically if a network of distributed ripple nodes gets to be kind of like the banking system we currently have, with most users just having accounts with their local "ripple banker" and banks routing payments amongst each other.

So in that case, if ripple took over the world, we might find ourselves in a situation that feels similar to the one we have now, except no central bank, no single point of failure, and bias towards more smaller credit disruptions rather than massive one-off catastrophes that then have to be bailed out and result in heads i win / tails i win too dynamic we currently have with increased centralization of wealth and power to the finance players through the central bank.

[Ryan Fugger]

I guess I also don't see p2p as fundamentally different technically
than distributed clusters. If anyone can run a cluster server, they
can run one only for themselves on their home machine or even their
phone if they want to. It's just an edge case.

Ryan

[Romualdo Grillo]

P2P

Reflecting I think I a gree with both, Thomas, Ryan.
1)P2P is not interesting at the moment
2)P2P technically is just an edge case of "Clusters".is agree with
those two points
Although there is a plus in P2P , maybe less important.

3)With P2P you do not need to trust an external server, you only need
to trust your personal device (PC or Mobile).


So I think the "roadmap" slide in this introductory video http://screenr.com/c5K
should be changed in next version.

Even if P2P is not feasible solution it is an interesting hypothesis,
and a concept familiar to almost everyone, so it is interesting to
compare it with other solutions.
I will add those notes to the diagram, feel free to correct me or add
more notes.

Romualdo

[Romualdo Grillo]

Direct vs API vs Embedded:

Ryan now I see the difference between 1 and 2!
Check out the new version, I left some text in orange because I'm not
good at "inventing" names, correct them if you want.

https://docs.google.com/drawings/edit?id=1Q2xBbgtsIp5oPL4p8Kb41t_qOTBINcnpf3v4BWJdXUU&hl=en

Ciao Romualdo

>
> >https://docs.google.com/drawings/edit?id=1Q2xBbgtsIp5oPL4p8Kb41t_qOTB...

[Ryan Fugger]

On Wed, Dec 1, 2010 at 9:19 AM, Romualdo Grillo <rg...@tin.it> wrote:
> 3)With P2P you do not need to trust an external server, you only need
> to trust your personal device (PC or Mobile).
>

Right. P2P is the case where you run your own server on a personal device.

I have considered a network design where everyone used their own
personal devices as servers, where you could delegate responsibility
for conducting transactions on your behalf to a neighbouring
device/server when you went offline, and where your profile would be
backed up at your neighbours so you could hook in with any new device
and retrieve all your data, but that was very complicated and fraught
with problems, even at a theoretical level.

Ryan

[Sepp]

Regarding P2P, I think we should look at the set-up that is being
developed right now in the Diaspora project, where nodes link up to
form the whole network. Everyone can make their own node (if they are
capable and have access to a server) or they can join some existing
node.

https://joindiaspora.com/

Diaspora is in Alpha release now, and is being actively developed. It
seems the most likely candidate for a distributed social network to
emerge, and certainly there could be synergies between it and Ripple.
It would also get us into the P2P area, without Ripple having to do
all the work.

Sepp

On Nov 30, 11:23 am, Ryan Fugger <rfug...@gmail.com> wrote:

> P2P is problematic in that the user most likely won't be able
> to maintain a constant network connection, nor maintain their own data
> reliably (backup, etc.).  So, while technically possible, I don't see
> much of a case for it in a serious Ripple network.

And Thomas Hartmann adds:

[Romualdo Grillo]

I have updated both diagrams.

https://docs.google.com/drawings/edit?id=1QOPSGzuxbtzvsPWYEmabuNn3p7lDXjanggeYM3eCPGI&hl=en

https://docs.google.com/drawings/edit?id=1Q2xBbgtsIp5oPL4p8Kb41t_qOTBINcnpf3v4BWJdXUU&hl=en

Comments?
Is there a voluntary to translate those tables in wiki tables ?

Ciao

[Daniel]

Wow, those look great... In the fully p2p scenario, some users may be
satisfied by using a proxy, so some servers may still host multiple
nodes, although this isn't a huge deal.

[Daniel]

Agreed overall... It would be great eventually to have a distributed
social network plugin that lets people quickly and easily hook up their
social networks as functional credit routing networks...

[Evgeni Pandurski]

On Thu, Dec 2, 2010 at 12:33 PM, Daniel <dan...@ripplexchange.com> wrote:
> Wow, those look great... In the fully p2p scenario, some users may be
> satisfied by using a proxy, so some servers may still host multiple
> nodes, although this isn't a huge deal.

In my opinion, distributed scenario is very hard to be done right. Take
the current banking system for example -- it is a real mess and is not
really distributed at all. The biggest problem I see is that making data
storage and computations distributed does not make the system loosely
coupled in terms of trust. To achieve a loose coupling of trust (and therefore
infinite social-scalability) a very clever set of secure protocols must
be developed and widely accepted. This, in my view, is really, really hard.
Over the years, Ryan have developed a very concrete idea what these
set of protocols should look like. Nevertheless, this is a very complex matter
and it is not clear if these solutions will be feasible in practice.

Evgeni

[Thomas Sherlock]

Along the lines of P2P, there is also http://dot-p2p.org/, which is a free, decentralized, and open Bit-torrent-based DNS p2p system still under development.

And then, you probably know Michel Bauwens' http://blog.p2pfoundation.net/

Tom

> --
> You received this message because you are subscribed to the Google Groups "Ripple Project" group.

[mcn...@ml1.net]

> coupled in terms of trust. To achieve a loose coupling of trust (and therefore
> infinite social-scalability) a very clever set of secure protocols must
> be developed and widely accepted. This, in my view, is really, really hard.

Zuckerberg wants to agree with you; I can't find the interview right
now (possibly this http://www.wired.com/epicenter/2010/05/zuckerberg-interview/)
but when talking about Diaspora he said that friend-of-a-friend trust
relationships and beyond, i.e. anything beyond the immediate friend
circle are hard to model even on a single server solution like
Facebook and therefore he had no regrets about donating $$$ to
Diaspora as he didn't consider Diaspora competition.

[Romualdo Grillo]

1)I have updated the diagrams following your comments.
https://docs.google.com/drawings/edit?id=1QOPSGzuxbtzvsPWYEmabuNn3p7lDXjanggeYM3eCPGI&hl=en
https://docs.google.com/drawings/edit?id=1Q2xBbgtsIp5oPL4p8Kb41t_qOTBINcnpf3v4BWJdXUU&hl=en
2)I have inserted them in the wiki
http://ripple-project.org/Main/DistributedArchitectures
http://ripple-project.org/Main/ModulesInARippleSystem
3)I will try to better link those diagrams to other contents in the
wiki.

Comments are welcome
Romualdo

[Romualdo Grillo]

I have finally created a kind of "Map" of Ripple systems, toghether
with their development status, based on the diagrams previously
discussed.

http://ripple-project.org/Main/ModulesInARippleSystem

Any comment or correction, improvement is welcome.
Romualdo

On 7 Dic, 19:43, Romualdo Grillo <rg...@tin.it> wrote:
> 1)I have updated the diagrams following your comments.https://docs.google.com/drawings/edit?id=1QOPSGzuxbtzvsPWYEmabuNn3p7l...https://docs.google.com/drawings/edit?id=1Q2xBbgtsIp5oPL4p8Kb41t_qOTB...
> 2)I have inserted them in the wikihttp://ripple-project.org/Main/DistributedArchitectureshttp://ripple-project.org/Main/ModulesInARippleSystem

[Daniel]

Awesome! Or should I say: Ottimo!

In your hypothetical interserver Ripple system, you could optionally
have a third dude using a client with an embedded server a la Rivulet.

I really like the legend.

I made a few minor edits to this and the "distributed architectures" page.

[Romualdo Grillo]

> Awesome! Or should I say: Ottimo!
>

Thanks Grazie

> In your hypothetical interserver Ripple system, you could optionally
> have a third dude using a client with an embedded server a la Rivulet.

John Paul Lewicke said his software Rivulet actually falls more under
API than embedded scheme.
So the "embedded" alternative seems now less important.
Do you think I should add it anyway ?

Ciao

[Daniel]

Oh, if it's already conceived as an API then there isn't necessarily an
advantage in adding "embedded" anyway... (Eventually one could have a
Ripple library or something, but for now that doesn't seem like an
urgent need.)

[Romualdo Grillo]

Daniel Thanks for your edits, my English is quite bad.

[Daniel]

Nonsense! Probably better than any of our Italian, and certainly quite
understandable and communicative.