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-- schema
22
23Some notes on the database schema. Mostly for development, but maybe useful
24for administration as well.
25
26The config table contains settings, some of which may not be editable via the
27normal interface.
28
29For development purposes, adding a config value (debug, 1) to the database
30will disable caching and hot reload templates. It's not meant to be
31harmful in production, just less efficient.
32
33We don't use null, only empty strings. This is easier to work with on the go
34side.
35
36The main table is honks. This stores both locally created honks and incoming
37ActivityPub notes converted to honks. It is important to differentiate the two
38cases so that we don't accidentally publish external honks in the public web
39view. (Previously this was accomplished via separate tables. That made some
40queries more difficult, but I think it's possible to workaround this. It would
41be considerably safer.) The honker column will be empty for local honks.
42
43The what column further refines the type of honk. If a reply, tonk. If
44deleted, zonk. If shared, bonk. In particular for the case of bonk, there
45aren't enough columns to store original honker and bonker. This seems to work
46out okay though.
47
48The honkers table is used to manage follows and followers. The flavor column
49describes what. 'sub' is a follow. We have subscribed to their newsletter.
50'dub' is a follower. They get dubbed whenever we honk. We also use this table
51to store public keys for anyone we interact with. This is regrettable.
52
53The xid column generally corresponds to ActivityPub id. For local honks, it
54will be a short string, not a complete URL.
55
56Such explanation would be less necessary were the tables not misused for
57multiple purposes. Will probably split them apart again soon.
58
59Note that some logical seeming joins won't work. The honker column of honks
60does not have a corresponding entry in the honkers table, since we frequently
61receive messages from people we don't follow. Should we track everybody whose
62identity crosses our path? This seems unnecessary. The honkers table is more
63like a mapping of active relationships, not a directory of all peoples.
64
65Some deduping of honks is performed. This may not be perfect.