tesaguri 🦀🦝 @tesaguri@fedibird.com

まあJavaScriptだけでなくCookieも求めるサイトよりは良心的ではある

FedibirdのベースのMastodonのバージョンはJavaScriptが無くても閲覧できるものだけど、これで困るのは（Web UIを使うためにはいずれにせよJSを有効にする必要がある）自分のサーバよりも他のサーバのURLを開いたときなのだよなあ

Mastodonも以前はJavaScript無しでも閲覧できたのだよなあ

Write on X: "Introducing Articles on X" / X
https://twitter.com/Write/status/1765884209527394325

そういえば旧TwitterのWrite改めArticles機能がいつの間にか正式にリリースされていたようだけど、DOMを見たら見出しらしきものも段落らしきものも全てただの`<div>`と`<span>`でずっこけてしまった。まあそれでも`white-space: pre-wrap;`な`<span>`に全てを突っ込んでいる通常のツイートよりはマシではあるけど

Mastodonは単独の改行は`<br />`扱いで改行2回で`<p>`扱いか。今まで連続の改行は見た目がうるさいから避けていたけど、意味論的には段落の区切りではきちんと2回改行した方が良さそうだな

テスト
テスト

テスト

| Usable? \ Decentralized? | T | F |
| - | - | - |
| T | ? | ? |
| F | ? | ? |

お淑やかなのでe14n（？）という用語を直接口にすることが出来ない

メタ何とか化した中央集権プラットフォーム、すなわちUnusable Centralized以下略

Usable Decentralized Social MediaというのはUnusable Decentralized Social Mediaの存在を暗示している（炎上）

"Usable Decentralized Social Media"がイヤらしいのは、ActivityPubの一般論とMastodonの個別論を上手いこと混ぜ込んでいるところなのだよな。
この記述の続きも、前半は"migrating to another server implies changing username"とMastodon固有の議論（といってもこれは他の実装でも一般的な仕様だけど）の後に"and preserving one’s followers during such a migration requires the cooperation of the old server."とMastodon方式の`Move`アクティビティの仕様に関するプロトコルレベルの議論が重ねられているわけだけど、どちらもプロトコルレベルで考えるならばActivity Streamsのアクターのサーバを移動しながらWebFingerの`subject`を保つようなことは可能……というか、WebFingerのRFCが陽にサポートしている範囲内のユースケースなのだよな。まあ、そんなことを言ったらAT Protocolのハンドルの優位性が薄れてしまうので言及したくないだろうけど

"Bluesky and the AT Protocol: Usable Decentralized Social Media" (<https://dl.acm.org/doi/10.1145/3694809.3700740>)でも"in the case of Mastodon, a user needs to choose a server when creating an account. This choice is significant because the server name becomes part of the username;"とか書かれていたわけだけど

WebFingerでも一応リソースごとに`subject`のドメインを自由に設定できるわけだけど、一般的なFediverseのサーバ実装ではMastodonの`LOCAL_DOMAIN`のようにあるActivityPubサーバ全体のアクターのusernameのドメインを設定できるというのがせいぜいで、アクターごとにドメインを設定できるような実装は見かけないのだよな。
Mastodonの`instance` APIのレスポンスとかも、一つのインスタンスにただ一つのドメインが対応する前提の作りだし

どこの国でもこういった身体的特徴にかこつけた攻撃があるものなのだなあ（念のため付言すると、感心しているわけではない）

まああくまでそれなりであって、表現できないものも多いけど。参考：
TypeScriptのJSDocサポートでできること、できないこと
https://zenn.dev/qnighy/articles/56917d9bf9077b
個人的には特に型実引数指定が出来ないところで躓いた
（記事はTypeScript 4.4が対象だけど、その後にTypeScript 5.0で関数のオーバーロード宣言や`satisfies`のサポートが入ったりしている（<https://devblogs.microsoft.com/typescript/announcing-typescript-5-0/>））

GitHubにポン置きのuser scriptのような、いちいちTypeScriptからビルドしてデプロイする手間をかけるのも微妙なコードでも、JSDoc記法で型注釈を書いておけばお手軽にそれなりの型検査が出来て便利