新しいものを表示
tesaguri 🦀🦝

まあ、Fediverseに溢れているBluesky批判もAtmosphere側から見れば大概似たようなものか（？）。同じことでもそれをあえてFediverseにおいて他人のインフラを使いながらやるとアレになるというだけで

0
tesaguri 🦀🦝

久しぶりに投稿したかと思ったら陳腐なMastodonオワコン論のリブログみたいな人、流石にアンフォローしちゃうよね

0
tesaguri 🦀🦝

たらればの話をしても仕方ないけど、それはそれとして僕の考えた最強のプロトコル設計の話は楽しいので（？）

0
+
tesaguri 🦀🦝

既存のnormが相容れないことについては、データ形式ごと放棄せずとも例えばFEP-ef61 portable objectsのように`id`の名前空間を仕切り直して、新しい名前空間で新たなnormを打ち立てることを目指すとかでも良かったのでは。どうせaccount portabilityの関係から名前空間を分ける必要性はいずれにせよ生じたものだろうし。
どちらもそのままでは相互運用できないことに変わりはないけど、完全に非互換なデータ形式と比べれば`id`が非互換なだけだったなら既存の実装が対応することも容易だっただろう。まあ、そうなるとActivityPub実装が一方的にBlueskyを読むだけというパターンが多くなったかも知れないし、それがBluesky側にとって望ましかったかは知らんけど

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

元の質問（ブリッジされていないけど、リプライ先の<atproto-browser.vercel.app/at/>のこと）がActivity Streamsについてだったのに対して、途中からはActivityPubの話になっているな。
まあ既存のActivityPubのエコシステムにおける純粋なActivity Streamsのサポートが渋くて、純粋なActivity Streamsを露出しても中途半端な扱いになったかも知れないというのはそれはそうかも知れないけど……

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

やはりRDFが嫌というのが第一の理由か。しかし根本的なアーキテクチャの違いなどと比べると、既存のエコシステムとの相互運用性と天秤にかけるには軽すぎるように個人的には思えるけど、まあこれはBlueskyにとっての一般のWebエコシステムとの相互運用性の重さというのがその程度でしかないという話なのだろう
QT: bsky.brid.gy/r/https://bsky.ap [参照]

Paul Frazee  
I gave RDF and ActivityStreams a really close look and there are two things I really didn’t like about it1, RDF usability is bad. It’s designed to...
1
tesaguri 🦀🦝 さんがブースト
+
Paul Frazee

I gave RDF and ActivityStreams a really close look and there are two things I really didn’t like about it 1, RDF usability is bad. It’s designed to solve the problem of universal terms agreement, and it does *that* very well, but that’s a far more general system than what a protocol needs —

0
tesaguri 🦀🦝

AT ProtocolのAppViewをGoogleに喩えると一般のWebと大して変わらないように思えるけど、恐らくAppViewというのは検索エンジンだけでなくgoogle.com/ampのようなキャッシュレイヤーでもあって、しかもGoogleのそれと違ってキャッシュされていないWebページ、もとい`at:` URIへのアクセスを許すようなものでもないっぽいので、重要な要素を取りこぼした喩えのように思っている

0
tesaguri 🦀🦝

例えばZennがGitHub以外のGitリポジトリからもデプロイできたとして、それを「分散」と呼んで良いのかみたいな（適当）

0
+
tesaguri 🦀🦝

Blueskyは「ActivityPubはスケールしない（笑）」（<bsky.brid.gy/r/https://bsky.ap>）という立場だから、「ActivityPubに対応」するようではそもそもの存在意義が薄れるわけで……。それを"decentralized"と呼んで良いかはアレとして [参照]

0
tesaguri 🦀🦝 さんがブースト
+
GENKI

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

1
tesaguri 🦀🦝

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

0
tesaguri 🦀🦝

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

0
+
tesaguri 🦀🦝

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

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

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

1
tesaguri 🦀🦝

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

0
+
tesaguri 🦀🦝

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

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

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

1
tesaguri 🦀🦝 さんがブースト
のえる

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

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

0
+
tesaguri 🦀🦝

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

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

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

トレンドタグ

リソース

開発者向け

Mastodon とは？

fedibird.com

さらに…