From c6ddfef62ad3a06a80bf17a1bfa145ccac222c24 Mon Sep 17 00:00:00 2001 From: Ted Unangst Date: Mon, 29 Apr 2019 13:42:38 -0400 Subject: [PATCH] document this, document that --- docs/manual.txt | 5 ++++- docs/security.txt | 3 +++ docs/spec.txt | 15 +++++++++++---- 3 files changed, 18 insertions(+), 5 deletions(-) diff --git a/docs/manual.txt b/docs/manual.txt index f56a314..b3dc94a 100644 --- a/docs/manual.txt +++ b/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. diff --git a/docs/security.txt b/docs/security.txt index f09f362..56d82c4 100644 --- a/docs/security.txt +++ b/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? diff --git a/docs/spec.txt b/docs/spec.txt index 3a53a60..5073962 100644 --- a/docs/spec.txt +++ b/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.