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