this chart shows inbound activitypub messages to my server. over time fediverse instances seem to receive increasing numbers of messages, many not addressed to anyone on the instance, so this represents an increase in that passive traffic, replies to other people's posts, as well as announcements/boosts/shares.

n.b. you can see all of the inbound messages to your ktistec server on the /everything endpoint.

#ktistec #fediverse #activitypub

among other improvements, document how rules work.

it's now possible to customize how ktistec processes ActivityPub inbound and outbound activities without having to write crystal language and recompile the server.

#ktistec #activitypub

i'm still making lots of small changes/improvements to ktistec: upgrading dependencies, fixing bugs, and cleaning up. i'm laying the foundation for improvements to the experience of reading posts on your ktistec instance—a reactive user interface with streaming updates/notifications, the ability to follow arbitrary collections of objects, and a timeline that can flexibly highlight content you find interesting (vs. displaying posts in chronological order). underpinning all of this is a flexible, scriptable, rule-based language for customizing the experience.

#ktistec #activitypub #fediverse

it would be nice to have a way to federate users around topics or areas of interest, without having to join a specific server. it would make it easier for people to discover each other based on interests, regardless of the server they join. federated interests...?

#activitypub #musing

i don't know about this decision:

It is suggested that LitePub implementations supply a locally hosted version of the LitePub JSON-LD Context as their @context.

what i see in practice (N > 100) is the same "litepub-0.1.jsonld" context but different URLs. all of these identical contexts have to be fetched, parsed, cached (hopefully).

it seems wasteful.

#activitypub

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