<p>Network addresses shall be opaque blobs, which may in practice consist of
an IP4 address plus some variable precision additional subnetwork address,
or may consist of an IP6 address some variable precision additional
subnetwork address, or some unknown future implementation for some non
standard network.. Only the lowest level software knows or cares. To
everything above, a network address is an opaque blog of unknown length
and unknown internal format, which is by default non human readable and
non human writeable, though some subtypes may be human readable and
writeable. <br/>
</p>
<p>There is a member function which may yield a derived class that is human
readable and writeable, but likely yields the null pointer. The
additional subnetwork information is used to handle the now common case
that there are many entities on a single machine.<br/>
</p>
<p>Which is to say, network addresses are implemented as a set of classes
whose internal details are as far as possible hidden, derived from an
interface base class, and all other software calls the methods of the
interface base class.</p>
<p>Similarly for public keys, and indeed everything else. Exposing the
internal structure of network addresses and port numbers and so on and so
forth to everything was a huge mistake.</p>
<p>The base classes of these heterogenous objects with common behaviors are
of course, abstract classes. Our networking system shall be built on
top of abstract classes, unlike the existing system where class internals
are exposed.<br/>
</p>
<ol>
<li>
<p>Given a network address, a member of our opaque classes, be able to
send unreliable messages in the clear. UDP equivalent, but as
yet no TCP equivalent. At this point, we make absolutely no
attempt to deal with NAT barriers.</p>
</li>
<li>
<p>Client knows server public key and server network address.
Client and server construct strong shared secret despite the possible
presence of an active man in the middle adversary. To deal with
replay attacks, establish shared global time and shared probabilistic
offset from that time. (Server and client agree to disagree on global
time, but know how big a disagreement they have. Everyone tries
to have their shared global cryptographic time to be the median
offset)<br/>
</p>
</li>
<li>
<p>Client knows server network address and server public key.
Client and server know username and weak password or hash
thereof. Client and server construct strong shared secret
despite the possible presence of an active man in the middle
adversary.</p>
</li>
<li>
<p>Client knows server network address but does not know server public
key, or anything that would allow it to reliably identify the server
public key. Client and server know username and weak password or
hash thereof. Client and server construct strong shared secret despite
the possible presence of an active man in the middle adversary.</p>
</li>
<li>
<p> Unite all the above code as derived from a single abstract base
class, which caches the connection between client and server,
regenerates a shared secret as needed. </p>
</li>
<li>
<p>We define the class “connection”. A connection is a member of a
class containing shared secret and network address information.
We have not yet, however, got to a concept replacing port number, or
even got anywhere near being able to build user interface. We have
however, placed what we need for encryption where it belongs, at close
to the most foundational level. Encryption first, port number
equivalent and TCP equivalent on top of encryption. Then we get
to UI later, and then we will get to how to know these public keys, or
hashes of rules identifying public keys. </p>
</li>
<li>
<p>The encrypted connection, and, finally ports. The encrypted
connection is a connection with encryption information. Packets arrive
with position information as to the order in which they were sent,
though not all packets arrive, and not in original order and some are
garbled. Packets are authenticated then decrypted and assigned to
their appropriate port, so when they get to the port they are
authentic, correct, and have known positions within the port stream
and connection stream, though not all make it to the port, and not in
order.</p></li></ol>
<p>Ports are an encrypted connection plus <ahref=".%5Cprotocol_negotiation.html">protocol
agreement information</a>. For every connection, there are usually
two ports, one to manage the creation and destruction of ports and the
connection, and at least one to actually transport useful information.</p>
<p>A port references an encrypted connection, probabilistic information
about the current state of information exchange, and a protocol
description.</p>
<p>Thus, the very first protocol is a protocol to negotiate new ports
and thus new protocols, and to shut down this connection.</p>
<p>This could potentially create additional round trips, thus we have
have a general rule for collapsing round trips, "Assuming you agree to
the proposed protocol, here is first packet of that protocol." If
server does not agree, then client adjusts its assumptions about
server state.</p>
<p>Each side transmits on its best guess about the state of the other,
but can back up to an earlier point in the state machine if such
provisional transmissions are revealed to be in error.</p>
<p>In the present tcp implementation, the client is a state machine, and
the server is a state machine, and they try to tend to corresponding
states. Thus the client state embodies knowledge about the server
state. I suggest that instead the client maintains a list of possible
server states, and as events happen, updates the weightings of each
guess as to server state.</p>
<p>The client also needs to model server guesses about client state, and
the server needs to model client guesses about client state, an
estimate about an estimate.</p>
<p>Server ids contain a link to a list of protocols they accept, signed by an authority responsible for those protocols. Protocols are identified by stream of bytes, in which zero or bytes have their high bit set, the stream being terminated by a byte with the high bit cleared. Lists of protocols are maintained by the system responsible for the list of server ids, with new lists only being added by a human decision at the distinguished proposer.</p>
<p>These lists only identify protocols capable of setting up a connection. When a connection is made, the client offers a list of subprotocols that it wants, and the server accepts the first one in the list that it recognizes and wants to handle. We will have no central authority for such subprotocol lists. Anyone can roll there own, and in the event that there come to be a lot of them, the implementer just chooses an identifier long enough and random enough that the risk of collision is small.</p>
<pstyle="background-color:#ccffcc;
font-size:80%">These documents are licensed under the <arel="license"href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
