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.
- 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
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
moneydand 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.
- 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.