all repos — honk @ 87e955d322e60c8e66d1afc204d9ed5baabe67ec

my fork of honk

document this, document that
Ted Unangst tedu@tedunangst.com
Mon, 29 Apr 2019 13:42:38 -0400
commit

87e955d322e60c8e66d1afc204d9ed5baabe67ec

parent

f801e7ef56b609bcbce7f87c39bdf0757cdfa918

3 files changed, 18 insertions(+), 5 deletions(-)

jump to
M docs/manual.txtdocs/manual.txt

@@ -21,13 +21,14 @@

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).

@@ -37,6 +38,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
M docs/security.txtdocs/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?
M docs/spec.txtdocs/spec.txt

@@ -21,9 +21,13 @@

-- 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

@@ -33,8 +37,8 @@

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.