このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
https://mastodon.social/@dansup/111617703110836835
> Soon we will be selectively enforcing authorized fetch for accounts with domain blocks so as to provide the best of both worlds.
なるほどなあと思うと同時に、むしろMastodonにおいて`AUTHORIZED_FETCH`がアカウント単位の設定でなくサーバ全体の設定になっている理由が気になってくるな。`AUTHORIZED_FETCH`のデメリットというとオブジェクトの署名の無効化によるinbox forwardingやらリレーやらの配送効率の低下であって、そのコストを負うのはサーバの管理者であるからとか？ エンドユーザにとってのデメリットというと互換性の低下くらいだろうか [参照]
個人的にはリクエストを何でもかんでも署名するのはプライバシー上の問題がないか心配なのだよなあ。まあ署名には基本的にsystem actorの鍵対を使うとして、それでも問題になるとすると個人用サーバの振る舞いがその管理者による操作をリアルタイムに反映してしまうことくらいだろうけど、それは元々IPアドレスから分かることではあるだろうから、署名によって新たな問題が生じるかというと微妙かも知れないけど
Backfill statuses from remote accounts when first subscribed · Issue #34 · mastodon/mastodon
https://github.com/mastodon/mastodon/issues/34#issuecomment-1703650033
System actorでなく個々のアカウントの鍵を使う動機のある機能の提案もあるので、そのあたりはどう実装されるか気になっている
ActivityPubのC2Sプロトコル（Social API）ではクライアントが直接アクティビティを生成するからFEP-ae97 (Client-side activity signing; <https://codeberg.org/fediverse/fep/src/branch/main/fep/ae97/fep-ae97.md>)のような面白そうなことが可能になるのだけど、その利点を活かすにはサーバはクライアントから送られたアクティビティのオブジェクトをそのまま配信する必要があるわけで、バリデーションやらデータベースにおける扱いやらがややこしくなりそうである
トリプルストアの普及の機運か？（？）いや、JSON-LDのコンテクストはどないすんねん（？）
バリデーションの問題についてはFederation Protocolにも言えることだし、案外同じ要領で処理できたりするだろうか。`published`の値なども任意に設定可能にするのは過激かも知れないけど、例えばproxy object（FEP-fffd）のようなユースケースではそのレベルの自由度も妥当なのでは。まあ汎用のサーバであらゆるユーザにそれを許すのは微妙かも知れないけど……
しかしクライアントサイドの署名を求める場合において`Update`アクティビティの扱いはどうなるのだろう。`Update`アクティビティの`object`プロパティはSocial APIとFederation Protocolの間でかなり異なるわけだけど。具体的には、Social APIにおいて`object`は元のオブジェクトからの差分として扱われるのに対して、Federation Protocolにおいては更新後のオブジェクト全体を`object`に含めることが求められているし、そもそも更新後に`object`のURIを参照外しした場合はその結果は更新後のオブジェクト全体になることが期待されるわけで
まあFederation Protocolと違ってSocial APIは<del>あまり流行っていないし、</del>互換性の影響範囲が特定のサーバとそのユーザの間に閉じているから多少は勧告と異なる要件を含めてもワンチャン許されそうだし（ホンマか？）、`Update`は部分的な更新でなく完全な置き換えとして扱う対応もアリかな？ そもそも部分的な更新は特にプロパティの削除に関してRDF的に扱いに怪しさがあるし（<https://github.com/w3c/activitypub/issues/396>）。まあ部分的な更新が出来ないと何かと面倒そうな気がしないでもないけど……
クライアントAPIの仕様がMastodonだのMisskeyだのといった特定の実装に紐付いていたり、例えばリアクション機能をMastodon APIで実現しようとしたときにFederation Protocolから独立して拡張が乱立したりするのはつらみがあるからActivityPubのSocial APIももう少し流行ってくれると良い気がするけど、実際のところとしてはいまいちパッとしないのだよなあ。「インスタンス」だのドメインブロックだののようにSocial APIの枠組みでは扱いづらそうな概念も多いし
これは冬コミで身に付けたFediverse的ライフハックですが、ActivityPubの仕組みに明るくない方に他サーバーの自分のアカウントを紹介するとき、直接自鯖のURLを伝えるのでは無くMisskey.ioで開いた自鯖のアカウントを共有することでフォローされやすくなるという知見を得ました
https://misskey.nokotaro.com/notes/818cc7516957ebcc543b6f2e
これ、照会しようとしたら逆に混乱するのではと思って取りあえずissueを立ててみた：
リモートユーザのプロフィールページに対する照会のリクエストに対してリダイレクトを返す · Issue #12892 · misskey-dev/misskey
https://github.com/misskey-dev/misskey/issues/12892 [参照]
usernameが同じpersonとgroupを照会できない · Issue #11713 · misskey-dev/misskey
https://github.com/misskey-dev/misskey/issues/11713
それぞれ別の`Person`と`Group`アクターが同じusernameを共有することがあるのか
https://github.com/mastodon/mastodon/pull/19059#issuecomment-1875154293
でもこれって`as:type`という名前を「プロパティ」として使っているけど、そんな名前のプロパティ（not "term"）は存在しなくない？ と思うなどした
このアカウントは、notestockで公開設定になっていません。
https://p1.a9z.dev/notes/9o1cfkb6qr
[Feature] Support Protobuf or Flatbuffers communication for performance · Issue #346 · w3c/activitypub
https://github.com/w3c/activitypub/issues/346
これを思い出した [参照]
ここでもまたしても（？）JSON-LDの扱いが課題として挙げられているけど、まあJSONのデータモデルのスーパーセットがあればJSON-LDのデータモデルも恐らく表せｒ……あ、`"@version": 1.1`（？）
の投稿
0x0@corteximplant.com
このアカウントは、notestockで公開設定になっていません。
今回問題になっているpushの場合はコンテンツ交渉の問題もあるか。Pullの場合なら`Accept`ヘッダに`application/ld+json; profile="https://www.w3.org/ns/activitystreams"`に加えてオレオレメディアタイプが指定されていたらオレオレ形式で返すような拡張は考えられるかも知れないけど
コンテンツ交渉に応じてオレオレ形式で応答したアクターの`inbox`にはオレオレ形式でpushしても良いものとするということも考えられなくもないだろうけど、そうすると例えばpush先がオレオレ形式のサポートを辞めたいときに困らないだろうか。Push時にリクエストボディのメディアタイプについて交渉できるような仕組みがあれば良いのか？（そして乱用されるALPN（？））
【配送遅延のお知らせ】
現在、配送に遅延が生じておりMisskey.io以外のサーバーから投稿が見れない場合があります。
ご迷惑おかけして申し訳ございません、改善に向けて調査・対応しております。
@0x0 That might work, but I think the downside of the Nodeinfo-based approach (over <del>ALPN</del> `Accept` header-based one) would be that you wouldn't be able to negotiate the media type that way and the cached Nodeinfo metadata might go stale at any time, which is likely especially for a possibly experimental extension like that (and yeah, I doubt if the binary serialization is worth it, too)
@0x0 s/negotiate the media type/\1 on a per-session basis/
@0x0 Uh, in theory, they could reimplement the whole stack just to handle ALPN. That would be an interesting exercise for overengineering indeed
ぎゃあ、途中から文章が全てリンクになっている！ 訂正：
[…] Pullの場合なら`Accept`ヘッダに`application/ld+json; profile=""https://www.w3.org/ns/activitystreams"` に加えてオレオレメディアタイプが指定されていたらオレオレ形式で返すような拡張は考えられるかも知れないけど
こういうときにサーバが`Note`オブジェクトの`Update`アクティビティに対応していないのが不便に感じなくもないけど、いずれにしても今回のような大修正の場合は単に`Update`するだけでなく修正した旨を明言するべき気もするし、まあ、はい
FEP-2c59: Discovery of a Webfinger address from an ActivityPub actor - Standards / Fediverse Enhancement Proposals - SocialHub
https://socialhub.activitypub.rocks/t/fep-2c59-discovery-of-a-webfinger-address-from-an-activitypub-actor/3813/14
色々と思うところがあるのだけどGmail云々
いい加減SocialHubに登録できないユーザによる議論への参加に関する方針を（他の同様の状況のユーザからも参照できる形で）確認しておかなくてはなあ、などと言い続けて幾星霜（？）
の投稿
AureoleArk@misskey.io
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
Semantics of embedded `object`s of `Update` activities in collections of activities · Issue #408 · w3c/activitypub
https://github.com/w3c/activitypub/issues/408
立てた
RDFの意味論について重箱の隅をつつく面倒くさいムーヴです、はい……
そもそもprtial updateは開世界仮説的なモデルに馴染まないよねなどと言い出さなかっただけ褒めて欲しい（？）
かくいう私もRDF SemanticsやRDF Schemaなどの各種勧告を1ミリも理解していないし（いわんやOWLをや）、JSON-LD Processing Algorithmsはブラックボックスとしてしか捉えられていないからなあ……
改めて試みたら普通に（確認メールがジャンク送りになっていたものの）登録できた。というか昨年の12月25日に登録を試みた時点で既にジャンク扱いではあったもののメールが届いていた（それ以前に試したときはジャンクにすら現れなかった）
Re: Congratulations! from O'Brien, Sean on 2023-12-15 (public-swicg@w3.org from December 2023)
https://lists.w3.org/Archives/Public/public-swicg/2023Dec/0063.html
W3CのSocial Web Incubator Community Groupのメーリングリストを購読したら、この揶揄に端を発する半月以上にわたるチクチク言葉の応酬のまっただ中だったので怖くて泣いている
「RFCの文面からはこう読み取れる」と書いたら「私はそのRFCの策定に関わったが、意図はそうではない」と返されて思わず「ずるい！！！」と叫んでしまった（？）
読解問題に対して作者が現れて「作者はそんなこと考えていません」とか言い出すやつじゃん（？）
コードレビューとかいうやつは重箱の隅をつつけばつつくほどえらくなれるのですごい（もちろん建設的であることは求められる）
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
https://mastodon.social/@LFLegal/111721331493993279
https://mastodon.social/@LFLegal/111546043984783550
Accessibility overlay周り、こんなことになっていたのか
用語解説：Accessibility overlays…Webアクセシビリティの問題を自動的に修正してくれるとされる魔法のツールの総称。アクセシビリティの瑕疵に由来する法的リスクの回避などに使われる [参照]
「オンライン状態」の表示機能みたいなものはせめてオプトインにするように法律で義務づけて欲しい〜
今はDiscourseのオンライン状態を消す方法を探しているところです
Discourse、他にも"read time"のようなユーザのプライベートな活動に関わる統計をやたらと公開してきて嫌だ
面倒くさいので基本的にログアウトしておいてCookieも毎回消す運用にするか……
連合でやり取りするファイル形式をバイナリにするとかよりも、`inbox`への`POST`で一方的に`Content-Encoding`を指定するとかの方が効果が見込めそうだし、まだ受け容れられる余地もあるのでは？（ない）
レスポンスの`Content-Encoding`についてはクライアントもサーバも様々な形式に対応しているのに、リクエストではそれを活かしづらいのは実際もどかしいなあ
Add FEP prefix by trwnh · Pull Request #3830 · perma-id/w3id.org
https://github.com/perma-id/w3id.org/pull/3830
👀
このアカウントは、notestockで公開設定になっていません。
の投稿
0x0@corteximplant.comこのアカウントは、notestockで公開設定になっていません。
の投稿
0x0@corteximplant.comこのアカウントは、notestockで公開設定になっていません。
European Union Public License v. 1.2 added to license list — Free Software Foundation — Working together for free software
https://www.fsf.org/blogs/licensing/european-union-public-license-v-1-2-added-to-license-list
EUPL、初めに概要を把握したときに「あれ？」と引っかかったものの、さすがに何かしらの抜け道の対策があるものと思って後で調べようと思っていたのだけど、本当にGPLで再ライセンスできてしまうのか……
fix(backend): reject malformed timestamp by acid-chicken · Pull Request #12554 · misskey-dev/misskey
https://github.com/misskey-dev/misskey/pull/12554
（2023-12-03のPR）
2000-01-01T00:00:00Z以前（aid/aidxの場合）のタイムスタンプを「不正」とみなすの、一見して妥当そうに思えるかも知れないけど、例えばWordPressのようにActivityPub対応以前の記事を遡及的にFediverseに配信するユースケースもあるから、実際のところ怪しい気がする
攻撃的な意図のないオブジェクトによるIDの枯渇を抑止する効果が期待できるのは分かるけど、いずれにせよ悪意のある攻撃への耐性も必要なわけで……と思ったけど、
https://github.com/misskey-dev/misskey/blob/4553d6426bfa6a54754d5cf477d04782d5e05860/packages/backend/src/misc/id/aid.ts
aidの場合は「ノイズ」の取りうる空間の大きさが36^2 = 1296なのか……
서버메이드 깐프の投稿
perillamint@silicon.moe
このアカウントは、notestockで公開設定になっていません。
https://github.com/mastodon/mastodon/blob/v4.2.3/lib/mastodon/snowflake.rb#L99-L105
秒精度のタイムスタンプに加えて(16 + log_2(1000)) ≈ 26.0 bitsの乱数をエンコードしているから実用上は十分という判断かな。攻撃耐性を考えると、birthday boundは2**(26/2) = 8192？ うーん……？
FEP-e232: Object Links - #60 by silverpill - Fediverse Enhancement Proposals - SocialHub
https://socialhub.activitypub.rocks/t/fep-e232-object-links/2722/60
> Threads implemented FEP-e232.
おお
別に衝突が1回発生するくらいなら件のコードでそうされているように再試行すれば良いだけで、衝突の例が見つかればこの世の終わりみたいな暗号学的ハッシュ関数などとは事情が違うか。ID生成器に対して有効な攻撃が成立する条件はID生成の平均コストないし失敗率を大幅につり上げることだろうから、それを防ぐには26 bitsもあればまあ十分かな？
ただ、生成のコストについてはともかく、失敗については一度でも発生したらこの世の終わりではないにせよ、特に攻撃的でないリクエストの場合においてはそこそこ困る部類のエラーであるな。まあ最大100回も再試行すれば本当に運が悪ければ応答が遅くなるものの、失敗にまで至ることは十分稀といえるか
もし平均の再試行回数を100近くまでにつり上げることが出来ればDoSが成立してしまうだろうけど、そのレベルの衝突率に持ち込むにはそれまでに膨大な数の攻撃的なリクエストを受け付けさせる必要があるわけで、それを弾けていないとすればそもそもIDの衝突が云々とか言っている場合ですらない事態だろうし
🍆の投稿
Yohei_Zuho@mstdn.y-zu.org
このアカウントは、notestockで公開設定になっていません。
そういえば、Fediverse上の匿名メッセージサービスについてfediverse-ideasのネタになりそうだと思って書き始めたものの途中で放置している下書きがあるのだった
- 差出人はエージェントとなるアクターを介してメッセージを送る（リモートのオブジェクトに対する通報の転送において既に実践されているのと似た要領？）
- 受取人は特定のエージェント経由のメッセージを受け容れる意思を事前に示すものとする（FEP-5624に関連して提案されているmention control policyの応用？）
- メッセージへの回答は引用投稿として公開する
……というところまで考えて、差出人からエージェントへの経路およびエージェントから受取人への経路で送られるメッセージのaudience targetingの扱いをどうしたものかなあ〜というところで止まっている。前者は受取人を特定する必要がある一方で受取人に直接通知してはならないという両立しづらそうな要件がある。後者は回答するまでは非公開にしておくべきである一方で回答は公開投稿として（も）行われるから、引用元より引用側の公開範囲を広くしたいという矛盾した要件になってしまう
まあドラフト段階のFEP-5624のそのさらに一般化を前提とするようなオーバーエンジニアリングに走らずとも、単にメンションでボットに対するコマンドを送りつけるとかでも良いだろうし、そちらの方が互換性としても優れるか
このアカウントは、notestockで公開設定になっていません。
"Here's why"でGailさんのエピソードを読めるのかと思ったら、それとは無関係のただの一般論的な内容だった
QT: https://mastodon.social/@protonmail/111849940346471311 [参照]
