Release v2.4.11 of Ktistec
ktistec
I'm trying to decide how much of "quote posts" I want to support in Ktistec. On one hand, it's not trivial functionality, and I really do question how much extra value someone's comments on someone else's post will add to the Fediverse. On the other hand, I dunno... assuming Mastodon limits abuse by enforcing quoting rules, Ktistec could probably just follow along and display quoted posts. Is there any value in just that?
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.
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...
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:
screenshot of the setting page with the primary semantic color definedThese changes will be in the upcoming release. Existing themes will continue to work, as is.
#ktistec #crystallang #activitypub #fediverse
