1
 2Some notes on the database schema.
 3
 4We don't use null, only empty strings. This is easier to work with on the go
 5side.
 6
 7The main table is honks. This stores both locally created honks and incoming
 8ActivityPub notes converted to honks. It is important to differentiate the two
 9cases so that we don't accidentally publish external honks in the public web
10view. (Previously this was accomplished via separate tables. That made some
11queries more difficult, but I think it's possible to workaround this. It would
12be considerably safer.) The honker column will be empty for local honks.
13
14The what column further refines the type of honk. If a reply, tonk. If
15deleted, zonk. If shared, bonk. In particular for the case of bonk, there
16aren't enough columns to store original honker and bonker. This seems to work
17out okay though.
18
19The honkers table is used to manage follows and followers. The flavor column
20describes what. 'sub' is a follow. We have subscribed to their newsletter.
21'dub' is a follower. They get dubbed whenever we honk. We also use this table
22to store public keys for anyone we interact with. This is regrettable.
23
24The xid column generally corresponds to ActivityPub id. For local honks, it
25will be a short string, not a complete URL.
26
27Such explanation would be less necessary were the tables not misused for
28multiple purposes. Will probably split them apart again soon.
29
30Note that some logical seeming joins won't work. The honker column of honks
31does not have a correspondng entry in the honkers table, since we frequently
32receive messages from people we don't follow. Should we track everybody whose
33identity crosses our path? This seems unnecessary. The honkers table is more
34like a mapping of active relationships, not a directory of all peoples.
35
36Some deduping of honks is performed. Known shortcoming: only the first bonk is
37recorded. Subsequent bonks, even by different actors, are ignored. Bonus
38shortcoming: we download such bonks every time.