I've been on the Fediverse since January 2017. I initially ran a single-user instance of Mastodon. In March 2020 I started to write Ktistec, my own implementation of an ActivityPub server in Crystal (a language with the ergonomics of Ruby but the speed of Go) because I wanted something more supportive of writing. This #introduction was written and published on Epiktistes, my Ktistec instance.

I'm an Engineer by training but now I run teams for companies in climate-tech.

I love #music, #sciencefiction and #fantasy literature (yes, I'm an R. A. Lafferty fan), attend fan conventions like #worldcon and #dragoncon, and do regular #weightlifting. I am also learning to play the #bagpipes, and I'm (re)learning #japanese.

The Ktistec executable is now ~24.7% smaller and build times are 28% faster.

I've been blogging about optimizations here, here, and here. This is the summary of the final outcome, with links to commits for the curious. I have one more post planned with a summary of my thoughts.

Here's my approach. Use nm to dump the symbols in a release build executable and then look for things that seem redundant. The first change and associated post below is a great example of what I mean—my original implementation led to the specialization of the #== method for every pairwise combination of model classes even though the result of the comparison was just false.

This might seem like a strange approach if you come from a compiled language where you mostly write all of the code yourself or invoke generics explicitly, but Crystal takes your code and does that for you. And it's not always obvious up front (to me, at least) what the final cost will be.

I've include counts of the lines added/removed because the point of this whole post is to say if you measure first and then optimize, a small change can have a big impact.

Here are the changes:

• Specialize model #==. (+7 -5)
  I talked about this here but didn't have the commit to link to. This change results in a large reduction in executable size on regular builds (~4.0%) and a small difference on release builds (~0.2%).
• Remove conversion to Hash. (+2 -2)
  This commit eliminates specialization of methods like __for_internal_use_only that get passed both named tuples and hashes by going all in with named tuples. It also eliminates instantiations of the Hash generic type itself for these cases. Reduces executable size by ~2.2%.
• Eliminate duplicate code in the executable. (+3 -3)
  This small change reduces the size of the executable by a further ~0.4% by eliminating redundant definitions of __for_internal_use_only entirely.
• Make InstanceMethods instance methods. (+1 -5)
  This was a goofy design I picked up somewhere. It's unnecessary. Changing this saves ~0.2% on release build executable size.
• Move the code for digging through JSON-LD. (+246 -281)
  It looks like a lot of lines of code changed here, but the large numbers are the result of moving code line-by-line from an included module to a utility class. Invoking these as methods on the utility class rather than as instance methods on each including class reduces the executable size by ~0.5%.
• Use map from base ActivityPub model classes. (+10 -2)
  map is a class method defined on each ActivityPub base model class. Each definition maps JSON-LD to a hash that is used to instantiate the class. Class methods defined on a base class are available on subclasses, as well. Calling the method on the subclass results in a copy of the method. This change reduces the executable size by ~5.8%.
• Move map into helper. (+104 -88)
  The map method does not depend on class/instance state. This change ensures that the mapping code is not duplicated even if a subclass's map method is accidentally again called. It looks like a lot of changes but this commit is mostly reorganization. It reduces executable size by ~0.4%.
• Replace classes with aliases. (+62 -148)
  Implementing ActivityPub's vocabulary with discrete model classes is expensive because every model class comes with machinery for type-specific CRUD operations. Enumerate aliases on each base model class (e.g. a "Service" is an "Actor"). This change reduces executable size by ~16.9%.

I'm off to optimize some queries now...

#ktistec #crystallang

After I release a new version of ktistec, I build the server commit-by-commit to see which commits increase the server executable size and build time the most. I do this because I’ve learned that small implementation details (inlined code, small methods, using blocks) can have large impacts on these numbers.

Here's the output:

Commit         Size          Time
======== ========== ======= ===== =======
248850b1   36426264          10.3
47268073   36425688  -0.00%  10.5  +1.60%
344de272   36425688  +0.00%  10.8  +3.24%
ef561f52   36425944  +0.00%  10.8  -0.08%
8ae2cbd4   36429128  +0.01%  10.8  -0.01%
3e425f3b   36429128  +0.00%  10.8  +0.22%
1487d903   36427704  -0.00%  11.0  +1.42%
935c9ceb   36427016  -0.00%  11.0  +0.14%
de37dc6a   36427016  +0.00%  10.9  -0.97%
a660a326   36427016  +0.00%  10.8  -1.12%
ff3d990e   36427016  +0.00%  10.8  +0.54%
5724a58d   36523192  +0.26%  11.0  +1.78%
7b5057d4   36523640  +0.00%  11.0  -0.44%
30ca6a3f   36541352  +0.05%  11.6  +5.73%
e2327eea   36671592  +0.36%  11.0  -5.36%
ad0d76eb   36671592  +0.00%  10.9  -0.48%
d388e74f   36671592  +0.00%  11.4  +4.59%
dacea7ad   36671592  +0.00%  11.0  -3.76%
03d5dfd8   36671592  +0.00%  10.8  -1.63%
79d9d89f   36671576  -0.00%  11.0  +1.82%
b65d292f   36792376  +0.33%  11.1  +0.95%
0ef53365   36808904  +0.04%  11.6  +4.88%
b3766e7b   36808904  +0.00%  11.1  -4.50%
56ba79ce   36825416  +0.04%  11.1  -0.50%
4824df58   36825736  +0.00%  11.1  +0.31%
c4705143   36837544  +0.03%  11.1  -0.03%
e3d37ef7   36837768  +0.00%  11.5  +3.52%
4509fa0d   36837768  +0.00%  11.0  -3.83%
0ff9237b   36837768  +0.00%  11.0  -0.55%

Overall, the server executable size increased by about 1.1% and the build time increased by about 6.8%. Maybe that's not too bad for a major feature, but let's dig in.

It's nice to see that three commits account for almost all of the increase in server executable size:

• 5724a58d Add `language` to `Object`.
  2 files +19  loc
• e2327eea Render `contentMap` on ActivityPub objects.
  2 files +17 -1 loc
• b65d292f Add translation actions to the objects controller.
  1 file +35 loc

But, compare 5724a58d to 8ae2cbd4 (Add `language` to `Account`). It added +22 loc but didn't increase the server executable size as much.

In any case, I'll look at e2327eea first. I'd like to understand why this relatively small change adds 130,240 bytes to the server executable size!

The follow ups are here, here, here, and here.

#ktistec #crystallang

I think I’m going to work on a Mastodon-compatible API next. I did all the hard work figuring out what I need to change months ago so this should be smooth. I’m happy with the existing #ktistec UI but there is a lot of interesting work on the client side that I’d like to sample.

FWIW, I’m not opposed to C2S—Ktistec comes with a lot of the necessary abstractions. But I feel like my users, myself included, will get more bang out a Mastodon-compatible API. (But change my mind!)

The latest release of Ktistec addresses the shortcomings of the previous release that became apparent after using quote posts in production for a few days. So far, there have been no major bugs, but there was room for improvement.

Here's the full changelog.

Added

• Federation documentation (FEDERATION.md).
• Visibility (private or direct) icon in object summary.
• Object social activity details include dislikes.
• "quotes-me" theming class for objects.
• Notification for quote posts.
• MCP integration for quote posts.

Changed

• Renamed NodeInfo siteName to more standard nodeName.
• Increased hard-coded limits for actor attachments and pinned collections.

Fixed

• Displaying quoted posts in draft view.
• Visual indication of nested quotes in object view.

I added a FEDERATION.md document to the project. This is documentation required by FEP-67ff on "information necessary for achieving interoperability with a federated service". The document describes, at a high level, what federation protocols and standards Ktistec currently supports.

#ktistec #crystallang #activitypub #fediverse

it would make me very happy if more people on the fediverse, especially those that see themselves as pillars of progressivism, treat others with a little more grace and thoughtfulness.

(I’m not advocating for being nice to fascists. I’m asking you to be nice to people here who share 99.9% of your values and differ on that one thing.)

working on writing FEDERATION.md i already found one easily fixable deviation (siteName instead of nodeName in nodeinfo).

#ktistec #ActivityPub #Fediverse

Before creating and publishing FEDERATION.md for #ktistec I wanted to understand what existing practice looked like across the Fediverse.

FEP-67ff describes the requirements of the FEDERATION.md file in loose terms and provides a non-normative template. I scraped the URLs of FEDERATION.md files from FEP-67ff itself and confirmed I could fetch them. The FEP listed 30 accessible projects (31 total, but one project—FIRM—does not appear to exist).

If a file had a section with the heading "Supported FEPs" per the non-normative template, I only looked there for supported FEPs. Otherwise I scanned the entire document.

Implemented FEPs, ranked by the number of implementations that attest support, are:

FEP   Name                                                        #
----  ---------------------------------------------------------  --
67ff  FEDERATION.md                                              18
f1d5  NodeInfo in Fediverse Software                             16
8b32  Object Integrity Proofs                                     7
044f  Consent-respecting quote posts                              7
2677  Identifying the Application Actor                           7
e232  Object Links                                                6
1b12  Group federation                                            6
3b86  Activity Intents                                            6
521a  Representing actor's public keys                            5
2c59  Discovery of a Webfinger address from an ActivityPub actor  5
7888  Demystifying the context property                           5
5feb  Search indexing consent for actors                          5
4adb  Dereferencing identifiers with webfinger                    4
d556  Server-Level Actor Discovery Using WebFinger                4
fb2a  Actor metadata                                              4
ef61  Portable Objects                                            4
8fcf  Followers collection synchronization across servers         4
844e  Capability discovery                                        4
7628  Move actor                                                  3
61cf  The OpenWebAuth Protocol                                    3
c390  Identity Proofs                                             3
400e  Publicly-appendable ActivityPub collections                 3
c0e0  Emoji reactions                                             3
0151  NodeInfo in Fediverse Software (2025 edition)               3
fffd  Proxy Objects                                               2
f228  Backfilling conversations                                   2
fe34  Origin-based security model                                 2
eb48  Hashtags                                                    2
171b  Conversation Containers                                     2
a5c5  Web Syndication Methods                                     2

There are obvious flaws in the methodology. Or maybe in the data. Only 18 out of the 30 projects I could access had a FEDERATION.md that attested FEDERATION.md support. Only 19 mentioned "FEDERATION.md". Only 21 mentioned "67ff". The remaining projects clearly did support FEP-67ff—the file itself was evidence. (FEDERATION.md is not meant to be machine readable—there's an issue about that).

It was more difficult to rank implemented federation protocols. I extracted keywords from documents with a  "Supported federation protocols and standards" section and created a dictionary of terms. If a file had a section with the heading "Supported federation protocols and standards", I only looked there. Otherwise I scanned the entire document.

Feature            #
----------------  --
activitypub       26
webfinger         24
http_signatures   21
nodeinfo          19
json_ld            2
ld_signatures      2
ostatus            2
authorized_fetch   1
atproto            1

If time allows, I'm going to try to rank these documents by "utility", though I haven't yet determined the exact metric. These documents clearly provide valuable information, but their lack of standardization makes them harder to analyze systematically.

#ActivityPub #Fediverse #Fep67ff #fep