P2P Chat Facility


The table below summarizes the capabilities that XLattice's p2p chat facility is expected to have at revision number n.n.n . In other words, these are the milestones in the implementation of p2p chat.

The descriptions below describe the protocol in IRC (Internet Relay Chat) terms, but in implementation it may more closely resemble Jabber (XMPP).

This table should be understood as an exercise in planning the implementation of a chat facility. This work is not underway at this time.
n n n capability at this revision number
0 0 0 Users can download/update basic software from XLattice server using Webstart protocol.
0 0 1 Node can generate public/private key pair, the node's cryptographic ID. This is entirely automatic, with no user involvement; if there is no crypto ID when the software begins running, the software generates a key pair.
0 0 2 Register IP addresss with XLattice server, get node ID from the server. As soon as the software has been installed and a node ID has been generated, the node registers itself with the server.
At this stage, the XLattice server is running a node registry binding node IDs to public keys ("cryptographic identities") and IP addresses.
0 0 3 Node can get list of neighbor IP addresses from XLattice server (no user involvement).
0 0 4 Node can establish contact with neighbors, send keep-alives.
0 0 5 Node-to-node plaintext messaging. No user involvement.
0 0 6 DH handshaking, session keys.
0 0 7 Encrypted none-node messaging.
0 1 0 Authentication cluster formation by neighbor nodes (automatic, no user involvement, but list of neighbor nodes and IP addresses available to user).
0 1 1 User name (nick) selection, confirmation by authentication cluster.
0 1 2 User registration with cluster, nick/public key binding.
0 1 3 Plaintext user-to-user (nick-nick) messaging within the cluster.
0 1 4 Encrypted nick-nick messaging within the cluster.
0 1 5 Cluster capable of assigning node ID to user.
0 1 6 Cluster capable of providing neighbor list to user.
0 1 7 XLattice server sets up cluster registry binding the cluster name, cluster ID, and a possibly time-varying set of crypto identities (node public keys)
0 1 8 Cluster gets cluster ID from XLattice server.
0 1 9 Cluster capable of operating a node ID registry
0 1 10 XLattice server begins referring users to cluster(s) for node ID assignment.
0 2 0 Authentication cluster capable of assigning chat channel names. That is, the nodes in the cluster can agree upon a common, shared name for a channel.
0 5 0 Supercluster node ID assignment capability.
0 5 2 Superclusters capable of referring users to clusters for node ID assignment.
0 5 3 XLattice server refers new users to supercluster(s) for node ID assignment.
0 2 1 Users (nicks) capable of creating channels by application to their cluster.
0 2 2 Channel creator can assign channel ops, that is, assign privileged status to other nicks.
0 2 3 Users (nicks) can join channels.
0 2 4 Clusters are now operating a dynamic channel registry relating channel names, creators, channel ops, and nicks
0 2 5 Plaintext channel messaging within the cluster.
0 2 6 Encrypted channel messaging within the cluster.
0 3 0 XLattice server capable of providing clusters with list of neighbor clusters.
0 3 1 Cluster-to-cluster messaging, communications between authentication clusters, initially keep-alives, then messages encrypted with session keys.
0 3 2 Byzantine supercluster formation: clusters capable of forming authentication groups with neighboring clusters
0 3 3 XLattice server sets up supercluster registry
0 3 4 Superclusters can register with XLattice server to get supercluster ID.
0 3 5 Superclusters capable of operating cluster registry and providing cluster neighbor lists to clusters.
0 3 6 XLattice server refers new clusters to supercluster(s) for cluster ID assignment.
0 3 7 Cluster node ID assignment capability.
0 3 8 Superclusters capable of referring users to clusters for node ID assignment.
0 3 9 XLattice server refers new users to supercluster(s) for node ID assignment.
0 3 3 Qualified nicks (clusterName.userName) bound to public keys.
0 3 4 Qualified nick-to-qualified nick encrypted messaging supported; this is user-to-user messaging within the supercluster.
0 4 0 Superclusters capable of agreeing on global nicks, nicks not qualified by cluster names, but bound to user's crypto ID (public key)
0 4 4 Superclusters operate global nick registry.
0 4 5 Global nick - global nick messaging.
0 6 0 Superclusters capable of global channel name assignment
0 6 1 Global channel creation: clusters can agree on shared name for a channel, with the same name to be used by all clusters, and with the same nick having 'channel creator' privileges across the cluster.
0 6 2 Global channel op assignment by creator.
0 6 3 Global channel joins
0 6 4 Global channel plaintext messaging
0 6 5 global channel encrypted messaging
0 7 0 Support for node-node Voice over IP (VOIP) communications; no human involvement, just creation of link and exchange of packets
0 7 1 User-to-user
0 8 0 Support for node-node video