Regenerated documentation, but still no new tests.

doc/Desiderata.md

@@ -0,0 +1,7 @@
+# Desiderata
+
+*Social media features which users want which [Mastodon](https://en.wikipedia.org/wiki/Mastodon_(social_network)) does not provide, or provides poorly.*
+
+1. User-specified inbox-ordering algorithms;
+2. Outbox search, by user (i.e. 'find all the times I interacted with x');
+3. Outbox search, full text (i.e. 'find the post where I wrote x');

doc/Per-User Database

@@ -0,0 +1,5 @@
+# Per-User Database
+
+*This is a design thought, not a design decision.*
+
+Obviously, the way to give each user control of their social media is for each user to have effectively their own server, and that thought is behind my ideas about driving more functionality down to the client. Allowing an architecture of intermittent links helps with this - the same client will not always appear on the same ip address and thus cannot use conventional SSL certificates for authentication, so we need a workaround for that.

doc/Using_ActivityPub.md

@@ -52,4 +52,3 @@ The Tombstone object is a means of acknowledging that the requested object did o
 If we're pushing entire objects – which may include media attachments – to the inboxes of many recipients who may never choose to read them, that feels like a lot of wasted bandwidth. However, if we're pushing only ids or links of posts which are not public, that feels like a major security headache in verifying that the requestors are indeed verified recipients.
 
 Again, the fact that Mastodon is able to show me '[user] edited a post' items in my notifications seems to imply that updates of the complete edited object are being pushed out to all recipients' inboxes, and again that seems expensive.
-