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 160 hashtags

The big feature in release v3.2.2 of Ktistec is pinned posts with support for the Mastodon Featured Posts collection. Federation works both ways—pin a post on Ktistec and it will show up as a pinned post on Mastodon and vice versa. When you refresh an actor profile, Ktistec also fetches and updates the actor's pinned posts. This is another small step in the direction of supporting all features that Mastodon-compatible client applications expect to access via the API. It's also useful in its own right.
The other major feature, which I posted a short video demonstrating here, is X-Ray Mode. X-Ray Mode is a developer and power-user tool for inspecting ActivityPub JSON-LD representations of actors, objects, and other content. Pressing Ctrl+Shift+X on any page displays the data behind the page—like an x-ray. You can:
Alt+Left and Alt+Right to navigate through your viewing historyThis feature is useful for debugging federation issues, understanding ActivityPub structures, and verifying how content is stored and represented.
Here's the full changelog for the release:
Added
Changed
The next release will focus on smaller features and bug fixes.
Enjoy!

would a "more from this actor" button be helpful on #ktistec? the use case is 1) navigate to an actor you're thinking of following, 2) click on "more from this actor" to fetch ~10 additional, recent posts. is there another feature that would be more useful?

I've streamlined theme development in Ktistec. The theming system uses a hierarchy of CSS custom properties and fallbacks. Theme authors can customize a theme at multiple levels:
Base Colors Only
Define only base colors like --text-primary, --bg-primary, --bg-input, --semantic-primary, etc. Derived colors will auto-generate using color-mix formulas. For example:
:root { --semantic-primary: #ffa500; }From this one line, theme-appropriate colors like --bg-accent-code, --anchor-color, etc. auto-generate.
Base Colors Plus Derived Colors
Define base colors and derived colors. Derived colors use custom values when defined. Undefined derived colors auto-generate. For example:
:root {
--text-primary: #333;
--text-primary-2: #ff0000; /* red for this specific shade */
}Given this theme, derived shades like --text-primary-1, --text-primary-3, and --text-primary-4 auto-generate. --text-primary-2 is red.
The simplest possible interesting theme redefines the primary semantic color. The single line above (in Base Colors Only) would result in the following, with button color, link color, disabled, selected, and hover states all derived automatically:

These changes will be in the upcoming release. Existing themes will continue to work, as is.

Experimenting with x-ray mode for ktistec.

Release v3.2.1 of Ktistec adds support for bookmarking posts. This was so immediately useful I don't know why it took me so long to get around to it!
Pinned/featured posts are in the works for the next release.
The full changelog:
Added
Fixed
Changed
In other thoughts... I'd like to make followed hashtags more consumable. I follow ~10 hashtags and: 1) it's hard to tell what's new, 2) it feels like they arrive in large batches that are difficult to digest, and 3) the reading experience is meh.

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

The major feature in v3.2.0 of Ktistec is thread analysis. The previous release, v3.1.2, added support for viewing threads from Lemmy communities. I follow the Open Source community, which leads to many large threads. The thread on FFMpeg and Google has 112 posts and is still growing.
Thread analysis helps me navigate these extensive conversations. It includes: top contributors, a timeline histogram, and notable branches.
The analysis applies several heuristics to identify interesting branches of the main thread. “Interesting” is subjective, but the algorithm currently looks for sudden bursts of activity and highlights those areas. Ktistec uses this to create a table of contents that links directly to those branches. Clicking on one of these links takes you to a branch-only view that focuses on the selected part of the thread.
It's fast—I anticipated needing to cache analyses, but analyzing a thread with over 400 posts takes only about 50 milliseconds on my production server.

This release also addresses an object visibility regression that was introduced in a previous version.
Full Changelog
Added
analyze_thread and get_threadFixed
Changed

I love a good discussion, but navigating large threads is difficult, and filtering the dross to find the silver and gold is tedious. I am working on thread analytics and an improved thread header to make it easier to identify the interesting bits and to quickly navigate to them.
Here's a peek:

In addition to top contributors, the thread header now includes a timeline histogram showing periods of engagement, and a table of contents with notable branches and direct links to those branches.
This feature is still under development, so expect changes and refinements before the next release.

Okay, my analysis is complete! Here are the core changes to Ktistec required for Mastodon API compatibility:
code_challenge parameter) ensures that an authorization code can only be exchanged by the client that initiated the OAuth request.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.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.resource parameter: This is honestly a bug on my part.The only thing here that gives me heartburn is that PKCE is not required.