"If you're not on board with AI you're going to get left behind"

Boost if you'd like to be left behind and would consider paying extra for a life without this bullshit.

###
3k boost edit: everyone who said a variant of "why should I pay" is right, but the world is wrong.

As a reminder fediblocking is stupid.

I have been a fedi admin for at least 6 years now and I have never domain blocked another instance ever.

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