OC-Copper/protocol.1

Copper Protocol :: Hierarchial Gateways
 20kdc, 2017

"Hierarchial Gateways" are a system for ISP-like bodies to prevent their
 users from causing havoc.
They are simply base low-level Copper nodes with two interfaces and the
 following rules:

 For the FROM address:

If it's on the parent side, reject if it's prefixed with hostname .. "/",
 otherwise prefix it with "<".
If it's on the child side, reject if it's prefixed with "<",
 otherwise prefix it with hostname .. "/".

 For the TO address:

If it's on the parent side, reject unless prefixed with hostname .. "/",
 otherwise remove that.
If it's on the child side, reject unless prefixed with "<",
 otherwise remove that.

 For the packet's general routing:

If it's on the parent side, run the rules above on the addresses,
 and forward to child side if not rejected.
If it's on the child side, run the rules above on the addresses,
 and forward to parent side if not rejected.

Notably, the hops field should be incremented as if going through a normal routing node -
 this prevents system misconfiguration from causing a complete meltdown.

This introduces a simple hierarchial structure that does not require any
 support code apart from in the nodes supporting the hierarchy.
There are only two downsides:
 1. Nodes connected to two gateways
     could have multiple addresses but believe they only have one
 2. Nodes behind two nested gateways can address themselves in two ways

However, this should all work out as long as people make a deliberate
 effort not to notice the hierarchial structure system in their code.

Specifically, problem 2 only causes an issue should some nodes not
 directly involved in gateway activities be
 attempting to parse hierarchial addresses.

Possible uses of hierarchial gateways:
1. A safe (untrusting of servers in it) inter-server networking hub,
    following the same protocol as everything else in Copper,
    unlike certain competitors
2. ISPs within servers, perhaps those using the hubs