Bridgy Fed、ブリッジ先のプラットフォームの字数制限まで文字数を切り捨てる処理で、分かち書きを前提にして最後の空白文字まで切り捨て(るようなライブラリを使用し)ているっぽくて、日本語の扱いが怪しい。
例えばこれとか:<https://atproto-browser.vercel.app/at/did:plc:lffon5yhpjy26636i2xjl6as/app.bsky.feed.post/3l7eq6tlwdcq2>
Bridgy Fed、ブリッジ先のプラットフォームの字数制限まで文字数を切り捨てる処理で、分かち書きを前提にして最後の空白文字まで切り捨て(るようなライブラリを使用し)ているっぽくて、日本語の扱いが怪しい。
例えばこれとか:<https://atproto-browser.vercel.app/at/did:plc:lffon5yhpjy26636i2xjl6as/app.bsky.feed.post/3l7eq6tlwdcq2>
https://github.com/snarfed/granary/blob/3245c42f9159da78ef411cca160341eb904f3abd/granary/source.py#L916
https://github.com/kylewm/brevity/blob/445f55c0f4c91bb76e38ce59cf653dbc3b24bdf3/brevity.py#L25
しかしBridgy Fedの"original post"は`id`でなく`url`なのか。リンクアグリゲータ系の実装で`url`がオブジェクト自身のHTML表現でなくリンク先を指すような例があったりするから、上手く動かないことがあってもおかしくなさそうだな。
しかし`id`は`id`でコンテンツ交渉に応じてActivity StreamsでなくHTML表現を返してくれる保証もないしなあ。HTMLを返さない例としてThreadsがある
https://www.w3.org/TR/2017/REC-activitystreams-vocabulary-20170523/#dfn-url
まあ`url`プロパティの"Identifies one or more links to representations of the object"という定義に照らせばリンクアグリゲータ等の慣習の方がおかしいと言えそうだし、そこまで気にしなくても良さそう?
しかし`Link`型を定義するくらいなら`url`プロパティもはっきりとRFC 8288のlink relationを示すものとして定式化しておけば良かったのにと思わないでもない。JSON Activity Streams 2.0の前身であるAtomでも`<atom:link>`で`url`相当の機能を実現していたわけだし
この辺りの定義がはっきりしていたらリンクアグリゲータとかだってきちんと`"rel": "about"`などを使っていただろうに(ホンマか?)
`url`プロパティを使う慣習というのはMbin(というか/kbin)を指してのことだったけど、LemmyやPieFedでは`attachment`に`Link`を入れる方式っぽいな。というかMbinでも`url`に加えて`attachment`でもリンク先を参照している
Announcing AT Protocol Grants | Bluesky
https://docs.bsky.app/blog/atproto-grants
重要なのを忘れていた。グラントもあるのだった。資金力〜
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
https://www.w3.org/TR/2017/REC-activitystreams-core-20170523/#extensibility
> 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.
これなあ
AT Protocol、"big world with small world fallbacks"とか書いてあったからてっきり将来的にはメッセージパッシング的な仕組みの併用も想定しているのかと思っていたら、「Blueskyは既に分散しているよ!」と言い切られてびっくりしてひっくり返っちゃったよね(?)
このアカウントは、notestockで公開設定になっていません。
いやまあ、"modeled after the open web itself"と言ったときの"web"に普通Webmentionのような仕組みを含めるかと言われたら確かに微妙ではあるかも知れないけど、それを言ったらコメント欄を外部のサービスに頼るようなブログというのもなかなかないわけで……
私が「AT Protocolは素直でない」と評するとき、それは必ずしも素直でないことが劣っていることを含意するものとして述べているわけではないのだけど、AT Protocolのもたらす保障……というか何を保障し*ない*かについての人々の理解が曖昧そうなまま漠然と「分散型SNSプロトコル」として受け止められているあたりは普通に弊害が大きいと思っている
QT: https://fedibird.com/@tesaguri/113506622239236636 [参照]
Voiceover issues on web · Issue #6116 · bluesky-social/social-app
https://github.com/bluesky-social/social-app/issues/6116
https://atproto-browser.vercel.app/at/did:plc:wlv2lek2tmwsfpob3r4mix7y/app.bsky.feed.post/3la6ddlhopv2u
https://atproto-browser.vercel.app/at/did:plc:wlv2lek2tmwsfpob3r4mix7y/app.bsky.feed.post/3la6dgj3ujd2k
> All the buttons for quoting, replying, retweeting, liking are all divs. Not even a `role="button"` in sight.
これについては既に修正済みらしいとはいえ、なかなか衝撃的だな……
ざっと眺めてみたら、視覚上は表示されているリポスト・引用数が先祖要素の`aria-label`で上書きされて聞き取れなくなっていて、"No ARIA is better than Bad ARIA"(<https://www.w3.org/WAI/ARIA/apg/practices/read-me-first/>)を思い出すなどした。
いや、リプライやいいねなどの他のボタンはその辺り配慮されているっぽいので、リポストボタンが単に漏れただけかも知れないけど
って、改めて確認してみたらFedibirdも似たようなものだな……。もしかしたら最新のMastodonでは改善されていたりするのかも知れないけど