diff --git a/OLD.mudclients b/OLD.mudclients
index 6ce7693..8191147 100644
--- a/OLD.mudclients
+++ b/OLD.mudclients
@@ -6049,3 +6049,99 @@
 
 
 
+Ende-zu-Ende-Verschluesselung fuer Intermud + Teile-mit (Zesstra, 16. Apr 2016, 12:25:34):
+Hallo allerseits,
+
+ich cross-poste hier mal eine Mail, welche ich heute mal an einige mud-Admins
+und LDMud-User geschickt habe. Aber vielleicht interessiert es hier ja auch
+Leute. Ich uebersetze sie aber nicht, ihr muesst also mit Englisch
+vorliebnehmen...
+
+--- cut here ---
+Recently I thought about how difficult it would be to extend the old intermud
+v2/zebedee with asynchronous E2E encryption. And I think, the MUDs don't need
+to support much, because most is obviously done in the clients.
+
+I would like to start a discussion and be happy if you invite people not on
+this mailing list to it.
+
+I looked at the Signal Protocol (former: Axolotl) because I think, it is
+currently the best solution available and there are several libararies
+implementing the protocol so it should be not too complicated to include them
+in clients. The signal protocol is used in Signal and (recently) WhatsApp.
+
+Properties of the Signal Protocol:
+asynchronous: the two user don't have to be online at the same time
+group chat possible / multicast encryption
+supports confidentiality, integrity, authentication, participant consistency,
+destination validation, forward secrecy, backward secrecy (aka future
+secrecy), causality preservation, message unlinkability, message repudiation,
+participation repudiation, and asynchronicity.
+uses Curve25519, AES-256, and HMAC-SHA256
+
+Please note the the protocol does not require user IDs to be phone numbers,
+they could also be user@mud.
+https://whispersystems.org/blog/asynchronous-security/
+https://whispersystems.org/blog/simplifying-otr-deniability/
+https://whispersystems.org/blog/private-groups/
+https://github.com/whispersystems/
+
+What MUD (servers) need to support:
+1) transport
+We need to transport messages between users. Basically, we have that already
+and it could be used as is. However, it might be useful to use something like
+GMCP for the actual transport between servers and clients instead of
+traditional commands (e.g. "teile-mit"). We might have to require clients to
+encapsulate the encrypted messages in ASCII.
+
+2) store and forward messages
+If the client is currently disconnected, a MUD should store the messages and
+transfer when the client connects next time. This should be relatively easy to
+implement in LPC.
+
+3) store public user keys
+The MUD has to store the users public identity keys and a number of (signed)
+prekeys. This should also be relatively easy. The interface for storing and
+restrieval for clients could be based on GMCP.
+
+4) implement and announce an intermud service "signalp"
+We would add another optional service to the intermud protocol for querying
+the key directories via intermud.
+
+Actually, all of this could also be done with only one MUD offering it,
+because nothing prevents a MUD to offer the service for users of other MUDs as
+well. However, I would prefer to have several MUDs offering these services to
+avoid a single point of failure and to make use of the p2p properties of
+intermud v2.
+
+What clients would need to support:
+1) GMCP or another protocol for exchanging keys and messages with muds. This
+mostly exists already and only requires a new optional module.
+2) the signal protocol. Implementations are available in several languages and
+there is not need to implement it again. Clients could implement a
+communcation command that transparently uses the signal protocol if available
+and traditional clear-text if not.
+
+The mud-to-mud transport would be decoupled from the mud-to-client transport
+and client functionality and could be extended to other protocols than
+intermud v2.
+Added bonus is, that even mud-internal communication between users could
+easily encrypted as well, the MUDs would see only who communicates with whom.
+Even private chat groups (Ebenen) would be possible.
+(Yes - this defeats snooping mostly, but I don't think this should be a reason
+not to implement a scheme like this.)
+
+Obviously, this would work best, if there are several MUDs and clients
+supporting this scheme. I am interested in your opinions concerning
+implementation details but also if you think we might get it going.
+I would start with adding a kind of reference implementation for the inetd in
+Morgengrauen, which should be easily adaptable for other muds.
+Are any of you working on clients and could be motivated to add something like
+this?
+
+Zesstra
+
+-----------------------------------------------------------------------------
+
+
+