diff --git a/src/SUMMARY.md b/src/SUMMARY.md
index 2834016..c95dd76 100644
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@@ -2,6 +2,7 @@
 
 - [Overview](./overview.md)
 - [Risk Model](./risk.md)
+- [Open Questions](./open-questions.md)
 - [Connectivity](./connectivity.md)
 - [Tapir](./tapir.md)
 - [Cwtch Library](./cwtch.md)
diff --git a/src/open-questions.md b/src/open-questions.md
new file mode 100644
index 0000000..3be0b23
--- /dev/null
+++ b/src/open-questions.md
@@ -0,0 +1,46 @@
+# Open Research Questions
+
+The only way to build secure software is to attack it from every angle. 
+There are a number of limitations and problems with Cwtch, both as designed 
+and as implemented in our prototype. We are working on many of these, 
+but would like to invite researchers to work with us on new solutions, 
+as well as find new problems.
+
+Here are the problems we know about:
+
+* **The User Experience of Metadata Resistance Tools**: Environments that offer
+ metadata resistance are plagued with issues that impact usability, e.g. 
+ higher latencies than seen with centralized, metadata-driven systems, or dropped connections resulting from unstable anonymization networks. Additional research is needed to understand how users experience these kinds of failures, and how apps should handle and/or communicate them to users.
+* **Scalability**: Heavily utilized Cwtch servers increase message latency, and
+ the resources a client requires to process messages. While Cwtch servers are 
+ designed to be cheap and easy to set up, and Cwtch peers are encouraged to 
+ move around, there is a clear balance to be found between increasing the 
+ anonymity set of a given Cwtch server (to prevent targeted disruptions) 
+ and the decentralization of Cwtch groups.
+* **The (Online) First Contact Problem**: Cwtch requires that any two peers are
+  online at the same time before a key exchange/group setup is possible. 
+  One potential way to overcome this is through encoding an additional public 
+  key and a Cwtch server address into a Cwtch peer identifier. This would allow 
+  peers to send encrypted messages to an offline Cwtch peer via a known server, 
+  with the same guarantees as a Cwtch group message. 
+  This approach is not without issues, as by encoding metadata into the Cwtch 
+  identifier we allow adversaries to mount partially targeted attacks 
+  (in particular denial-of-service attacks against the Cwtch server with the 
+  aim of disrupting new connections). However, the benefit of first contact 
+  without an online key exchange is likely worth the potential DoS risk in many 
+  threat models.
+* **Reliability**: In Cwtch, servers have full control over the number of
+  messages they store and for how long. This has an unfortunate impact on the 
+   reliability of group messages: if groups choose an unreliable server, they
+    might find their messages have been dropped. 
+    While we provide a mechanism for detecting dropped/missing messages, we do 
+    not currently provide a way to recover from such failures. There are many 
+    possible strategies from asking peers to resend messages to moving to a 
+    different server, each one with benefits and drawbacks. 
+    A full evaluation of these approaches should be conducted to derive a
+     practical solution.
+* **Discoverability** of Servers: Much of the strength of Cwtch rests on the
+  assumption that peers and groups can change groups at any time, and that 
+  servers are untrusted and discardable. However, in this paper we have not 
+  introduced any mechanism for finding new servers to use to host groups. 
+  We believe that such an advertising mechanism could be built over Cwtch itself.