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 201 hashtags

Running Ktistec the First Time
One of Ktistec's design goals is to make installation and configuration as easy as possible. Rather than multiple supporting data store services, Ktistec uses Sqlite. The database, along with uploaded images, are stored on disk, for easy setup (and, more importantly, backup).
When you run Ktistec the first time, you'll set up the instance, and then you'll set up the primary account.

Ktistec needs to know the name of its permanent home on the internet. The host name is part of the identity of every account on the instance. My identity is "toddsundsted@epiktistes.com"—other federated hosts, and users, send messages and other content to me at "epiktistes.com". (This means you'll need a domain of your own, too.) Give the instance a site name and submit.

Once you name the instance, you create the primary account. Ktistec current supports only one account. This is intentional—another one of Ktistec's design goals is to promote a more fully distributed fediverse. A fediverse with a handful of large, multiuser services isn't a whole lot better than the world we had before, imo. (But don't worry—secondary accounts are on the roadmap.)
At a minimum, you need to specify the username and the password of the account. You can use a single character for the username, but you'll need six characters that include both letters, numbers and symbols for the password. Display name and summary are optional.

Once those two steps are done, you're online!

a fistful of improvements to ktistec

i put the finishing touches on content editing and presentation.

because i want to support long form content, one of my goals was inline images that present as attachments on other implementations like mastodon. my choice of editor, trix, handles image uploads, which is nice, but the generated markup is verbose and suboptimal (trix uses br instead of p tags to break up text into paragraphs, for example).

with open source software, things break but you can get in under the hood to investigate and fix. a recent, breaking change to signatures in mastodon recently broke ktistec federation. a few hours and a few commits later, things were working again. of course, i would have been happier if it hadn't been a breaking change... 😐

i just pushed commits that add a settings page and handle image uploads (for background image and profile icon). a lot of code was already written and supported image upload from the editor—i just had to bend it to my purpose. i'm using FilePond to handle preview and upload in the browser.

generally, i'm pretty happy with the result!

i posted about the problems caused by the lack of a clear license a week ago. commits ca662ca through 49d3e2a remove the kemal-session and kemal-csrf shards and replace them with lightweight improvements to a session store i'd written previously and forgotten about and cut-and-paste reuse of kemal-csrf (which has a clear license and clean history). ktistec will be released under AGPLv3.

these commits show the actor's public posts when an anonymous user navigates to the site, and show the authenticated actor the content timeline for both their inbox and their outbox. these are really two big queries with a pagination scheme i found on the internet. i haven't yet benchmarked it against the common "OFFSET LIMIT" method.


i implemented support for in-the-flow images with attachments as the fallback on federated platforms that don’t support them.

saki shows up in the flow on epiktistes and as an attachment elsewhere.

epiktistes runs on ktistec (still no README). the choice of crystal and sqlite has worked out really well. a small fully threaded conversation using a recursive query took 9.55ms to retrieve and render.