diff --git a/waku.md b/waku.md
index 9bfa47f5..960862b7 100644
--- a/waku.md
+++ b/waku.md
@@ -1,6 +1,6 @@
 # Waku Whisper Specification
 
-> Version 0.1.0 (Initial release)
+> Version 0.1.1 (Initial release)
 >
 > Authors: Oskar Thorén oskar@status.im, Dean Eigenmann dean@status.im
 
@@ -21,11 +21,17 @@
 - [Additional capabilities](#additional-capabilities)
     - [Light node](#light-node)
     - [Mailserver and client](#mailserver-and-client)
+        - [Requesting messages](#requesting-messages)
+        - [Receiving historic messages](#receiving-historic-messages)
 - [Backwards Compatibility](#backwards-compatibility)
     - [Waku-Whisper bridging](#waku-whisper-bridging)
 - [Forwards Compatibility](#forwards-compatibility)
-- [Security considerations](#security-considerations)
-- [Implementation Notes](#implementation-notes)
+- [Appendix A: Security considerations](#appendix-a-security-considerations)
+    - [Scalability and UX](#scalability-and-ux)
+    - [Privacy](#privacy)
+    - [Spam resistance](#spam-resistance)
+    - [Censorship resistance](#censorship-resistance)
+- [Appendix B: Implementation Notes](#appendix-b-implementation-notes)
     - [Implementation Matrix](#implementation-matrix)
 - [Footnotes](#footnotes)
 - [Changelog](#changelog)
@@ -339,16 +345,67 @@ Waku is a different subprotocol from Whisper so it isn't directly compatible. Ho
 
 It is desirable to have a strategy for maintaining forward compatibility between `waku/0` and future version of waku. Here we outline some concerns and strategy for this.
 
-
-## Security considerations
+## Appendix A: Security considerations
 
 There are several security considerations to take into account when running Waku. Chief among them are: scalability, DDoS-resistance and privacy. These also vary depending on what capabilities are used, such as mailserver, light node, and so on.
 
-### Light node privacy
+### Scalability and UX
+
+**Bandwidth usage:**
+
+In version 0 of Waku, bandwidth usage is likely to be an issue. For more investigation into this, see the theoretical scaling model described [here](https://github.com/vacp2p/research/tree/dcc71f4779be832d3b5ece9c4e11f1f7ec24aac2/whisper_scalability).
+
+**Mailserver High Availability requirement:**
+
+A mailserver has to be online to receive messages for other nodes, this puts a high availability requirement on it.
+
+**Gossip-based routing:**
+
+Use of gossip-based routing doesn't necessarily scale. It means each node can see a message multiple times, and having too many light nodes can cause propagation probability that is too low. See [Whisper vs PSS](https://our.status.im/whisper-pss-comparison/) for more and a possible Kademlia based alternative.
+
+**Lack of incentives:**
+
+Waku currently lacks incentives to run nodes, which means node operators are more likely to create centralized choke points.
+
+### Privacy
+
+**Light node privacy:**
 
 The main privacy concern with light nodes is that directly connected peers will know that a message originates from them (as it are the only ones it sends). This means nodes can make assumptions about what messages (topics) their peers are interested in.
 
-## Implementation Notes
+**Bloom filter privacy:**
+
+By having a bloom filter where only the topics you are interested in are set, you reveal which messages you are interested in. This is a fundamental tradeoff between bandwidth usage and privacy, though the tradeoff space is likely suboptimal in terms of the [Anonymity](https://eprint.iacr.org/2017/954.pdf) [trilemma](https://petsymposium.org/2019/files/hotpets/slides/coordination-helps-anonymity-slides.pdf).
+
+**Mailserver client privacy:**
+
+A mailserver client has to trust a mailserver, which means they can send direct traffic. This reveals what topics / bloom filter a node is interested in, along with its peerID (with IP).
+
+**Privacy guarantees not rigorous:**
+
+Privacy for Whisper / Waku haven't been studied rigorously for various threat models like global passive adversary, local active attacker, etc. This is unlike e.g. Tor and mixnets.
+
+**Topic hygiene:**
+
+Similar to bloom filter privacy, if you use a very specific topic you reveal more information. See scalability model linked above.
+
+### Spam resistance
+
+**PoW bad for heterogenerous devices:**
+
+Proof of work is a poor spam prevention mechanism. A mobile device can only have a very low PoW in order not to use too much CPU / burn up its phone battery. This means someone can spin up a powerful node and overwhelm the network.
+
+**Mailserver trusted connection:**
+
+A mailserver has a direct TCP connection, which means they are trusted to send traffic. This means a malicious or malfunctioning mailserver can overwhelm an individual node.
+
+### Censorship resistance
+
+**Devp2p TCP port blockable:**
+
+By default Devp2p runs on port `30303`, which is not commonly used for any other service. This means it is easy to censor, e.g. airport WiFi. This can be mitigated somewhat by running on e.g. port `80` or `443`, but there are still outstanding issues. See libp2p and Tor's Pluggable Transport for how this can be improved.
+
+## Appendix B: Implementation Notes
 
 ### Implementation Matrix
 
@@ -376,6 +433,7 @@ Notes useful for implementing Waku mode.
 
 | Version | Comment |
 | :-----: | ------- |
+| 0.1.1   | Add security considerations appendix |
 | 0.1.0 (current) | Initial Release |
 
 ### Differences between shh/6 waku/0