diff --git a/extensions/mono/README b/extensions/mono/README
new file mode 100644
index 000000000000..bdadf79bbf9f
--- /dev/null
+++ b/extensions/mono/README
@@ -0,0 +1,58 @@
+A CURSORY AND LIKELY MISLEADING GUIDE TO MONOCONNECT
+
+General Architecture
+--------------------
+
+The goal of this code is to provide a two-way bridge between the
+CLR/.NET/Mono/C#/etc. world and XPCOM.
+
+We want:
+ - Natural C#/etc. syntax for consumers.
+ - Acceptable performance (wrapper space and call speed)
+ - "Correctness" (maintenance of object identity, reference management).
+ - Dynamic, lazy generation of stubs and interfaces from interface-info.
+
+We do not want:
+ - People distributing generated stubs.
+
+To that end, we register for TypeResolve and AssemblyResolve events on
+our AppDomain (components.cs, RegisterAppDomainHooks).  When user code
+references an interface or stub-proxy that we have not yet generated
+(and is not special-cased, like nsISupports), our TypeResolve hook
+triggers the generation of an appropriate class.
+
+The generation of proxy classes happens in generate-proxy.cs, where we
+employ the many wonders of System.Reflection.Emit to create a proxy
+for the indicated interface.  The proxy class for a given interface
+will have specialized marshalling code emitted for the specific
+interface parameters and index.  There is currently virtually no code
+shared between proxy methods, which is something that we should remedy
+in the future: a rough census of Mozilla interfaces (circa 1.6)
+indicates that generating a static helper method or delegate per
+unique method signature would give us significant savings.
+
+typeinfo.cs has a bunch of infrastructure for inspecting interface
+info from the IIM.  I am not particularly proud of any of that
+infrastructure, but it does get the job done at present.  Lots of it
+is likely not even used today, since it largely predates actual proxy
+generation.  xptinvoke.cs is along the same lines.
+
+(typeinfo.cpp exists mainly because we need C-linkage entry points for
+P/Invoke, and secondarily because I wanted to reduce mono<->C thunking
+as much as was easy.)
+
+wrapped-clr.cs is where the CLR-implementing-XPCOM-interfaces code
+should go.  Today, it basically...who am I kidding?  You can see the
+source, it clearly does almost nothing.  I have fantasies about
+patching the C++ vtable with JITted delegate pointers.
+
+There's one piece missing to this puzzle (other than all the other
+pieces): we need to generate metadata-only interface assemblies for
+people to compile C# against, because our TypeResolve/AssemblyResolve
+tricks are not enough to get us wired into the compiler.
+
+Other things that are missing:
+- AString support
+- Exceptions
+- figuring out a good way to map casting to QI
+- a component loader