このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
そういえば今さらだけど、情報公開後はCI走らせ放題なのだから、やろうと思えばちゃちゃっと手直ししてテストすることも出来たか。今はもう上流にもマージされているのであれだけど
QT: https://fedibird.com/@tesaguri/112359219184301424 [参照]
けものフレンズ３｜おしらせ｜(5/1 18:00更新)「のとじま臨海公園水族館」様に対する支援金の寄付実施について｜アピリッツ
https://kemono-friends-3.jp/info/detail/010898JaZFaNb6.html
tesaguri/rsa-signature-2017-rs: [WIP] Rust implementation of `RsaSignature2017` cryptosuite of Linked Data Signatures spec
https://github.com/tesaguri/rsa-signature-2017-rs
はい（？）
PoCを試みているときに良い感じのLD Signaturesの署名用のツールがないものかとざっと探したところめぼしいものが見当たらなかったので、なら自分で書くかと思って書き始めて途中で正気に戻って一旦放棄したやつです（？）
まあ、Mastodonのドキュメント（<https://docs.joinmastodon.org/spec/security/#ld>）にも書かれているとおり、Linked Data Signaturesというドラフト段階の仕様は必要がないなら実装するべきでないですよね（今言うことか？）
古いドラフトの仕様が使われているという点についてはcavage-http-signaturesにも言えることだけど、Linked Data Signaturesは当時のドラフト（<https://github.com/w3c-ccg/ld-signatures/blob/d0af56856684924156a94838f9482a27766bb2be/index.html>）のSecurity Considerations節が空っぽだったという点において微妙さのレベルが一段違うと思う
ところで`RsaSignature2017`の定義（というかより仕様中でsignature suiteの例として示されていただけの定義だけど……）としては`"digestAlgorithm": "https://registry.ietf.org/ietf-digest-algorithms#SHA256" `としか指定されていたのに対してMastodonの実装ではCreate Verify Hash Algorithmにおける"the message digest algorithm"相当の処理で入力をSHA-256でハッシュしてから16進法表現にエンコードしている（<https://github.com/mastodon/mastodon/blob/1726085db5cd73dd30953da858f9887bcc90b958/app/lib/activitypub/linked_data_signature.rb#L55>）のだけど、この16進法表現の根拠がいまいち分かっていない
もしかしたら<https://registry.ietf.org/ietf-digest-algorithms#SHA256>に何か書いてあったのかも知れないけど、リンクが切れている（というかregistry.ietf.orgとかいう強そうな名前のドメインでも落ちるものなのか……）
FediverseがDDoSツールになるの、外部の最も修正すべきって意見はわかるけど理念的に最も修正困難な問題だし手のつけようがないのではって気持ちにもなる
連合先を信用するなら連合先がDocumentかPageオブジェクトをLinkの代わりにつけて取得を回避とかになるかもしれないけど信用するもんじゃないだろうしなぁ
このアカウントは、notestockで公開設定になっていません。
ブリッジ方式の弱点は、橋渡しを行っているブリッジが、ひとつだけしか存在しないことです。
よしんばブリッジを複数設けるとしても、今度は同じアカウントが複数の名称を持つことになり、重複してしまいます。
（ブリッジA、ブリッジB、ブリッジCがあると、noellabo.jp@A、noellabo.jp@B、noellabo.jp@C、というまったく同じ内容のアカウントが発生してしまうということです）
そして、そのブリッジを利用するActivityPub上のサーバ、AT Protocol（Bluesky）上のサーバが、ただ一つのサービスに依存することになります。
Bridgy Fedは、Ryan Barrettさんが作って、個人で運営しているサービスです。
Ryanさんは分散SNSに対する理解・理念・非営利で持続できる運営体制など、頼りにできる信頼に足る人物であろうと思いますが、
そうであっても、ひとつのサービスで発生したトラブルが全体に影響を及ぼす構造であることは避けられません（単一障害点）。
そういった問題を構造で解決しようというのが分散SNSの目指すところで、理想から遠ざかってしまうのです。
解決策はあるかもしれませんが、原状、そういうポジションにあるということは憶えておいてください。
https://fed.brid.gy/docs#other-bridges
snarfed氏は確かFEP-fffd Proxy Objectsに関心を持っていたよなと思ってドキュメントを見たら、ちゃんと言及されていた
Add proxy links to AP objects via FEP-fffd · Issue #543 · snarfed/bridgy-fed
https://github.com/snarfed/bridgy-fed/issues/543
@perillamint I think one of the most trickiest workarounds would be handling of objects referencing other objects, such as reblogs/shares and quotes.
Perhaps, the implementation could act as a bridge and generate bridged objects when such references are made, but copyright implication of that approach is unclear, and it would worsen the duplication problem further
`STANDARD`←何のstandard？
`general_purpose::STANDARD`←General purposeな何？
`engine::general_purpose::STANDARD`←何のengine？
`base64::engine::general_purpose::STANDARD`←長い！