{ "@context":[ "https://www.w3.org/ns/activitystreams", {"Hashtag":"as:Hashtag"} ], "published":"2022-04-15T13:08:09.864Z", "attributedTo":"https://epiktistes.com/actors/toddsundsted", "to":["https://www.w3.org/ns/activitystreams#Public"], "cc":["https://epiktistes.com/actors/toddsundsted/followers"], "content":"
status update on ktistec...
commits 831dce60 to aa608699 reimplement notifications and timeline management as declarative rules rather than procedural logic. this is the culmination of work announced a while back. here's a sample of what the code looks like now:
rule \"create\" do\r\n condition var(\"activity\"), IsAddressedTo, var(\"actor\")\r\n condition CreateActivity, var(\"activity\"), object: var(\"object\")\r\n any Mention, var(\"mention\"), subject: var(\"object\"), href: var(\"actor\").iri\r\n none Notification, owner: var(\"actor\"), activity: var(\"activity\")\r\n assert Notification, owner: var(\"actor\"), activity: var(\"activity\")\r\nend\r\n\r\nrule \"announce\" do\r\n condition var(\"activity\"), IsAddressedTo, var(\"actor\")\r\n condition AnnounceActivity, var(\"activity\"), object: var(\"object\")\r\n condition Object, var(\"object\"), attributed_to: var(\"actor\")\r\n none Notification, owner: var(\"actor\"), activity: var(\"activity\")\r\n assert Notification, owner: var(\"actor\"), activity: var(\"activity\")\r\nend\r\n...
the first rule says, if an object (post) mentions the actor (you) and a notification doesn't already exist, create one. the second rule says, if someone announces (shares/boosts) an object (post) attributed to the actor (you) and a notification doesn't already exist, create one.
the implementation took three steps: 1) implement a simple, generic rules engine called school, 2) implement logic in ktistec to make it possible to expose the object model and records in the database as facts in the rules engine, 3) reimplement the rules. there was plenty of yak-shaving, too—the preceding ~15-20 commits were fixing things that were in the way. (my usual heuristic assumes 25% refactoring existing code and 75% developing new code, but in this case it was 75%/25% in the other direction.)
while not trivial, rules are easier to reason about than code. toward the end of the project i realized that i wasn't adding replies addressed to me to the timeline (they were only visible in a thread). i was able to fix that defect with a small modification to the rules.
the goal is to make rules modifiable by the user at runtime so that users can customize their ktistec instance without having to rebuild it. the next step toward that end is a simple rules definition language and parser.
", "mediaType":"text/html", "attachment":[], "tag":[ {"type":"Hashtag","name":"#ktistec","href":"https://epiktistes.com/tags/ktistec"}, {"type":"Hashtag","name":"#school","href":"https://epiktistes.com/tags/school"}, {"type":"Hashtag","name":"#crystal","href":"https://epiktistes.com/tags/crystal"}, {"type":"Hashtag","name":"#nocode","href":"https://epiktistes.com/tags/nocode"} ], "type":"Note", "id":"https://epiktistes.com/objects/EMCWJ4YuW6U" }