新しいものを表示

YouTubeが中々しぶとくAtomフィードを提供し続けている(なんとPubSubHubbub/WebSubにも対応している)ので、Googleは一応まだ最大手のフィードのパブリッシャーの一つではあるのではとは思う

FeedBurner、フィードにXSLTを付けてそのままブラウザに表示させていた面白サイト(?)という印象がある

tesaguri 🦀🦝 さんがブースト

#Google がいかにして #RSS :rss: を無効化してきたかの歴史を振り返る記事。

:tony_sigh: Chrome から :rss: ボタンを削除
:tony_sigh: #FeedBurner を買収した後に閉鎖
:tony_sigh: #GoogleReader の閉鎖
:tony_sigh: #Google アラートから :rss: 昨日を削除
:tony_sigh: :rss: アドオンも削除
:tony_sigh: #GoogleNews からも :rss: を削除
:tony_neutral: 2021年に #Chrome:rss: 機能の復活に取り組んでると発表したがその後、正式リリースについては音沙汰なし

こうやって振り返ると、#Google はある時期からあらゆるプロダクトのユーザーから :rss: の存在を隠すというか消していってるんだよな…

openrss.org/blog/how-google-he

atproto-browser.vercel.app/at/
> Gift links or Gift Articles - paywall bypassing links to major publications.
こういうことをされるとパブリッシャーとしては困ったりしないのだろうか。
記事のギフト機能というのがどういう想定で運用されているのかよく知らないのであれだけど

この利用できない添付ファイルを開こうとするとリダイレクトする挙動、ローカルのWeb UIで開くつもりがリモートのURLを踏むことになりがちで個人的に困るのだよな。ランダムなサーバに不用意に接続したくないので……(過敏)

tesaguri 🦀🦝 さんがブースト

Mastodonの画像処理についてちょっと書いておきましょうか。

まず、Mastodonは、サーバのユーザーが投稿しようとしている画像、リモートからやってきた投稿などについてくるリモート画像を、添付ファイルの保存場所に保存します。

ファイルの取得がエラーになったり、ファイル種別と拡張子がウソだったり、サイズが大きすぎたり、未対応の形式だった場合、

投稿の場合はWebUIやクライアントにエラーを返し、

リモート画像の場合はURLだけ保存して、ファイル未取得の添付ファイルとしてデータベースに記録を保存します。

添付ファイルは通常、APIから取得した場合、様々なメタデータを取得できますが、未取得・エラーの場合はそれを提供できないので、ほとんどがデータなし、ファイル種別は不明になります。

リモートのURLだけは教えてくれるので、クライアントアプリの実装側で、これを直接参照して、うまくいけば画像表示することは可能です。

ただし、Mastodonが通常行う、不正なデータを拒否し、サイズを調整し、必要なら読める形式に画像変換するなど、安全に対する対策が効かなくなります。

そのために直接参照ではなく取得したデータを提供しているので、安直にリモートURLへフォールバックすることはお勧めしません。

5ドルのレンチで殴られて256ビットの鍵を吐かされるの嫌すぎる

スレッドを表示

昔は200ビット前後の鍵空間のランダムなパスワードを暗記で運用したりしていたので(?)、Curve25519の秘密鍵くらいなら何とか暗記でいけるか? 忘れた時のリスクが大きすぎるし、いずれにしても5ドルのレンチで殴られたらおしまいだけど

小型金庫なんてあったってどうせ5ドルのレンチで殴られたら全ておしまいなのにな(?)

スレッドを表示

まだセキュリティキーを持っていないのに、何故か鍵のバックアップを保管するための小型金庫だけは用意済みだったりする(?)

円が安くて買うタイミングを逃していたけど、どうせ他にちょうど良い機会もないだろうから、そろそろ買おうかなあ

tesaguri 🦀🦝 さんがブースト

🔥 Black Friday: 10% off everything, today only! 🛡️

🔒 Secure your data
🌍 Sustainable & Made in Germany
⚙️ Open Source transparency

⏰ 29.11.2024, 00:00–23:59 (CET)
🔗 Shop now: shop.nitrokey.com

#BlackFridayDeals #CyberSecurity #Nitrokey

というかBridgy Fedさん、削除されたと認識した投稿のログを公開のdashboardに正直に表示し続けないでいただけるとありがたいのですけど……

何故ここでバリデーションエラーみたいなものを吐いているのか……

スレッドを表示

$ curl --fail-with-body -s -H 'Accept: application/json' 'atproto.brid.gy/xrpc/com.atpro' | jq
{
"error": "InvalidRequest",
"message": "in com.atproto.repo.strongRef, string cid with value `''`: is invalid for format cid"
}

例えば、例えばの話だけど、特定の自治区の人々のアカウントが、いや、例えばの話なのですけど、集中的にtakedownされたとして、それでAppViewを移動したとしても出来上がるのは親パレスチナ派にしか投稿が届かないネットワークに他ならないであろうわけで、それはあまり嬉しくないよね、的な。モデレーションが厳しいMastodonサーバから移動するのとかとは訳が違う訳で

個人的にはタイムラインの構築もメッセージパッシングをデフォルトにでもしなければ、プラットフォームにオーディエンスを人質に取られることは避け得ないと思っているけど、まあこれは目的意識の違いと言われればそれまでである
QT: fedibird.com/@tesaguri/1135551
[参照]

tesaguri 🦀🦝  
"ActivityPub can't scale (笑)"の根拠として大きいのは恐らくフォロワー数に比例して増える配送負荷のことだろうと思っていて、それならリプライ等の1対1のやり取りはメッセージパッシング方式にしてくれても良いのではと思っている。 それさえ出来ればタイムラインの構築等の他の機...

> Resilient small-world bsky AppViews could work by periodically polling specific accounts from their PDS and indexing relevant posts.
というかこれ本当にやって良い想定なのですか? `com.atproto.sync.subscribeRepos`の個別リポジトリのみを購読するバージョンを用意しないなら私は本当にレートリミットの許す限りの頻度でポーリングするつもりだぞ、おおん?(?)

スレッドを表示

"ActivityPub can't scale (笑)"の根拠として大きいのは恐らくフォロワー数に比例して増える配送負荷のことだろうと思っていて、それならリプライ等の1対1のやり取りはメッセージパッシング方式にしてくれても良いのではと思っている。
それさえ出来ればタイムラインの構築等の他の機能も含めてネットワークの集約によらずどうにかする余地が生まれるだろうし

古いものを表示
Fedibird

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