The Auto-Peering discussion is getting a bit into the weeds and @sappenin made me realize that we haven’t been clear enough with the use case for that feature. I’m going to take a stab at articulating some high level goals and disaggregating terminology like @adrianhopebailie did in the Settlement Architecture thread.
Goals
Make the Interledger network easy for new users to use by providing tools that find and connects to providers on the network with minimal configuration
Help expand the Interledger network by simplifying the peering process for ILSPs/providers/connector operators
Use Cases
I’d suggest that we differentiate between three types of flows / use cases (I’m not wedded to the specific terms so feel free to suggest a rename if you feel more strongly about it):
Auto-Peering - You run a node and it automatically connects to other nodes as a peer. You send route updates to one another and treat one another as equals.
Easy Peering - You run a node and want to connect to a specific other node. You interact with your node to indicate you want to peer with them, maybe get a specific string to give to the other operator (your domain name or that plus a one-time-use code), they put that string into their node, and you’re peered.
Open Signup - You run a local/personal node like a moneyd and want to connect to the Interledger network. It automatically discovers (using a to-be-defined discovery mechanism) nodes to connect to and registers / signs up with them as a child. They might send you route updates, but they do not accept route updates from you.
Open questions:
Is “auto-peering” possible with our current routing protocol?
Is “easy peering” a goal or is it okay for peers to manually configure their systems with all of the relevant options?
Would a “local/personal node” have a publicly accessible URL? Should we use a protocol like BTP (which uses WebSockets) to avoid this requirement, or should every node be run on a server with a public URL?
Can more than one of these flows be handled by a single API or does each require a separate API? If there are multiple, which one(s) do we need to work out now?
I think coming to some agreement on the goals and use case(s) first would help us determine details like authentication mechanisms.
I think we must support nodes without publicly accessible URLs.
While it’s not a problem for end users/clients using hosted accounts, it presents a major problem for self-hosted clients, and makes connecting to ILP much more burdensome. Client software would either require a public port, likely requiring it to be hosted on a remote machine that the client controls (which is not easy/accessible to setup, and probably isn’t free), or requires a more trusted forwarding service like LocalTunnel, which seem to be either (a) unreliable, or (b) cost money. Neither is great.
While hosted accounts may be necessary for any significant end user adoption of ILP, the network is simply not there. In the short term, growth of the network will likely require buy-in from the crypto community, since ILP presents a compelling value proposition for exchanging and moving value in crypto with limited trust. And to get buy-in from the crypto community, self-hosted solutions must be supported.
I’d also add, many current clients on the network are self hosted, and I don’t see a compelling argument for why that should be broken/deprecated.
Perhaps ILP connectors could voluntarily list their discovery details in a neutral distributed network that sits adjacent to the ILP network. One possibility would be to use a smart contract as a type of certificate authority on a Federated Byzantine Agreement network for this. The ILP connectors would then just have to read this Federated Byzantine Agreement network to learn about new peers, changed/expired credentials, supported currencies, etc.
Personally, I am opposed to auto-peering in most situations because Interledger is effectively a credit network that relies on maintaing relationships. Auto-peering could be supported by ledger, wallet, and local services, but should be disabled by default. Disabling automatic-peering by default might seem counterintuitive, but would otherwise broaden the denial-of-service attack surface.
Attackers could potentially create a number bogus connections that lead to payment failure which in turn damages the reputation of honest connections. The prolonged exposure to a denial-of-service attack encourages a sender to find more reputable connections and conceivably terminating unreliable connections altogether. Under these assumptions, I believe automatic-peering is infeasible at scale; however, it could prove to be useful within certain sub-network applications.
I think “easy peering” makes a lot more sense within the context of Interledger, since it is just a simplification of the current method of peering, whereby users seek and maintain reputable connections. It is very important that these connections are created with reasonable ledger-specific default settings, but still seems feasible within the exhaustive configuration options provided by moneyd. The acquiescent nature of “easy-peering” could pose limited security risk, but this could be minimized by an alert system set up by the passive peer, signaling new connections.
Interledger is currently burdened by mental costs associated with peer configuration, so I believe this should be a goal. Manual configuration should still be recommended, but the current method of peering is a significant psychological hurdle. Currently, we are advertising “simple” as if it is as simple as using TCP/IP, not understanding the low-level details during setup. The stakes are arguably higher on ILP, but can you imagine manually setting up connections to access Twitter?
I am not sure what open signup accomplishes – could you elaborate more on this?
Excellent points! Based on this thread, I’m leaning towards:
Auto-Peering -> non-goal, based on the reasoning @ekrenzke outlined
Easy-Peering -> nice to have, but maybe not super high priority until we have a manual flow we’ve tried out and are trying to automate
Open Signup -> keep using BTP for this, in order to support non-server clients as @kincaid mentioned
Unless others vehemently disagree with these conclusions, this suggests that we don’t have any more to do on this right now and should instead focus on finalizing settlement and the ledger / settlement system abstraction.
I agree with the above arguments - except, regarding the open sign-up idea, do connectors get auto-discovery from the BTP? I read in the documentation that " A well-defined standard for automatic discovery of peers has not been taken up in the network. As such this spec has been deprecated to avoid confusion." Or is the auto-discovery a separate and long-term goal apart from BTP? Having some certificate authority style system should provide a way to achieve auto-discovery while also allowing non-server clients.
Good question / point. BTP has been used for “open signup” but does not provide the discovery function.
For node discovery, we could use:
A hard-coded list in the implementations
A list hosted on Github or interledger.org that connector operators could submit a PR to to add their nodes
A centralized API that would return a list of nodes with some uptime or other quality requirements
A gossip protocol in which nodes broadcast their presence to one another and some hardcoded bootstrap nodes that clients would connect to to get the full list
A blockchain or consensus system that nodes can insert themselves into
The question about how centralized or decentralized this discovery process should be hinges a bit on a) whether the list of nodes should be raw and uncensorable or curated b) what type of external dependencies we will accept c) how large we expect the list to be.
My hunch is that the logic for how a new node will select which other nodes to connect to will be slightly harder to “get right” than how the new node gets the full list in the first place (because that logic dictates who will get the new node’s business).
I completely agree with your points - the crucial part will be a node operator determining how to select which nodes they connect to.
Depending on how private the information is, an ILP node operator could leverage the certificate authority system to publicly express what nodes it has chosen to connect to / accepted connections from. This would give newcomers to the network a direct map of the trustlines that propagate through the network, and also a global history of how these trustlines have changed over time. This would also be useful for aiding data collection on the network, in particular for analysing disjoint sections of the ILP network.
The certificate authority could also be used as the first point of entry that new nodes use to issue a signal to express their intent to peer with a particular node. This would allow ILP connectors to lock down their infrastructure to only peers they already are connected with. Then, periodically, the ILP connectors can read the certificate authority and optionally decide to open up new connections to new nodes.
ILP connectors could also leverage the certificate authority to express a global signal about changes in their live public keys or wider infrastructure configuration.
I believe such a certificate authority system should be designed completely independently of any particular centralised/decentralised consensus system underpinning it. Also, having this certificate authority system as a modular element away from the ILP node would make it easier to add/change functionality such as authentication strategies or information about supported assets to it overtime without largely effecting the core ILP implementation.
I’m going to write up a fuller analysis that goes into much more detail, including an analysis of the tradeoffs of the underlying centralised/decentralised consensus system.
you’re peered.
