読んだ和訳
* アカウントと削除

www.bluecast.app/user/@yamarten.bsky.soci...

今週のリンク(2/2) #ATプロトーク
* MLF(lexicon代替構文)のパッケージ機能案
* [関連]typelex: TyepeSpecベースの代替構文
* [関連]prototypey: TS埋め込みDSL型の代替構文
* [関連]laplan-kdl: KDLベースの代替構文
* attested.network: 支払い記録lexicon
* ATStore: Atmosphere/Blueskyアプリディレクトリ
* Pocketenv: サンドボックス定義
* close.community: 場所情報投稿

今週のリンク(1/2) #ATプロトーク
* サービスID仕様改訂案アップデート
* firehoseインデックス体験談
* ミートアップ資料等
* ハッカソン成果発表アーカイブ
* [関連]絵師ギャラリー
* [関連]青空マップ
* RecordPath: レコード内フィールド指定構文案
* panproto: スキーマ変換・バージョン管理ツール

Bluecast ATプロトーク: atproto情報紹介 by 山貂

🔴 LIVE: 🎙 #Bluecast で配信をはじめました！
"ATプロトーク: atproto情報紹介" #ATプロトーク (パブリック)
www.bluecast.app/user/@yamarten.bsky.soci...

ミュートは効果を及ぼす対象がミュート利用者の使ってるappviewだけでいいので、敢えて公開情報にする理由があるとしたら複数appviewを日常的に使っていても設定を同期させられる、とかかなあ。そっちを好む人がいてもおかしくないけど、(Bluesky一強でなかったとしても)多分少数派だよね。

ブロックの設計理念の話も時々掘り返した方がいいのかな。もう3年近く前の記事だもんね。 https://atproto.com/blog/block-implementation

この辺の難しさの話は前にもしてたね。

ソフトブロックを実装すべきとは全く思ってないけど。そもそもblockの実装も嫌い寄りだし。

所謂ブロ解が問題なのはそれを「ブロックしてから解除する」という儀式によって実現しようと考えている点であって、別途ソフトブロックとして実現する分には別にブロックと変わりないだろうと思っている。再フォローを許したいとかになると面倒だけど。

概念的にはそんな感じです。実際にはブロック情報は内部でインデックスしてるのでDB引いてます。 github.com/bluesky-social/atproto/b...

フォローの強制解除に対する説明としては正しいけど、ブロック中のフォロー/フォロワーカウントはappview内に閉じた話なのであんまり関係無いのでは。全実装に強制はできないとは言えるけど、それ言ったらブロック機能自体そうだし。

キャップといえば以前Blueskyの人が空色のを被ってた記憶があるけれども、リニューアルされたのかな。

僕自身としては貢献というより好き勝手やってるだけだし、和訳にしろATプロトークにしろお手伝いいただいてるところではあるので少し申し訳ない気はしつつも、貰えるもんは貰っとけの精神。

Blueskyグッズの写真。Blueskyロゴ入りキャップ、Atmosphere Conf. 2026のTシャツ、色々なステッカー

Blueskyの高野さん(@naoko.cc)から、グッズ色々頂きました。先日のミートアップで賞品にもなっていたBlueskyキャップと、ATmosphereConf土産のステッカーにTシャツ。
atproto.con和訳や #ATプロトーク 等での情報発信に対してとのことで、ありがたい話……。

Attention PDS devs! We merged a lexicon change last week increasing the max image upload for Bluesky posts from 1 MB to 2 MB. This rolled out to our PDSs instances last Friday.

We'll begin enabling this in the Bluesky app soon. If your PDS implementation is still validating at 1 MB, plz update! ✌️

PDSやrelayは無色透明なインフラであろうとしているけど、利用者はそこに意味付けをしたがるの、どうしてもチグハグな感じになってしまうよな。そうでもしないと運用者が増えないし、そうまでしてでも運用者を増やさないといけない、という意識があるからこそなのだろうけれども。

いち利用者としてはまだBluesky含むATmosphereに対してATmosphere情報収集以上の価値を見出せてないので、今年はそこからもう一歩進めることを期待している。

日本の開発者達が発信していこうみたいな話も今まさに議論されてたりするけど、あれも伝え方難しそうに思うし、まずどこに向けて何を発信していくかの意識統一が大変よね。

今動画も確認しましたが、Blueskyで活用されるか自体も明言しないくらい、はっきりぼかしてましたね。発表全体としてプロトコルへの意識誘導が多めで、オタク的には満足度高めでしたが、やっぱり伝え方はなかなか難しいですね。

なるほど、それなら納得です。関連機能の要望は多いでしょうし、動いてはいるから待っててね、くらいの気持ちなのかもしれませんね。

はい、そんな感じに見込んでます。以前からプロトコル側のロードマップで夏と言われてるのとも整合しますし。というのを踏まえると、製品機能として実装されるかのように聞こえる話をするのは(どっちのつもりだったにせよ)だいぶ前のめりだな、と思うわけですが……。 atproto.com/blog/2026-sp...

一応もう概観は明かされているので、プロトタイプ公開くらいはいけると思うんですよね。そこから仕様確定してアプリ機能展開までいけるのか、という感じ。 dholms.leaflet.pub/3mhj6bcqats2o

Youtubeに残ってるっぽいので帰宅したら一応確認かなあ。

実況をちょろっと見ただけなので実際にどう言われてたかは分からんけど、並んでる他のアイテムを見るとアプリケーション機能として実現すると言っているように見える。

permissioned dataが2026夏予定というのは既出だけど(それも若干不安だけど)、Blueskyのロードマップとしても2026夏に置いてるのマジ？いけるのか？

認証トークンに非互換な変更が入るらしい。proposalから方針転換してる点に注意。といっても影響受けるのは一部のフィード持ちくらいな気がするけど。 github.com/bluesky-soci...

まあ外から見りゃコミュニティも含めた全体が「Bluesky」なので、その辺はあんまり関係無い話だろうけど。

「Blueskyの手で分散化させるのは原理的に不可能」という話、本人の発表でもやってたわ。 atmosphereconf.org/event/rjQ96kl

そういや今日のATプロトークでmeetupの話を出すの忘れてたな。Blueskyでも最初の告知以降全く話題に上げてなかった気がする。明日のmeetupは音声配信もあるらしいですね。 www.bluecast.app/user/@event.bluecast.app...