diff --git a/README.org b/README.org
index 9f69e3c..55c8fd3 100644
--- a/README.org
+++ b/README.org
@@ -625,11 +625,62 @@ standing up for human rights; if the choice is between doing
 business in a country or not violating its citizens' rights,
 most companies will seek to maximize value for their shareholders.
 
-But don't give up hope!
-There is a way out of this mess, after all.
-
 ** A way forward: networks of consent
 
+Don't give up hope!
+There is a way out of this mess, after all.
+It lies with the particular use of a security paradigm called "object
+capabilities" (or "ocaps").
+We will get into the technicality of how to implement ocaps in
+[[*How to build it][How to build it]] but for now, let's think about our high-level goals.
+
+The foundation of our system will rely on establishing trust between
+two parties.
+If Alice trusts Carol to be able to perform an action, she might
+"give consent" to Carol.
+However, giving consent to Carol is not necessarily permanent; Alice
+has the tools to track abuse of her resources, and if she sees that
+Carol is responsible, she can revoke her consent to Carol.
+(While Carol could have handed this authority to someone else, Alice
+would still see the abuse coming from the access she handed Carol,
+and could still hold Carol responsible.)
+
+What about users that do not yet trust each other?
+If Alice does not yet know or trust Bob, it is up to Alice's default
+settings as to whether or not Bob has any opportunity to message Alice.
+Maybe Alice only gets messages from entities she has existing
+relationships with.
+
+However, it is possible that Alice could have a "default profile"
+that anyone can see, but which bears a cost to send a message through.
+Perhaps Bob can try to send a message, but it ends up in a moderator
+queue.
+Or, perhaps Bob can send Alice a message, but he must attach "two
+stamps" to the message.
+In this case, if the message was nice, Alice might refund Bob one
+or both stamps.
+She might even decide to hand him the authority to send messages to
+her in the future, for free.
+But say Bob is a spammer and is sending a viagra ad; Alice can keep
+the stamps.
+Now Bob has to "pay" Alice to be spammed (and depending on how we
+decide to implement it, Alice might be paid to be spammed).
+There is always a cost to unwanted messages, but in our current
+systems the costs lie on the side of the receiver, not the sender.
+We can shift that dynamic for unestablished relationships.
+And critically, it is up to Alice to decide her threshold: if she
+is receiving critically abusive messages, she can up the number of
+stamps required, disable her public inbox entirely, or hand over
+moderation to a trusted party during a particularly difficult period.
+But even if she disables her inbox, the parties which have existing
+trust relationships with Alice can still message her at no cost.
+
+This document does not specify mechanisms but opens up several
+opportunities.
+It is up to the community to decide which routes are considered
+acceptable.
+But the framework for all of this is object capabilities.
+
 ** Must we boil the ocean?
 
 * How to build it