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?
Are you sure you want to delete the OAuth client [Client Name]? This action cannot be undone and will revoke all access tokens for this client.
Are you sure you want to revoke the OAuth token [Token ID]? This action cannot be undone and will immediately revoke access for this token.
#ktistec 160 hashtags

building ktistec is still an endeavor—both in time and in space. i have work ahead of me to reduce the build footprint—since starting this project, i've learned that some combinations of the crystal language features i used to recreate rails magic (macros, named arguments and inheritance) are hard on the compiler.
in any case, having exceeded the capacity of the tiny linux vps that hosts epiktistes, i set out to build a statically linked executable on my laptop (macos mojave) that i could deploy to my vps (linux centos).
the official instructions, using docker and alpine linux, are here. to get it to build, i had to install the static libraries for sqlite, and to get it to run on my vps i had to specify the location of the openssl cert file, which is loaded at runtime and doesn't match the location in alpine linux.
tl;dr the steps
docker run --rm -it -v $(pwd):/workspace -w /workspace crystallang/crystal:latest-alpine shapk update && apk upgradeapk add sqlite-staticcrystal build src/ktistec/server.cr --staticexitSSL_CERT_FILE=/etc/ssl/certs/ca-bundle.crt ./server
commits 99a0fd6 to 70bcf3f implement metrics and charting.

an instance of the Point model records an occurrence of an event—for example, the arrival of an activity in my inbox. points have a timestamp and a value and can be aggregated by day, week, etc. aggregation takes into account the timezone of the account that's viewing the chart so you'll need to specify a timezone during setup or in your account settings. i use chart.js for the charts.
i'm only collecting inbox and outbox metrics right now, but this will expand to include other types of metrics—social events, errors, etc.
looking at the chart above... i clearly need to post more...

i spent most of the summer cleaning up the codebase of my covid project (aka ktistec).
in theory, ruthlessly refactoring should be a pleasure. truth be told, i don't enjoy it as much as building new features. nonetheless, everyone else—including my future self—should find things more consistent.
things i did include replacing ecr templates with slang templates, using form helpers to make forms behave more consistently and to reduce boilerplate, etc. etc. etc. i also moved from turbolinks to turbo, which allowed me to remove my custom code for making updates to parts of a page. i know it's not cool but i'm a fan of html over the wire. i also fixed/improved timeline handling and refactored population/management of timelines and notifications. i really need to refactor handling of all side-effects—i just found another place in the code where out-of-order messages result in duplicates in the inbox.
(interesting aside about that... it's possible to get a forwarded create activity from a source before receiving the create activity from the origin itself. it's not surprising in retrospect. the origin was busy sending to followers and i was in the queue. meanwhile, another follower who was mentioned in the related object broadcast the activity to their followers...)

i took time off this summer to enjoy the analog world and play board games, but i did make some small progress in a few areas.
commits 31260ad through d6b35cb fix various bugs and performance problems and improve the user experience:
there's a bunch of work under the hood, as well—mostly deferred refactoring and cleanup.
in parallel, i'm still working on metrics collection and charts. here's a teaser:


i’m patiently working my way toward a 1.0 release of the ktistec server. the 1.0 release must have a stable database schema—that’s the one hard requirement. in terms of features, it’s close now. i’m adding internal metrics for the power user and block lists. then it ships!

and commits eb740e1 through 091a1b1 implement a materialized timeline. it replaces a large and complex query for dynamically generating the timeline from activities. the query worked well enough but was slow—over 200ms for a single page in a timeline containing over 4000 objects. the replacement is 3x better, but still builds a b-tree to get the sorted results. the solution, i suspect, is to remove the final two joins, at which point the existing index on created_at will be used to get the sorted rows. to do that, i'll need to remove deleted actors and objects when they are deleted...

ktistec commits 4a32680 to 9b68508 add support for notifications—mentions, announcements/shares/boosts, likes and follows all create notifications for easy alerting and management.

commits #22a2fe2 to b4b0bb3 add support for pretty/canonical URLs.
posts are automatically assigned a unique, but arbitrary, identifier (this post is known as https://epiktistes.com/objects/mMpIAUimtjg) . you can also manually assign posts a "pretty", canonical identifier, for seo purposes (if you care about that) or as an helpful mnemonic (this post is also known as https://epiktistes.com/commits-22a2fe2-b4b0bb3).
also in these commits is support for editing/updating published posts. mastodon instances currently ignore updates, but if you are using ktistec to "blog" maybe that's okay.

commits #f087a58 to fc9069c add support for approved posts. approved posts appear in public threaded conversations, and allow authors to control what parts of a conversation are visible to anonymous visitors.
it's a nod toward the day when fediverse spammers show up. (lol "when"...)


My Covid-19 quarantine plan for the last 12 months was to write code every day. With a few exceptions, I pulled that off. The big pre-Covid plan was to write every day, but in traditional hacker fashion I first built some tools (Ktistec and kin).
The big project was Ktistec, of course, but early on I spent a lot of time on MXNet.cr, mostly on native MXNet bindings, but also on a Gluon compatible library. I also put a lot of time into Ishi, a project that sprang from my desire to visualize MXNet output inside of my iTerm console.
Now, to do some writing...