document this, document that

docs/manual.txt

@@ -21,13 +21,14 @@ like https://example.com/users/name. Note that the commonly seen URL with
 Followed honkers may be assigned to combos, listing all their honks together.
 
 Selecting just peeping won't actually follow them. (Incomplete feature.)
+Cant be useful for managing as part of a combo, however.
 
 -- zonking
 
 You can zonk anything you like (or dislike), either your own honk or
 those of others that you're tired of seeing. This reduces its visibility, but
 doesn't attempt to delete it, which is infeasible.
-It's more like disavow.
+It's more like disavow or disregard.
 
 The killzone supports blocking unwanted contacts. One may block an actor
 (zonker), a domain (zurl), or thread (zonvoy).
@@ -38,6 +39,8 @@ Honks are public. Welcome to the internet.
 
 Received messages are only visible when logged in, regardless of addressing.
 
+Recevied messages that are less than public are tagged with a red border.
+
 -- css
 
 Custom CSS may be provided by creating a views/local.css file.

docs/security.txt

@@ -17,6 +17,9 @@ If the key is only used for signing http requests, it can be be changed
 basically at will. Change the key in the actor, give it a new name (to avoid
 conflict with any cached keys), carry on.
 
+Since keynames in practice don't change, honk will simply discard a key after
+a signature failure and attempt to get a fresh key.
+
 Using keys to sign json is more complicated. The current practice is to name
 keys with URL fragments. example.com/user#key. If the keyname is changed to
 #newkey, how does one fetch the old key to verify existing data?

docs/spec.txt

@@ -21,10 +21,14 @@ A random drift of up to 10% is added to each delay to avoid swarming.
 -- federating
 
 Messages are transformed for federation and display. Some transformations
-occur send side and some occur receive client because it's more exciting that
+occur send side and some occur receive side because it's more exciting that
 way. @mentions and *markdown* are converted to HTML before transmission.
 Message :emoji: are converted to inline images after receiving.
 
+Up to four parents of a reply will be fetched.
+
+Attachments for received messages are rescaled before saving.
+
 -- schema
 
 Some notes on the database schema. Mostly for development, but maybe useful
@@ -33,8 +37,8 @@ for administration as well.
 The config table contains settings, some of which may not be editable via the
 normal interface.
 
-For development purposes, adding a config value (debug, 1) to the database
-will disable caching and hot reload templates. It's not meant to be
+For development purposes, adding a config value ('debug', 1) to the database
+will disable caching and hot reload the templates. It's not meant to be
 harmful in production, just less efficient.
 
 We don't use null, only empty strings. This is easier to work with on the go
@@ -52,12 +56,15 @@ deleted, zonk. If shared, bonk. In particular for the case of bonk, there
 aren't enough columns to store original honker and bonker. This seems to work
 out okay though.
 
+Attachments are physically saved as files, and logically joined to honks via
+the donks table. Emus are saved as donks as well.
+
 The honkers table is used to manage follows and followers. The flavor column
 describes what. 'sub' is a follow. We have subscribed to their newsletter.
 'dub' is a follower. They get dubbed whenever we honk.
 
 The xonkers table stores info about external accounts that we may interact
-with. Their keys, their inboxes, etc.
+with. Their keys, their inboxes, etc. Not user visible.
 
 The zonkers table stores things we do not wish to see, per the wherefore
 column. zonkers are bad people, zurls are bad hosts, zonvoys are bad threads.