autumn dragon

support indy artists!

i've tested ktistec compatibility with:

  • mastodon
  • peertube
  • pixelfed
  • lemmy

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:

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

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

newest addition

Character 田 ("ta/da") in the name of city 三田 ("sanda") is usually read as "da". As the character can also be read as "ta", Sanda is doing just that in December to call itself "Santa". Kanji are nice.

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

toddsundsted shared a note by wlNov 21, 2021

First time hosting much of a website myself, it's going ok now. Running ktistec for the activitypub federation stuff.

Hosting it on Hetzner's CPX11 (Memory: 2GB, Cores: 2) seems perfectly fine but you can't build the server if you don't have any swap (w/ 2gb mem), of which were my circumstances I discovered. The default Debian iso on Hetzner doesn't have any, so now you know.

But I had an obvious idea after told me to build it and then run the binary: build it on my machine and then transfer it over to run said binary, 16GB of RAM should do after all. And it did with slight trouble.

I cloned the repository, checked out the dist branch, and ran the suggested command: crystal build src/ktistec/

Subsequently an error:

/usr/bin/ld: cannot find -lgmp (this usually means you need to install the development package for libgmp)

On Fedora the package to install was gmp-devel

Ran the build command again, no error just warnings:

In src/controllers/

 33 | location = lookup(account).gsub("{uri}", URI.encode(actor.iri))
Warning: Deprecated URI.encode. Use `.encode_path` instead.

In /usr/share/crystal/src/uri/

 119 | { |io| encode(string, io, space_to_plus: space_to_plus) }
Warning: Deprecated URI.encode:space_to_plus. Use `.encode_path` instead.

A total of 2 warnings were found.

Warnings I can live with, but the resulting binary I can't because I stupidly built a dynamically linked one on my own system. Reading some documentation tells me about the --cross-compile flag:

This will generate a .o and will print a line with a command to execute on the system we are trying to cross-compile to.
You must copy this .o file to that system and execute those commands. Once you do this the executable will be available in that target system.

Simple enough, it gave me a command to run on my VPS. Transfer over the server.o file, and removed some weird "command -v pkg-config" stuff and here the command is:
cc server.o -o server  -rdynamic -L/usr/lib64/crystal -lgmp  -lxml2  -lsqlite3  -lz -lcrypto -lpcre -lm -lgc -lpthread -levent  -lrt -ldl -lm

Which Debian said to me:
/usr/bin/ld: cannot find -lgmp
/usr/bin/ld: cannot find -lxml2
/usr/bin/ld: cannot find -lsqlite3
/usr/bin/ld: cannot find -lz
/usr/bin/ld: cannot find -lcrypto
collect2: error: ld returned 1 exit status

Promptly I hunted down the appropriate dev packages for:
sudo apt install libgmp3-dev zlib1g-dev libsqlite3-dev libxml2-dev

Run the linking command again. It works.

$ ./server and here we are.

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.


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. 🎉