← 2026-03-09 の一覧へ戻るホーム
**ブラックスカイ・AppView**

2026/03/09 6:40

**ブラックスカイ・AppView**

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

Blacksky の AppView は Bluesky Social PBC の AT Protocol 参考実装をフォークしたもので、外部からの貢献やプルリクエストは受け付けません。すべての変更は 

packages/bsky
、
services/bsky
の3つのディレクトリと1つのマイグレーションファイルに限定され、参考コードの大部分を保持しています。

リポジトリは組み込みの TypeScript フィーホーズコンシューマーを Rust ベースのインデクサ rsky‑wintermute に置き換えており、並列キューを通じて約10 k+ レコード/秒を取り込むことができます。Wintermute はブートストラップツール（

queue_backfill
、
direct_index
、
label_sync
など）を提供し、ライブインデクシングとバックフィルを分離します。

主なパフォーマンス最適化は次の通りです：

  • PostgreSQL の LATERAL JOIN 再書き込み（
    getTimeline
    / 
    getListFeed
    用）
  • Redis キャッシュレイヤー（アクタープロファイル TTL 60 s、レコード TTL 5 m、相互作用カウント TTL 30 s、投稿メタデータ TTL 5 m）
  • 通知設定のサーバー側強制

実装された修正：

  • JWT 検証における古い署名鍵の処理
  • JSON のサニタイゼーションで null バイト／制御文字を除去
  • アクターメモリキャッシュ内の protobuf タイムスタンプバグへの対策

Blacksky は コミュニティ投稿サポート をカスタムレキシコン namespace（

community.blacksky.feed.*
）と専用 
community_post
テーブル、データプレーン/API 層でのメンバーシップゲーティングを通じて追加しています。これは混在した投稿スレッド（
getPostThreadV2
）とも統合されます。

全体アーキテクチャフロー： Bluesky Relay → rsky‑wintermute（フィーホーズコンシューマ/バックファラー/ラベルインデクサ） → PostgreSQL 17 → bsky‑dataplane（gRPC） → オプションの Redis キャッシュ → bsky‑appview（HTTP） → リバースプロキシ、Palomar が OpenSearch 検索機能を提供

バックフィル性能： ライブインデクシングは約1 k イベント/秒。42 M ユーザーと 18.5 B レコードのフルバックフィルは10 k レコード/秒で 2–4 週間、部分的なバックフィルは数時間〜数日で完了

ブートストラップ課題への対策：

  • PostgreSQL COPY による JSON 腐敗
  • null バイト処理
  • タイムスタンプ精度の強制
  • 通知テーブルの肥大化緩和
  • 投稿埋め込みテーブルの人口化
  • ラベル否定順序
  • Fjall キュー毒性解決
  • TLS プロバイダ初期化
  • アカウント移行後の署名鍵回転

フルネットワーク AppView のリソース要件： ≥ 16 CPU コア（推奨 48+）、≥ 64 GB RAM（256 GB 推奨）、10 TB NVMe ストレージ（28 TB RAID 推奨）、同一マシンまたは低遅延での PostgreSQL、継続的ネットワーク 100 Mbps（1 Gbps+）以上の取り込み帯域

リポジトリは MIT/Apache 2.0 のデュアルライセンスです。アップストリーム同期手順は 

git remote add upstream https://github.com/bluesky-social/atproto.git
で提供されています。

本文

Blacksky の AT Protocol 参照実装のフォーク

このリポジトリは 

api.blacksky.community
にある AppView を動かすために使用されています。
透明性を確保する目的で公開していますが、貢献・Issue・PR は受け付けていません。
正規の AT‑Protocol 実装については 
bluesky-social/atproto
を参照してください。

何が違うのでしょうか？

変更点は以下のディレクトリに集中しています。

  • packages/bsky – AppView のロジック
  • services/bsky – ランタイム設定
  • 1 つのカスタムマイグレーション
    (
    20260202T120000000Z-add-community-post.ts
    )

それ以外は upstream と同じです。

なぜ組み込み Firehose コンシューマを使わないのでしょうか？

オリジナルのデータプレーンには、イベントを順次インデックスする TypeScript の Firehose コンシューマがあります。
ネットワーク規模（約 1 k イベント/秒、総記録数 18.5 B）では、90 レコード/秒でバックフィルすると 6½ 年 かかります。

そこで rsky‑wintermute（Rust のインデクサ）に置き換えました。主な理由は次の通りです。

ReasonDetail
スケール時のパフォーマンスTypeScript コンシューマはイベントを順次処理しますが、Wintermute は並列キュー処理で 10 k レコード/秒以上を目指します。
バックフィル構成ライブインデックスとバックフィルは独立したキュー (
firehose_live
, 
firehose_backfill
, 
repo_backfill
, 
labels
) を走らせます。ライブイベントはバックフィルの作業でブロックされません。
運用ツールWintermute は次のようなユーティリティを備えています。
特定アカウントのインデックス、PLC ディレクトリの一括インポート、ラベルストリーム再生、Blob 参照修復、キュー管理 – AppView をゼロから起動する際に必要です。

データプレーンと AppView はそのまま動作し、Wintermute が書き込む PostgreSQL データベースを読み取ります。
組み込みの Firehose サブスクリプションは起動しません。

パフォーマンス & 運用上の改善点

以下は自己ホスト型 AppView を大規模に運用する際に役立つ機能です。

FeatureLocation
LATERAL JOIN クエリ最適化（フィードルート）
packages/bsky/src/data-plane/server/routes/feeds.ts
– ユーザーごとのインデックス使用を強制し、フルテーブルスキャンを回避。
Redis キャッシュ層
packages/bsky/src/data-plane/server/cache/
– アクタープロフィール（60 s TTL）、レコード（5 m）、相互作用数（30 s）、投稿メタデータ（5 m）をキャッシュ。プロダクショントラフィック下で DB 負荷を削減。
既知の問題: アクターキャッシュに protobuf タイムスタンプバグがあるため、現在は Redis キャッシュを無効化して運用しています。修正案としては書き込み時に ISO 文字列でシリアライズし、読み取り時に再構築する方法です。
通知設定のサーバー側強制
packages/bsky/src/api/app/bsky/notification/listNotifications.ts
– クライアントが理由を省略した場合でも、ユーザー保存済みの通知設定を適用。
Auth verifier の古い署名鍵修正
packages/bsky/src/auth-verifier.ts
– JWT 検証再試行 (
forceRefresh
) 時にデータプレーンのメモリ内アイデンティティキャッシュをバイパスし、PLC ディレクトリから DID ドキュメントを直接解決。アカウント移行後の認証失敗を修正。
JSON サニタイズ
packages/bsky/src/data-plane/server/routes/records.ts
– JSON パース前に null バイト (
\u0000
) と制御文字を除去。RFC 8259 では許容されるが Node.js の 
JSON.parse()
が拒否するため、パース失敗で投稿が欠落してしまう問題を解決。

Blacksky 固有のコミュニティ投稿

AppView 上に存在し、個別 PDS には存在しないプライベートコミュニティ投稿用インフラです。

  • community.blacksky.feed.*
    というカスタムレキシコン namespace を定義。
    提出・取得・削除・タイムライン・スレッド表示のエンドポイントを提供。
  • 独立した 
    community_post
    テーブル（
    20260202T120000000Z-add-community-post.ts
    マイグレーション）を使用。
  • データプレーンと API 層でメンバーシップゲーティングを実装。
  • getPostThreadV2
    と統合し、標準投稿とコミュニティ投稿の混在スレッドをサポート。
  • 別途 membership DB（
    BLACKSKY_MEMBERSHIP_DB_URL
    ）が必要。

アーキテクチャ

Bluesky Relay (bsky.network)
     |
     v
rsky-wintermute ─────► PostgreSQL 17 ◄──── Palomar
   (Rust indexer)          |                (Go search)
   - firehose consumer     |                     |
   - backfiller            |                     v
   - label indexer         |               OpenSearch
   - direct indexer        |
                           v
                   bsky-dataplane (gRPC :2585) ◄── Redis (optional)
                           |
                           v
                   bsky-appview (HTTP :2584)
                           |
                           v
                   Reverse proxy (Caddy/nginx)

コンポーネント概要

Componentソース目的
rsky‑wintermute
blacksky-algorithms/rsky
Rust の Firehose インデクサ。イベントを消費し、バックフィル、レコードを PostgreSQL に書き込み。
rsky‑relay
blacksky-algorithms/rsky
ラベラーサービスからのモデレーションラベル受信用 AT Protocol Relay。
rsky‑video
blacksky-algorithms/rsky
動画アップロードサービス。Bunny Stream CDN でトランスコードし、Blob をユーザー PDS にアップロード。
bsky-dataplane本リポジトリ (
services/bsky
)		PostgreSQL 上の gRPC データレイヤー。
bsky-appview本リポジトリ (
services/bsky
)		HTTP API サーバー（xrpc エンドポイント）。
Palomar
blacksky-algorithms/indigo
OpenSearch へのフルテキスト検索。プロファイルと投稿をインデックスし、フォロワーカウントでブースト。
palomar-sync
blacksky-algorithms/rsky
PostgreSQL のフォロワー数・PageRank を OpenSearch に同期。

rsky‑wintermute 詳細

Wintermute は 4 つの並列処理パスを持つモノリシックな Rust サービスです。

  1. Ingester – bsky.network Firehose の WebSocket 接続からイベントを取得し、Fjall（埋め込みキーバリューストア）のキューへ書き込み。
  2. Indexer – キューから読み取り、レコードをパースして PostgreSQL に書き込む (
    ON CONFLICT
    で冪等性)。
  3. Backfiller – PDS から全リポジトリ CAR ファイルを取得し、バックフィルキューへ展開。
  4. Label indexer – ラベラーの WebSocket ストリームに購読し、ラベル作成/否定イベントを処理。

CLI ツール一覧：

Tool目的
queue_backfill
CSV、PDS 発見、または DID リストからバックフィル対象の DIDs をキューへ投入。
direct_index
キューを経由せずに特定リポジトリを直接取得・インデックス（個別アカウント修復時に便利）。
label_sync
ラベルストリームを 0 から再生し、欠落した否定イベントを追跡。
plc_import
PLC ディレクトリからハンドル/DID マッピングを一括インポート。
palomar-sync
フォロワー数と PageRank を OpenSearch に同期。

rsky‑video

bluesky.video.bsky.app
をサポートしない PDS へ動画をアップロードするためのサービスです。自前 DID (
did:web:video.blacksky.community
) でサービス認証 JWT を使って認証します。

フロー：

  1. クライアントは PDS（audience: 動画サービス DID）からサービス認証トークン取得。
  2. クライアントが rsky‑video に動画バイト列をアップロード。
  3. rsky‑video が CID を生成し、Blob をユーザー PDS にアップロード。
  4. Bunny Stream CDN へ転送してトランスコード。
  5. 完了後、クライアントは Blob を参照する投稿を作成（PDS が存在確認）。 |

ラベル処理

モデレーションラベルはラベラーサービス（例：Bluesky の Ozone）から WebSocket で受信。Wintermute の label_live キューに専用処理を行います。

label_sync
ツールで全ストリームを再生し、欠落した否定イベント（ラベル削除）を追跡します。

セットアップ

必要条件

  • Node.js 18+ と pnpm（データプレーンと AppView のビルド）
  • PostgreSQL 17 (
    bsky
    スキーマ)
  • Redis（任意、キャッシュ用 – 現在は無効化推奨）
  • rsky‑wintermute が Firehose を消費し DB に書き込む
  • OpenSearch（Palomar 検索を利用する場合）

データベース

bsky
スキーマはデータプレーンのマイグレーションで作成されます。最初に実行すると自動的に全マイグレーションが適用されます。Blacksky 固有のマイグレーションは
20260202T120000000Z-add-community-post.ts
です。コミュニティ投稿が不要なら削除してください。

rsky‑wintermute は同じスキーマへ書き込み、全 INSERT が 

ON CONFLICT
を使用するため、マイグレーションと Wintermute の起動順序は問われません。

ビルド & 実行

データプレーン

node services/bsky/dataplane.js
Variable必須説明
DB_PRIMARY_URL
はいPostgreSQL 接続文字列 (
?options=-csearch_path%3Dbsky
)
DB_REPLICA_URL
いいえリードレプリカ接続文字列
BSKY_DATAPLANE_PORT
いいえgRPC ポート（デフォルト 2585）
BSKY_REDIS_HOST
いいえRedis ホスト:ポート（キャッシュ用、無効化推奨）
BLACKSKY_MEMBERSHIP_DB_URL
いいえコミュニティメンバーシップ専用 DB（Blacksky 固有）

AppView

node services/bsky/api.js
Variable必須説明
BSKY_APPVIEW_PORT
いいえHTTP ポート（デフォルト 2584）
BSKY_DATAPLANE_URLS
はいコンマ区切りの gRPC URL
BSKY_DID
はいAppView の DID（例：
did:web:api.example.com
）
BSKY_MOD_SERVICE_DID
はいOzone モデレーションサービス DID
BSKY_ADMIN_PASSWORDS
はい基本認証用のパスワードをコンマ区切りで指定

大規模運用

バックフィルタイムライン

全ネットワークバックフィル（約 42 M ユーザー、18.5 B レコード）は、Wintermute の並列処理でも数週間かかります。

フェーズ内容
ライブインデックスデイ・ワンからリアルタイムで約 1 k イベント/秒を追跡。
全バックフィル10 k レコード/秒で 2–4 週間（PDS 応答性・ネットワークに依存）。
部分バックフィルコミュニティメンバーのみなど、数時間〜数日。

バックフィル中でも AppView は機能しますが、未バックフィルユーザーのデータは不完全です。ライブイベントはバックフィル進捗に関係なく即時インデックスされます。

解決した課題

IssueFix
COPY テキスト形式 JSON 破損 – PostgreSQL が 
\"
を 
"
と解釈。約 66 k レコードを公的 API から再取得して修復。
JSON 中の null バイト – Node.js が拒否。書き込み前に除去。
タイムスタンプ形式の感度 – PostgreSQL はミリ秒精度 + 
Z
を期待。ナノ秒やオフセットはソートに影響。
通知テーブル膨張 – 
(did, recordUri, reason)
に一意制約が無いと 10 億行以上（663 GB）へ拡大。インデックス作成後 
ON CONFLICT DO NOTHING
を追加。
投稿埋め込みテーブル欠落 – インデクサが処理しない場合、
getAuthorFeed
のメディアフィルタで何も返さず。別途バックフィル必要。
ラベル否定順序 – バックフィル中に否定が先に来るケースを 
label_sync
で再生して追跡。
Fjall キューの汚染 – クラッシュ後に DB が「汚染」状態になることがある。キューディレクトリ削除して再起動すると、リレーのカーソル（約 72 h の履歴）から追跡開始。
TLS プロバイダー初期化 – Rust 
rustls
は明示的に crypto provider をインストール (
rustls::crypto::aws_lc_rs::default_provider().install_default()
) 必要。未設定だと最初の WebSocket 接続でパニック。
署名鍵ローテーション後の認証失敗 – データプレーンは 1 h の staleTTL で identity をキャッシュ。移行期間中に JWT 検証が失敗。検証再試行時にキャッシュをバイパスし PLC ディレクトリから直接解決。

リソース要件（全ネットワーク AppView）

Resource最小推奨
CPU16 コア48+ コア
RAM64 GB256 GB
ストレージ10 TB NVMe28+ TB NVMe（RAID）
PostgreSQL専用、同一マシンか低レイテンシ同一推奨
ネットワーク持続 100 Mbps1 Gbps+

ストレージ内訳（概算）

テーブル群サイズ
投稿 + レコード~3.5 TB
ライク~2 TB
フォロー~500 GB
通知~600 GB
インデックス~4 TB
OpenSearch (Palomar)~500 GB

小規模コミュニティで部分 AppView を運用する場合は、インデックス数に比例してリソースがスケールします。

upstream との同期

git remote add upstream https://github.com/bluesky-social/atproto.git
git fetch upstream
git merge upstream/main

衝突は主に 

packages/bsky/src/data-plane/server/routes/
と 
packages/bsky/src/api/
内で発生します。自社の追加分と upstream の変更を併せて保持してください。

ライセンス

upstream と同様、MIT と Apache 2.0 がデュアルライセンスです。詳細は 

LICENSE-MIT.txt
と 
LICENSE-APACHE.txt
をご覧ください。

同じ日のほかのニュース

一覧に戻る →

2026/03/09 5:30

エージェント・セーフハウス – macOS ネイティブサンドボックスによるローカルエージェントの保護 --- **ポイント解説** - **Agent Safehouse** は、macOS 上で動作するローカルエージェント（バックグラウンドプロセスやサービス）を安全に隔離し、外部からの不正アクセスや権限昇格を防ぐための仕組みです。 - 「macOS‑native sandboxing」は、Apple が提供するサンドボックス機能（`sandbox-exec`, `com.apple.security.*` など）を利用しており、追加のソフトウェアやカーネル拡張は不要です。 **主な特徴** 1. **最小権限で実行** – 必要最低限のファイル・ネットワークアクセスのみ許可し、それ以外は自動的にブロック。 2. **監査ログ** – アクセス試行や失敗がすべて記録され、後からトラブルシューティングやセキュリティ調査に利用可能。 3. **設定の柔軟性** – プロファイルベースでポリシーを定義でき、企業規模に合わせた細かな制御が可能。 **実装例（サンドボックスプロファイル）** ```xml <key>com.apple.security.app-sandbox</key> <true/> <key>com.apple.security.files.user-selected.read-write</key> <true/> ``` このように、エージェント・セーフハウスは macOS の標準機能だけで安全性を大幅に向上させるソリューションです。

## Japanese Translation: > Safehouse は、ローカル AI エージェントがアクセスできるファイルを厳密に制御する軽量な macOS ネイティブサンドボックスです。デフォルトでは「deny‑first」ポリシーに従い、指定されたワークスペース外への読み書き試行はカーネルエラー（“Operation not permitted”）を引き起こし、SSH キーや `.aws` などの機密項目やその他個人リポジトリを保護します。ツールは `curl` を使って `~/.local/bin` にインストールされる単一の Bash スクリプト（`safehouse.sh`）でセットアップされます。 > > エージェントは `safehouse claude --dangerously-skip-permissions` のようなコマンドで呼び出され、現在の作業ディレクトリ（通常は git リポジトリルート）への読み書きアクセスを自動的に許可し、インストール済みツールチェーンへの読み取りアクセスのみを許可して残りのホームディレクトリは拒否します。 > > 上級ユーザーは `safe() { safehouse --add-dirs-ro=~/mywork "$@"; }` のようなシェル関数を `.zshrc` や `.bashrc` に追加し、すべてのエージェント呼び出しがデフォルトで Safehouse 内で実行されるようにできます。セッションごとにサンドボックスをバイパスするには、コマンドに文字列 `command` を接頭辞として付けます（例：`command claude`）。 > > このゼロコンフィグ方式により、開発者やチームはローカルファイルとの AI 連携を安全に行い、個人プロジェクト、クラウド認証情報、企業リポジトリでの偶発的なデータ漏洩を減らすことができます。

2026/03/09 4:58

「エージェント時代にリテラトープログラミングを見直すべきです。」

## Japanese Translation: > 本稿は、コードと説明文を組み合わせたリテラトープログラミングが、AI エージェント（例：Claude や Kimi）が Org‑Mode ファイルを単一の真実源として扱う場合に実用化できることを主張しています。 > > Org の構文を解析することで、これらのエージェントはランブックを生成し、埋め込みコードブロックを実行し、Jupyter ノートブックのように結果を保存し、プローズとコードを同期して自動的に更新できるため、ナラティブと実行可能なスクリプトを分離する手作業「タンギング」ステップが排除されます。 > > 著者は、Org Mode を設定管理に個人的に使用した例でこれを示しています：エディタ内で直接コマンドを書き込み、それらを実行し、メモを自動的に取得します。 > > コードとプローズの2つの並列文書を維持することは採用への一般的な障壁ですが、AI 主導のワークフローは `AGENTS.md` ファイルに記載された指示（実行前のタンギング、常にステップを説明するプローズ、両側を同期させる）に従うことでそのオーバーヘッドを排除します。 > > このアプローチはワークフローを合理化し、コードベースを複数の読みやすいフォーマットへエクスポートしやすくし、「コードを書く」から「コードを読む」へのシフトを促進します。また、大規模プロジェクトにおける Org‑Mode の Emacs 統合の限界を浮き彫りにし、リテラトープログラミングの普及を広げるために Markdown などの類似フォーマットを推奨することも示唆しています。

2026/03/05 21:24

**テスト対象のボードコンピュータ（2025）** - Raspberry Pi 4 Model B - NVIDIA Jetson Nano - BeagleBone Black - ASUS Tinker Edge - Odroid‑C2 - OrangePi R1 - Pine64 RockPro64 - Banana Pi M5 - UP²（UP Squared） - Udoo X86 *(各モデルは性能、電力消費、および周辺機器の互換性を評価しました。)*

## 日本語訳 --- ## 要約 2025年にシングルボードコンピュータ（SBC）の市場は、**8社から15社へ拡大**し、価格帯は **$42–$590** で、Rockchip、Broadcom、Qualcomm、MediaTek、Allwinner、StarFive、CIX、および Texas Instruments のSoC が採用されています。 ### 価格とセグメンテーション - **予算 (< $50):** BeagleBone Green Eco ($42)、StarFive VisionFive 2 Lite ($43)、Arduino UNO Q ($44)、Orange Pi RV ($46–$50)、Radxa Cubie A7A ($45)。 - **ミッドレンジ ($50–$100):** Radxa ROCK 4D ($60)、Radxa Dragon Q6A ($70、Qualcomm QCS6490 シングルコアで Raspberry Pi 5 レベル)、ArmSoM CM5 ($95)、Banana Pi R4 ($99)。 - **ハイエンド (>$100):** Raspberry Pi 500+ ($200)、ArmSoM AIM7 ($239)、Radxa Orion O6N ($199)、Orange Pi 6 Plus ($260)、Radxa Fogwise Airbox Q900 ($590)。 ### パフォーマンスのハイライト - **CIX P1** は Radxa Orion O6N と Orange Pi 6 Plus を動かし、32 GB LPDDR5 で約7,000 のマルチコア Geekbench スコアを実現。 - **Qualcomm QCS6490** が搭載された Radxa Dragon Q6A は、$70 で Raspberry Pi 5 と同等のシングルコア性能を提供。 - **RISC‑V ボード**（VisionFive 2 Lite、Orange Pi RV/RV2）は、シングルコア Geekbench スコアが 59–118、マルチコアは 180–528 と ARM 対応機種に比べて遅れをとる。 ### 市場ドライバー - LPDDR4/5 の価格は 2025 年後半に高利益率 AI メモリ需要の増加で上昇し、ボード全体のコストに影響。 - 市場は SoC 選択肢が拡大しており、CIX P1 が際立ったシリコンオプションとして浮上、Qualcomm は初めて重要な SBC 参入を果たし、RISC‑V の採用はパフォーマンスギャップにもかかわらず継続的に拡大。 ### インプリケーション 消費者は予算別により多くのハードウェアオプションを持ち、ホビイスト、教育関係者、および商業開発者が恩恵を受ける。メーカーはメモリコスト上昇と性能ニーズのバランスを取りつつ、エコシステムは AI 中心型アプリケーションへ拡大していく必要がある。 ---

**ブラックスカイ・AppView** | そっか～ニュース