{
  "@context":[
    "https://www.w3.org/ns/activitystreams",
    {"Hashtag":"as:Hashtag","sensitive":"as:sensitive"},
    {"toot":"http://joinmastodon.org/ns#","focalPoint":"toot:focalPoint"}
  ],
  "published":"2025-11-11T01:18:43.441Z",
  "attributedTo":"https://epiktistes.com/actors/toddsundsted",
  "replies":"https://epiktistes.com/objects/RAJbjd5sFKQ/replies",
  "to":["https://www.w3.org/ns/activitystreams#Public"],
  "cc":["https://epiktistes.com/actors/toddsundsted/followers"],
  "content":"<p>Okay, my analysis is complete! Here are the core changes to <a href=\"https://github.com/toddsundsted/ktistec\">Ktistec</a> required for <strong>Mastodon API compatibility:</strong></p><ul><li><strong>PKCE (Proof Key for Code Exchange) must be optional:</strong> Because Mastodon makes PKCE optional, clients don't support it, which means other servers <em>can't require it</em>. PKCE (and the <code>code_challenge</code> parameter) ensures that an authorization code can only be exchanged by the client that initiated the OAuth request.</li><li><strong>Support for the </strong><strong><code>client_credentials</code></strong><strong> grant type:</strong> The <code>client_credentials</code> 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 <code>null</code> account id in the client secrets table.</li><li><strong>Addition of a </strong><strong><code>created_at</code></strong><strong> timestamp property:</strong> Mastodon requires a non-standard <code>created_at</code> property in the body of the <code>/oauth/token</code> endpoint response instead of (in addition to) the standard <code>expires_in</code> property.</li><li><strong>Support for both form-encoded and JSON request bodies:</strong> This isn't a Mastodon requirement <em>per se</em> but popular clients clearly demand some latitude in what they send.</li><li><strong>WebFinger must accept requests with no </strong><strong><code>resource</code></strong><strong> parameter:</strong> This is honestly a bug on my part.</li><li><strong>Mastodon-compatible endpoints:</strong> 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...</li></ul><p>The only thing here that gives me heartburn is that PKCE is <em>not required</em>.</p><p><a href=\"https://epiktistes.com/tags/ktistec\" class=\"hashtag\" rel=\"tag\">#ktistec</a> <a href=\"https://epiktistes.com/tags/mastodonapi\" class=\"hashtag\" rel=\"tag\">#mastodonapi</a> <a href=\"https://epiktistes.com/tags/oauth\" class=\"hashtag\" rel=\"tag\">#oauth</a></p>",
  "contentMap":{
    "en-US":"<p>Okay, my analysis is complete! Here are the core changes to <a href=\"https://github.com/toddsundsted/ktistec\">Ktistec</a> required for <strong>Mastodon API compatibility:</strong></p><ul><li><strong>PKCE (Proof Key for Code Exchange) must be optional:</strong> Because Mastodon makes PKCE optional, clients don't support it, which means other servers <em>can't require it</em>. PKCE (and the <code>code_challenge</code> parameter) ensures that an authorization code can only be exchanged by the client that initiated the OAuth request.</li><li><strong>Support for the </strong><strong><code>client_credentials</code></strong><strong> grant type:</strong> The <code>client_credentials</code> 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 <code>null</code> account id in the client secrets table.</li><li><strong>Addition of a </strong><strong><code>created_at</code></strong><strong> timestamp property:</strong> Mastodon requires a non-standard <code>created_at</code> property in the body of the <code>/oauth/token</code> endpoint response instead of (in addition to) the standard <code>expires_in</code> property.</li><li><strong>Support for both form-encoded and JSON request bodies:</strong> This isn't a Mastodon requirement <em>per se</em> but popular clients clearly demand some latitude in what they send.</li><li><strong>WebFinger must accept requests with no </strong><strong><code>resource</code></strong><strong> parameter:</strong> This is honestly a bug on my part.</li><li><strong>Mastodon-compatible endpoints:</strong> 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...</li></ul><p>The only thing here that gives me heartburn is that PKCE is <em>not required</em>.</p><p><a href=\"https://epiktistes.com/tags/ktistec\" class=\"hashtag\" rel=\"tag\">#ktistec</a> <a href=\"https://epiktistes.com/tags/mastodonapi\" class=\"hashtag\" rel=\"tag\">#mastodonapi</a> <a href=\"https://epiktistes.com/tags/oauth\" class=\"hashtag\" rel=\"tag\">#oauth</a></p>"
  },
  "mediaType":"text/html",
  "attachment":[],
  "tag":[
      {"type":"Hashtag","name":"#ktistec","href":"https://epiktistes.com/tags/ktistec"},
      {"type":"Hashtag","name":"#mastodonapi","href":"https://epiktistes.com/tags/mastodonapi"},
      {"type":"Hashtag","name":"#oauth","href":"https://epiktistes.com/tags/oauth"}
  ],
  "type":"Note",
  "id":"https://epiktistes.com/objects/C8wCjYrZs8A"
}