AT Protocolが何故お得意の（？）NSIDを`com.atproto.label.defs#label`の`val`にも使わなかったのか疑問に思っている
AT Protocolが何故お得意の（？）NSIDを`com.atproto.label.defs#label`の`val`にも使わなかったのか疑問に思っている
Fediverseでも、管理者とモデレーターを初手ブロックする仕草とかあるよ。
要注意人物として扱って欲しいのかな？
そもそも何故そのサーバに登録するのか……と思ったけど、例えば連合で利用できない機能が提供されていたりする場合は信用していない主体が運用するサーバに登録する必要性が発生しうる……？
ほら、旧Twitterとかにはまさにオーナーをブロックしている人も多そうじゃん？（？）
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
Misskeyにおける`Block`の扱いが実際にどうなっているのかについてはさておくとしても、ActivityPubの場合は被フォローを厳選した上で非公開投稿を使うというより確実な方法があるからなあ
非常に細かいことを述べるなら、確かActivityPubではアクティビティをaudience targetingで指定された対象以外に配送してはならない（MUST NOT）とも規定されていなかったと思うけど……。実際、勧告の"Note: Silent and private activities"には、S2Sの配送における受取人の指定されていないアクティビティの扱いは未定義と明記されていて、アクセス制御については"recommended"（小文字）という表現に留まっている。
まあ、流石にまともな実装で一般的に非公開とされる投稿を晒すようなものはないだろう（ありし日のWildebeestは数に入れないものとする）（`Like`アクティビティ等が平気で晒されていることについてもここでは考えないものとする）（？）
@hongminhee @kisaragi_marine ちなみに、画像に示されている表の手前にItems not marked as "Functional" can have multiple values.と書かれている通り、"Functional: True"とされているプロパティは1つの値しか持てません
このアカウントは、notestockで公開設定になっていません。
個人的なJSON-LDに対する認識は概ねこれだけど、ことActivity Streamsの場合は下手に人間による読み書きのしやすさを追求して拡張コンテクストが乱立することになってしまったのは失敗だと思っている
Schema.orgのように皆が同じコンテクストを共有している場合はplain JSONのノリで読み書きできて便利ですねで済むかも知れないけど、現状のFediverseのように各参加者が好き勝手にコンテクストを定義しているような状況では、plain JSON的な処理だけではある拡張タームがどのような意味を持つか判定できない。
Compactionをかければplain JSONとして見てもある程度曖昧性のない表現になるけど、これは初めからアドホックなコンテクストを導入せずexpanded formで表現していれば不要だったはずのオーバーヘッドでしかない。Expanded formのデメリットといえば人間にとって書きづらいことくらいだろうけど、現実の通信でJSONを手書きする必要なんてないわけで
恐らくJSON-LDは送受信者の間で固定されたコンテクストを共有した上でcompacted formをplain JSON的に処理することは想定しているけど、送信者が好き勝手にコンテクストを定義するユースケースはあまり想定されていないのではないかと思っている。
例えばVC Data IntegrityのContext Validationアルゴリズムでは、文書のコンテクストを自前の既知のコンテクストと比較して、一致しなければcompactionをかけるかあるいは単にエラーを吐くかするといった処理が定義されている（<https://www.w3.org/TR/2024/CRD-vc-data-integrity-20241015/#context-validation>）
ぶっちゃけ適当なURIをfetchしてそのURIのノードからRDFデータセットを辿る分には（少なくとも連結なグラフの場合は）そこまで大変でもないのではという気持ちがあるけど、ActivityPubの`inbox`に送り付けられた文書の場合はRDFデータセットとして見たときにどのノードからどう手を付けるべきなのかよく理解できていない
`inbox`の場合はデータセットからアクティビティを探してその副作用を処理するという形で一見辻褄が合いそうだけど、データセットに複数のアクティビティがあった場合にどうするべきかとかよく分からないし。例えば`Announce`の`object`がアクティビティだったりすることもあるわけだけど、その`object`のアクティビティの副作用を処理するわけにはいかないだろうし。
そして`outbox`に至ってはアクティビティでないオブジェクトを受け取ったら`Create`アクティビティで包むとかいう謎の処理（<https://www.w3.org/TR/2018/REC-activitypub-20180123/#create-activity-inbox>）があけど、RDFとして見たときにどのノードを包むべきか見当もつかない
暗黙にJSON-LD表現におけるトップレベルのオブジェクトから処理することが期待されているように思えてならない
そうそう。「既知の範囲を既知の構造に変換する」を compaction でやれるし、そうでなければ RDF データモデルでグラフ上を動くしかないから、「未知の部分に『知らないとまずいやつ』が潜んでいる」みたいなのユースケースの想定外になってる気がする
JSON-LDの意味論についてはエッジケースが多すぎるので、plain JSONとしての処理を想定するなら大人しくRDFでなくJSONを署名するのが無難そう
@hongminhee That's probably related to the colons in the authority part. @silverpill has had an interesting insight into that topic (it's about the `ap:` scheme, but the same should stand for the `at:` scheme)
QT: https://mitra.social/objects/01928b16-c1f7-a4c7-d63f-0d82c691b58f [参照]
検討はされていたらしい（それはそう）
QT: https://bsky.brid.gy/r/https://bsky.app/profile/did:plc:44ybard66vv44zksje25o7dz/post/3klkv42tmbk2b [参照]
（Bridgy Fed経由では分かりづらいけど、引用元の投稿はブリッジにオプトインしていないアカウントの投稿へのリプライ）
結局NSIDにしなかった理由はよく分からないけど（NSIDでないただの文字列の方が名前空間（またはその欠落）の問題は深刻になるように思える）
まぁ
(ので意味は) ないです。