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

Bridgy Fed、ブリッジ先のプラットフォームの字数制限まで文字数を切り捨てる処理で、分かち書きを前提にして最後の空白文字まで切り捨て（るようなライブラリを使用し）ているっぽくて、日本語の扱いが怪しい。
例えばこれとか：<atproto-browser.vercel.app/at/>

1
tesaguri 🦀🦝 さんがブースト
+
SyoBoN

ただ、Pleromaはどこかのソフトウェアと違ってdevelopの修正がstableに降ってくるのにだーいぶ時間がかかるため……

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

たしか「追加情報が多すぎた場合、単にオーバーした分を無視してRejectはしない」「Rejectしたら一定期間Fetchしない」あたりの修正がdevelopには入ってたと思います

スレッドを表示
1
tesaguri 🦀🦝

User: truncate remote user fields instead of rejecting (!4220) · Merge requests · Pleroma / pleroma · GitLab
git.pleroma.social/pleroma/ple
> feld merged 3 months ago
3 months ago…?

0
tesaguri 🦀🦝

なるほどなあ……

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

具体的に言うと

1. ioのバナーはプロフィールの「追加情報」として連合される
↓
2. 結果、追加情報が30個くらいついてるユーザーが生まれる
↓
3. 追加情報欄のPleromaのデフォルトの上限がわりと低いので、上限を余裕で越す
↓
4. よってPleromaはRejectするが、バグがあって「Rejectしたものを再Fetchしない」ようになっていない
↓
5. そのため、PleromaはまたFetchしようとする
↓
6. 3に戻る

となっています [参照]

SyoBoN  
これな〜〜〜〜〜〜〜(ioのバナークソアホにつけてるユーザーフェッチしようとするとPleromaのバグでDoSしちゃうやつ)
1+
tesaguri 🦀🦝 さんがブースト
+
村上さん🔰

AkkomaとかPleroma、バグっててDDoS状態になってるんだけど、この状態になってからそろそろ半年近く経つのでもう少し様子みて改善されないならブロックする必要がある

1+
+
tesaguri 🦀🦝

そもそも一般にサービス提供者視点で（ユーザ視点でなく）AT Protocol上にサービスを作る嬉しさというものが何なのかあまり理解していない気がするな。
Blueskyのユーザ層を引き込めること……はリレーを別けたら微妙そう。Blueskyのモデレーションに相乗りできること……もリレーを別けたら意味ないな。「ナウなAT Protocolのサービス」という話題性……うーん？

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

いや、同じlexiconを喋る複数のAppViewに分裂するならまだしも、独自のAppViewで独自のlexiconを喋る分には混乱はそこまで発生しないか？　いずれにせよあえてAT Protocolの上に実現する嬉しさがあるのかも微妙な気はするけど

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

例えばpixivのようなモデレーションの方針が相容れなそうな（偏見）プラットフォームがAT Protocol対応する際に独自のリレーを構えるようなシナリオを想像していたけど、ネットワークを別けるくらいならそもそもAT Protocolに対応する意義も薄いか

1
+
tesaguri 🦀🦝

これ、Blueskyの崩壊とまではいかないまでも仮にモデレーションの方針の違いなどからリレーが分裂して、ユーザ層がある程度重複しつつも一致はしないネットワークに別れたりしたときに困らない？

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

勢いで「現在の仕組みでは」と書いてしまったけど、あるリポジトリの所有者がどのAppViewを使っているかクエリするための仕組みなんて将来的にも実現されるわけがないか。あるAppViewやリレーが`com.atproto.sync.subscribeRepos`しているホストの一覧くらいならまだしも

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

あと、自分の視界を確保する分には既知の人々のPDSを探してクロールするということも出来なくはないだろうけど（PLCの解決の問題をどうにかしてどうにかしたとして）、他人にリプライなどのアクティビティを届けるには相手が自分のPDSの存在を把握している必要があるわけだけど、この疎通の有無をこちらから確認するのは少なくとも現在の仕組みでは困難では。
現在は`bsky.network`が「公式」という権威をもって実質的に全てのPDS（あえて連合していないものを除く）から`com.atproto.requestCrawl`を受けて大域的なネットワークのクロールを実現しているものと理解しているけど、Blueskyが散り散りになった後にそのような権威が自明に存在しうるとも思えないし

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

Bluesky PBCが消滅してもBlueskyを「セルフホスト」することが出来ると言われても、仮にBluesky PBCですら失敗したのだとすれば他に誰がリレーだのAppViewだのといったデカブツを世話できるのかという問題があるわけで、代替可能であることがどこまで嬉しいのかは疑問に思う。
これらは酔狂で持続的にセルフホストできるだけの細かい単位に分割できるようなアーキテクチャにはなっていないわけで

1
tesaguri 🦀🦝 さんがブースト
+
ふぉの :inkan: :sabakan: (自律しろ)

Blueskyも、Blueskyというフロントエンドが死んでも誰かが立てれば良いという側面があるので、それらすべての対応実装が死なない限り死んだとは言い切れないという問題が

1
+
tesaguri 🦀🦝

いわゆるauthorized fetchで弾きたいようなアクセスはある程度の敵対的関係を前提にしたケースが多いと思うけど、公開オブジェクトについては許可リスト連合でもない限りはいくらでも迂回のしようがあるし、脅威モデルとしては「行儀良くアクセスしてくれる敵対者」という奇妙な存在が仮定に含まれるということになりそうだよなあ

1
tesaguri 🦀🦝 さんがブースト
+
洪 民憙 (Hong Minhee)

Hot take: It is bad that #ActivityPub software implements #AUTHORIZED_FETCH, also known as secure mode, because, contrary to its name, it does not actually contribute to security and instead gives a false sense of security.

swicg.github.io/activitypub-ht

1+
+
tesaguri 🦀🦝

というかアクターがサーバの協力なしに脱出できるようになると「ローカル」と「リモート」という分類の意味するところすら変わりうるな

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

考えてみれば、リモートのオブジェクトの`id`を不透明な文字列として扱っているのをローカルのオブジェクトにも一般化すれば良いだけの話か。どうせクライアント側での署名を考えると特定のパスの形式を強制するのは難しいだろうし
QT: mitra.social/objects/01935ec0- [参照]

silverpill  
@tesaguri The path component is a so called "opaque string". It is supposed to be implementation-independent and shouldn't be tied to routes used b...
スレッドを表示
1
tesaguri 🦀🦝 さんがブースト
+
silverpill

FEP-ef61 should be compatible with other DID methods.

did:tdw is one of those candidate methods: it is similar to did:web (supports rotation), but DID document can be migrated to a different domain.

1
古いものを表示
Fedibird

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

トレンドタグ

リソース

開発者向け

Mastodon とは？

fedibird.com

さらに…