This action will delete this post on this instance and on all federated instances, and it cannot be undone. Are you certain you want to delete this post?
This action will delete this post on this instance and on all federated instances, and it cannot be undone. Are you certain you want to delete this post?
This action will block this actor and hide all of their past and future posts. Are you certain you want to block this actor?
This action will block this object. Are you certain you want to block this object?
Are you sure you want to delete the OAuth client [Client Name]? This action cannot be undone and will revoke all access tokens for this client.
Are you sure you want to revoke the OAuth token [Token ID]? This action cannot be undone and will immediately revoke access for this token.
#ktistec 182 hashtags

I have started work on a Mastodon-compatible API layer intended to support the many Mastodon front-ends available. It is incomplete and requires an explicit build flag to enable, but what's there (the main timeline) already works with the official Mastodon app, Tusky, and Phanpy.
Here's the full changelog:
Fixed
Changed
As always, check out the full diff for the complete details.

This small release focused on two big deliverables: support for the latest version of Crystal and fixes for a few delivery issues.
Previous releases supported a wide range of Crystal Language versions, but ran into problems with version 1.17.x and beyond due to breaking changes in the standard library. This release works on 1.19.1 but also requires at least 1.19.1.
This release also fixes a bug, present since mid-2020 when HTTP signatures were first added, that resulted in signatures some fediverse servers wouldn't accept. Mastodon did, but with the proliferation of new ActivityPub servers, I increasingly encountered servers that did not.
Here's the full changelog:
Fixed
keyId now includes #main-key fragment.Changed
It's always good to stay up-to-date on releases. But if your platform doesn't yet support 1.19.1, I've also released a parallel branch that still runs on 1.16.3 and earlier. I'll maintain that branch for the next few releases to give everyone time to upgrade.

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
Changed
siteName to more standard nodeName.Fixed
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.

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

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.

RE: https://epiktistes.com/objects/8yfM5LbtUww
i just released an experimental version of this feature. i don't love how it looks but i do love reading this way. i'm going back through my timeline looking for chains of posts that i didn't read before that i can (more easily) read now!

i think i'm going to add a feature to #ktistec that rolls up a chain of self-replies into a single post that i can just read. i don't understand why that (mis)feature of twitter remains so popular on the #fediverse

Release v3.3.0 of Ktistec adds support for consent-respecting quote posts (FEP-044f). Quote posts represent the most lines of code I've written for any single changelog entry in my life.
Added
Changed
next_attempt_at in tasks now means not scheduled when nil.Important: Quote posts come with a few big caveats. I've been using iterations of this in production for weeks, but if you don't like what you read below you might want to wait for the patch release.

still working on quote posts... getting close...
as an aside, #ktistec x-ray mode is really useful when debugging and when i want to navigate to a quoted post that hasn't yet been remotely approved!

i think i'm going to add a feature to #ktistec that rolls up a chain of self-replies into a single post that i can just read. i don't understand why that (mis)feature of twitter remains so popular on the #fediverse