新しいものを表示
+
tesaguri 🦀🦝

Switch Bluesky to opt out? · Issue #1471 · snarfed/bridgy-fed
github.com/snarfed/bridgy-fed/

1
+
tesaguri 🦀🦝

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

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

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

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

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

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

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

スレッドを表示
0
+
tesaguri 🦀🦝

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

1
+
tesaguri 🦀🦝

I think OStatus was fine enough, except for lack of native support for private posts and manual approval of follows (and, uh, proper documentation). That has been making me wonder if WebSub would've been actually a nice fit for AT Protocol, that doesn't support private posts either (Bluesky's direct messages aren't quite integrated into the protocol AFAICT)

0
+
tesaguri 🦀🦝

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

スレッドを表示
0
+
tesaguri 🦀🦝

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

1+
+
tesaguri 🦀🦝

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

スレッドを表示
1
+
tesaguri 🦀🦝

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

スレッドを表示
1
+
tesaguri 🦀🦝

AppViewの運用というものにはグローバルビューの集約という劇重責務が付き物であることから、気軽に実装して運用できるような代物でないという構造的なインセンティヴの問題はあるかも知れない

スレッドを表示
0
+
tesaguri 🦀🦝

AT Protocolのサービスといっても、単なる"Sign in with Bluesky"レベルのものやbsky.appの代替Webクライアントの見分けが付きづらいのが困る。いや、それこそが意図して設計された「機能」なのかも知れないけど

1
tesaguri 🦀🦝

例によってPLCについては考えないものとする（？）

0
+
tesaguri 🦀🦝

「bsky.socialに一極集中」については、BlueskyとBridgy Fedを除いたPDSのアクティブユーザ数は、ええと……約0.027%？（<blue.mackuba.eu/stats/>）

スレッドを表示
1
+
tesaguri 🦀🦝

AppView実装という意味ならBlueskyの他にWhiteWindやFrontpage、Linkatなどがあるから、「ATProtoの実装はBlueskyしか存在しな」いはフェアな表現でないように思う。
PDS実装としてもarroba（Bridgy Fedのsnarfed氏がメンテナンスしているやつ）などがあるけど、可搬なデータ形式を共有する以上はPDS実装による違いというのは実際のところ多分そこまで重要でない。違いがあるとしてもXRPCメソッドの実装詳細などの細かい差異くらいだろうか。
で、分散という観点においてより重要であろうリレーについては……知らんｗ（？）

1
tesaguri 🦀🦝 さんがブースト
そらいろ

せんせー！どうしてATProtoの実装はBlueskyしか存在しなくて、かつbsky.socialに一極集中しているのですかー？

0
tesaguri 🦀🦝

申し訳ないとは思っている。いやほんと、申し訳ないとは思っているのよ

0
+
tesaguri 🦀🦝

（まあ理論上の問題としては受信のタイミングだけではなくて、例えば接続元やkeyid等によって異なる表現を出し分けられるとか、何ならfetchの度にランダムに異なる表現を返されるとか、あらゆる可能性を想定できてしまうのだけど）

スレッドを表示
0
+
tesaguri 🦀🦝

投稿の編集を肯定しようがしまいが、content-addressedとかなわけでもないデータを連合している以上はリモートのオブジェクトが勝手に書き換わることを妨げられないわけで、オブジェクトの編集の受信をサポートしなければオブジェクトを受信したタイミングによって異なる表現を掴まされうるという問題を抱えるだけだよね

1
古いものを表示
Fedibird

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

トレンドタグ

リソース

開発者向け

Mastodon とは？

fedibird.com

さらに…