https://codeberg.org/wiktor 2026-04-01T02:23:40+02:00 <p dir="auto">I work on cryptographic software and integration with hardware security modules (TPMs, PKCS#11...)</p> 2026-03-17T12:35:42+01:00 111305916: https://codeberg.org/openpgp-card/state/pulls/17#issuecomment-11744703 Implement an ephemeral pin storage backend for Linux <p dir="auto">I wonder if we need a bit of documentation on the backend in the README too? (I think it&#39;d be cool to also list a couple of <code>keyctl</code> commands to see the PIN...)</p>

Implement an ephemeral pin storage backend for Linux <p dir="auto">I wonder if we need a bit of documentation on the backend in the README too? (I think it&#39;d be cool to also list a couple of <code>keyctl</code> commands to see the PIN...)</p>

wiktor [email protected] 2026-03-16T15:09:04+01:00 110899578: https://codeberg.org/openpgp-card/state/pulls/17#issuecomment-11713041 Implement an ephemeral pin storage backend for Linux <p dir="auto"><a href="/classabbyamp" class="mention" rel="nofollow">@classabbyamp</a> wrote in <a href="https://codeberg.org/openpgp-card/state/pulls/17#issuecomment-11710794" class="ref-issue" rel="nofollow">#17 (comment)</a>:</p>

Implement an ephemeral pin storage backend for Linux <p dir="auto"><a href="/classabbyamp" class="mention" rel="nofollow">@classabbyamp</a> wrote in <a href="https://codeberg.org/openpgp-card/state/pulls/17#issuecomment-11710794" class="ref-issue" rel="nofollow">#17 (comment)</a>:</p>

wiktor [email protected] 2026-03-16T12:39:07+01:00 110848872: https://codeberg.org/openpgp-card/state/pulls/17#issuecomment-11707419 Implement an ephemeral pin storage backend for Linux <p dir="auto"><a href="/classabbyamp" class="mention" rel="nofollow">@classabbyamp</a> wrote in <a href="https://codeberg.org/openpgp-card/state/pulls/17#issuecomment-11678862" class="ref-issue" rel="nofollow">#17 (comment)</a>:</p>

Implement an ephemeral pin storage backend for Linux <p dir="auto"><a href="/classabbyamp" class="mention" rel="nofollow">@classabbyamp</a> wrote in <a href="https://codeberg.org/openpgp-card/state/pulls/17#issuecomment-11678862" class="ref-issue" rel="nofollow">#17 (comment)</a>:</p>

wiktor [email protected] 2026-02-27T13:09:14+01:00 103891790: https://codeberg.org/mechko/awesome-maintainer-funding/issues/7 <p dir="auto">A friend sent me a link to <a href="https://endowment.dev/funding/" rel="nofollow">https://endowment.dev/funding/</a></p> <p dir="auto">I don&#39;t know anything about it but on the surface it seems fitting here... hopefully you don&#39;t mind me creating a tracking ticket here <span class="emoji" aria-label="grinning face with sweat" data-alias="sweat_smile">😅</span></p> <p dir="auto">Have a nice day! <span class="emoji" aria-label="waving hand" data-alias="wave">👋</span></p>

7#Investigate Open Source Endowment#

wiktor [email protected] 2026-02-03T11:49:29+01:00 96166960: https://codeberg.org/iNPUTmice/Conversations/issues/640#issuecomment-10337866 Allow a text body in the same Message as a http-upload. <p dir="auto"><a href="/licaon-kter" class="mention" rel="nofollow">@licaon-kter</a> wrote in <a href="https://codeberg.org/iNPUTmice/Conversations/issues/640#issuecomment-5904571" class="ref-issue" rel="nofollow">#640 (comment)</a>:</p>

Allow a text body in the same Message as a http-upload. <p dir="auto"><a href="/licaon-kter" class="mention" rel="nofollow">@licaon-kter</a> wrote in <a href="https://codeberg.org/iNPUTmice/Conversations/issues/640#issuecomment-5904571" class="ref-issue" rel="nofollow">#640 (comment)</a>:</p>

wiktor [email protected] 2026-01-26T13:59:34+01:00 94074765: https://codeberg.org/iNPUTmice/Conversations/pulls/778 <p dir="auto">Found it when reading the README.</p>

778#Fix a typo in README.md#

wiktor [email protected] 2026-01-26T13:58:47+01:00 94074594: https://codeberg.org/wiktor/Conversations/commit/1b69b9a1d85b9e4f9deeeb99aa526be5c1656d71 <a href="https://codeberg.org/wiktor/Conversations/commit/1b69b9a1d85b9e4f9deeeb99aa526be5c1656d71" rel="nofollow">1b69b9a1d85b9e4f9deeeb99aa526be5c1656d71</a> Fix a typo in README.md

<a href="https://codeberg.org/wiktor/Conversations/commit/1b69b9a1d85b9e4f9deeeb99aa526be5c1656d71">1b69b9a1d85b9e4f9deeeb99aa526be5c1656d71</a> Fix a typo in README.md

wiktor [email protected] 2026-01-26T13:58:47+01:00 94074591: https://codeberg.org/wiktor/Conversations/src/branch/fix-readme-patch wiktor [email protected] 2026-01-26T13:57:33+01:00 94074342: https://codeberg.org/wiktor/Conversations wiktor [email protected] 2026-01-26T12:35:14+01:00 94045215: https://codeberg.org/iNPUTmice/Conversations/issues/777#issuecomment-10172295 MUC avatar not displaying <p dir="auto">Ack. Thanks for a thorough explanation! I&#39;ll check the servers but this sounds to be relevant: <a href="https://issues.prosody.im/1922" rel="nofollow">https://issues.prosody.im/1922</a></p>

MUC avatar not displaying <p dir="auto">Ack. Thanks for a thorough explanation! I&#39;ll check the servers but this sounds to be relevant: <a href="https://issues.prosody.im/1922" rel="nofollow">https://issues.prosody.im/1922</a></p>

wiktor [email protected] 2026-01-26T11:31:02+01:00 94019316: https://codeberg.org/iNPUTmice/Conversations/issues/777#issuecomment-10170990 MUC avatar not displaying <blockquote> <p dir="auto">Private groups?</p> </blockquote>

MUC avatar not displaying <blockquote> <p dir="auto">Private groups?</p> </blockquote>

wiktor [email protected] 2026-01-26T09:45:37+01:00 93990465: https://codeberg.org/iNPUTmice/Conversations/issues/777#issuecomment-10168305 MUC avatar not displaying <p dir="auto">FWIW I also have this problem (I&#39;m using 2.19.9+playstore). I see there were quite a few issues about avatars already and some fixes 7 months ago... <span class="emoji" aria-label="thinking face" data-alias="thinking">🤔</span></p>

MUC avatar not displaying <p dir="auto">FWIW I also have this problem (I&#39;m using 2.19.9+playstore). I see there were quite a few issues about avatars already and some fixes 7 months ago... <span class="emoji" aria-label="thinking face" data-alias="thinking">🤔</span></p>

wiktor [email protected] 2025-11-02T18:19:02+01:00 69855338: https://codeberg.org/keyoxide/keyoxide-web/issues/154#issuecomment-8049743 Show UID comment <blockquote> <p dir="auto">I&#39;ll definitely switch to that</p> </blockquote>

Show UID comment <blockquote> <p dir="auto">I&#39;ll definitely switch to that</p> </blockquote>

wiktor [email protected] 2025-11-01T21:51:25+01:00 69712760: https://codeberg.org/keyoxide/keyoxide-web/issues/154#issuecomment-8041805 Show UID comment <blockquote> <p dir="auto">After GitHub and Codeberg, <a href="https://keyoxide.org/[email protected]" rel="nofollow">https://keyoxide.org/[email protected]</a> points now to my self-hosted website <span class="emoji" aria-label="slightly smiling face" data-alias="slightly_smiling_face">🙂</span></p> </blockquote>

Show UID comment <blockquote> <p dir="auto">After GitHub and Codeberg, <a href="https://keyoxide.org/[email protected]" rel="nofollow">https://keyoxide.org/[email protected]</a> points now to my self-hosted website <span class="emoji" aria-label="slightly smiling face" data-alias="slightly_smiling_face">🙂</span></p> </blockquote>

wiktor [email protected] 2025-10-24T13:31:44+02:00 67783898: https://codeberg.org/superseriousbusiness/gotosocial/issues/4520#issuecomment-7881692 [feature] Add support for `sharedInbox` <p dir="auto">Ugh, I swear I searched for duplicates. Apparently I made a typo... or something. Thanks for your work! <span class="emoji" aria-label="waving hand" data-alias="wave">👋</span></p>

[feature] Add support for `sharedInbox` <p dir="auto">Ugh, I swear I searched for duplicates. Apparently I made a typo... or something. Thanks for your work! <span class="emoji" aria-label="waving hand" data-alias="wave">👋</span></p>

wiktor [email protected] 2025-10-24T10:51:35+02:00 67745729: https://codeberg.org/superseriousbusiness/gotosocial/issues/4520 <h3 id="user-content-is-your-feature-request-related-to-a-problem" dir="auto">Is your feature request related to a problem ?</h3> <p dir="auto">I&#39;m always frustrated when I need to send a JSON request to GoToSocial user. In other implementations, there&#39;s just a single <code>/inbox</code> (<code>sharedInbox</code> endpoint) and the server figures out how or where to route the activity. Not so in GoToSocial.</p> <p dir="auto">The <a href="https://docs.gotosocial.org/en/latest/federation/actors/" rel="nofollow">docs</a> acknowledge this:</p> <blockquote> <p dir="auto">GoToSocial accounts do not currently implement a sharedInbox endpoint, though this is subject to change.</p> </blockquote> <h3 id="user-content-describe-the-solution-you-d-like" dir="auto">Describe the solution you&#39;d like.</h3> <p dir="auto">I&#39;d like GoToSocial to expose <code>sharedInbox</code> endpoint for all users.</p> <h3 id="user-content-describe-alternatives-you-ve-considered" dir="auto">Describe alternatives you&#39;ve considered.</h3> <p dir="auto">I&#39;ve considered not interacting with GoToSocial users as this is additional friction but I want to avoid that if possible.</p> <h3 id="user-content-additional-context" dir="auto">Additional context.</h3> <p dir="auto">None, I haven&#39;t seen a backing ticket for this, that&#39;s why I&#39;m creating it.</p> <p dir="auto">Have a nice day! :wav</p>

4520#[feature] Add support for `sharedInbox`#

wiktor [email protected] 2025-10-01T12:32:33+02:00 62453998: https://codeberg.org/wiktor/test-256-repo/compare/2a71ef43c4c92889ba86df7eb726e5a7b59d65208019e18ad439c8146499151f...664d6b4cc0ffa42d464bd771b31c9692b41daecb6de4bba15fd98faad4e7932f <a href="https://codeberg.org/wiktor/test-256-repo/commit/664d6b4cc0ffa42d464bd771b31c9692b41daecb6de4bba15fd98faad4e7932f" rel="nofollow">664d6b4cc0ffa42d464bd771b31c9692b41daecb6de4bba15fd98faad4e7932f</a> Add info on Github <a href="https://codeberg.org/wiktor/test-256-repo/commit/f491211a42627c6f2a8437381759b735c022b9cb53d0ef5e04d8086f8d81422d" rel="nofollow">f491211a42627c6f2a8437381759b735c022b9cb53d0ef5e04d8086f8d81422d</a> Add info on the purpose of this repo

<a href="https://codeberg.org/wiktor/test-256-repo/commit/664d6b4cc0ffa42d464bd771b31c9692b41daecb6de4bba15fd98faad4e7932f">664d6b4cc0ffa42d464bd771b31c9692b41daecb6de4bba15fd98faad4e7932f</a> Add info on Github <a href="https://codeberg.org/wiktor/test-256-repo/commit/f491211a42627c6f2a8437381759b735c022b9cb53d0ef5e04d8086f8d81422d">f491211a42627c6f2a8437381759b735c022b9cb53d0ef5e04d8086f8d81422d</a> Add info on the purpose of this repo

wiktor [email protected] 2025-10-01T12:30:08+02:00 62453764: https://codeberg.org/wiktor/test-256-repo/commit/2a71ef43c4c92889ba86df7eb726e5a7b59d65208019e18ad439c8146499151f <a href="https://codeberg.org/wiktor/test-256-repo/commit/2a71ef43c4c92889ba86df7eb726e5a7b59d65208019e18ad439c8146499151f" rel="nofollow">2a71ef43c4c92889ba86df7eb726e5a7b59d65208019e18ad439c8146499151f</a> Add more Github discussion links

<a href="https://codeberg.org/wiktor/test-256-repo/commit/2a71ef43c4c92889ba86df7eb726e5a7b59d65208019e18ad439c8146499151f">2a71ef43c4c92889ba86df7eb726e5a7b59d65208019e18ad439c8146499151f</a> Add more Github discussion links

wiktor [email protected] 2025-10-01T12:19:15+02:00 62452078: https://codeberg.org/wiktor/test-256-repo/commit/85b0b15e5dac14136ad3f2874ba097f83392483146f77c5e33d50e03c80b02e2 <a href="https://codeberg.org/wiktor/test-256-repo/commit/85b0b15e5dac14136ad3f2874ba097f83392483146f77c5e33d50e03c80b02e2" rel="nofollow">85b0b15e5dac14136ad3f2874ba097f83392483146f77c5e33d50e03c80b02e2</a> Add info about support

<a href="https://codeberg.org/wiktor/test-256-repo/commit/85b0b15e5dac14136ad3f2874ba097f83392483146f77c5e33d50e03c80b02e2">85b0b15e5dac14136ad3f2874ba097f83392483146f77c5e33d50e03c80b02e2</a> Add info about support

wiktor [email protected] 2025-10-01T12:14:39+02:00 62451658: https://codeberg.org/ <a href="https://codeberg.org/wiktor/test-256-repo/commit/336f007f23f2dd44f88a6873b1084cdd8966ad6f990d53a5f49cbca64236c3f6" rel="nofollow">336f007f23f2dd44f88a6873b1084cdd8966ad6f990d53a5f49cbca64236c3f6</a> Add further explainer <a href="https://codeberg.org/wiktor/test-256-repo/commit/cbf74c08eccfe97110b401cbf238b19a8fcbdd6c055c8eaa35924d32f4077196" rel="nofollow">cbf74c08eccfe97110b401cbf238b19a8fcbdd6c055c8eaa35924d32f4077196</a> Add project info

<a href="https://codeberg.org/wiktor/test-256-repo/commit/336f007f23f2dd44f88a6873b1084cdd8966ad6f990d53a5f49cbca64236c3f6">336f007f23f2dd44f88a6873b1084cdd8966ad6f990d53a5f49cbca64236c3f6</a> Add further explainer <a href="https://codeberg.org/wiktor/test-256-repo/commit/cbf74c08eccfe97110b401cbf238b19a8fcbdd6c055c8eaa35924d32f4077196">cbf74c08eccfe97110b401cbf238b19a8fcbdd6c055c8eaa35924d32f4077196</a> Add project info

wiktor [email protected] 2025-10-01T12:14:39+02:00 62451655: https://codeberg.org/wiktor/test-256-repo/src/branch/main wiktor [email protected] 2025-10-01T12:14:18+02:00 62451640: https://codeberg.org/wiktor/test-256-repo wiktor [email protected] 2025-09-17T13:00:58+02:00 59343628: https://codeberg.org/iNPUTmice/lttrs-android/issues/22#issuecomment-7224868 Autodiscovery not working on Stalwart <p dir="auto">Btw, personally I consider this an issue with the JMAP auto-discovery. All other schemes I know use <code>.well-known</code> as a directory that can be accessed without any authentication and only the request to the target service is authenticated. For example <code>host-meta</code> (random sample: <a href="https://hulegarden.dedyn.io/.well-known/host-meta.json" rel="nofollow">https://hulegarden.dedyn.io/.well-known/host-meta.json</a>) is readable without any auth.</p> <p dir="auto">So, I think the easiest workaround here would be reading the <code>Location</code> header without following requests and retrying with the target URL. Yep, it&#39;s not as clean as it should be but IMO the complexity stems from the JMAP spec that clearly didn&#39;t analyze impact of GET requests with authorization across domains (which I consider a quite significant use-case).</p>

Autodiscovery not working on Stalwart <p dir="auto">Btw, personally I consider this an issue with the JMAP auto-discovery. All other schemes I know use <code>.well-known</code> as a directory that can be accessed without any authentication and only the request to the target service is authenticated. For example <code>host-meta</code> (random sample: <a href="https://hulegarden.dedyn.io/.well-known/host-meta.json" rel="nofollow">https://hulegarden.dedyn.io/.well-known/host-meta.json</a>) is readable without any auth.</p> <p dir="auto">So, I think the easiest workaround here would be reading the <code>Location</code> header without following requests and retrying with the target URL. Yep, it&#39;s not as clean as it should be but IMO the complexity stems from the JMAP spec that clearly didn&#39;t analyze impact of GET requests with authorization across domains (which I consider a quite significant use-case).</p>

wiktor [email protected] 2025-09-17T12:51:00+02:00 59342395: https://codeberg.org/iNPUTmice/lttrs-android/issues/22#issuecomment-7224766 Autodiscovery not working on Stalwart <blockquote> <p dir="auto">I wonder if the missing credentials thing is something that only happens on redirects across domains. Because I’m reasonable sure that in the testing I did with Cyrus there was also a redirect from .well-known/jmap to /jmap (or something)</p> </blockquote> <p dir="auto">Ugh, you&#39;ve nerd-sniped me into looking at that and the good news is you&#39;re spot on (header lost on changing domains) but the bad news is that it seems to be by design:</p> <p dir="auto">Quoting <a href="https://datatracker.ietf.org/doc/html/rfc9110#section-11.6.2" rel="nofollow">the spec</a>:</p> <blockquote> <p dir="auto">If a request is authenticated and a realm specified, the same credentials are presumed to be valid for all other requests <em>within this realm</em></p> </blockquote> <p dir="auto">Also <a href="https://datatracker.ietf.org/doc/html/rfc1945#section-11" rel="nofollow">here</a>:</p> <blockquote> <p dir="auto">The realm value (case-sensitive), in combination with the canonical root URL of the server being accessed, defines the protection space.</p> </blockquote> <p dir="auto">I haven&#39;t seen realms being used in <code>Bearer</code> tokens but they <a href="https://datatracker.ietf.org/doc/html/rfc6750#section-6.1.1" rel="nofollow">are specified</a>.</p> <p dir="auto">Additionally I found a Browser compat section which tracks the &#34;<code>Authorization</code> header removed from cross-origin redirects&#34; feature: <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Authorization#browser_compatibility" rel="nofollow">https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Authorization#browser_compatibility</a></p> <p dir="auto">Interestingly, there&#39;s <a href="https://stackoverflow.com/a/28671822" rel="nofollow">a question on stackoverflow</a> discussing the same problem (suggesting several workarounds).</p> <p dir="auto">The final nail to the coffin seems to be <a href="https://github.com/square/okhttp/issues/2937" rel="nofollow">the okhttp ticket</a> where users asked for this feature to be configurable and closed as &#34;won&#39;t fix&#34;.</p>

Autodiscovery not working on Stalwart <blockquote> <p dir="auto">I wonder if the missing credentials thing is something that only happens on redirects across domains. Because I’m reasonable sure that in the testing I did with Cyrus there was also a redirect from .well-known/jmap to /jmap (or something)</p> </blockquote> <p dir="auto">Ugh, you&#39;ve nerd-sniped me into looking at that and the good news is you&#39;re spot on (header lost on changing domains) but the bad news is that it seems to be by design:</p> <p dir="auto">Quoting <a href="https://datatracker.ietf.org/doc/html/rfc9110#section-11.6.2" rel="nofollow">the spec</a>:</p> <blockquote> <p dir="auto">If a request is authenticated and a realm specified, the same credentials are presumed to be valid for all other requests <em>within this realm</em></p> </blockquote> <p dir="auto">Also <a href="https://datatracker.ietf.org/doc/html/rfc1945#section-11" rel="nofollow">here</a>:</p> <blockquote> <p dir="auto">The realm value (case-sensitive), in combination with the canonical root URL of the server being accessed, defines the protection space.</p> </blockquote> <p dir="auto">I haven&#39;t seen realms being used in <code>Bearer</code> tokens but they <a href="https://datatracker.ietf.org/doc/html/rfc6750#section-6.1.1" rel="nofollow">are specified</a>.</p> <p dir="auto">Additionally I found a Browser compat section which tracks the &#34;<code>Authorization</code> header removed from cross-origin redirects&#34; feature: <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Authorization#browser_compatibility" rel="nofollow">https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Authorization#browser_compatibility</a></p> <p dir="auto">Interestingly, there&#39;s <a href="https://stackoverflow.com/a/28671822" rel="nofollow">a question on stackoverflow</a> discussing the same problem (suggesting several workarounds).</p> <p dir="auto">The final nail to the coffin seems to be <a href="https://github.com/square/okhttp/issues/2937" rel="nofollow">the okhttp ticket</a> where users asked for this feature to be configurable and closed as &#34;won&#39;t fix&#34;.</p>

wiktor [email protected] 2025-09-17T11:11:15+02:00 59316964: https://codeberg.org/iNPUTmice/lttrs-android/issues/22#issuecomment-7220710 Autodiscovery not working on Stalwart <blockquote> <p dir="auto">It looks like the login (&#34;[email protected]&#34; here) is only sent with the first request, but not in the second one to the redirect target.</p> </blockquote> <p dir="auto">I reached the same conclusion when trying to setup Fastmail integration with:</p> <pre class="code-block"><code class="chroma language-text display">location ~ /.well-known/jmap { return 301 https://api.fastmail.com/.well-known/jmap; } </code></pre><p dir="auto">I guess setting up a proxy which forwards all headers would work but I wonder if the HTTP client of Ltt.rs can be configured to resend auth headers on redirects...</p> <blockquote> <p dir="auto">Ltt.rs currently doesn’t do automatic discovery via DNS because this essentially requires DNSSEC.</p> </blockquote> <p dir="auto">I&#39;ve got DNSSEC enabled and it didn&#39;t work so I assume this is not implemented. I wonder if <a href="https://github.com/MiniDNS/minidns" rel="nofollow">minidns</a> could be used for that.</p> <p dir="auto">There&#39;s also another alternative: do the <code>https://&lt;userdomain&gt;/.well-known/jmap</code> request with <em>no redirects</em> enabled, read the <code>Location</code> header and proceed with the header value as if it has been entered by the user. That&#39;d mean the <code>Authorization</code> headers would be sent to correct target servers and everything would work seamlessly.</p> <p dir="auto">One way or another, using Ltt.rs is such a breeze of fresh air compared to old e-mail clients. Thanks for your efforts, they really show! <span class="emoji" aria-label="waving hand" data-alias="wave">👋</span></p>

Autodiscovery not working on Stalwart <blockquote> <p dir="auto">It looks like the login (&#34;[email protected]&#34; here) is only sent with the first request, but not in the second one to the redirect target.</p> </blockquote> <p dir="auto">I reached the same conclusion when trying to setup Fastmail integration with:</p> <pre class="code-block"><code class="chroma language-text display">location ~ /.well-known/jmap { return 301 https://api.fastmail.com/.well-known/jmap; } </code></pre><p dir="auto">I guess setting up a proxy which forwards all headers would work but I wonder if the HTTP client of Ltt.rs can be configured to resend auth headers on redirects...</p> <blockquote> <p dir="auto">Ltt.rs currently doesn’t do automatic discovery via DNS because this essentially requires DNSSEC.</p> </blockquote> <p dir="auto">I&#39;ve got DNSSEC enabled and it didn&#39;t work so I assume this is not implemented. I wonder if <a href="https://github.com/MiniDNS/minidns" rel="nofollow">minidns</a> could be used for that.</p> <p dir="auto">There&#39;s also another alternative: do the <code>https://&lt;userdomain&gt;/.well-known/jmap</code> request with <em>no redirects</em> enabled, read the <code>Location</code> header and proceed with the header value as if it has been entered by the user. That&#39;d mean the <code>Authorization</code> headers would be sent to correct target servers and everything would work seamlessly.</p> <p dir="auto">One way or another, using Ltt.rs is such a breeze of fresh air compared to old e-mail clients. Thanks for your efforts, they really show! <span class="emoji" aria-label="waving hand" data-alias="wave">👋</span></p>

wiktor [email protected] 2025-09-01T15:05:10+02:00 55898092: https://codeberg.org/wiktor/.profile/commit/b7a095ff5c33945ccae9a50fbc46cb5f180f0cae <a href="https://codeberg.org/wiktor/.profile/commit/b7a095ff5c33945ccae9a50fbc46cb5f180f0cae" rel="nofollow">b7a095ff5c33945ccae9a50fbc46cb5f180f0cae</a> Trim the content a bit

<a href="https://codeberg.org/wiktor/.profile/commit/b7a095ff5c33945ccae9a50fbc46cb5f180f0cae">b7a095ff5c33945ccae9a50fbc46cb5f180f0cae</a> Trim the content a bit

wiktor [email protected] 2025-09-01T14:35:23+02:00 55892908: https://codeberg.org/keyoxide/doipjs/pulls/173#issuecomment-6843814 Add support for Direct Key Signature proofs <p dir="auto"><a href="/Ryuno-Ki" class="mention" rel="nofollow">@Ryuno-Ki</a> would you mind taking a look at this PR? I&#39;d really want to see it live <em>somewhere</em> so that I could work on the CLI proof updater part... kthxbai <span class="emoji" aria-label="person bowing" data-alias="bow">🙇</span></p>

Add support for Direct Key Signature proofs <p dir="auto"><a href="/Ryuno-Ki" class="mention" rel="nofollow">@Ryuno-Ki</a> would you mind taking a look at this PR? I&#39;d really want to see it live <em>somewhere</em> so that I could work on the CLI proof updater part... kthxbai <span class="emoji" aria-label="person bowing" data-alias="bow">🙇</span></p>

wiktor [email protected] 2025-09-01T14:34:39+02:00 55892734: https://codeberg.org/keyoxide/doipjs/pulls/172#issuecomment-6843787 fix: proper handling of aspe links <p dir="auto">Interesting that it didn&#39;t trigger any test failure. Would that be hard to add a regression test for this case? <span class="emoji" aria-label="thinking face" data-alias="thinking">🤔</span></p>

fix: proper handling of aspe links <p dir="auto">Interesting that it didn&#39;t trigger any test failure. Would that be hard to add a regression test for this case? <span class="emoji" aria-label="thinking face" data-alias="thinking">🤔</span></p>

wiktor [email protected] 2025-09-01T14:07:50+02:00 55888675: https://codeberg.org/wiktor/pks-spec/commit/df302144e51cf7c6803044058e1092739bc98792 <a href="https://codeberg.org/wiktor/pks-spec/commit/df302144e51cf7c6803044058e1092739bc98792" rel="nofollow">df302144e51cf7c6803044058e1092739bc98792</a> Document why the 2to3 transformation happens

<a href="https://codeberg.org/wiktor/pks-spec/commit/df302144e51cf7c6803044058e1092739bc98792">df302144e51cf7c6803044058e1092739bc98792</a> Document why the 2to3 transformation happens

wiktor [email protected] 2025-09-01T14:02:46+02:00 55887415: https://codeberg.org/wiktor/pks-spec/commit/97d51d83ad006da68fc3eface0bbee916fbb3ffc <a href="https://codeberg.org/wiktor/pks-spec/commit/97d51d83ad006da68fc3eface0bbee916fbb3ffc" rel="nofollow">97d51d83ad006da68fc3eface0bbee916fbb3ffc</a> Use newer <code>idnits</code> tool

<a href="https://codeberg.org/wiktor/pks-spec/commit/97d51d83ad006da68fc3eface0bbee916fbb3ffc">97d51d83ad006da68fc3eface0bbee916fbb3ffc</a> Use newer <code class="inline-code-block">idnits</code> tool

wiktor [email protected]