{
"type": "entry",
"published": "2026-11-06 13:01-0800",
"url": "https://gregorlove.com/2026/11/to-read-a-resistance-history-of-the-united-states/",
"content": {
"text": "Want to read: A Resistance History of the United States by Tad Stoermer (ISBN 9781586424367)",
"html": "<p>Want to read: <span class=\"p-read-of h-cite\"><a class=\"u-url\" href=\"https://gregorlove.com/isbn/9781586424367\">A Resistance History of the United States</a> by <span class=\"p-author\">Tad Stoermer</span> (ISBN <span class=\"p-uid\">9781586424367</span>)</span></p>"
},
"author": {
"type": "card",
"name": "gRegor Morrill",
"url": "https://gregorlove.com/",
"photo": "https://gregorlove.com/site/assets/files/6268/profile-2021-square.300x0.jpg"
},
"post-type": "note",
"_id": "50151650",
"_source": "95"
}
{
"type": "entry",
"published": "2026-11-05T03:07:55.314077+00:00",
"url": "https://cleverdevil.io/2026/ugh-of-all-the-weeks-for-malachi-toney-t",
"syndication": [
"https://cleverdevil.club/@jonathan/117561627469159956",
"https://bsky.app/profile/cleverdevil.io/post/3mzjvaplpyt2e"
],
"content": {
"text": "Ugh\u2026 of all the weeks for Malachi Toney to get injured \ud83e\udd26",
"html": "<p>Ugh\u2026 of all the weeks for Malachi Toney to get injured \ud83e\udd26</p>"
},
"author": {
"type": "card",
"name": "Jonathan LaCour",
"url": "https://cleverdevil.io",
"photo": "https://cleverdevil.io/profile/photo"
},
"post-type": "note",
"_id": "50130699",
"_source": "10"
}
{
"type": "entry",
"author": {
"name": null,
"url": "https://herestomwiththeweather.com/",
"photo": null
},
"url": "https://herestomwiththeweather.com/2026/11/03/outgoing-rfc-9421-signatures/",
"published": "2026-11-03T13:41:15+00:00",
"content": {
"html": "<p>Previously, I mentioned that support for incoming <a href=\"https://www.rfc-editor.org/info/rfc9421/\">RFC 9421</a> signatures was added to <a href=\"https://github.com/herestomwiththeweather/irwin\">Irwin</a> for inbox deliveries. A week ago, I finished implementing outgoing signatures for both inbox deliveries and \u201cauthorized fetch\u201d GET requests. So, how does it know whether to send a legacy signature or a new RFC 9421 signature? In general, the <a href=\"https://swicg.github.io/activitypub-http-signature/#how-to-upgrade-supported-versions\">double-knocking technique</a>:</p>\n\n<blockquote>\n <p>First, try generating or verifying an HTTP Signature with one version, ideally (but not necessarily) the latest. If the remote server rejects that signature, eg with an HTTP 401 response, or the incoming signature doesn\u2019t verify, try with another version. Repeat until a signature passes or you\u2019ve tried all supported versions.</p>\n\n <p>(Many fediverse servers do process incoming activities asynchronously, but they generally still verify signatures synchronously, so double knocking is still viable when delivering activities to remote inboxes.)</p>\n</blockquote>\n\n<p>So, first try RFC 9421 and if that returns a 401, then retry with the legacy signature.</p>\n\n<p>However, Irwin also has a hosts database table and a new <code>legacy_signature</code> boolean was added to it. By default, it is false. There is a long tail of fediverse hosts that do not support RFC 9421: many hosts that my fediverse server rarely interacts with and I do not bother with setting their <code>legacy_signature</code> to true.</p>\n\n<p>However, there are a few that my fediverse server does interact with a lot, so their host records have been updated so that Irwin doesn\u2019t make many unnecessary requests. For example, threads.net returns 404 when it is sent a request signed with RFC 9421 rather than the expected 401 that correctly implemented servers return.</p>\n\n<p>So, at the start of <a href=\"https://github.com/herestomwiththeweather/irwin/blob/main/app/lib/http_client.rb#L42\">HttpClient#request_headers()</a>, the legacy signature is sent for such hosts:</p>\n\n<pre><code> def request_headers(method_string, legacy_signature = false)\n if !legacy_signature && Host.find_by(name: @url.host)&.legacy_signature\n Rails.logger.info \"#{self.class}##{__method__} setting legacy signature for #{@url.host}\"\n legacy_signature = true\n end\n</code></pre>\n\n<p>The API method to construct signature headers for both legacy and RFC 9421 signatures is the same.</p>\n\n<pre><code> klass = legacy_signature ? Serge::FediSignature : Serge::MessageSignature\n Rails.logger.info \"#{self.class}##{__method__} signing request with #{klass}\"\n\n headers.merge!(\n klass.headers(\n method: method_string,\n url: @url,\n body: @body,\n public_key_id: @main_key_url,\n private_key: @private_key\n )\n )\n</code></pre>\n<p>The ruby gem library <a href=\"https://github.com/herestomwiththeweather/serge\">serge</a> that is being used here uses the <a href=\"https://github.com/nomadium/linzer\">linzer</a> gem for RFC 9421 signatures and Irwin\u2019s old code for the legacy signatures.</p>",
"text": "Previously, I mentioned that support for incoming RFC 9421 signatures was added to Irwin for inbox deliveries. A week ago, I finished implementing outgoing signatures for both inbox deliveries and \u201cauthorized fetch\u201d GET requests. So, how does it know whether to send a legacy signature or a new RFC 9421 signature? In general, the double-knocking technique:\n\n\n First, try generating or verifying an HTTP Signature with one version, ideally (but not necessarily) the latest. If the remote server rejects that signature, eg with an HTTP 401 response, or the incoming signature doesn\u2019t verify, try with another version. Repeat until a signature passes or you\u2019ve tried all supported versions.\n\n (Many fediverse servers do process incoming activities asynchronously, but they generally still verify signatures synchronously, so double knocking is still viable when delivering activities to remote inboxes.)\n\n\nSo, first try RFC 9421 and if that returns a 401, then retry with the legacy signature.\n\nHowever, Irwin also has a hosts database table and a new legacy_signature boolean was added to it. By default, it is false. There is a long tail of fediverse hosts that do not support RFC 9421: many hosts that my fediverse server rarely interacts with and I do not bother with setting their legacy_signature to true.\n\nHowever, there are a few that my fediverse server does interact with a lot, so their host records have been updated so that Irwin doesn\u2019t make many unnecessary requests. For example, threads.net returns 404 when it is sent a request signed with RFC 9421 rather than the expected 401 that correctly implemented servers return.\n\nSo, at the start of HttpClient#request_headers(), the legacy signature is sent for such hosts:\n\n def request_headers(method_string, legacy_signature = false)\n if !legacy_signature && Host.find_by(name: @url.host)&.legacy_signature\n Rails.logger.info \"#{self.class}##{__method__} setting legacy signature for #{@url.host}\"\n legacy_signature = true\n end\n\n\nThe API method to construct signature headers for both legacy and RFC 9421 signatures is the same.\n\n klass = legacy_signature ? Serge::FediSignature : Serge::MessageSignature\n Rails.logger.info \"#{self.class}##{__method__} signing request with #{klass}\"\n\n headers.merge!(\n klass.headers(\n method: method_string,\n url: @url,\n body: @body,\n public_key_id: @main_key_url,\n private_key: @private_key\n )\n )\n\nThe ruby gem library serge that is being used here uses the linzer gem for RFC 9421 signatures and Irwin\u2019s old code for the legacy signatures."
},
"name": "Outgoing RFC 9421 Signatures",
"post-type": "article",
"_id": "50114987",
"_source": "246"
}
