diff --git a/OLD.entwicklung b/OLD.entwicklung
index 4eb4927..68cce30 100644
--- a/OLD.entwicklung
+++ b/OLD.entwicklung
@@ -128821,3 +128821,54 @@
 
 
 
+oeffentliche Basismudlib (Zesstra, 17. Jul 2016, 11:15:31):
+Huhu,
+
+die oeffentliche Basismudlib ist jetzt als git-Repository auf
+https://anonymizer.zesstra.de:8443/#/admin/projects/
+abgelegt.
+Das Repo mudlib-public wird ebenfalls nach github repliziert:
+https://github.com/MorgenGrauen/mg-mudlib
+
+Damit braucht es eigentlich keinen daily snapshot mehr (den ich daher in
+einige Zeit einstellen werde) und ihr bekommt unsere Aenderungen auch mit
+commit-Message zu sehen. ;-)
+
+Ausserdem koennt ihr auf https://anonymizer.zesstra.de:8443/ auch Aenderungen
+einreichen, welche dann von mir oder Arathorn gemerged werden koennen.
+
+Es kann sein, dass etwas in dieser oeffentlichen Lib fehlt, was da noch
+hingehoert. Meldet euch dann mal.
+
+Anmerkung zum Standort des Repos: dieser ist hoffentlich vorlaeufig und wird
+in absehbarer Zukunft auf den MG-Rechner umziehen. Daher hat die Website auch
+nur ein selbst-signiertes Zertifikat, welches eurer Browser als unsicher
+anmeckern.
+Unsicher ist es nicht, wenn es den folgenden SHA256-Fingerprint hat: ;-)
+EC:BF:F3:D1:02:86:5F:00:1A:3A:1D:7C:47:AB:C6:6F:FB:9C:D2:3F:EA:DC:47:86:D6:40:
+94:24:18:A2:67:D7
+
+Zesstra
+
+-----------------------------------------------------------------------------
+
+
+
+oeffentliches MPA-Archiv (Zesstra, 17. Jul 2016, 11:28:59):
+Huhu,
+
+auf https://anonymizer.zesstra.de:8443/#/admin/projects/
+liegt jetzt ein git-Repository mpa-archiv, welches das MPA-Archiv enthaelt.
+Die oeffentlichen Rubriken sind im Zweig "public" und fuer jeden lesbar.
+Magier haben Zugriff auf weiterer Zweige, welche nicht-oeffentliche Rubriken
+enthalten.
+
+Die bislang fuer Magier erstellten Archive unter /news/ entfallen damit in
+Zukunft.
+
+Zesstra
+
+-----------------------------------------------------------------------------
+
+
+
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
+
+-----------------------------------------------------------------------------
+
+
+