Federation Problems & Solutions

Identity

Problem:

Identity is currently a centrally managed concept at echoplexus. Only one user can register and assume a nickname, and thus state is stored about this nickname on the server when registration occurs (to prevent further registrations). If multiple echoplexi are to participate in a network, we cannot rely upon any one of them respecting the existing registrations nor do we want to impose the overhead of synchronizing a distributed database of registrations.

Proposed Solution:

Use PGP: The anonymous user has no lock icons at all beside their name. The user who wishes to be pseudonymous can supply a private&public PGP/GPG key for the duration of his session in the channel. The private key is only stored in memory while the client is running, never sent across the wire, and is used to digitally sign every message the user produces. The public key is stored persistently (e.g., localStorage) across client sessions (much like the /identify password/token is now).

The public key is transmitted via /gpg-identify [my public key] and is associated with the client object. This prompts a yellow unlocked-lock icon beside his user name. Other clients can notice this icon and click on it to mark it as trusted. This is either: an act of faith (accomplishing linkable anonymity) or manual verification (consulting an external web of trust for true identification). Once the key has been trusted, the lock icon becomes a green locked-lock and a map of "channelName:userName:publicGPGKey" is persistently maintained. All messages received from this nickname are checked for: presence of public key, and that the digital signature is correct. Thus, ancient history can be maintained and known to be consistent and valid, in spite of other echoplexi or malicious users trying to rewrite it.

Bonus: If multiple clients are using PGP, a 1v1 encrypted chat can be easily negotiated between them.

Pulling Chatlogs

Problem:

It would be painful to synchronize chatlogs across potentially many echoplexi.

Potential Solution:

Require each client to keep a set of logs as they see fit (or potentially for some, to keep no logs). The local supernode is consulted for N chatlogs, as well as a hash of these logs, and these are sent to the requesting client. Along with this, the requesting client asks M other peers for only the hash of the same set of logs. If these match, we have a fairly good indicator of validity. If they don't match, we might be able to fallback to GPG digital signature verification for messages that have them (and validate at least a subset of them).

Editing Sent Messages

Problem 1:

If an edit is performed but all peers don't receive it, we'd encounter a failure of chatlog integrity verification when pulling chatlogs.

Solution 1:

Change edit to become an operation performed by the client system. Client system receives an event that is designated as an edit, and must choose whether to apply it to their local history or display it as chat message containing /edit #3939 foo. Thus, the edit operation decouples directly from chatlog verification but now extra care must be taken while verifying (as different clients have different sets of chatlogs, and so may be unable to verify a full batch).

Problem 2:

Related to the Identity problem above. Currently, editing is a centralized action and the user must be properly identified to edit across sessions.

Solution 2:

Perhaps it's only possible to rectify this with some signature verification scheme. The client can receive the edit operation, compare signatures with the old message and the proposed edit, and continue applying the edit as described in solution 1.

Private Channels

~towrite