1honk spec
 2
 3-- references
 4
 5See security.txt for some notes on security.
 6
 7See ping.txt for a proposed Ping extension to ActivityPub.
 8
 9-- retries
10
11If a message can't be delivered, we backoff and retry.
12
131 - five minutes later in case the servce restarted
142 - one hour later in case the server rebooted
153 - 12 more hours later in case the server was upgraded
164 - 24 more hours later in case there was a catastrophe
175 - it's dead.
18
19A random drift of up to 10% is added to each delay to avoid swarming.
20
21-- federating
22
23Messages are transformed for federation and display. Some transformations
24occur send side and some occur receive side because it's more exciting that
25way. @mentions and *markdown* are converted to HTML before transmission.
26Message :emoji: are converted to inline images after receiving.
27
28Up to four parents of a reply will be fetched.
29
30Attachments for received messages are rescaled before saving.
31
32-- schema
33
34Some notes on the database schema. Mostly for development, but maybe useful
35for administration as well.
36
37The config table contains settings, some of which may not be editable via the
38normal interface.
39
40For development purposes, adding a config value ('debug', 1) to the database
41will disable caching and hot reload the templates. It's not meant to be
42harmful in production, just less efficient.
43
44We don't use null, only empty strings. This is easier to work with on the go
45side.
46
47The main table is honks. This stores both locally created honks and incoming
48ActivityPub notes converted to honks. It is important to differentiate the two
49cases so that we don't accidentally publish external honks in the public web
50view. The whofore column value of 2 indiciates a public honk.
51
52The what column further refines the type of honk.
53
54Attachments are physically saved as files, and logically joined to honks via
55the donks table. Emus are saved as donks as well.
56
57The honkers table is used to manage follows and followers. The flavor column
58describes what. 'sub' is a follow. We have subscribed to their newsletter.
59'dub' is a follower. They get dubbed whenever we honk.
60
61The xonkers table stores info about external accounts that we may interact
62with. Their keys, their inboxes, etc. Not user visible.
63
64The zonkers table stores things we do not wish to see, per the wherefore
65column. Also used for tombstones for deleted honks to prevent refetching.
66
67The xid column generally corresponds to ActivityPub id.
68
69Note that some logical seeming joins won't work. The honker column of honks
70may not have a corresponding entry in the honkers table, since we frequently
71receive messages from people we don't follow. Should we track everybody whose
72identity crosses our path? This seems unnecessary. The honkers table is more
73like a mapping of active relationships, not a directory of all peoples.
74
75Some deduping of honks is performed. This may not be perfect.