P2P Chat Facility
Roadmap
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).
Note
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
|
