新しいものを表示

w3.org/TR/2017/REC-activitystr
> Consuming implementations that encounter unfamiliar extensions MUST NOT stop processing or signal an error and MUST continue processing the items as if those properties were not present.
これなあ

tesaguri 🦀🦝 さんがブースト

MastodonもSidekiq見てると外部から取ってきた投稿のバリデーションエラーが一定数あり、あれもバリデーションエラーとして処理したらダメだよなあとは思ってる

Akkomaには連絡が行っていなかったのかな……

tesaguri 🦀🦝 さんがブースト

information finally got to us around the houses, but release - irregular release 3.13.3 to corect some behaviour around fields interacting badly with misskey

bundled with what is a bunch of stuff i didn't feel i had enough for a full release over so enjoy

same process as ever! [db migrations exist, make sure you do them]
https://docs.akkoma.dev/stable/administration/updating/

misskeyの開発者などへ:今後、不具合可能があるかもしれない場合には、私たちakkomaチーム(あるいはpleromaの)に直接ご連絡してください!

Announcing AT Protocol Grants | Bluesky
docs.bsky.app/blog/atproto-gra
重要なのを忘れていた。グラントもあるのだった。資金力〜

スレッドを表示

`url`プロパティを使う慣習というのはMbin(というか/kbin)を指してのことだったけど、LemmyやPieFedでは`attachment`に`Link`を入れる方式っぽいな。というかMbinでも`url`に加えて`attachment`でもリンク先を参照している

スレッドを表示

この辺りの定義がはっきりしていたらリンクアグリゲータとかだってきちんと`"rel": "about"`などを使っていただろうに(ホンマか?)

スレッドを表示

しかし`Link`型を定義するくらいなら`url`プロパティもはっきりとRFC 8288のlink relationを示すものとして定式化しておけば良かったのにと思わないでもない。JSON Activity Streams 2.0の前身であるAtomでも`<atom:link>`で`url`相当の機能を実現していたわけだし

w3.org/TR/2017/REC-activitystr
まあ`url`プロパティの"Identifies one or more links to representations of the object"という定義に照らせばリンクアグリゲータ等の慣習の方がおかしいと言えそうだし、そこまで気にしなくても良さそう?

スレッドを表示

しかしBridgy Fedの"original post"は`id`でなく`url`なのか。リンクアグリゲータ系の実装で`url`がオブジェクト自身のHTML表現でなくリンク先を指すような例があったりするから、上手く動かないことがあってもおかしくなさそうだな。
しかし`id`は`id`でコンテンツ交渉に応じてActivity StreamsでなくHTML表現を返してくれる保証もないしなあ。HTMLを返さない例としてThreadsがある

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

tesaguri 🦀🦝 さんがブースト

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

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

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

スレッドを表示

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…?

tesaguri 🦀🦝 さんがブースト

具体的に言うと

1. ioのバナーはプロフィールの「追加情報」として連合される

2. 結果、追加情報が30個くらいついてるユーザーが生まれる

3. 追加情報欄のPleromaのデフォルトの上限がわりと低いので、上限を余裕で越す

4. よってPleromaはRejectするが、バグがあって「Rejectしたものを再Fetchしない」ようになっていない

5. そのため、PleromaはまたFetchしようとする

6. 3に戻る

となっています [参照]

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

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

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

スレッドを表示

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

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

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