This action will delete this post on this instance and on all federated instances, and it cannot be undone. Are you certain you want to delete this post?
This action will delete this post on this instance and on all federated instances, and it cannot be undone. Are you certain you want to delete this post?
This action will block this actor and hide all of their past and future posts. Are you certain you want to block this actor?
This action will block this object. Are you certain you want to block this object?
driving a tesla from washington state to new york state...
our may the 4th projects are done.
i used our 3d printer to print dozens of heads/beads, and my wife and i made necklaces. we’ll save the left over parts and use them for swag and seek at dragon con this fall.
the c3p0 heads were the most difficult to print—the neck made a tiny base, which didn’t adhere well when printed in multiples, even with a brim.
the death star is by nils kal, and was originally a clock face. I love it.
everyone is off today so we’re boardgaming…
forgotten waters is an app-driven, co-op game with an entertaining storyline. in the first scenario, our goal is to sail past/off the edge of the world (entertaining, right). players have their own individual goals as well, and to win they much achieve those goals. so it’s possible for the team to win but individual players to lose, which adds a competitive dynamic to the gameplay.
dynamic rules (configurable at run time rather than compile time) will soon be merged into the main branch of ktistec. the current rules define handling of notifications (which activities result in notifications to the user) and the timeline (which activities end up in the user's timeline).
by default, posts that mention other users but not you won't show up in your timeline. but maybe you want to see them in your timeline. now you can change the rules so that you can!
rules for handling the inbox, outbox and collections in general will be coming soon...
next up on ktistec...
i'm writing a simple tdop/pratt parser for rules, now. i've done it before for other projects, with more complicated grammars, and imo they're easier to understand and extend than lr/ll parsers. douglas crockford popularized them in a post a while back—writing a javascript parser in javascript.
@Gargron it's been a good weekend for cat photos!
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 condition var("activity"), IsAddressedTo, var("actor") condition CreateActivity, var("activity"), object: var("object") any Mention, var("mention"), subject: var("object"), href: var("actor").iri none Notification, owner: var("actor"), activity: var("activity") assert Notification, owner: var("actor"), activity: var("activity") end rule "announce" do condition var("activity"), IsAddressedTo, var("actor") condition AnnounceActivity, var("activity"), object: var("object") condition Object, var("object"), attributed_to: var("actor") none Notification, owner: var("actor"), activity: var("activity") assert Notification, owner: var("actor"), activity: var("activity") end ...
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.