新しいものを表示
tesaguri 🦀🦝 さんがブースト

#Bluesky は、分散型を謳うからには実際に分散して、あと標準化団体がちゃんと標準化した技術であるところの #ActivityPub :activitypub: に対応してから出直しておいで…と、2億年前から思っている。
横目で応援はしてるけど、not for me という感じ :tony_normal:

github.com/tesaguri/userscript
> fix(fedibird-hook-bsky-app-links): oh shoot `RequestInit.referrer` uses correct spelling
今日のクソコミット

First draft of ActivityPub HTML Discovery report from Evan Prodromou on 2024-11-16 (public-swicg@w3.org from November 2024)
lists.w3.org/Archives/Public/p
ActivityPub Discovery
swicg.github.io/activitypub-ht

どちらかというと後者のRedoclyの方が食っていたっぽいかな

スレッドを表示

FirefoxとThunderbiredくらいしか開いていないのにメモリ不足になって何事かと思ったけど、Misskey Hubや<misskey.io/api-doc>を閉じたら2 GiBくらい空いた(?)

あと、どう取り繕っても悪口みたいになってしまうけど、Misskey APIの命名は全体的に英語として理解しづらいがち。
例えば今言及した`MiNote`エンティティも、他のプラットフォームでは`inReplyTo`とでも呼ぶであろう概念を単に`reply`という名前で指していたりするし……(単に"reply"というと、素朴にはそのノートに対して返信している他のノートのことのように思えてしまう)

あと返信が1件もないときにも"Show replies"が表示される仕様も混乱しがち。いや、`GET notes/show`を呼んだときに`repliesCount`が`0`だったとしても後から`GET notes/children`を呼んでみればリプライが生えていることもそりゃありうるだろうけどさ……

スレッドを表示

他人からのリプライについてはともかく、なぜ自己リプライ・スレッドまでワンクッションの操作を挟む仕様なのか気になっている表示も何か小さいし

tesaguri 🦀🦝 さんがブースト

Misskeyは返信わかりづらいよね。

だいたいMastodonと同じことができるよって言えるんだけど、リプライツリー・スレッドについては厳しい。

AT Protocol(というか`app.bsky.*` lexicon?)の性質を考えればオプトアウトの方が馴染むというのは総論として同意だけど、`!no-unauthenticated`セルフラベルやリプライ制御と、(特にアカウントの所有者本人によってセルフホストされた)他のブリッジとの重複への対応をどうするのか気になるな
QT: fedibird.com/@tesaguri/1132656
[参照]

tesaguri 🦀🦝  
ActivityPubからAT Protocolのブリッジについてはどうしてもdata repositoryへのデータの複製・再頒布を伴うからオプトインが妥当だと思うけど、逆方向についてはAPサーバというのは単なるプロクシとして振る舞えるので、一般のAppViewと同じくオプトインなしで閲覧で...
スレッドを表示

ここでの「ローカル」とは、フォロイーのサーバがフォロワーのサーバに直接アクティビティを配送して、フォロワーのサーバがそれを`inbox`コレクション(あるいはMastodon API等における相当物)にまとめるという二者間通信を基本とするActivityPubの世界観を念頭に置いた上での、「グローバル」の対義語としての表現のつもり。
「リモート」の対義語と紛らわしいので、「大域的」/「局所的」とでも言った方が良かったかも知れない

スレッドを表示
tesaguri 🦀🦝 さんがブースト

まあ、APの世界観だとrepliesとかついてくるし、なんならs2sでもLinkほぼ使わずに生Object突っ込むのも許されてるので、もしかしたら本当に二者間で閉じてるところもあるのかもしれないな。もしくは一旦サーバーに溜め込むという意味でのローカルなのか。

スレッドを表示
tesaguri 🦀🦝 さんがブースト

これ実際けっこうしんどいと思っていて、例えばbsky appview代替をスモールスタートしようとすると、(backfill抜きにしても)かなり困難があるのは確か。本当に最低限、個人の視界確保から始めるならfeed generatorくらいのノリでいけるだろうけど、使い途あるかは怪しい。 一方でホームタイムライン(Following)の構築がローカルな体験と言われると、ちょっと疑問ではあるが。 [参照]

tesaguri 🦀🦝  
全てが無料でないというのは当然のコストとしても、自己負担で良い感じに慎ましく自己統治する選択肢に乏しいのが問題だと思っている。PDSはセルフホストしたところでリレー・AppViewレベルの検閲からの自由を得られるような代物ではないし、リレー・AppViewも自分の必要な範囲だけで慎ましく運用で...

というかフィードのエントリをメッセージフィルタで分類するのは今までもやっていたことだけど、この通知の仕様は以前からあったものだったっけ

スレッドを表示

フィードリーダとしてのThunderbirdが新着エントリを通知してくれない(<bugzilla.mozilla.org/show_bug.>)のが今までの悩みどころだったけど、どうもメッセージフィルタでエントリをフォルダに移動すると通知が発火してくれるらしいので、これなら実用上は問題なさそう

`com.atproto.sync.subscribeRepos`(<github.com/bluesky-social/atpr>)とかも、見たところPDS全体でなく個別のリポジトリのみを購読するようなことは出来ないようで、いかにもリレー専用メソッドという感じである。
`com.atproto.repo.listRecords`のポーリングで代用できなくもないだろうけど

スレッドを表示

AT Protocol、もうちょっとWebSubとフィードアグリゲータに近い感じの世界観だったら好きになれただろうにと思っている。
というか今からでもWebSubと(セルフホストの)フィードアグリゲータをもっと流行らせません?(?)

全てが無料でないというのは当然のコストとしても、自己負担で良い感じに慎ましく自己統治する選択肢に乏しいのが問題だと思っている。PDSはセルフホストしたところでリレー・AppViewレベルの検閲からの自由を得られるような代物ではないし、リレー・AppViewも自分の必要な範囲だけで慎ましく運用できるような代物でもなければ、運用したところでやはりオーディエンスが着いてこなければどうしようもないことに変わりはないし。
ホームタイムラインの構築のような、(自分が選んだユーザ以外の情報のインデックスを必要としないという意味で)ローカルで基本的な体験までもがグローバルビューの集約と同一レイヤーによって担われているせいで、結局リレー・AppViewという強力なネットワーク効果を握る存在から逃れられないのではと思っている

スレッドを表示

まあクローリングや、場合によっては集約も含めた面倒くさい部分を避けてつまみ食いでハックできるのは開発者体験としては魅力的ではあるのだろう。
一方でその誰も実装したくないリレーやらAppViewとかいうやつがいつまでもfirehoseやその他のインタフェースをunensh*ttified(?)かつ無料で提供し続けてくれるのか甚だ疑問だけど

スレッドを表示
古いものを表示
Fedibird

様々な目的に使える、日本の汎用マストドンサーバーです。安定した利用環境と、多数の独自機能を提供しています。