break up blocklists and allow-lists into subsections

README.org

@@ -421,6 +421,18 @@ structurally insufficient to be the /foundation/ of our approach.
     -- Marc Stiegler, [[http://www.skyhunter.com/marcs/ewalnut.html][E in a Walnut]]
 #+END_QUOTE
 
+Blocklists and allow-lists appear, at first glance, to be a good
+foundation for establishing trust or distrust on a social network.
+Unfortunately, both solutions as a foundation actually shake the
+structure of the system apart after long enough.
+
+This isn't to say we aren't sympathetic to the goals of block-lists
+and deny-lists, but that they don't work long term.
+In order to understand this, we need to look at the problem from
+several sides.
+
+**** The Nation-State'ification of the Fediverse
+
 Part of the major narrative of the federated social network at the
 moment is that running an instance is an excellent opportunity to host
 and support a community, maybe of people like you or people you like.
@@ -482,6 +494,8 @@ that instances should play /altogether/.
 While there is nothing wrong with blocking an instance or two, the
 network effect of having this be the foundation is re-centralization.
 
+**** Where do communities really live?
+
 Furthermore, it doesn't even reflect human behavior; few people
 belong to only one community.
 Alice may be a mathematics professor at work, a fanfiction author
@@ -503,6 +517,8 @@ social web: the instance is not the community level, because users
 may have many varying communities on different instances, and each
 of those instances may govern themselves very differently.
 
+**** Not only a social problem, but a security problem too
+
 So far the problems with "perimeter security" described above have
 been examples restricted to the social level.
 As it turns out, perimeter security has another problem when we start