W3C home > Mailing lists > Public > public-interledger@w3.org > November 2015

Re: Routing (was Vetting connectors)

From: Ryan Fugger <arv@ryanfugger.com>
Date: Tue, 10 Nov 2015 12:40:17 -0800
Message-ID: <CAD83BY2zXmM+BfiQX+m3EGfzfY6fREZXwxiHMnoSKPW=y0buvA@mail.gmail.com>
To: Interledger Community Group <public-interledger@w3.org>
On Tue, Nov 10, 2015 at 2:02 AM, Lucas Huber <lh@codoo.io> wrote:

>
>
> How this flood search should work from the payee? How does the payee know
> to start searching?
>

The payer would have to send a message to the payee to initiate it.  Even
if the search was only going to be conducted from the payer end, the payee
would probably have to know about it to recognize that the transaction was
meant for them when the search messages reached their node.  I suppose it
would be possible to encrypt something with the payee's public key and
include it in the search, but then every connector would have to attempt to
decrypt every search message they received to see if it was for them...

>
>
> How the nodes/connectors are distributing informations and updates over a
> protocol seems to be over rather complicated in comparison to a shared
> permissioned ledger. Of course a permissoned ledger does need a certain
> amount of centralisation, but also the protocol solutions requires a
> minimum of governance per cell.
> http://archive.ripple-project.org/Protocol/CellStructureRouting
>
> In the protocol every node has the possibility to introduce other nodes to
> the cell, is that correct? Wouldn't be that a general security risk?
>
>
>
>
Cell structure routing is just a sketchy idea I had years ago.  I'm not
sure how useful or feasible it is, but I linked to it in case it helps
someone to come up with a truly good idea :)


>
> * <http://moneygrid.net>*
>
> Am 09.11.2015 um 21:36 schrieb Ryan Fugger:
>
> I should add that the most basic private routing scheme would just be a
> flood search, possibly from both the payer and payee ends simultaneously.
>
>
>
Received on Tuesday, 10 November 2015 20:41:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 10 November 2015 20:41:06 UTC