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.
#crystallang 75 hashtags

I've been running v3.0.0 of Ktistec in production for the last few weeks, and it seems stable and I’m using it every day, so it’s time to release it!
This release adds:
Model Context Protocol (MCP) is a simple, general API that exposes Ktistec ActivityPub collections (timeline, notifications, likes, announces, etc.) to MCP clients. To be fully transparent about what this means, MCP clients are shells for Large Language Models (LLMs).
When building this, I focused on a few use cases that are important to me: content summarization, content prioritization (or filtering) based on my interests or the content's structure (well-constructed arguments vs. low-signal opinions) or its tone, especially when it comes to shared posts. Ktistec is a single user ActivityPub server and Epiktistes (my instance) gets a lot of traffic. I want to build the “algorithms” that surface the content I want to see.
Of note, there’s currently no support for content generation.
While I work on this, I’m not abandoning the 2.x line. I’ll continue to add compatible features and fix bugs as long as I'm able. I realize the use of LLMs, and MCP by extension, and therefore the 3.x branch, is controversial—I don’t intend to push v3 on anyone.
If you're still with me, Ktistec now exposes:
ktistec://actors/{id*})ktistec://objects/{id*})ktistec://users/{id})ktistec://information)count_collection_since(name, since)paginate_collection(name, page, size)read_resources(uris)whats_newSupported collections include:
hashtag#<name> (e.g., "hashtag#technology")mention@<name> (e.g., "mention@euripides")There is more detail in the README.
TL;DR Add a remote MCP connector in your MCP client of choice: supply the URL of your instance including the /mcp path (e.g. "https://epiktistes.com/mcp").


Release v2.4.9 of Ktistec fixes two significant bugs. From the changelog:
next_attempt_at in tasks when server restarts.The first bug resulted in server maintenance tasks running immediately, every time the server restarted, and then beginning their cadence of scheduled runs from there. The second bug surfaced after I released a new version of Slang that itself included a bug fix.

Ktistec v2.4.8 has many small fixes and improvements, but includes one significant fix to ActivityPub garbage collection, which was the major feature introduced in the last release.
⚠️ Important Note: Building with Crystal Language version 1.17.x is not supported due to two breaking changes. See:
(Maybe it's three changes—compile times are also far slower and executable sizes are much larger.)
Added
Fixed
Changed
Enjoy!

Ktistec (temporarily) only builds with versions of the Crystal Programming Language 1.16.3 and below. There was a significant change to the libxml integration in the Crystal Standard Library in version 1.17.0. Ktistec implements some extensions on top of the standard library that need to be updated as a result. A permanent fix in in progress.

After a mental health break, release v2.4.7 of Ktistec is out. The biggest improvement is the addition of a command line switch/option to run garbage collection on startup. Garbage collection, in this context, trims down your database by deleting old ActivityPub objects that are not connected to your user through:
It reduced the size of my database ~24%. Details on usage, warnings, etc. are in the README.
Other changes:
Fixed
WITH RECURSIVE queries.Changed
Other

Release v2.4.6 of Ktistec is out. As mentioned in an earlier post, this release focuses on database performance improvements. This means caching the results of expensive queries (like counting all posts with a particular hashtag or mention). On my instance at least, pages like the notifications page are now snappier.
There are still slow queries (queries that take more than 50msec). Most of those are requests for pages of old posts where none of the necessary database pages are in the page cache. I have increased the page cache size, and that reduces the frequency, but I don't see an immediate fix.
Fixed
Changed
Removed
X-Auth-Token.Other
POST socket operations.I don't have an immediate plan for the next release. There have been a bunch of feature requests that I think have merit. I'll probably get started on some of those.

You can specify the SQLite database and pass options (pragmas like cache_size, journal_mode, ...) on the command line when you start the Ktistec server. The following example sets the cache size to 20,000 pages (up from the default of 2,000 pages) which improves performance on larger instances.
KTISTEC_DB=~/ktistec.db\?cache_size=-20000 ./server
You can also enable the write-ahead log (but make sure you know what that means).
KTISTEC_DB=~/ktistec.db\?journal_mode=wal\&synchronous=normal ./server
Pragmas supported are limited to those listed here.

A new release of ktistec that improves database performance is imminent. In the past, database optimization usually meant "fixing a bunch of poorly constructed queries", and I'm sure there's more of that to do—I'm not an expert. But this time, I found most of the queries were as good as they were going to get on my watch (I'm not an expert). If you have a million records and you need to filter and count them, that's just going to take some time...
So this time, I focused on caching the results of queries like that (which really means I focused on cache invalidation, right). A case in point is commit d544b1af. Previously, the nodeinfo endpoint filtered and counted posts on every request, and it took +80msec to do that. Worse, the filtering pushed everything else out of the sqlite page cache, which made the next, unrelated database query slow!
Caching this value, and only recounting when I post something, not only dropped the service time for the request to ~1msec but actually improved database performance, generally!
More to come...

Finally I could release Blueprint 1.0.0 after almost 2 years in development.

Crystal is fast because methods are monomorphized at compile time. In simple terms, that means that at compile time, a polymorphic method is replaced by one or more type-specific instantiations of that method. The following polymorphic code...
def plus(x, y) x + y end
...is effectively replaced by two methods—one that does integer addition if called with two integers, and one that does string concatenation if called with two strings.
This extends to inherited methods, which are implicitly also passed self. You can see this in action if you dump and inspect the symbols in a compiled program:
class FooBar
def self.foo
puts "#{self}.foo"
end
def bar
puts "#{self}.bar"
end
end
FooBar.foo
FooBar.new.bar
class Quux < FooBar
end
Quux.foo
Quux.new.barDumping the symbols, you see multiple instantiations of the methods foo and bar:
... _*FooBar#bar:Nil _*FooBar::foo:Nil _*FooBar@Object::to_s<String::Builder>:Nil _*FooBar@Reference#to_s<String::Builder>:Nil _*FooBar@Reference::new:FooBar _*Quux@FooBar#bar:Nil _*Quux@FooBar::foo:Nil _*Quux@Object::to_s<String::Builder>:Nil _*Quux@Reference#to_s<String::Builder>:Nil _*Quux@Reference::new:Quux ...
The optimizer in release builds is pretty good at cleaning up the obvious duplication. But during my optimization work on Ktistec, I found that a lot of duplicate code shows up anyway.
Most pernicious are weighty methods that don't depend on class or instance state (don't make explicit or implicit reference to self). As I blogged about earlier, this commit replaced calls to the inherited method map on subclasses with calls to the method map defined on the base class and reduced the executable size by ~5.8%. The code was identical and the optimizer could remove the unused duplicates.
So, as a general rule, if you intend to use inheritance, put utility code that doesn't reference the state or the methods on the class or instance in an adjacent utility class—as I eventually did with this commit.
(The full thread starts here.)