ATProto Spaces：非公開データを可能にする ATProto の新しい拡張機能 #八23

Blueskyに鍵垢が来た。atprotoチームは新機能「Spaces（スペース）」のアルファ版を公開し、開発用の動作コード、SDK、サンプルアプリ、ホストされたPDSアカウントを提供しているため、今すぐ試用と開発が可能だと発表した。

Spacesはこれまでのatprotoの公開データ設計に対し、非公開（＝アクセス制御された）データを扱える新しいプロトコルプリミティブであり、可搬な識別（DID）、JSONレコードとLexiconによるデータ定義、アプリのリポジトリ同期といったatprotoの利点を保ちながら、特定のユーザーやアプリだけがデータにアクセスできるようにする仕組みを提供する。

スペース自体は軽量で、単一レコードから10億レコード規模まで拡張可能であり、各スペースのアクセスを管理する「スペース権限者」は通常のDIDで表現され、許可されたDIDに対してスペース内のレコードを参照させる。スペース内のレコードは著者のPDS内のスペース専用の権限付きリポジトリに格納されるため、中央サーバーは存在せずデータは各ユーザーのPDSに保持される点はこれまでの設計と一貫している。 

ただしスペースの目的は「機密化」ではなく「アクセス制御」であり、スペース内データは許可を得た利用者やアプリには平文で読める形式で保存されるため暗号化による自動的な秘匿を前提としない。公開atprotoとの主な違いは、あるPDSが別のPDSからスペース内のレコードを要求する際に、スペース管理者が署名したトークンで読み取り許可を示す必要がある点で、この署名付きトークンがアクセスを仲介する仕組みとなる。したがって、PDS自体が「中央サーバー」ではなく、各ユーザーが自分のPDSにデータを保持しつつ、スペースのアクセス許可に従って他者がそのデータを要求・取得するという分散的モデルが維持される。 用途としては、設定情報や非公開ブックマーク、会員制フォーラム、購読限定コンテンツ、プライベート投稿や一部限定の視聴権を要するメディア配信など、公開ネットワークでは扱いにくかった機能群を実現できる。スペースは典型的な「プライベート」だけでなく、「保護された」アクセス（例：Patreonの会員特典やペイウォール、特定相手のみ閲覧可能な投稿）に適している。運用面ではまだアルファ段階のため互換性の破壊的変更があり得るので本番運用は推奨されず、開発とテストに限定して利用すべきである。 

コミュニティの反応としては期待と興奮が強く、プライベートアカウントや限定公開のニーズに対する肯定的な声が多い。実際にいくつかのサービスやクライアント（例：Kimbia）がスペース対応を実装し始めており、設定画面からPDSがスペースをサポートしているか確認して有効化することで、新しい活動がデフォルトでスペースに記録されるなどのユーザー側の利用フローが整いつつある。 技術的議論では、スペース導入がIDSA（International Data Spaces Association）など既存のデータ空間概念や既存オントロジー（schema.org 等）の再利用議論とどのように整合するか、語彙やスキーマの混乱をどう抑えて互換性を高めるかといった懸念や期待が示されている。また、署名付きマークルツリー等の暗号的処理により、ドメインから公開鍵のIDを復元してデータ移行や識別の持続性を保つことは技術的に難易度が高く、既存の課題として残るが基礎的な設計作業は進んでいるとの指摘がある。 スペースは単なる中央サーバーの追加ではなく、PDS上に保存された分散データモデルを維持しながらアクセス許可を付与する、新たなアプリケーションレイヤのプロトコルとして位置づけられている。つまりHTTPのような基礎的トランスポートとは別に、状態表現を前提としたアプリ層プロトコルを定義して実装間で確実に転送できるようにする点で、ActivityPubに類似する要素を持ちつつatprotoの設計哲学を踏襲している。従って、スペースはベンダーロックイン対策や分散的エコシステム維持という課題に対処しつつ、これまで公開前提だったatprotoに保護付きデータを導入するための基盤を提供する。 最後に、開発者への注意点としては現状アルファであり破壊的な変更があり得るため、本番運用は避けて実験的に実装・評価すべきこと、そしてスペースは暗号化による自動的機密化を目的としないため必要に応じて追加の暗号化策や運用ポリシーを設計する必要がある点が強調されている。

ATProto Spacesの本質

ATProto Spacesは、従来「すべて公開」が原則だったAT Protocolに、**「非公開データを扱うためのアクセス制御レイヤー」**を追加するものです。公式には「permissioned data → buckets → spaces」と名称が変遷し、現在は「小さなATProtoネットワーク」と説明されています。

重要なのは、

Private data ≠ Confidential data

という点です。

Spacesは暗号化ではありません。Space Authorityが「どのDIDにアクセスを許可するか」を決定し、許可されたユーザー／アプリケーションがPDSからデータを読める仕組みです。

したがって、

概念Spaces
公開性非公開にできる
アクセス制御○
認可○
暗号化×
機密性保証しない
DIDベースの主体管理○
データのPDS保存○
Relayによる全世界への再配信Spaceでは基本的に×
リアルタイム同期○
ポータビリティATProtoの設計思想を維持

という位置づけになります。

「PDSは中央サーバーなのか？」という議論

ここはHacker Newsのコメントで混乱しやすいところです。

PDSは中央サーバーではありません。

通常のATProtoと同様、ユーザーのデータはPDS上のRepositoryに保存されます。Spaceではさらに、Spaceごとのpermissioned repositoryが作者のPDS上に存在します。

つまり、

                    ATProto
                       │
        ┌──────────────┴──────────────┐
        │                             │
    Public Data                  Space Data
        │                             │
      Relay                     Space Authority
        │                             │
   全世界へ配信                 Access Control
                                      │
                              ┌───────┴───────┐
                              │               │
                             DID A           DID B
                              │               │
                             PDS             PDS

という違いです。

Public ATProtoでは、

PDS → Relay → AppView

という「公開ブロードキャスト型」が重要でした。

Spacesでは、

PDS → 許可されたApplication

という直接同期モデルになります。公式説明でも、SpaceにはRelayという概念がなく、アプリケーションがPDSホストから直接同期するとされています。

「サーバー」より「データ空間」と考えるほうが近い

Hacker Newsの、

「これは単なるサーバーなのか？」

という疑問に対しては、**「サーバーというより、アクセス制御されたデータ空間」**と理解するほうが正確です。

Spaceは、

Identity + Repository + Lexicon + Sync + Authorization

を組み合わせた、mini-ATProto networkです。

しかもSpace自体は非常に軽量で、1レコード程度の小さなSpaceから10億レコード規模まで想定されています。

この設計が重要です。

例えば

個人Space

User
 └── Space
      ├── drafts
      ├── bookmarks
      ├── settings
      └── private notes

購読型Space

Publisher
 └── Space
      ├── subscriber A
      ├── subscriber B
      └── subscriber C

コミュニティSpace

Community
 └── Space
      ├── member 1
      ├── member 2
      ├── member 3
      └── ... millions

という3段階を同じプロトコルプリミティブで扱えるわけです。公式も、設定・下書き・ブックマークのような1人用から、サブスクリプション出版、数百万人規模のコミュニティまでを用途として挙げています。

ここで「ATProtoはRSSの再発明なのか」という議論が面白い

貼られたコメントには、

ATProtoは「昔のWeb」に近い

という見方があります。

これは半分正しいです。

確かに思想としては、

自分のデータ
    ↓
自分が管理する場所
    ↓
プロトコルで公開
    ↓
第三者が取得
    ↓
好きなUI/AppViewで表示

という、従来Web・RSS・ブログに近い構造を持っています。

しかしATProtoが単純なRSSと違うのは、identity / repository / cryptographic history / synchronization / schema / authorizationまでプロトコル層に含めていることです。

公式仕様にもData Model、Repository、Cryptography、DID、Handle、AT URI、XRPC、OAuth、Permissions、Event Stream、Syncなどが独立した仕様として存在します。

したがって、

RSS = コンテンツ配信

に対して、

ATProto = 分散identity + データモデル + データ所有 + 同期 + アプリケーションプロトコル

と見るほうが適切です。

「IDSA」「RDF」「schema.org」の指摘は別の論点

Hacker Newsコメントの、

International Data Spaces（IDSA）をなぜ議論しないのか

という指摘は、Spacesそのものの仕様説明というより、「データスペース」という語彙が既存のData Spaces研究と重なっているという問題提起です。

ここは重要ですが、今回の公式資料からは、

ATProto SpacesがIDSAを直接継承した／IDSAを設計上参照した

とは確認できません。

したがって、

「ATProto SpacesはIDSAの実装である」

と解釈するのは、この資料だけでは行き過ぎです。

むしろ面白いのは、同じ「Space」という言葉が、

  • Data Space

  • Permissioned Data

  • Social Space

  • Community Space

  • Subscription Space

など複数の意味で使われ始めていることです。

これは将来的に語彙の衝突・概念の再整理を引き起こす可能性があります。

Tangledとの関係がかなり面白い

貼られたコメントにある、

tangled.shにはプライベートリポジトリがもうすぐ

という話も重要です。

TangledのようなGit系サービスとATProto Spacesを組み合わせると、

ATProto Identity
       │
       ▼
   Space Authority
       │
       ▼
Permissioned Repository
       │
       ├── Git repositories
       ├── Issues
       ├── Discussions
       ├── CI metadata
       └── Project collaboration

という構造が可能になります。

つまりSpacesは、単に**「Blueskyに鍵アカウントを追加する機能」**ではありません。

むしろ、

ATProtoを「公開SNSプロトコル」から「アクセス制御可能な汎用データ・プロトコル」へ拡張する

ことのほうが本質です。

そして最大のポイントは「private account」ではない

現在の反応では、

private accountsが来る！

という受け止め方がかなり多いですが、これはUIレベルの理解です。

プロトコルレベルではもっと大きい。

                ATProto
                   │
        ┌──────────┴──────────┐
        │                     │
     Public                 Spaces
        │                     │
     Public                  ACL
     Relay                    │
        │               ┌─────┴─────┐
        │               │           │
     Social           Private    Shared
     Network           Data      Context
                          │           │
                       Drafts      Community
                       Settings    Subscription
                       Bookmarks   Collaboration

つまりPublic Social GraphだけだったATProtoに、Permissioned Social/Data Graphが加わる。

これが一番大きな変化です。

ただし「完全なプライバシー基盤」ではない

ここは非常に重要です。

Spaceは暗号化されていません。公式自身が、

access control, not confidentiality

と明示しています。

したがって、

「Google Driveの共有フォルダ」

には近いですが、

「E2EEされたSignalのグループ」

とは違います。

許可されたPDS、アプリケーション、ユーザーなどがデータを読める設計です。

そのため、

  • パスワード

  • 秘密鍵

  • 医療情報

  • 本当に漏洩してはいけない機密情報

などを置く用途ではありません。

しかも現在はAlphaで、公式自身が「security review未実施」「機密情報をアップロードするな」と警告しています。

現時点での評価

私は今回のSpacesを、

「Blueskyのプライベートアカウント機能」

として評価するより、

「ATProtoにAuthorization Planeを追加した」

と評価するほうが本質を捉えていると思います。

レイヤー従来ATProtoSpaces
IdentityDIDDID
Data ownershipRepositoryRepository
SchemaLexiconLexicon
Public distributionRelay原則なし
Synchronization○○
Access control限定的○
Confidentiality××
Shared context△○
Subscription外部実装中心プロトコルで可能
Private account困難可能性が大幅拡大
CommunityPublic中心Permissioned community

そして公式自身もSpacesを「非公開データを保存・同期しながら、portable identity、interoperable/remixable data、permissionless participationというATProtoの利点を維持するprimitive」と位置づけています。

なので、今回のAlphaは「Blueskyに鍵垢が来た」というニュースではなく、ATProtoが「公開データプロトコル」から「公開＋権限制御データプロトコル」へ一段階拡張されたニュース、と見るのが適切です。

なお、公式発表時点ではAlphaであり、正式ローンチは「今年後半を目標」とされています。ATProtoの進化は、単なる「Blueskyの技術史」ではなく、Twitter代替サービス → 分散型ソーシャルプロトコル → ユーザー所有型データネットワーク → 汎用的なPermissioned Data基盤という方向に拡張してきた、と見ると分かりやすいです。

ATProtoの進化史

年月フェーズ主な出来事技術的な意味
2019構想Twitter内部で「ソーシャルメディアをプロトコル化する」構想が始まるPlatform → Protocolという発想の出発点
2019年末Bluesky開始TwitterがBlueskyを分散型ソーシャルネットワーク研究プロジェクトとして開始Twitterそのものではなく、将来の分散SNSプロトコルを研究
2021独立BlueskyがTwitterから独立した組織へ特定プラットフォームから独立したプロトコル開発へ
2022年5月ADX**Authenticated Data Experiment（ADX）**としてコードを公開現在のATProtoにつながる認証付きデータモデルの実験開始
2022年10月ATProto誕生ADXから**Authenticated Transfer Protocol（AT Protocol）**へ名称変更プロトコルとしてのアイデンティティが確立 (ウィキペディア)
2022–23基礎設計DID、Repository、Lexicon、CAR、Merkle Tree、署名などを整備「投稿をサーバーに置く」から「自己認証可能なデータを所有する」へ
2023プロトコル分離PDS、Relay、AppViewなどの役割を分離SNSを一枚岩のサービスではなく交換可能なサービス群へ
2023年10月v1ロードマップProtocol v1に向けたロードマップ公開2024年のProduction Federationを明確な目標に設定 (AT Protocol)
2024年2月Federation開始Self-hosted PDS向けFederationのEarly AccessBluesky以外のPDSがネットワークに参加可能に (AT Protocol)
2024年春Open FederationProduction networkのFederationを一般開放「Blueskyが運営するネットワーク」から誰でも参加できるネットワークへ (AT Protocol)
2024Account Migrationアカウントを別PDSへ移動する仕組みを実装ID・フォロー・データをサービスから切り離す方向が明確化
2024Moderation分離Labeler / Ozoneなどのモデレーション基盤を整備モデレーションを単一企業の中央機能から分離
2024OAuth / ProxyOAuth、Generic Proxyなどを整備アプリ・認証・サービスの分離をさらに推進 (AT Protocol)
2024–25ATmosphere形成Bluesky以外にもWhiteWind、Tangled、PinkSea等のATProtoアプリが登場Bluesky ≠ ATProtoが現実化
2025Ecosystem化ATProtoを利用する複数アプリ・サービスが増加「SNSプロトコル」からアプリケーション・エコシステムへ
2025標準化への移行ATProtoの標準化をIETFへ持ち込む動きが本格化独自プロトコルからInternet Standard候補へ
2026年4月IETFAuthenticated Transfer Protocol Working Group発足ATProtoの標準化プロセスが正式な段階へ (AT Protocol)
2026年5月Lexicon強化TypeScript SDK、Lexicon関連の整備アプリ間で共有可能なデータ語彙層を強化 (AT Protocol)
2026年6月Standard.site等ATProtoをブログ・Webコンテンツにも拡張SNS以外のWebデータへの適用が進む (AT Protocol)
2026年8月13日Protocol ServicesJetstream v2、Network Replay、SDKなどを展開Firehose/Jetstreamなどのデータストリーム基盤をサービス化 (AT Protocol)
2026年8月20日Spaces AlphaAtproto Spaces公開最大の転換点。Public Data → Permissioned Dataへ拡張 (AT Protocol)
2026年現在次段階Private accounts、Subscription、Private Communities、Collaborative appsなどPublic Social Web + Permissioned Social Webへ

技術アーキテクチャの進化

もう一つ重要なのが、ATProto内部の「何を分離していったか」です。

世代中心概念データの扱いネットワークモデル
初期Twitter型PlatformTwitterが保持中央集権
ADXAuthenticated Data自己認証可能なデータ実験段階
初期ATProtoRepository + DIDユーザー単位でデータを保持分散
FederationPDS各PDSがユーザーデータをホストFederated
RelayFirehose公開データを集約・再配信Public broadcast
AppViewViewsデータからアプリ独自のViewを構築Application-layer federation
LexiconSchema共通語彙による相互運用Interoperable data
Account MigrationPortable IdentityIDとデータを移動可能にVendor lock-in低減
Labeler/OzoneDecentralized Moderationモデレーションを外部化Policy federation
JetstreamEvent StreamingJSONイベントをリアルタイム取得Developer infrastructure
SpacesPermissioned DataACL付きデータPublic + gated federation

この変化を一行で書くと、

PDS → Relay → AppView → Lexicon → DID → Migration → Labeler → Jetstream → Spaces

という具合に、最初は「分散SNSを動かすための部品」だったものが、徐々に汎用的なデータネットワークのプロトコルスタックになっています。

5段階で見るATProto

段階時期ATProtoの正体
① Twitter代替技術2019–22「Twitterを分散化できないか」
② 分散SNSプロトコル2022–24Blueskyを支えるFederated Protocol
③ ユーザー所有型Social Web2024–25DID・PDS・Migrationによるportable identity
④ オープンWeb・データ基盤2025–26Bluesky以外のブログ、Git、動画、ゲーム等にも拡張
⑤ Permissioned Internet2026–Spacesによって公開データ＋アクセス制御データを同一プロトコルで扱う

特に⑤が重要です。

従来のATProtoは極端に言えば、

「すべてを公開することで相互運用性を最大化するプロトコル」

でした。公式も、従来は投稿・フォロー・Like・Blockなどがすべてpublicで、Relayがそれをglobal firehoseとして再配信する設計だったと説明しています。(AT Protocol)

Spacesによってこれが、

「公開するデータ」と「許可した相手だけに見せるデータ」を同じIdentity / Repository / Lexicon / Syncの世界で扱う

方向へ変わります。

つまりATProtoの歴史を最も抽象化すると、

Platform → Protocol → Federation → Data Ownership → Interoperability → Permissioned Data

という進化です。

そして2026年のSpacesは、単なる「Blueskyの鍵アカウント」ではなく、ATProtoをSocial ProtocolからGeneral-purpose Data Protocolへ押し広げる転換点と見るのが最も重要です。(AT Protocol)。ATProto Spaces × WordPress、この2つを並べると、かなり面白い比較になります。結論から言うと、ATProto SpacesはWordPressの「有料コンテンツ機能」の代替ではなく、その下位にある「権限制御されたデータ配信・同期のプロトコル層」に近いです。

ATProto Spaces × WordPress

比較軸WordPressATProto Spaces
主目的Webサイト／CMS分散データ・アプリケーション基盤
コンテンツ記事、固定ページ、画像、動画等Lexiconで定義されたRecord
データ保存WordPress DBPDS上のRepository
IdentityWordPressアカウント等DID
公開コンテンツ○○
限定コンテンツ○○
アクセス制御CMS／プラグインSpace Authority
暗号化プラグイン等に依存×
決済Stripe、WooCommerce等プロトコル自身は担当しない
サブスク○アプリ側で実装可能
会員管理WordPress／プラグインDID＋Spaceの認可
メール配信○プロトコル自身は担当しない
UIWordPressテーマAppView／クライアント
データ移植性CMS依存プロトコル設計上かなり高い
複数アプリ利用△○
ベンダーロックイン比較的発生低減する設計
Relay不要Publicでは重要、Spaceでは原則なし
リアルタイム同期プラグイン等Spaceの同期プロトコル
典型的用途ブログ、ニュースサイト、EC、会員サイトSNS、コミュニティ、購読サービス、共同作業、Private Data

ATProto公式では、Spaceを「アクセスを許可されたユーザーやアプリだけが利用できるminiature atproto network」と説明しており、データは著者のPDS上のper-space permissioned repositoryに保存されます。

構造的には「WordPress＋会員プラグイン」のさらに下

WordPressの場合は、おおむねこうです。

読者
 │
 ▼
WordPress
 │
 ├── 記事
 ├── 会員
 ├── 決済
 ├── 権限
 └── テーマ/UI

ATProto Spacesの場合は、

             Application
                  │
          ┌───────┴───────┐
          │               │
       Payment          AppView
          │               │
          └───────┬───────┘
                  │
             ATProto Space
                  │
          ┌───────┴───────┐
          │               │
    Space Authority       PDS
          │               │
       Access ACL     Permissioned Repo

となります。

つまり、決済・課金・UI・メール配信はSpaceの外側です。

Spaceが提供するのは、その中心にある、

「誰が、どのデータを読めるか」

というプロトコル上の基盤です。

WordPressの「有料記事」をATProto的に考えると

例えば、

月額1,000円のAI研究レポート

を考えます。

WordPressなら、

ユーザー
 ↓
Stripeで1,000円決済
 ↓
WordPress会員DB
 ↓
有料記事へのアクセス許可
 ↓
記事表示

です。

Spacesなら、概念的には、

ユーザー
 ↓
決済サービス
 ↓
「このDIDは購読者」
 ↓
Space Authority
 ↓
DIDにアクセス権付与
 ↓
Permissioned Space
 ↓
ユーザーのAppがデータ取得

となります。

ここで重要なのは、決済と認可を分離できることです。

Stripeがなくてもよいし、Stripe以外でもよい。

決済システムは、

「このDIDにはSpaceへのアクセス権を与えてください」

という状態を作る役割にできます。

これはWordPressの会員プラグインとかなり違う

WordPressでは、

会員情報 → WordPressサイトのアクセス権

という関係が強いです。

一方Spacesでは、

DID → Spaceへの権限

という関係になります。

したがって、

                 WordPress

          ┌────── Website A
User ─────┤
          ├────── Website B
          └────── Website C

よりも、

                  DID
                   │
          ┌────────┼────────┐
          │        │        │
       Space A  Space B  Space C
          │        │        │
        App A    App B    App C

という構造を作りやすい。

ここがATProtoの非常に大きな特徴です。

「有料配信」もプロトコル化できる

したがって、WordPressで現在、

  • 有料記事

  • 月額会員

  • 有料ニュースレター

  • 会員限定コミュニティ

  • 購読者限定動画

  • 有料教材

として実装しているものを、ATProto Spacesでは将来的に、

「購読者DIDにSpaceへのアクセス権を与える」

という共通プリミティブで実装できます。

WordPressの機能Spacesで対応する概念
会員DID
会員ランクSpace／権限グループ
有料記事Permissioned Record
会員限定ページPermissioned Space
有料コミュニティShared Space
購読者Authorized DID
会員DBSpace Authorityによる認可情報
会員ログインDID/OAuth等
WordPress DBPDS Repository
WordPressテーマAppView / Client
Stripe外部サービス
WooCommerce外部アプリケーション
メルマガ外部サービス

さらに面白いのは「購読先の乗り換え」

WordPressの場合、

出版社A
   │
   └── WordPress
          │
          └── 会員DB

という構造になりやすい。

ATProtoでは、

               DID
                │
       ┌────────┼────────┐
       ▼        ▼        ▼
    Publisher A  B       C
       │        │        │
     Space    Space    Space

とできます。

つまり、

「誰が購読者なのか」というIdentityを出版社自身から切り離せる

可能性があります。

これは、ATProtoのportable identity / interoperable dataという思想と非常に整合します。公式もSpacesについて、従来のATProtoの利点であるportable identity、interoperable/remixable data、permissionless participationを維持することを明示しています。

WordPressから見ると「競合」ではなく「次のレイヤー」

ここが一番重要です。

                 WordPress
        ┌──────────────────────┐
        │ CMS                  │
        │ Theme                │
        │ Plugin               │
        │ Membership           │
        │ Commerce             │
        └──────────┬───────────┘
                   │
             Application
                   │
                   ▼
        ┌──────────────────────┐
        │     ATProto          │
        │                      │
        │ DID                  │
        │ Repository           │
        │ Lexicon              │
        │ Sync                 │
        │ Authorization        │
        │ Spaces               │
        └──────────────────────┘

つまり、

WordPress = Publishing Application

ATProto = Data/Application Protocol

という違いです。

そしてSpacesで「WordPress的なWeb」が再構成できる

将来的には、

ATProto
   │
   ├── Public Space
   │     └── 無料記事
   │
   ├── Subscriber Space
   │     └── 有料記事
   │
   ├── Community Space
   │     └── 会員コミュニティ
   │
   ├── Author Space
   │     └── 下書き・メモ
   │
   └── Collaboration Space
         └── 共同編集

という構造が可能になります。

その上に、

WordPress-like CMS
Substack-like newsletter
Patreon-like membership
GitHub-like collaboration
Discord-like community

のような異なるUI/AppViewを載せることができます。

これがATProtoの「AppView」という思想と非常に相性がいい。

ただし最大の違い：Spacesは「課金システム」ではない

ここを混同しないことが重要です。

ATProto Spaces

「誰にデータを見せるか」

Stripe

「誰からお金を受け取ったか」

WordPress

「どういうWebサイトとして見せるか」

Newsletter system

「どうやって読者に届けるか」

です。

したがって、

Spaces + Stripe + AppView + Newsletter

という組み合わせによって、WordPressの有料会員サイトに相当するサービスを分散型プロトコル上で構築できる、という理解が最も正確です。

最終的な位置づけ

システム主役
WordPressPublisher / CMS
WooCommerceCommerce
PatreonMembership
SubstackPublication + Newsletter
DiscordCommunity
ATProtoIdentity + Data + Interoperability
ATProto SpacesPermissioned Data + Shared Context

したがって、Spacesの本当の競合相手はWordPressそのものというより、WordPress、Patreon、Substack、Discord、GitHubなどが個別に持っている「会員・権限・データ共有」の部分を、プロトコル層へ押し下げることだと考えると理解しやすいです。

しかも現在のSpacesはまだAlphaで、公式自身が「security review未実施」「本番利用禁止」「仕様・SDK・DB schemaは変更される」と明記しています。

つまり2026年8月時点では**「WordPressを置き換える技術」ではなく、「将来、WordPressのようなアプリを複数ベンダーがATProto上に構築できるようにするための基盤」**と見るのが妥当です。

コメント

コメントを投稿

このブログの人気の投稿

#Brexitが英国企業を揺るがす：従業員15.7%削減の衝撃と、北アイルランドが生き残った「禁断の果実」#Brexit #2016六23Brexit_平成英国史ざっくり解説 #労働市場 #イノベーション 🇬🇧📉💡　#五29

Brexitが英国企業を揺るがす：従業員15.7%削減の衝撃と、北アイルランドが生き残った「禁断の果実」#Brexit #英国経済 #労働市場 #イノベーション 🇬🇧📉💡 EU離脱は英国経済に何をもたらしたのか？ 国境を隔てた二つの英国が織りなす、驚くべき適応と試練の物語。 目次 1. Brexitの経済的波紋：英国企業の適応と挑戦 1.1. はじめに：英国を分断したBrexitのリアル 1.2. 研究の意義とアプローチ：なぜ北アイルランドが鍵なのか？ 1.2.1. アイルランド国境の役割と「自然実験」 1.2.2. 企業レベルのデータ分析：LSBSが暴く真実 2. Brexitが労働需要に与える実際の影響：従業員削減の衝撃 2.1. 国境からの距離が示す明暗：最大15.7%の雇用喪失 2.2. 労働市場の変化を補完する視点 3. Brexitの不均一な影響：業界と熟練労働者の課題 3.1. 業界の異質性：建設業の悲鳴と小売業の耐性 3.2. 熟練労働者の採用難：EUからの距離 4. 試練を乗り越える適応戦略：R&Dと貿易の力 4.1. 研究開発（R&D）代替効果：イノベーションが雇用を守る？ 4.2. 既存の貿易エクスポージャー：国際ネットワークの強み 5. 日本への影響：対岸の火事ではないBrexit 5.1. 貿易と企業活動への課題 5.2. 日英EPAの活用と今後の展望 6. 歴史的位置づけと今後の研究課題 6.1. 欧州統合の後退：グローバリズムとナショナリズムの衝突 6.2. 今後望まれる研究：長期的な生産性と労働市場の変化 7. 参考リンク・推薦図書 7.1. 日本語資料 7.2. 学術論文 8. 年表：Brexitを巡る主な出来事 9. 用語索引（アルファベット順） 10. 補足 10.1. 補足1：3つの視点から見たこの記事への感想 10.2. 補足2：この記事に対する様々な反応と反論 10.3. 補足3：潜在的読者のためのキャッチーなタイトル・SNS案 10.4. 補足4：一人ノリツッコミ 10.5. 補足5：大喜利 10.6. 補足6：高校生向け4択クイズと大学生向けレポート課題 1...
MORE »

Too Big To Fork：AI時代のLinuxとデジタル公共財の終焉 #TooBigToFork #Linux #AI #七18 #1991九17LinuxとOSSプロジェクト_平成IT史ざっくり解説

Too Big To Fork：AI時代のLinuxとデジタル公共財の終焉 #TooBigToFork #Linux #AI 自由の楽園だったオープンソースは、なぜ巨大な「知識のブラックホール」へと変貌したのか。初学者のための新ガバナンス論。 目次（クリックすると各章にジャンプします） イントロダクション：一文字のコードが背負う「重力」 要旨・本書の目的 方法論：デジタル経済学とソフトウェア工学の交差分析 本書の梗概・構成：四つの転換点 登場人物紹介 年表：UNIXからLlamaエコシステム、そしてAIカーネルへ 第1部：技術的中立性と実用主義の系譜 第1章：イデオロギーなき実用主義 1.1 「良いコード」は宗教を超える 1.2 BitKeeper事件再考：なぜ自由よりも効率を選んだか 1.3 歴史的位置づけ：先行研究に見るLinusの意思決定モデル 第2章：AIを「ツールチェーン」として再定義する 2.1 LLMはGit以来の「パイプ」である 2.2 Rust導入に見る「保守性」への執着 2.3 ローカルLLM：OSS哲学とハードウェアの再結合 第2部：生成の過剰とレビューの希少性 第3章：レビュー・ボトルネックの正体 3.1 限界費用ゼロのコード供給がもたらす悲劇 3.2 定量分析：PR飽和曲線とメンテナーのバーンアウト 3.3 新造語：Vibe-Verification（雰囲気検証）の罠 第4章：AI Assisted Review of Linuxの設計学 4.1 知識...
MORE »

#INVIDIOUSを用いて広告なしにyoutubeをみる方法　#士17 #2018INVIDIOUSとOmarRoth_令和IT史ざっくり解説

https://www.youtube.com/watch?v=XXXXXXXXXX ↑のURL↓のように入れ替えると広告なしにyoutubeをみれる。 https://yewtu.be/watch?v=XXXXXXXXXX Invidious は、 YouTubeに代わる無料のオープンソースのフロントエンドです。 Dockerコンテナとして、またはGitHubマスター ブランチから利用できます。公式 YouTube Web サイトの軽量で「プライバシーを尊重した」代替サイトとして使用することを目的としています。多くのプライバシー保護リダイレクト ソフトウェアおよび YouTube クライアントは Invidious インスタンスを使用します。 Invidious は、YouTubeの動画を広告なしで視聴できる、プライバシーに配慮したオープンソースのサービスです。Googleのトラッキングを避けつつ、YouTubeコンテンツを楽しみたい方におすすめです。 Invidiousのメリット 広告なし: YouTubeの煩わしい広告をスキップできます。 プライバシー保護: Googleのデータ収集を抑え、プライバシーを重視した視聴が可能です。 オープンソース: 誰でも自由に利用・開発できるオープンソースソフトウェアです。 多様なインスタンス: 世界中に多くのInvidiousインスタンスが存在し、それぞれ異なる特徴や機能を提供しています。 Invidiousの使い方 Invidiousインスタンスを探す: 検索エンジン: "invidious instance"などで検索すると、多くのインスタンスが見つかります。 リスト: いくつかのInvidiousインスタンスをまとめたリストサイトも存在します。 YouTubeの動画URLをInvidiousの検索バーに入力: 視聴したいYouTube動画のURLをコピーし、選んだInvidiousインスタンスの検索バーに貼り付けます。 動画を再生: 検索結果から目的の動画を選択し、再生ボタンを押せば広告なしで視聴できます。 Invidiousの使い方 Invidiousは、YouTube動画を広告なしで視聴できる便利なサービスです。 基本的な使い方 Invidio...
MORE »