FEP-8b32はJSONベースの署名を埋め込みオブジェクトで上手く動作させるために`object`タームの定義をオーバーライドしてセマンティクスにも手を入れているけど（<https://codeberg.org/fediverse/fep/src/branch/main/fep/8b32/fep-8b32.md#nested-objects>）、Activity StreamsオブジェクトをRDFとして扱っている実装（`rdf-pub`がそうだっけ？）との互換性が気になっている
FEP-8b32はJSONベースの署名を埋め込みオブジェクトで上手く動作させるために`object`タームの定義をオーバーライドしてセマンティクスにも手を入れているけど（<https://codeberg.org/fediverse/fep/src/branch/main/fep/8b32/fep-8b32.md#nested-objects>）、Activity StreamsオブジェクトをRDFとして扱っている実装（`rdf-pub`がそうだっけ？）との互換性が気になっている
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
手続きマクロのUIテストの結果が手元とCIで食い違っていて首を傾げているけど、まあ実用上は困らなそうなので取りあえずはヨシッ（？）
手元とCIでツールチェーンのバージョンが一致していることはもちろん確認済
UIテスト、当然ながらツールチェーンを更新するたびに結果がコロコロ変わりがちなのがつらい。しかしいつの間にか全く想定していない出力になったりしても困るので、いずれにせよ継続的にテストを回す必要はあるのだけど
まあ`trybuild`のおかげで追従作業がかなり楽にはなった。`compiletest_rs`のときは毎回手作業でテストを書き換えていたからなあ
このアカウントは、notestockで公開設定になっていません。
Mastodonの`toot:indexable`とかは（デフォルトで検索可能と解するのが一般的である）Webの慣行と相性が悪いと思うけど、一方でフォロワー以外のユーザによる検索タイムラインにも含まないという仕様については、いわゆる非収載／未収載／ホーム「公開範囲」を「公開タイムラインに含めない」ものとして扱う慣習を踏まえればある種の一貫性はあるように思う（それに倣うべきかは別として）
「公開範囲」を鉤括弧で囲んでいるのは、「公開範囲」／「可視性」というのはActivityPub/Activity Streamsで定められているわけでもない概念だからですね。Activity Streamsにあるのはアクターやそのコレクションを対象としたaudience targetingであって、"public"/"unlisted"/"limited"/"direct"といった有限通りの列挙型的な「公開範囲」ではないので（早口）（過激派）
このアカウントは、notestockで公開設定になっていません。
しかしaudience targetingを検索可能性に流用するのはやはり標準で明示的に定められた仕様ではないし、そうなると（著作権法施行規則第四条の四で`robots.txt`に与えられているような）法的な効力を持たせるのも難しそうだし、本当なら`fedibird:searchableBy`のような専用の仕組みを整備するのが良いのだろうけど
s/(?<=一方で)/「非収載」のオブジェクトを/
（推敲のつもりで文節を並び替えているうちに前後が繋がらなくなってしまっていた）
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
`Emoji`が標準化されていないとはいっても、オブジェクトの帰属を`id`のauthorityで判断するのは普通に普遍的な解釈だと思うけどなあ。
アクターのホストと`Emoji`オブジェクトのホストが食い違うときに無効なものと判定するならまだ分かるけど、当該の`Emoji`オブジェクトをアクターのホストのものとして処理する（というのが現行のMisskeyの仕様という認識で合っている？）のはかなりアクロバティックなように思える
FEP-5e53: Opt-out Preference Signals - Standards / Fediverse Enhancement Proposals - SocialHub
https://socialhub.activitypub.rocks/t/fep-5e53-opt-out-preference-signals/4323/6
そういえば`X-Robots-Tag`をActivityPubに輸入しようという提案もあるのだった
というか少なくともFedibirdはローカルのアクターによるリモートの絵文字リアクションへの「相乗り」の`Like`アクティビティの`tag`にリモートの`Emoji`オブジェクトを全て埋め込んでいるようだけど、これは（C2Sでなく連合の場合は）本来なら単にURIで良いはずだよね。
仮に埋め込みでないと上手く相互運用できないというなら、それは相手のサーバが（`id`をfetchし直さず埋め込まれた内容をそのまま信用するなどの）怪しい処理をしているということに他ならないわけだし
まあこれは本来なら不要というだけで、埋め込んだら何かがまずいというわけでもないので別に良いのだけど
あのMetaだってActivityPub対応を進めているのだから、もはやActivityPubに対応していないプラットフォームはDMA違反扱いで良いのでは（適当）
Early Access Federation for Self-Hosters | Bluesky
https://docs.bsky.app/blog/self-host-federation
> Unlike a Mastodon instance, it does not need to function as a full-fledged social media service
お、喧嘩売っとんのか？（？）
別にActivity Streamsだってオブジェクトを静的にホストすることは出来るわけですけど〜？ <small style="font-size: xx-small">LDNを購読する代わりに静的な`Collection`をクロールできるような実装はまだ一般的でないけど</small>
Pub/subを管理することに比べて定期的にクロールするというのはそこまで難しいものでないだろうから、本当に単に機運がないからやっていないだけなのでは
ワードミュート等のフィルタリングの仕組みといわゆる検索避けを両立するには検索されたくないという意志を表示する手段は不可欠だと思うので、Mastodonの方式に従うかは別として何らかのオプトアウトの仕組みは欲しいよね
`toot:indexable`は粒度が粗すぎて個人的には使いづらいと感じている。個別実装のインタフェースとしてアカウント単位の設定しか提供しないのは良いとしても、多様な実装から利用されることを想定した連合上の表現としては`fedibird:searchableBy`くらいの柔軟性が欲しいよね
まあ連合上でオブジェクト単位で設定可能にした場合、アカウント単位で設定を変更したい場合にどうするんだという問題があるけど。というか`toot:indexable` aka. FEP-5febがアクター単位の設定になっているのがまさにその理由なのだよな（<https://socialhub.activitypub.rocks/t/fep-5feb-search-indexing-consent-for-actors/3550/10>）
それはそれとしてブーリアンでなくaudience targetingの表現を流用するくらいはできたのではという気はするけど。個別の実装として「フォロワー限定」のような検索範囲に対応したくないなら検索不能にフォールバックすれば良いわけで
`toot`拡張、当然っちゃ当然ではあるけど、全体的にMastodonの実装詳細に影響されすぎの感がある。
例えば`manuallyApprovesFollowers`とかも、ActivityPubでは「フォロー承認制」相当の挙動がデフォルトなのだからそこは`automaticallyApprovesFollowers`のようなプロパティを生やすべきところだろという感じだし（細かい表現にうるさいオタク）。あ、これは`toot:`名前空間でなく`as:`名前空間に直接生やしてしまった拡張プロパティだったか
@mei23 Fedibirdの場合はこんな感じですね（一部略）：
```json
{
"id": "https://fedibird.com/emoji_reactions/113101768896873277",
"type": "Like",
"content": ":blobsignya:",
"object": "https://fedibird.com/users/tesaguri/statuses/112989776912649991",
"tag": [
{
"id": "https://misskey.m544.net/emojis/blobsignya",
"type": "Emoji",
"name": ":blobsignya:",
"icon": { /* … */ }
}
]
}
``` [参照]
@mei23 私もFedibirdの実装を詳しく追っているわけではないですが、`Emoji`オブジェクトに`id`があるならそのURIの同一性をもってリモートのものと同一の絵文字であることが判定できるのではないでしょうか
@mei23 その場合はそのURIをfetchすれば良いのではないでしょうか。<https://github.com/kmycode/mastodon/security/advisories/GHSA-c7p6-c688-fhgp>のような脆弱性のリスクを避けるためにはいずれにしても`id`をfetchする必要はあるでしょうし
まあ、いちいち実装前にFEPを提案して相互運用性を検証しながら地道に仕様を固めたりしなくても、とりあえず実装してユーザ数の力で既成事実化すれば他の実装が追従してくれるのでユーザ数が正義なのだろう（炎上）
一応補足しておくと、`toot:indexable`は実装後にFEPを出している（FEP-5feb）。一方で`fediverse:creator`などは……はい。Claire氏やa氏などとその他のメンバーで温度感が違いすぎるといったところだろうか
重箱（じゅうばこ；音＋訓）
湯桶（ゆとう；訓＋音）
辣油（らーゆ；普通話＋音）（？？？）
@hongminhee 普通話で油はyóu（仮名に音訳するならヨウに近い）のみだと思っていましたが、もしかして他にも読み方があったりしますか？
しゅいろの投稿
syuilo@misskey.io
このアカウントは、notestockで公開設定になっていません。
「知らない人と話すな」と念入りに教え込まれた児童・生徒が身内以外の大人から挨拶されたらまずは警戒するのがむしろ普通なのでは（男女差があるとの主張の説明にはなっていないけど）
私もコミュニケーションが下手くそで、予期せず他人から話しかけられると初期処理に3秒以上はかかりがちなので、ランダムな通行人に挨拶されると応答を確定する前にほぼ確実にタイムアウトする（社会適合性ゼロ）
近所の人や教員に引率された園児の列などは高確率で挨拶してくるものと認識していて、エンカウンターする前に前処理を走らせておくことで何とか対応できるけど（何なら場合によって先制で挨拶する）、全てのランダムな他人に対していちいちその心構えは出来ないので
自分で書きながら、コミュニケーション下手くそすぎて嫌になってきた（？）
@hongminhee 一応「そびえと」の変換候補に「蘇維埃」も含まれていますが、日常的にはあまり使われないですね。例えば「日ソ基本条約」も普通は「日蘇基本条約」などとは書きませんし
LD Signaturesで署名された投稿の検索範囲が改竄できてしまう · Advisory · kmycode/mastodon
https://github.com/kmycode/mastodon/security/advisories/GHSA-mcfx-232h-427c
CVE-2022-24307の出涸らしみたいな報告をするなどしていた
JSON-LDにおいて`"foo": []`は`"foo": null`や`undefined`と同じ意味なので、plain JSONとして処理するときはこれらを等価なものとして扱うべきという話
【相互リンク機能おためし期間終了のお知らせ】
本日をもちまして、無料プランの方は相互リンク機能をご利用いただけなくなります。
既に設定されているものに関しましては他ユーザーから見えない状態になります。
支援プランの設定数は、引用元の投稿またはFANBOXのプランをご確認ください。
RE: https://misskey.io/notes/9wxlzb1qrr3l0a39
支援者限定の機能にするなら確かにあまりリモートサーバに機能を開放しすぎてしまうと困るか（え？）
このアカウントは、notestockで公開設定になっていません。
ld-signatures/index.html at d0af56856684924156a94838f9482a27766bb2be · w3c-ccg/ld-signatures
https://github.com/w3c-ccg/ld-signatures/blob/d0af56856684924156a94838f9482a27766bb2be/index.html#L651-L652
> Remove any `signature` nodes from the default graph in _document_ and save it as _signature_.
本来なら文書全体をexpandして`sec:signature`を取り出すというのが"正しい"のだろうけど（仕様が曖昧なので実際の策定者の意図としてどうなのかは知らぬ）、それをやると正しく`@context`で定義されていない`signature`が消えるという
なので既存実装との互換性を考えると`signature`という名前のタームを決めうちで取り除くしかないのだけど、安易にそれをやると先祖オブジェクトの`@context`が`signature`オブジェクトに反映されなくなってしまうので、`signature`が先祖オブジェクトのタームを使っているケースを想定するなら先祖オブジェクトの`@context`を`signature`オブジェクトに注入するという面倒な前処理が必要になる[独自研究]：<https://github.com/tesaguri/rsa-signature-2017-rs/blob/38eca544e8179ac03c05f12d1eb4e872fd0812fc/src/json_ld.rs#L358-L362>
そもそものLD Signaturesのドラフト仕様が所定の「ターム」を取り除くべきなのか「プロパティ」を取り除くべきなのかに関して曖昧だからなあ……
https://github.com/mastodon/mastodon/blob/1726085db5cd73dd30953da858f9887bcc90b958/app/lib/activitypub/linked_data_signature.rb#L35-L50
それにつけてもMastodonが署名のハッシュ計算時にoptionsに`identity`コンテクストを埋め込んでいる一方で、最終的な署名済オブジェクトのoptionsからはコンテクストを省いているのは謎である
https://github.com/mastodon/mastodon/blob/HEAD/app/lib/activitypub/linked_data_signature.rb#L26
そして検証時に`identity`コンテクストを決めうちで上書きしているのはさらに謎
そもそもの仕様が中途半端にplain JSONの幻想に寄り添った書き方をしていたものだからCVE-2022-24307のような脆弱性を引き起こしたのではという気持ちがある。いずれにせよその程度はsecurity considerationsとしてカバーしておくべきだったとは思うけど（まあドラフトなので仕方ない）（ドラフトをプロダクションで使った方が悪い）
JSON-LD、結局のところ"all the memory safety of C combined with all the blazing speed of Smalltalk"になっている気がする（？）
JSON-LDの利点の一つとして既存のJSON文書を変更することなくlinked dataとしての解釈を与えられるという点があると思うけど、Activity Streams 2.0の場合は恐らく既存のJSON文書を考慮する必要は少なかっただろうから、辺に色気を出して短いタームを使わずともプロパティのIRIを全て書き出す（<https://codeberg.org/fediverse/fep/src/commit/8441175ce0a8434046ddc7a5cbf3e489db22d270/fep/e229/fep-e229.md#extension-property>）ようにした方が良かったのではという気がしている
単体で参照しても自己完結的になるようにスレッドを組み立てるべきだとは思いつつ、気を抜くとすぐに別のスレッドに依存した書き方をしてしまいがち
`endpoints`とかいう、アクターとは独立したオブジェクトを指すものとして定義されているものの、実際にURIで別文書を参照する形で使用されることが滅多にないプロパティなあ
https://github.com/w3c/activitypub/issues/410#issuecomment-1981457081
終いにはPrimerで`endpoints`にURIを指定することを非推奨にする可能性が仄めかされる始末
https://www.w3.org/TR/2018/REC-activitypub-20180123/#endpoints
`endpoints`プロパティの定義で"(typically server/domain-wide) endpoints"とあるので、当初の意図としては同一サーバ内のアクター間で同一の`endpoints`オブジェクトを共有するような用法を想定していたのかなあと
結局複数アクターにまたがる「サーバ」的な概念を指す役割は`sharedInbox`に取って代わられた感がある
https://www.w3.org/TR/2018/REC-activitypub-20180123/#x3-1-object-identifiers
> all objects distributed by the ActivityPub protocol MUST have unique global identifiers, unless they are intentionally transient
↑ほぼ空文化していてかわいそう（？）
というか、埋め込まれたオブジェクトが独立したオブジェクト（RDFリソース）であるという認識があまり浸透していない？
We are excited to launch a new project that will help small and medium-sized fediverse servers and their users have better access to search and discovery through the use of pluggable Fediverse Discovery Providers, supported by a grant from @EC_NGI. See our new dedicated website for details:
> Fediverse platforms like Mastodon that offer search have thus made it opt-in
🤔
いやしかし実際ね、横着してMastodon基準のオプトインをあたかも普遍的なものであるかのように扱っているといつか皺寄せを受けると思うのですよ
`"toot:indexable": false`をオプトアウトの意思表示として扱うところまでは良いとしても、`indexable: undefined`を検索拒否とみなすのは無理筋に思える。
例えば`Sec-GPC`に法的な効力を認めている法体系だって`Sec-GPC`未指定を`Sec-GPC: 1`のようには扱わないだろうし（IANAL）
Discovery provider自体を信用しない前提のモデルで効率的な検索を実現するにはオブジェクトの署名が欠かせないと思いますけど、ようやくVCDIを実装する機運ですかね？
「LD Signaturesを使います」「ｽﾞｺｰｯ」のフリではない（？）
`Like`が匿名化されるべきというのも万人に通用する理屈なのか疑問がある。Misskeyのリアクションとかは公開のコミュニケーションの手段としての側面が強いように思えるし、というか公開したくないのだったら非公開の「ブックマーク」機能などを使うべきだろうし。
自分と送信先のアクターの間の秘密のやり取りにとどめたいという需要はあるかもしれないけど、だったらまずMastodonはあらゆる`Like`を`GET /api/v1/statuses/:id/favourited_by`で晒すのをやめろと（<https://github.com/mastodon/mastodon/issues/11339#issuecomment-2267270087>）
まあ`Like`を取得するには検索対象のオブジェクト自体が`likes`コレクションを実装すれば事足りるだろうから、discovery providerが`Like`を仲介する必要性はいずれにせよ乏しいか
`as:Public`に宛てられていない`Like`を晒すな、ダイレクトメッセージを晒すぞ（？？？）
これは冗談で、実際にダイレクトメッセージは晒しません（念のための補足）
検索についてはFedibirdでいろいろ実験的な取り組みをしてきたので、思うところはあるよ。
Indexableは簡易だけど雑過ぎる。細かいことはユーザーに意識させなくていいけど、プロトコルレベルではsearchableByぐらいの粒度が欲しい。
ActorとNote（あるいは他にも）のsearchableByをサポートすることによって、公開範囲と同様に意志を反映させられるようになっていて欲しい。
（※ なんならLikeにsearchableByがあったっていい）
ひとつには、フォロー関係やブロックが反映されるようにすること。ブロックした相手に見つかりたくないとか、フォロワーには検索できるようにしたいとかあるでしょう？ Fedibirdは対応してるよ？
なお、fedibird.comにアカウント情報や公開投稿を突っ込む（インデックスさせる）には、Fedibird Relay Serviceに登録すればOKで、すでにある程度実現できる。
ActorのserachableByを設定するには、Fedibirdのようにネイティブ表現できない場合は、互換のハッシュタグ表現をActorのsummaryに含めることで実現できる。
まだできないのは、この検索能力を外部提供するAPIやプロトコルがないこと。
UX設計としては良くてもプロトコル設計としては雑という点に尽きるよなあ
というか"reblog"でなく"boost"と表記されている……（細かい）
`toot:indexable`の設計は「アカウント単位の設定を簡単に切り替えられた方が嬉しいよね」という動機によるものらしいけど、そもそも過去に明示的に検索を拒否していた投稿を一括して許可したいようなケースなんてあるのだろうか。
それこそ一律で検索拒否扱いと見做していた古いバージョンからのMastodonユーザくらいにしか存在しない需要なのでは
QT: https://fedibird.com/@tesaguri/113101697566736014 [参照]
考えてみると、今からでもロビーを頑張って`toot:indexable`の値域を`xsd:boolean`から`xsd:boolean | Actor | Collection`に拡げるくらいのことは出来るのでは。キモいけど
https://socialhub.activitypub.rocks/t/fep-5feb-search-indexing-consent-for-actors/3550/20
とりあえず提案だけしておいた
今日も一日
