I really enjoy optimization. Release v3.5.0 of Ktistec doesn't drop significant new features, but it does deliver a ~15% smaller executable and significantly faster queries on anonymous endpoints. The two are intertwined.

The size reduction comes from replacing a poorly designed, custom rules engine with a materialized view layer that uses SQL to define membership in a collection. The rules engine worked well enough but required a lot of supporting code to present rules as a DSL (Domain Specific Language) over the domain objects in ktistec. The driving realization was that SQL is a DSL and membership in a collection is just a query and domain objects are just rows. Voilà!

Query performance improvements came from using this new view layer to materialize two very popular but expensive-to-query views: the instance's public timeline and public hashtag pages. Because both are public pages they receive more traffic than internal pages.

The problem with the original queries was that performance was not uniform. Querying for posts with popular tags was okay. Querying for posts with sparse tags was very slow. I could have added more indexes, but that's its own cost. After the change, endpoints all respond in a consistent ~10msec timeframe and the CPU barely registers when a crawler hits. (I don't want to make things easier for bots, but I don't want to pay a tax for their activity either—ask me about my new nginx configuration.)

Here is the full changelog:

Added

• Lightweight probe endpoint for authenticated sessions.
• max-id and min-id pagination links on web pages.

Fixed

• Correct the notifications collection's JSON representation.
• Accept both single-value and array forms of JSON-LD properties.
• Handle variation in schema.org property mapping.

Changed

• Faster timeline, public, hashtag, and notification collections.
• Adjust the layout of actor profile properties.

Removed

• The school dependency; replaced by activity processors and materialized views.
• The openssl_ext dependency; vendored in.

There are still a few slow queries. In the next release I'm going to see if I can get everything under 10msec, and maybe release a new feature, too. 🚀

#ktistec #crystallang #activitypub #fediverse

I just finished working on improvements to #ktistec that cut about 15% off the built executable size, and speed up some of the more common public queries by 2x to 5x (they were already fast, so this is headroom).

It does this by replacing a poorly designed, feature poor, custom rules engine with a materialized view layer that uses SQL as its DSL (domain specific language).

I am about to smoke test it on my own site. If it’s not available—well, you know why! 😀

bitten

https://github.com/mastodon/mastodon/issues/18361

#ktistec #jsonld

This release fixes a small number of bugs found in recent releases.

The full changelog:

Fixed

• Prevent runaway recursion when handling filtered posts.
• Ensure profile header and header_static images are always present.
• Render the inline replies collection for local objects.
• Exclude blocked actors from object statistics and notifications.

Changed

• Return 410 Gone instead of 404 Not Found for missing actors.

Removed

• Tag counts on public pages.

This release fixes a hard-to-exploit but potentially server-crashing bug. If you're running v3.3.9 or v3.4.0, you should upgrade.

#ktistec #crystallang #activitypub #fediverse

The biggest change in release v3.4.0 of Ktistec is cursor-based pagination for all web-navigable collections (timeline, notifications, etc.). Offset-based pagination will be removed completely in the next release.

Offset-based (e.g. page/size) pagination works well on collections that don't change. But, what does "the second page" contain in a dynamic timeline? Support for cursor-based pagination is required by the Mastodon-compatible API, but has been a desirable feature for quite a while.

While updating queries to paginate by cursor, I also made performance improvements to the queries themselves, as mentioned elsewhere. Scrapers and bots have already adapted—sort of. I now see odd hybrid requests in the log like /tags/xyz?page=7&min_id=123. Overall CPU usage under normal load is now sitting at 0-1%.

Here is the full changelog for the release:

Added

• Cursor-based pagination for web-navigable collections. (fixes #122)
• Mastodon-compatible API: /api/v1/timelines/tag/:hashtag endpoint.

Fixed

• Negative replies count when viewing a post that is also a reply.
• Order cached actors' posts by published rather than id.

Changed

• Report 401 and 403 as distinct errors in Ktistec::Network.get.

Removed

• Unused paginated query methods.

Enjoy!

#ktistec #crystallang #activitypub #fediverse

while replacing page/size pagination with cursor-based pagination throughout ktistec, i took the opportunity to optimize queries. various changes—like leveraging the natural sort order of existing indexes—improved performance across the board by about 10x. that number is a little bit misleading—queries that took ~10msec now take less than 1msec, but that isn’t much in absolute terms. still, it moves the bottleneck!

#ktistec

Release v3.3.9 of Ktistec continues the security hardening work from recent releases, with further progress on the Mastodon-compatible API.

Of note: all network connections now go through a new Ktistec::Network module. This allows Ktistec to limit the size of HTTP bodies it reads, on both inbound and outbound requests, and ensures it only opens connections to valid remote IP addresses.

Here's the full changelog:

Added

• New Mastodon-compatible APIs.

Fixed

• Close DNS rebinding window for outbound HTTP requests.
• Limit the size of HTTP bodies the server reads.
• Sanitize RSS feed output to prevent CDATA breakout.
• Destroy all sessions and access tokens on account termination.

Changed

• Ensure all GET and POST requests utilize Ktistec::Network.
• Process local recipients in-process in inbox/outbox activity processors.

As always, it's worth upgrading for the security fixes!

#ktistec #crystallang #activitypub #fediverse

I don't have a large number of followers, but a recent reply to a relatively short thread (< 10 total posts) resulted in 247 HTTP GETs in the first 100 seconds after the post. Only 29 of those were requests for the object. 218 were requests for the object's replies, which surprised me—why do servers poll for replies within the first 100 seconds? Mean response time was 481μs—well under 1ms. Peak throughput hit 20 req/s.

#ktistec

This release continues my focus on security instead of new features. As I wrote earlier this week, I rebuilt the template framework Ktistec uses with type safety as a central principle. What does that mean?

Imagine that you have an instance of a String that holds federated data. Where can you safely render that in a browser, and what operations (sanitization, escaping, etc.) do you need to do first?

The only way to answer that is to look carefully at the lineage of that data: where it came from, how it was stored, how it was transformed, and where it's rendered. A name holds text; an href or src attribute holds a URL. If you want to render a name inside an HTML element you should HTML escape it. You should escape href and src, too, but the escaping rules for URLs are slightly different from the HTML rules. It's easy to make mistakes.

Ktistec uses four "safe" types to express the contracts:

SafeHTML: A String wrapper marking HTML markup safe to emit raw into HTML data slots (text content, between tags).

SafeAttrValue: A String wrapper marking a value safe to emit raw inside a double-quoted HTML attribute (attr="..."), other than URL or event-handler slots.

SafeURI: A String wrapper marking a URL safe to emit raw into a URL attribute slot (href, src, action, etc.).

SafeJSON: A String wrapper marking JSON output safe to emit raw into the body of a <script type="application/json"> block.

Using the wrong type at a call site is either a compile-time error, or it triggers automatic sanitization of the underlying string value.

Here's the full changelog:

Added

• String safety framework with typed "safe" strings.
• New Slang template engine with compile-time safety checks.
• Vendored WebFinger and HostMeta client shards.

Fixed

• Prevent delivery to unknown IRIs.
• Narrow Like/Dislike addressing to the liked object's author.

I have at least one more cleanup pass to do, and then I'll turn my attention back to the Mastodon-compatible API and a few features I've been looking forward to—like scheduled posts.

#ktistec #crystallang #activitypub #fediverse

One of the nice benefits of working on an open source project is that you can scratch an itch for as long as you feel like scratching. A game I like to play while scratching is called "what invalid states can I make unrepresentable" using the type system.

ktistec uses a template language for views and partials. In its original form, it allowed a programmer to use = to escape an untrusted value or == to render it unescaped. You might want to escape an actor's name property because a name should never contain HTML but you might want to sanitize an object's content property and then render it without escaping because the body of a post can contain HTML.

The problem is you have to remember the rules and never make a mistake. If you accidentally type == actor.name you've just created a potential cross-site scripting (XSS) vulnerability!

ktistec's template language now makes it much more difficult to screw up.

There's now only = syntax and by default it escapes everything. The only way to get it to emit a string without escaping is to wrap it in SafeHTML. The sanitize helper sanitizes HTML and then wraps it for you. Other common helpers (e.g. path construction helpers) do the same.

Importantly, if you interpolate a safe value into a string, it is demoted back to a string and will be escaped unless it is explicitly wrapped again.

Unescaped HTML is still possible to construct, but it's now much harder to do so accidentally. You can't just concatenate some strings together—forgetting that one comes from an untrusted source—and render that as unescaped HTML.

#ktistec #crystallang