commits b9e0658d to d42482bb cut the time required to run all #ktistec tests from ~35 seconds to ~26 seconds, a savings of about 25% (there are currently 5114 tests). the faster tests run, the more you run them, so this is a good outcome.

no #ktistec release this week. i have been working on bookmarked posts, pinned/featured posts, as well as some minor performance improvements, but i need to spend time fixing an issue with my libxml extensions that is preventing me from moving to the latest release of #crystallang. i've been putting it off but it's gotta get done, so...

Okay, my analysis is complete! Here are the core changes to Ktistec required for Mastodon API compatibility:

• PKCE (Proof Key for Code Exchange) must be optional: Because Mastodon makes PKCE optional, clients don't support it, which means other servers can't require it. PKCE (and the code_challenge parameter) ensures that an authorization code can only be exchanged by the client that initiated the OAuth request.
• Support for the client_credentials grant type: The client_credentials grant type is used to grant a client app-level access without requiring user authentication. Mastodon requires this for some of its "public" API endpoints. This necessitates a change to the database schema to allow a null account id in the client secrets table.
• Addition of a created_at timestamp property: Mastodon requires a non-standard created_at property in the body of the /oauth/token endpoint response instead of (in addition to) the standard expires_in property.
• Support for both form-encoded and JSON request bodies: This isn't a Mastodon requirement per se but popular clients clearly demand some latitude in what they send.
• WebFinger must accept requests with no resource parameter: This is honestly a bug on my part.
• Mastodon-compatible endpoints: A boatload of them. Clients expect many endpoints and don't gracefully degrade if they're not present. Really I should just implement features like pinned posts and bookmarks...

The only thing here that gives me heartburn is that PKCE is not required.

#ktistec #mastodonapi #oauth

There are two big features in release v3.1.3 of Ktistec: auto-approve followers and a new image viewer.

Auto-approve followers is conceptually simple ("the server automatically sends an Accept activity when it receives a Follow activity") but it required extensive changes to some of the oldest code in the codebase: the inboxes and outboxes controllers. I refactored inbox and outbox side-effect processing into independent services, which made it possible to support side-effects like auto-approve follow (and also auto-follow back), without having to go through the controllers.

A more significant change for me personally was replacing the lightGallery image gallery (an external dependency) with my own implementation. It's not as slick, and not as full of features—I wrote it in two days—but it is fully free software, and that's important to me.

Added

• Add admin page for managing OAuth access tokens.
• Add support for auto-approve followers. (fixes #26)
• Add support for auto-follow back.

Fixed

• Prevent triggering actor refresh when user is anonymous.

Changed

• Replace "lightgallery" dependency with custom image viewer.
• Set OAuth access token expiry to 30 days (previously expired after 24 hours).
• Refactor inbox and outbox processing into dedicated processor services.

The OAuth changes set the groundwork for better support of the Mastodon API and the Fediverse clients that depend on it. Stay tuned!

#ktistec #fediverse #activitypub #crystallang

I’m exploring features for navigating and reading large threads. A “large thread” is a thread with more than 250 replies. I personally can’t easily consume all of that, and quite a number of replies are uninformative in any case (they are simple statements of agreement or dismissal).

Some things I’m trying:

• Highlighting replies by the original poster—the assumption is that, if I'm interested in the thread, I'm interested in what the original poster had to add.
• Highlighting replies with a larger than average number of replies, in turn—the assumption being, they must have added something meaningful to the thread.
• Maybe longer replies are more interesting? Highlight them?

By way of replies to this post, I am definitely interested in others' thoughts on good heuristics.

#ktistec

I'm working on federation issues.

👻 Release v3.1.2 of Ktistec improves support for Lemmy and community servers like it that distribute content by wrapping it in Announce activities (FEP-1b12: Group federation support). Ktistec also supports the audience property, although support for that was removed from Lemmy earlier this year.

🎃 This release also adds support for delivering to shared inboxes, which are widely supported by other ActivityPub servers. Despite being federated, the Fediverse is not highly distributed, and this optimization can reduce outbound delivery traffic by 10-20x.

Added

• Support for the Dislike activity.
• Support for the audience property on activities and objects.
• Support for delivery to shared inboxes.
• Support for full-width hash signs in hashtags (e.g. ＃日本語) commonly used in Japanese and other Asian languages.

Fixed

• Strip HTML from object summaries rather than escaping it.
• Properly unwrap Lemmy-style Announce activities.

Changed

• Destroy discarded drafts instead of deleting them.

Enjoy!

#ktistec #fediverse #activitypub #crystallang

i'm too lazy to read a thread with 420+ replies so i'm building a little tool using the #ktistec API that will summarize that thread for me.

time to just read the thread: probably 15 minutes. time to build the little tool: well i started on it an hour ago and...

#LazinessIsAVirtue

i added better support for delivering to shared inboxes in #ktistec. kind of lame, but this post is how i'm testing it...