aaaaand i've tagged the v1.0.0 release of ktistec! 🎉 🎊 🥂

the last push was for greater compatibility with other fediverse servers—it took quite a bit of yak-shaving to get it done.

i also released a docker image if you want to try it out:

docker run --rm -it -p 3000:3000 toddsundsted/ktistec:latest

enjoy!

#ktistec

i've tested ktistec compatibility with:

• mastodon
• peertube
• pixelfed
• lemmy
• write.as

many things work—follows in both directions and creating/updating notes (AKA toots, etc.)—but there's lots of room for improvement. lemmy, for example, announces activities instead of forwards activities. i'm working on 1.0, but in the next major release, i'll build server-specific extensions to handle more of these kind of issues.

i created a few issues in other repos:

• https://github.com/pixelfed/pixelfed/issues/3049
• https://github.com/pixelfed/pixelfed/issues/3050

and worked around a few issues that haven't quite rolled out:

• https://github.com/LemmyNet/lemmy/pull/1962

and made many other concessions for compatibility.

#activitypub #ktistec

once you've seen one activitypub implementation, you've seen one activitypub implementation.

i just wrapped up a whole lot of interoperability work for ktistec. bottom line, you can't just read and implement the activitypub spec et al and expect anything to federate with your implementation. your best bet, in fact, is to doggedly copy the mastodon implementation, right down to the braces and brackets—since every other implementation is at least shooting for mastodon compatibility—and then work from there.

to be fair, about half of the fixes were arguably due to bugs in my own code. but seriously lemmy, why do you require the json-ld context to be a list, even when the context is defined by a single URL...?

#activitypub #ktistec

one criticism of activitypub is that it's not a specification, and as a consequence you have to test extensively to ensure interoperability between implementations.

this is a valid criticism.

1. minimally you need to implement a few things beyond activitypub to get even basic interoperability with popular implementations—http signatures at a minimum (and a draft version of that) and probably webfinger. (i guess this really isn't a problem with activitypub per se, but it sure feels like it is.)
2. the recommendation doesn't tell you what to do with the various object types, so even if you get the basic transport working, you don't really have an application. what's the right way to implement an interoperable "comment", for example?
3. and then there are interoperability problems in practice—just scan the issues for popular implementations. these have to be identified and fixed multiple times, every time someone spins up a new implementation.

to some degree i guess i don't care. i'm building a free/open source application not a commercial product, and it's aimed at relatively tech-savvy users, and i kind of enjoy spelunking issues like these anyway, but for anyone whose goal is mass adoption of the "fediverse" concept, it's a problem.

#activitypub #ktistec

a major milestone in the life of ktistec... with the release of blocking, the database schema for 1.0 is now fixed. this means no more migrations. i'm working on a few interoperability issues, and then i'll tag 1.0.

#ktistec

commits a2f3fad to 485dbf2 add support for blocking actors and objects. like many things, blocking is built on the back on a lot of earlier cleanup and refactoring.

as expected, blocking an actor removes the actor and its content from your timelines. blocking an object removes only that object.

finishing this is the last blocker to a 1.0 release. 🎉

#ktistec

before it was called "agile programming" it was called "extreme programming". one of the tenets of extreme programming is "merciless refactoring". another is "edgy adjectives".

an often overlooked "freedom" in a free software project is the freedom to refactor, mercilessly. why turn a free software project into a feature factory? you can get that in an office job, right?

anyway, commits 14d22ca to 14fb9af do away with 1860 lines of code, while only adding 880 lines. more importantly, they do away with quite a lot of distracting boilerplate—like explicit identifiers (IRIs) that usually have no bearing on the outcome of a test.

the one big addition was spec_helper/factory.cr (349 lines), which adds lightweight factories that take care of the details of instantiating a valid model instance.  i picked up the build/create paradigm from the factory_bot gem, and extended the let/let! pattern used in spectator.

#ktistec #agile #extreme #refactoring

in ktistec news, commits 4d2f699 through 4d2f699 include several improvements and bug fixes. highlights:

• at runtime, the KTISTEC_DB environment variable overrides the default location for the SQLite database file. i use this during testing. it may be useful for some deployments.
• the background TaskWorker now kicks off as soon as a new task is scheduled. the previous implementation polled for new work every five seconds.
• i collected all inbox/outbox side-effects in one location. this makes mailbox processing easier to reason about, and also made it easier to prevent a race condition that resulted in the same object being added to the timeline more than once†.
• images are lazy loaded in browsers that support loading="lazy".

i'm also now only one feature away—blocking actors and objects—from tagging the 1.0.0 release.

† the race condition occurs when an activity, like a create, arrives that takes a long time to validate, maybe because ids need to be dereferenced. while it's being validated, an announce activity arrives for the same object. now two activities for the same object are being processed concurrently. being added to a timeline is a side-effect, and collecting all side-effects in one location made it easier to put the duplicate check after validation but before any side-effects, which saved me from having to unwind side-effects if a duplicate was detected.

#ktistec

what a difference one line of code makes!

commit fe18dc5 moved the line @saved_record : self | Nil = nil from the module Ktistec::Model::InstanceMethods into the macro Ktistec::Model.included.

that single change cut the build time in half and reduced the memory required to build by about a third. you can be sure the improvement came as a surprise!

but really, it wasn't just this change itself—although it introduced the biggest improvement—because after all of the subsequent refactoring, simply moving the line back didn't increase the build time again.

the build time also improved slightly after other subsequent commits. and several of those commits introduced changes that reduced the amount of macro generated code. and that's the key insight: macros reduce visible boilderplate but don't reduce actual code that needs to be compiled.

i'm still investigating, but clearly the original placement of the line resulted in the generation of a lot of redundant/unnecessary code!

TL;DR if you're planning on using macros in crystal, check your build times before and after your changes—i'm sure there's a corresponding commit somewhere in the past that introduced this problem and i didn't catch it!

#ktistec #crystal

whoa! there are two instances...

https://fedidb.org/software/ktistec

#ktistec