List of Atproto [text.Baldanders.info]

「なうぷれあっと」を試す

2026-06-27T11:28:22+00:00

すいばりさんによる音楽共有サービス「なうぷれあっと」を試してみた。ご本人による紹介記事はこちら

日本の音楽シーンをATプロトコルで共有するSNSを作った｜すいばり

AT Protocol ベースの音楽共有サービスとしては Rocksky が有名らしいが，あちらのメインボリュームは（当然ながら）英語圏の人達なので，上がってくる楽曲もあちらの音楽が中心になる。そこで

日本のユーザーが、日本語の音楽でつながれる場所が欲しかった。

日本の音楽シーンをATプロトコルで共有するSNSを作ったより

というのがサービスを立ち上げた動機だそうな。

うんうん。よく分かる。私なんて今はアニソンか VTuber の楽曲しか聴かないため，JPOP ならまだしも，海の向こうの音楽はさっぱり分からない。なので，こういうサービスは大変ありがたかったり。

というわけで試してみた。サインアップは Bluesky (というか atproto) のアカウントで行う。設定画面はこんな感じ。

設定より

「自動投稿」を有効にして Last.fm のユーザ名をセットすれば Last.fm の scrobble 情報を使って Bluesky に自動投稿してくれる。 Last.fm と Spotify などの音楽配信サービスを連携すれば，それらの視聴データも反映される。

私はスマホに Onkyo HF Player を入れていて，楽曲の音源を入れてヘヴィローテーションしているのだが，これも Last.fm のアプリで認識できた。

なうぷれあっとのデータは各ユーザの PDS リポジトリに公開情報として格納される。なうぷれあっと自体はユーザの視聴データを保持しないが，各 PDS リポジトリのデータをかき集めてトップページに統計情報を表示しているらしい。

ATプロトコルは 分散型アーキテクチャ です。「再生回数が多い曲」「人気ユーザー」のような集計は、複数のサーバーをまたぐデータを扱う必要があります。

音楽SNSのような中央集権的なサービスが当たり前にやっていることを、分散型の制約の中でどこまで実現できるか試してみたかったです。

日本の音楽シーンをATプロトコルで共有するSNSを作ったより

なうぷれあっとより

Bluesky への自動投稿は設定で間引くことができる。さっき書いたように，私は聴き始めると割とヘヴィローテーションしてしまうので，全部を Bluesky にポストすると TL が #なうぷれ で埋め尽くされてしまう。ポストの頻度についてはチューニング中だが，私は 10% くらいで十分かなぁと思っている。

実は Last.fm のことをすっかり忘れていた。 Scrobble の履歴を見たら2016年が最後のアクセスだった。まだアカウントがあったことにびっくりだよ。当時の履歴もちゃんと残ってたし。

そういえばなうぷれあっとに上がってる楽曲で Spotify 等で視聴可能なものについては該当のページに飛べるようになっている。素晴らしい。 Spotify はアカウントだけ取って完全に放置してたんだよな¹。初めて役に立ったよ（笑）

今回のサービスを試してみて思ったが，ソーシャルなサービスだからといって何でもフラットにすればいいというわけじゃないよな。グローバルとの繋がりは保ちつつ，やんわりと囲える設計がいいのかもしれない。そう考えると Mastodon というか ActivityPub はよくできているかも。

Spotify に限らないけど（アルゴリズムで）機械的に作ったプレイリストやおすすめを聴くのってダルくない？まぁ，私はアナログレコードや CD の世代で，気に入った楽曲は手元に置いて聴き倒したい人だからしょうがない（←年寄り）。今は FLAC 形式の音源が普通に買えるようになって本当によかった。リッピングしなくて済む。 ↩︎

最近の話題（2026-06-07）

2026-06-07T03:29:03+00:00

例によって Mastodon や Bluesky の TL で見かけた記事を紹介する。今回は複数あるので，コメントは簡単に。

お品書きはこちら：

ではどうぞ。

非会員による Kagi Translate 利用の一時停止

An update on Kagi Translate

私は Kagi Translate がローンチする前にサブスクリプション契約をしていたので気が付かなかったが，今まではサインアップしなくても誰でも Kagi Translate を使うことができたらしい。したら，エラい人気だったらしく，運営コストがヤバいことになってるそうな。そこで，一時的に有料会員（無料の Trial プランも除外かな）のみ利用可能にしたとのこと。この一時的制限がいつ解除されるのか（あるいは恒久的なものになるのか）はまだ決まってないみたい。もしかしたら Kagi Translate のみ利用可能な格安プランとかできるかも？

Kagi Translate の日本語訳は，最初の頃こそぎこちなかったが，今では Google 翻訳を凌駕する性能だと思っている。文脈や話者ごとに別訳も提示してくれるし，入力もテキストだけでなく PDF やオフィスドキュメントなどにも対応している。あとは辞書機能と校正機能かな。校正機能は結構ヘヴィに使っている人もいるようだ。

個人的にはメインの Kagi Search にしても Kagi Assistant にしても（月10USD程度なら）お金を払う価値は十分あると思うけどねぇ。

Bridgy Fed からの信頼できる脱出

Launches: Credible Exit, Bridged User Notifications, & Fediverse Re-Bridge

Bridgy Fed 内にあるアカウントをネイティブ・アカウントに移行できる機能を提供開始したらしい。

If you’re bridging from the Atmosphere to the Fediverse, you can migrate the bridged account to Mastodon; if you’re bridging from the Fediverse to the Atmosphere, you can migrate the bridged account to any PDS of your choice. After that, you’ll have two native accounts that you can choose to use separately, or migrate them into a service like Wafrn that lets you use both protocols with one account.

via Launches: Credible Exit, Bridged User Notifications, & Fediverse Re-Bridge

さらに Mastodon でアカウントを「引っ越し」した場合でも Bridgy Fed も追従できるようになったそうな。

From now on, we track your Fediverse moves and automatically migrate your bridged account with it. No action needed on your side – we handle all the work, and you can keep posting across the bridge to all your followers on the Atmosphere.

via Launches: Credible Exit, Bridged User Notifications, & Fediverse Re-Bridge

個人的にこれらの機能を使うことは（今のところ）ないと思うけど，プラットフォームからの脱出方法があるというのは安心材料と言える。

Linus Torvalds は激おこらしい（いつものこと？）

Why Linux creator Linus Torvalds gets angry hearing “99% of code is AI”

“AI is a great new tool, but it’s a tool, and when I see people saying, ‘Hey, 99% of our code is written by AI,’ I literally get angry, because those same people — I can pretty much guarantee — that 100% of their code is written by compilers. But they never say that.”

via Why Linux creator Linus Torvalds gets angry hearing "99% of code is AI"

「コードの 99% が AI によって書かれている」としても AI が書けない（書かない）残り 1% が最も重要なのよ。「コードを書かない人」はそのことに気が付かず，統計上の数字だけを見て人材を機械に置き換えようとする（そして往々にして失敗する）。これはプログラミングに限ったことではないと思う。

昨今の「生成 AI」に対する Linus Torvalds 氏の見解は一貫していて，上の引用にもある通り「 AI はあくまでもツール」というものだ。故に，この便利なツールをどのように使うかということには関心があるようだが， AI が人に取って代わるとか，ましてや「自分たちは神を創造できる」などと頭のおかしいことを言う連中には絶対に与しないと思う。

私もどちらかというと Linus Torvalds 氏に近いかな。ただ AI に対して命令（command）でも指示（instruction）でもなくプロンプト（prompt）を与えるという点が従来の「道具」とは違う点だと最近は考えている。

“People who know what they’re doing to understand systems will be able to prompt tools to write good code,” Torvalds said. “People who don’t understand the complexity of systems will also prompt systems and write processes that will fail. So, I think you do want to understand how it all works.”

via Why Linux creator Linus Torvalds gets angry hearing "99% of code is AI"

GitHub Copilot が登場した当初はコードを「洗浄」する生成 AI に反発が大きかったが，今や AI にコードを書かせることが当たり前になっている。その一方で

Post by @zetamatta@mstdn.jp

View on Mastodon

という懸念にも見られるように FOSS の価値というか優位性は，少しずつ低下しているようにも見える。

どうなるやら。

ブックマーク

オープンソースブラウザ「Ladybird」が外部コード受け入れを停止、AI時代の開発体制へ転換

欧州は脱米国に突き進むのか

欧州で進む「米国テック依存」から脱却の動き。トランプ政権下で高まる危機感

ゼロ年代は（オバマ政権に替わるまで¹）「チャイナ・リスク」が問題視された。今や「US リスク」について真剣に考えなければならない時代になっている。その意味で欧州が脱米国に走るのは自然な成り行きに思える。

私の観測範囲は広くないが，特に atproto を中心とした The Atmosphere 界隈を眺めると脱米国の動きが目立つ。 Eurosky とか Streamplace とか tangled とかあからさまだもんねぇ。

そういやゼロ年代， Bill Gates 氏が Microsoft に健在で「悪の帝国」などと呼ばれていた頃，欧州は脱 Microsoft として Linux などの FOSS 製品を積極的に導入しようとしたんだよね。結局は失敗したっぽいけど。今回はどうなるやらだよ

たとえ欧州の企業や政府機関がMicrosoft Outlookのような米系サービスから移行したとしても、「スマートフォンでは依然として米国製OSを使っているかもしれませんし、米国企業の管理下にあるインターネット基盤を利用せざるを得ないでしょう」とヴェルディエは語る。「現時点では、こうした巨大テック企業を完全に代替できる存在はありません」

欧州で進む「米国テック依存」から脱却の動き。トランプ政権下で高まる危機感より

オバマ政権（というか民主党政権）は中国を「未開拓市場」とみなして積極的に関与する政策に転換した。もちろん米国の事実上の属国である日本も追従する。でも中国のような老獪な国に対してそれは悪手だったんじゃないだろうか，と今にしては思えてならない。米国が「覇権主義」から手を引き始めたのは子ブッシュ政権時代から（政権を超えて）一貫している。その意味で現トランプ政権は，そうした米国の姿勢を加速しているだけとも言える。中国は独裁政治をやりすぎて陰りが出ている。英雄はやはり晩節を汚すのか？まぁ，トランプ氏は最初から晩節で既に汚しまくりだけど（笑）政治には，過去に対しても未来に対しても「もしも」はない。結果が全て。 ↩︎

ぞーぺん（ZonePane）で bsky.social 以外の PDS にサインインする

2026-05-08T11:56:43+00:00

以前書いた「そろそろ PDS を個人で管理する時代か？」で「常用しているぞーぺん（ZonePane）も bsky.social 以外の PDS に対応してない」と愚痴ったのだが ZonePane for Desktop v2.9.18 で bsky.social 以外の PDS (Personal Data Server) にもサインインできるようになった¹。ありがたや。さっそく試してみよう。

bsky.social 以外の PDS でサインインを試す

アカウント追加画面に移動して

アカウント追加より

「Bluesky にサインイン」を選択する。

サインインより

折りたたまれた状態ではあるが「サーバー（PDS）」の項目が追加されている。 Bluesky の既定 PDS である bsky.social であればこの項目は空欄でもいいが，それ以外の PDS のアカウントの場合は PDS のドメインを入力する必要がある。

サインインより

これで「サインイン」ボタンを押せばブラウザの OAuth 認証・承認画面に飛ぶ。

Authorizeより

ここで承認すればサインイン完了である。

Bluesky じゃないほうの PDS を利用している方はプロバイダから PDS 名のアナウンスがあるはずなので必ずメモしておくこと。紛失しちゃった場合は PDSls で確認する手もある。

photos.baldanders.info - PDSlsより

デスクトップ版 ZonePane の Mastodon やら Bluesky やらをゴチャまぜにしてマルチカラムで表示するインタフェースはホンマに重宝していて，もう手放せなくなっている。これからもよろしくお願いします。

v2.9.18 は bsky.social 以外の PDS で OAuth 認証した場合に再認証で PDS ドメイン名を忘れてしまう不具合があったが 2026-05-08 にリリースされた v3.0.0 では修正されていた。

ありがたや 🙇

アプリケーションとデータストレージの抱き合わせはリスクか？

今までは，ユーザから見てアプリケーションとユーザデータ（のストレージ）が一体であることは当たり前だった。分散型と言われる Mastodon でさえストレージはアプリケーション・インスタンスの一部になっていて，別のインスタンスに移りたければインスタンス間でデータの「引っ越し」が必要である（引っ越しができるだけマシだが）。

ここで AT Protocol が登場し Eurosky や Periwinkle といったアカウントとデータを専ら扱う PDS サービスが出てきたことで（ユーザから見た）アプリケーションとユーザデータの関係が変わってきているんじゃないだろうか。たとえば Bluesky は利用したいが Bluesky が擁する PDS に自分のアカウントとデータは置きたくない，といったような。

（上の記事によると，コリイ・ドクトロウ氏は PDS を自前で用意したようだ）

私が pckt.blog サービスのアカウント（photos.baldanders.info）を取得するときには深く考えず「ひとつくらい別 PDS のアカウントがあってもいいだろう」くらいの軽い気持ちだったのだが，最近 atproto エコシステムにおいてアプリケーションとデータストレージの抱き合わせは（アプリケーションがなんであれ）リスクなんじゃないかと思い始めている。

というわけで PDS を引っ越そうか悩み中である。

【2026-05-10 追記】

Andorid 版および iOS 版の ZonePane も最新版で bsky.social 以外へのサインインに対応したようだ。

手元のスマホで試したが問題なくサインインできた。

デスクトップ版 ZonePane は現在「お試し版」の状態で Windows, macOS, Linux (Debian, Ubuntu) で利用可能。 ↩︎

Mastodon 10年史を AI に語らせてみた

2026-04-16T01:32:24+00:00

Mastodon の TL を眺めてたら mstdn.jp が10年目に突入したというポストを見かける。 mstdn.jp が10年目に突入したということは，Mastodon 自体は丸10年経ったということになるか？

ここで Mastodon の10年を振り返る記事を書いてみたら面白いと思ったのだが，実は Mastodon って（特に歴史的な部分は）よく知らないんだよね。なので，AI に Mastodon の10年史を語らせてみることにした。

利用サービスは GitHub Copilot with VS Code，選択モデルは GPT-5.3-Codex で行っている。ではどうぞ。

Mastodon が最初に公開されたのは 2016 年です。2026 年は公開から丸10年の節目で，分散型 SNS の歴史を振り返るには良いタイミングだと思います。

Mastodon 略歴（ざっくり）

2016年: Eugen Rochko 氏が Mastodon を公開。Twitter に似た操作感を持ちながら，サーバーを分散運用できる設計が注目される。
2017年: 各地で個人・コミュニティ運営のインスタンスが増加。日本語圏でも利用者が急増し，「連合（Fediverse）」という言葉が広まりはじめる。
2018年ごろ: ActivityPub を中心に，Mastodon 以外の実装ともつながる流れが強くなる。単体サービスではなく「相互接続できるSNS群」としての性格が明確になる。
2019年〜2021年: 大規模な爆発的成長というよりは，コミュニティ運営やモデレーションの知見が蓄積される時期。ローカルルール重視の文化が定着。
2022年: 主要SNSの環境変化をきっかけに，Mastodon への関心が世界的に再上昇。新規インスタンス立ち上げや移住が加速。
2023年〜2025年: 一時的なブームを越えて，日常的に使う人とコミュニティが残るフェーズへ。Mastodon は「代替先」ではなく，独自の選択肢として位置づけられていく。

ここまでを一言で言えば，Mastodon の10年は「中央集権型の巨大SNSに対するカウンター」から始まり，「分散型コミュニティ運営の実践知」を積み重ねた10年でした。

この記事では，この略歴をもう少し丁寧に追いながら，技術・文化・運用の3つの観点で整理してみます。

技術面: Mastodonの10年

技術面で最初に押さえるべき点は，Mastodon が単なる「Twitter風アプリ」ではなく，最初から連合を前提にした実装だったことです。単一サービスの拡張ではなく，サーバー同士の接続を前提にした設計を採ったことで，後の Fediverse 全体の成長に直接つながりました。

1. プロトコル中心への転換

初期の利用者体験は Web UI の分かりやすさに注目が集まりましたが，長期的に効いたのは ActivityPub を軸にした相互接続性でした。これにより，実装が異なるソフトウェア同士でもフォローや投稿配送ができるようになり，「アプリを選ぶ自由」と「コミュニティをまたぐ接続性」が両立しました。

2. 実装の成熟とクライアント多様化

10年のあいだに，Mastodon 本体は機能追加だけでなく，安定性や管理機能の面でも成熟しました。同時に，公式クライアント以外の選択肢も増え，ユーザーは自分に合う UI やワークフローを選べるようになりました。分散型サービスでは，この「クライアント多様性」が継続利用のしやすさを支える重要な土台になります。

3. 分散設計が生む技術的トレードオフ

一方で，分散設計は常にメリットだけではありません。サーバー間配送の遅延，モデレーション方針の差，メタデータや検索範囲のばらつきなど，中央集権型では見えにくい課題が日常的に現れます。ただし，これは欠点というより，「一つの正解に全員を合わせない」設計思想の裏返しでもあります。

4. 2026年時点で見える技術的意義

2026年の時点で見ると，Mastodon の技術的意義は，巨大プラットフォームに代わる機能を再実装したことではなく，「SNSの相互運用を現実にした」点にあります。実装の競争軸を囲い込みから接続性へ移したこと自体が，この10年で最も大きな技術的成果だと言えます。

文化面: Mastodonの10年

文化面で特徴的なのは，Mastodon が「プロダクトの利用規約に従う場」よりも，「コミュニティの合意で育つ場」として発展してきたことです。同じソフトウェアを使っていても，インスタンスごとに雰囲気や価値観が異なり，その違い自体が Fediverse の多様性を作ってきました。

1. ローカル文化の重視

中央集権型 SNS では，全員がほぼ同じルールとランキングに従います。一方 Mastodon では，インスタンスごとにルールやモデレーション方針を設計できるため，小規模でも目的に合った場を作りやすくなります。技術系，創作系，地域コミュニティなど，話題ごとに文化圏が生まれたのはこの仕組みの効果です。

2. タイムライン体験と会話の速度

Mastodon の体験は，アルゴリズム推薦の強い可視化よりも，時系列で流れる会話の連続性に重心があります。結果として，短期的な拡散効率より，継続的なやり取りや顔なじみ同士の関係が育ちやすい傾向があります。これは「バズ中心の文化」から距離を取りたい利用者に支持された要因の一つでした。

3. ブームと定着の反復

この10年で何度か大きな流入が起きましたが，そのたびに全部が定着したわけではありません。ただ，波が引いた後にも一定数の利用者と運営者が残り，文化が薄く積み上がっていきました。急成長よりも，継続的な共同運営を重視する土壌が形になってきたと言えます。

4. 2026年時点で見える文化的意義

2026年の時点での文化的意義は，「巨大サービスの代替」を超えて，「小さな共同体が自分たちの会話空間を持てる」ことを実証した点にあります。Mastodon の10年は，SNSを一枚岩で捉えるのではなく，複数の文化圏の集合として扱う視点を広げた10年でもありました。

運用面: Mastodonの10年

運用面で重要なのは，Mastodon が「使うサービス」でもある一方で，「運営するサービス」でもあることです。大規模プラットフォームでは運営が利用者から見えにくいのに対し，Mastodon では管理者，モデレーター，利用者の距離が近く，運用そのものがコミュニティの性格を決めます。

1. インスタンス運営の実務

インスタンス運営では，サーバー保守だけでなく，利用規約の整備，問い合わせ対応，荒らし対策，バックアップ運用など，多面的な作業が発生します。特に利用者が増える局面では，技術対応より先に運営体制がボトルネックになることも多く，持続可能な分担設計が不可欠でした。

2. モデレーションと連合ポリシー

Fediverse では，どのサーバーと連合するかを各インスタンスが判断できます。この自由度は大きな強みですが，同時に運営の責任も増やします。迷惑行為の封じ込め，外部インスタンスとの関係調整，方針説明の透明性など，モデレーション実務の成熟が長期運用の鍵になりました。

3. 財政と継続性の課題

多くのインスタンスは有志運営であり，コストと労力の持続可能性が常に課題です。寄付，スポンサー，コミュニティ課金など，運営モデルは多様ですが，どれも万能ではありません。10年の蓄積で見えてきたのは，「拡大速度」より「無理なく続けられる規模」を選ぶ判断の重要性です。

4. 2026年時点で見える運用的意義

2026年時点での運用的意義は，SNSの運営をブラックボックスにせず，コミュニティが意思決定に参加できる形を実例として示したことです。Mastodon の10年は，技術と文化を支える土台として，運用設計そのものがプロダクトの一部であることを可視化した10年だったと言えます。

近年台頭してきた Bluesky との比較

近年は Bluesky も急速に存在感を高めており，分散型 SNS の文脈で Mastodon と並べて語られることが増えました。両者は「中央集権型 SNS に依存しない選択肢」という点では近い一方で，重視する設計とコミュニティの作り方には違いがあります。

プロトコルと構造: Mastodon は ActivityPub を前提に，複数サーバーの連合運用を早期から実践してきました。Bluesky は AT Protocol を軸に，IDやデータ可搬性をより前面に出した設計を進めています。
体験と文化: Mastodon はインスタンスごとのローカル文化が濃く，コミュニティ単位で空気を作る傾向があります。Bluesky は比較的単一空間に近い体験から入りやすく，公開空間での拡散と会話の見通しやすさが強みです。
運用モデル: Mastodon は各インスタンス管理者の裁量が大きく，運営方針の多様性がそのままネットワークの多様性になります。Bluesky はプラットフォーム提供側の整備と利用者体験の統一感を活かしつつ，段階的に分散化を広げるアプローチを取っています。

要するに，Mastodon は「先に分散運用を社会実装した10年」，Bluesky は「分散化を再設計しながらスケールを狙う現在進行形」と整理できます。どちらが優れているかではなく，設計思想の違いを理解して使い分けることが重要です。

まとめ

Mastodon の10年を振り返ると，重要だったのは単なる機能競争ではなく，「つながり方の設計」を社会に実装したことでした。技術面では相互運用性を現実のものにし，文化面では小さな共同体の多様性を支え，運用面ではコミュニティが意思決定に関与するモデルを積み上げてきました。

その意味で，2026年は「分散型SNSは成立するのか」という問いに対して，Mastodon がすでに10年分の実例を示した年だと言えます。これから先は，Mastodon と Bluesky を含む複数の流れがどう交差し，利用者にどんな選択肢を広げていくかを見ていく段階に入った，と私は考えています。

Mastodon どうでしょう

アウトラインは AI と一緒に考えたが（AI だけに考えさせると論文みたいな構成になるw），中身は 100% AI による記述で，私は1文字も触っていない。

どうだろうか¹。私なんか文章を読んで「ほほう」と感心してしまったよ（笑）

しかし10年か。 Mastodon の登場は一昔前の話になってしまったねぇ。日本で Mastodon が話題になった頃に「GW 過ぎたらみんな忘れてるに100カノッサ」と言ってた頃が懐かしいよ。当時は Twitter がここまでメタクソ化するとは思わなかったし「どうせ山ほどある Twitter クローンのひとつでしょ」という認識しかなかったからなぁ。

IT 業界は2〜3年でシーンが変わるからな。 10年も経てば，そりゃあ変わるか。

ブックマーク

Kagi Assistant にも同じように聞いてみたが，こちらは Mastodon が「強力なアンチハラスメントツール」として機能していることを強調していた。ユーザ側の高度なフィルタリング機能や投稿時に公開範囲を制御できることを評価しているみたい。 ↩︎

Streamplace と Livepeer

2026-04-12T13:23:13+00:00

前回の続き。

というか，前回の記事が思ったより長くなったのと，話の中心が Streamplace のほうに横滑りしそうになったので記事を分けたのだった。

Livepeer について

Streamplace の話をする前にバックエンド（基盤技術）のひとつである Livepeer について説明しておこう。

Livepeer は Ethereum blockchain 上に構築された分散型のビデオインフラストラクチャ・プラットフォーム，だそうだ。 Blockchain 関連は Ethereum が登場するあたりからどんどん興味が薄れていったのだが，こんなまともそうなものもあるんだ。

Livepeer は以下の疑問が出発点となり，2017年に設立されたらしい。

What if video - the most captivating, expressive medium online - ran on open, permissionless infrastructure instead of expensive, proprietary systems?

via Livepeer Story - Livepeer Docs

Since its launch in 2017, Livepeer’s mission has been to deliver affordable, performant open video & AI infrastructure rooted in decentralised video technology enabled by cryptoeconomic primitives.

via Livepeer Story - Livepeer Docs

Doug and Eric set out to revolutionise video streaming infrastructure from the hardware infrastructure up by:

Turning idle GPUs around the world into a competitive marketplace,

Using crypto-economic incentives to guarantee reliability and quality,

Delivering measurable cost reductions via decentralised economies of scale.

via Livepeer Story - Livepeer Docs

Livepeer の特徴について Kagi Assistant にまとめてもらった。

分散型トランスコーディング
- 動画配信で最もコストがかかる「トランスコーディング（動画を視聴者の環境に合わせた形式に変換する処理）」を、世界中のコンピューター（ノード）に分散して実行させます
- これにより YouTube や AWS などの巨大な中央集権的サーバーを利用するよりも大幅に低コストで配信インフラを構築できます。
ネットワークの参加者
- オーケストレーター（Orchestrators）: 自分のコンピューターのリソース（CPU/GPU）を提供して動画処理を行い報酬を得る参加者です。
- デリゲーター（Delegators）: 自分が持つ LPT トークンを信頼できるオーケストレーターに預け（ステーキング）、ネットワークのセキュリティに貢献しながら報酬の一部を受け取る参加者です。
LPT (Livepeer Token)
- Livepeer の独自トークン「LPT」は、ネットワークの調整、ガバナンス、およびセキュリティ維持のために使用されます。
AI との統合
- 最近ではビデオ配信だけでなく、分散型 GPU リソースを活用した AI 推論（リアルタイムのビデオ生成や加工など） のインフラとしても機能を拡張しています。
開発者向けツール
- 開発者が自分のアプリに簡単にビデオ機能を組み込めるよう、SDK や「Livepeer Studio」といったホスト型プラットフォームも提供されています。

だいたい合ってる？ Streamplace や Livepeer 周辺で Web3 が云々とか聞こえてきたのはそういう訳だったんだねぇ。

Streamplace について

ここで Streamplace が登場する。 Streamplace は2024年後半にパイロット版が公開され，2025年の ATmosphereConf のライブ配信に採用されて注目を集めた。 2026年の ATmosphereConf でも Streamplace によるライブ配信が行われていた（まぁ，私はそれで知ったのだが）。

Streamplace は，この Livepeer が提供する強力な分散型ビデオ処理能力をバックエンド（基盤）として利用することで特定の企業に依存しない自由な配信プラットフォームを実現する，ということのようだ。前回の記事でも挙げたが「特定の企業」のひとつである YouTube と Streamplace との比較を再び挙げておく（AI による要約なので鵜呑みにしないように）。

比較項目	Streamplace	YouTube
運営形態	分散型（特定の企業に依存しない）	中央集権型（Google が運営）
基盤技術	AT Protocol / Livepeer ネットワーク	Google 独自のクローズドなインフラ
ソースコード	オープンソース（誰でも利用・改善可能）	非公開（プロプライエタリ）
データの所有権	ユーザー自身（自己主権型アイデンティティ）	運営企業（Google）
主な目的	分散型 SNS 向けのビデオインフラ提供	広告収益を主とした動画共有サービス
検閲・制限	プロトコルレベルでの検閲は困難	運営企業のポリシーにより削除・停止あり
主な利用者層	Web3 開発者，分散型 SNS ユーザー	一般消費者，クリエイター，広告主

もちろん，基盤技術として AT Protocol (Authenticated Transfer Protocol) が使われているのもポイントで，つまり Streamplace は「万能アカウント（The Everything Account）」上のアプリケーション（のひとつ）である，とも言えるわけだ（分散サービスではあるが，匿名サービスではない）。

The Atmosphere, as you can see above, already has countless apps you can use. There are Twitter-like apps such as Bluesky and Blacksky; blogging services like Leaflet, Offprint, and pckt; collection and annotation tools like Semble, Margin, and Seams; and I can go on and on because the ecosystem is expanding by the day. And this is just a small portion of the existing Atmosphere - I couldn’t fit all of the different apps because there are just. so. many.

via The Everything Account

なお VOD (Video on Demand) については，この記事を書いてる時点でまだ開発・テスト中の段階らしい。特にフロントエンド側が未整備のようで，私達一般ユーザが利用できるのはまだ先のようだ。

Livepeer が分散ネットワークであるということは Streamplace はセルフホストしないといけないのか？と一瞬思ったが，一般ユーザ向けには Streamplace 公式の環境（stream.place）が用意されている（使い方は前回記事参照）。組織向けや自前で動画配信プラットフォームを構築したいユーザはセルフホストもできますよ，というスタンスみたい¹。 Streamplace がもっと注目されれば（今 PDS サーバがボコボコ立ち始めているように）一般ユーザが選択可能なインスタンスがもっと増えるのかも知れない。

Streamplace のマネタイズってどうなってるの？

でも，そうなると stream.place のマネタイズってどうなってるのか気になる。ベンチャーキャピタルから資金調達しまくって，挙げ句の果てにメタクソ化か？とか意地悪なことも考えたが，ちょっと違うらしい。

Streamplace は Livepeer Treasury から助成金を受けて開発を行っているらしい（LPT 払い？）。 Livepeer にとって Streamplace はエコシステム上の「公共財（public good）」と見なされていて， Streamplace を育成することが Livepeer エコシステムの拡大に繋がると考えているようだ。

一方 Streamplace 側は Gateway ビジネスモデルによるマネタイズを将来的に考えているらしい。アーキテクチャと支払いフローはこんな感じ。

flowchart LR subgraph ApplicationLayer [Application Layer] direction TD A1["User Apps\nWeb, Mobile,\nTouchDesigner"] end subgraph GatewayLayer [Gateway Layer] direction TD A1 --> J[Job Intake] J --> A1 G1["Capability Discovery"] G2["Pricing & Selection"] G3["Routing / Session Mgmt"] end subgraph OrchestratorLayer [Orchestrator Layer] direction TD J --> GW[GPU Worker] GW --> J AI["AI Models / BYOC\nContainers"] T[Transcoder] end style ApplicationLayer stroke:#3cb540,stroke-width:2px style GatewayLayer stroke:#3cb540,stroke-width:2px style OrchestratorLayer stroke:#3cb540,stroke-width:2px

via Gateway Architecture - Livepeer Docs

flowchart LR A["End users / \nApplications"] G["Gateway"] O["Orchestrator"] W["Transcoder / \nAI Runner"] C["Arbitrum \n(on-chain)"] R["Gateway revenue"] A -- "Pay gateway's rate \n(business layer)" --> G G -- "Pay network rate \n(ETH payment tickets)" --> O O -- "Pay workers" --> W O -- "Redeem tickets" --> C G -- "Keep margin" --> R

via Gateway Business Model - Livepeer Docs

この “End users” は配信者を指すのか？視聴者も含むのか？

上の図は Streamplace を含む Livepeer エコシステムに対する支払いモデルだ。でも，これだと最終的にかかるコストを配信者と視聴者の間でどう配分するかについて不透明な感じがする（見落としがあったらゴメン）。一応

アプリ開発者や配信者が使用したリソース分を支払う従量課金モデル（クラウド資源利用とかでよく見る方式）
高度な機能や安定した帯域を保証する代わりに視聴者が一定額を支払うサブスクリプションモデル（Amazon Prime Video や Netflix みたいな感じ）

とかいった方法で収益化を行うことを考えてるみたいだけど…

YouTube などは基本的にオーディエンスの規模が大きいほど（視聴者への接触機会が多いほど）配信者が稼げる構造になっているが，広告モデルであるが故に配信者も視聴者もコストを払っている感覚が薄い（スパチャのような投げ銭に近いものもあるが）。そういう意味でも YouTube は現代版「テレビ」なんだよなぁ。

動画配信に限らないけど，こういうのって流れ (トレンド) を激変させるほどのキラーコンテンツが現れるかどうかなんだよな。そう考えると Streamplace はまだ「整ってない」感じがするし，整ったとしてもバズるかどうかは運次第といったところもある。

P2P や Web3 などに興味のある人にとっては注目すべき点もあろうが，一般のユーザにとっては「もうしばらく様子見かな」といったところか。やっぱ VOD 機能が正式にサービスインされないと是とも非とも言えないなぁ。

でも，私みたいに今まで「配信」とは無縁だった周回遅れの人が「ちょっとやってみようかな」と思える程度にはなっているかな。

暗号通貨/資産はゼロサムゲームか？

私個人の感覚で申し訳ないが， Livepeer が Ethereum blockchain 上に構築されていると聞いて身構えてしまうのは「暗号通貨/資産って，結局のところゼロサムゲームなんじゃないの？」と思ってしまうからだ。特に NFT (Non-Fungible Token) とか極まってるよね。生成 AI が登場して，そちらに興味が移ったら，あっという間に廃れたけど（笑）

…ていう雑談を Kagi Assistant としてたのだが AI 曰く

投資家同士のマネーゲーム（富の移転）で終わるのではなく、そのプロジェクトが 「世の中をどう便利にするか」「どんな問題を解決するか」 という実需が伴うことで、市場全体が成長するポジティブサムな関係が成立します。

なんだそうな。確かに NFT には「実需」はなかったな。 LPT はどうなんだろう。 Livepeer エコシステムを通じて何かしらの「実需」を創造できるのだろうか。

ブックマーク

なお，セルフホスト用に Docker 環境が用意されているそうな。 WebRTC を利用するので（UDP ポートをいっぱい開ける），その辺の知識がないと難しいかも。 ↩︎

Streamplace で Gogh 作業配信を行う

2026-04-12T06:23:32+00:00

前回の最後の方で「Streamplace を使うことを考えてみようかな」と書いたが，実際に試してみることにした。なお gogh のゲーム画面を動画配信サイトに乗せるのは基本的に OK のようだが，制作会社からガイドラインが示されているので，それに従う必要がある。

gogh二次利用ガイドライン

Streamplace とは

Streamplace は分散型 SNS 向けのビデオレイヤおよびオープンソースのライブビデオ配信プラットフォームで AT Protocol (Authenticated Transfer Protocol) エコシステム下で構築されているのが特徴らしい。

Kagi Assistant に Streamplace と YouTube の比較表を作ってもらった（YouTube 以外の動画配信サービスでも似たようなものだろう）。

比較項目	Streamplace	YouTube
運営形態	分散型（特定の企業に依存しない）	中央集権型（Google が運営）
基盤技術	AT Protocol / Livepeer ネットワーク	Google 独自のクローズドなインフラ
ソースコード	オープンソース（誰でも利用・改善可能）	非公開（プロプライエタリ）
データの所有権	ユーザー自身（自己主権型アイデンティティ）	運営企業（Google）
主な目的	分散型 SNS 向けのビデオインフラ提供	広告収益を主とした動画共有サービス
検閲・制限	プロトコルレベルでの検閲は困難	運営企業のポリシーにより削除・停止あり
主な利用者層	Web3 開発者，分散型 SNS ユーザー	一般消費者，クリエイター，広告主

だいたい合ってるかな。

Streamplace および基盤技術である Livepeer については別記事でもう少し掘り下げて紹介する。まずは（細かいことは考えず）アカウントを取得するところから始めよう。

Streamplace 側の準備

公式サイトのトップページの右上にある Sign Up をクリックする。

via Streamplace Signup

サインアップには Bluesky などのアカウントが必要らしい。アカウントを入力して（上の図では隠れているが）下の方にある Continue をクリックすると OAuth の認証画面になるので確認して承認すればサインアップは完了。

via OAuth Authentication

ドメイン等をきちんと確認すること。

サインアップ（あるいはサインイン）したら Live Dashboard に移動する。

via Live Dashboard

ここで Stream from OBS をクリックする。

via Stream from OBS

プロトコルは RTMPS を選択。この状態で Generate Stream Key をクリックする。

via Stream from OBS

Stream Key が伏せ字で表示されるので右側のボタンをクリックしてクリップボードにコピーする。

OBS 側の設定に必要なので以下の情報はどこかにメモっておこう。

Service： Custom…
Server： rtmps://rtmp.stream.place:1935/live
Stream Key： 上で取得した値
Output Settings
- Output Mode： Advanced
- Keyframe Interval： 1s
- x264 Options： bframes=0

OBS Studio 側の準備と配信の開始

当然ながら gogh はあらかじめ起動しておいてね。

OBS Studio のインストールおよびシーンやソースの設定については割愛する（前回記事の後半でもちょこっと説明している）。各自でいい感じに設定して欲しい。

配信設定については，設定（Settings）画面を表示し配信（Stream）タブで，上の情報を参考に，以下のように設定する。

via OBS Studio ➢ Settings ➢ Stream

さらに出力（Output）タブでも，以下のように設定する。

via OBS Studio ➢ Settings ➢ Output

これであとは Start Streaming ボタンを押せば Streamplace 側に配信が流れる。 Streamplace の Live Dashboard が以下のような状態になっていれば OK（まだプレビュー状態）。

via Live Dashboard

タイトル等を入力して Start Livestream! をクリックすれば配信が開始される。

via Live Dashboard

ちなみに，最近の Bluesky はライブ中フラグを立てることができる。

via Edit live status

ライブ中状態にすると以下のようにアバターアイコンに赤枠が付く。

via Profile

スマホ用アプリ

Streamplace の配信は Web ブラウザで見れるが，スマホ用のアプリも提供されている。

Android だとこんな感じ（横持ちの場合）。

via Streamplace App

見るだけならサインインしなくても OK なようだ。これならスマホ版の gogh は要らんな（笑）配信¹ 仕掛けてポモドーロ・タイマーを起動しておけば出先でも使えるぢゃん。

…後半へ続く。

~~Streamplace 配信は特定のユーザにだけ見えるようにすることもできる。~~ 勘違い。 gogh の限定公開機能と混同していた。 ↩︎

Gogh でてきぱきワーキング【2026-05-23 追記】

2026-04-04T10:08:09+00:00

gogh で作業支援

いわゆる作業支援ゲームあるいはもっと簡単に「作業ゲー」と呼ばれるものは色々と登場しているが gogh (ゴッホ) で自身の作業ルームを公開されている方を Bluesky で見かけたので私も試してみた。

gogh - Focus with Your Avatar
ambr｜note : gogh の制作会社によるブログ
gogh ゴッホ - YouTube : gogh の公式 YouTube チャンネル
@goghjpn.bsky.social on Bluesky : gogh の公式 Bluesky アカウント

Steam 版の gogh は作業ルームをかなり細かくカスタマイズできて，しかもそれを他のユーザと共有できるというので，クリエイター寄りの方々にも人気らしい。

実際、マルチプレイヤー機能が入ってからは本当に爆発的に広まりました。これはgogh配信の大きな特徴なのですが、想像もしていなかったような有名なイラストレーターさんや漫画家さんが次々に作業配信をしてくれました。開発チームには漫画好きやイラストレーターファンが多いので「え…？あの先生も…！？」とチームのSlackに毎日驚きと喜びが溢れていました。

世界30万本を超えたSteam版goghを振り返る - 開発編｜ambrより

モバイル版（Android/iOS）が無料で提供されているにもかかわらず有料の Steam 版がこれだけ売れてるというのは，この辺に理由があるのかも知れない。

Steam 版の gogh の特徴としてはマルチルーム（マルチプレイ）機能の他に

ポモドーロ・タイマー¹
ToDO リスト，日課，日記の記入・管理
複数のアバターを作成可能（最大18アバター）
- DLC でコラボレーションアバターも提供されている
- アバターデザインを公開・共有可能（v3.1.1 より）
複数の部屋を作成可能（最大27部屋）
- 大人数が入れるLサイズ部屋も作成可能
- 壁や天井のない野外ルームもあり
- ルームデザインを公開・共有可能（v3.0.0 より）
- 透過背景可能（v3.1.1 より）
ルームアイテムへのWebカメラストリーミング
- OBS の仮想カメラにも対応（後述）
YouTube 連携（v3.0.0 より）
お絵描きチャット（通常のチャット機能，音声チャット機能はない）
ローカル音楽プレイリスト
テキストチャット機能（v3.2.0 より正式リリース）

などといったものがある。

via File:Pomodoro Technique.jpg - Wikimedia Commons

試しに（マルチプレイヤーでも使えるように）Lサイズ部屋をひとつ作ってみたのだが，うっかり興が乗ってしまい夜ふかし（というかほとんど徹夜）してしまった。我ながら何やってんだか。

goghより

任意の画像データ（GIF も可）を絵や写真オブジェクトとして室内に設置できる。上の部屋では Flickr で公開している写真を展示してみた。まぁ，飾るような写真じゃないんだけどね。雰囲気だよ雰囲気（笑）

gogh と OBS

gogh は OBS と組み合わせてゲーム内でストリーム配信することもできる²。たとえばパソコンモニタやプロジェクタ・スクリーンといったオブジェクトに OBS の仮想カメラの映像を映し出すことができる。

今まで配信とか無縁の生活だったが，面白そうなので OBS Studio をインストールして試してみた³。のだが，どうしても上手くいかない。最初は OBS 側のシーンやソースの設定の問題かと思って色々弄ってみたが全然ダメで，ふと思いついて Web カメラを gogh のアイテムに直結してみたが，これもダメだった。これって多分 gogh 側にカメラ映像が渡ってないな。

ちなみに私のメインマシンは Ubuntu なのだが，よく考えたら Steam 版 gogh は Windows 版のみの提供で Linux/Ubuntu 環境では Proton でエミュレーションして動かしているのだった。だから OBS との連携ができなくても仕方ないのかな？

しょうがない。ミニ PC (Windows 機) に OBS Studio を入れるか。あまりパワーがないのでまともに動くか不安だけど。

goghより

おっ。あっさり動いた。自分で自分を映してるので合わせ鏡みたいになってるが，まぁよかろう。一応 gogh とは別のゲームを起動して仮想カメラで映してみたが，これも問題なかった。パワーがないのでちょっとカクカクしてたけど（笑）

.｡oO（マルチプレイ用に部屋を公開したらストリーミングが切れてしまった。これってこういうもの？）

OBS を使えば YouTube などのサービスにも配信できる。とはいえ，これで稼ぐ気はないし，何となく Google のサービスは嫌なので atproto エコシステム下のサービスである Streamplace を使うことを考えてみようかな。

Start streaming with OBS | Streamplace Docs

上手くいったらまた報告する。

ブックマーク

参考

てきぱきワーキン〓ラブ (5) (ビームコミックス): 竹本泉 (著); エンターブレイン 2000-05-01; コミック; 4757700423 (ASIN), 9784757700420 (EAN), 4757700423 (ISBN); 評価

[Comment] ついに（「さよパラ」にも出てきた）アレックスの謎が解ける？

reviewed by Spiegel on 2017-10-13 (powered by PA-APIv5)

ポモドーロ・タイマーはいわゆるポモドーロ法（Pomodoro Technique）に基づいたタイマーで，メインの作業時間（通常25分）と休憩時間（通常5分）を交互に繰り返すことで集中力を維持するためのもの。gogh では作業時間と休憩時間の長さはユーザが自由に設定できる。「ポモドーロ」とはイタリア語で「トマト」を意味し，この名前はこの方法を考案した Francesco Cirillo がトマト型のキッチンタイマーを使っていたことに由来するらしい。 ↩︎
OBS (Open Broadcaster Software) はオープンソースの高機能ライブ配信・録画用ソフトウェア。 “OBS Studio” という製品名で無料提供され Windows, macOS, Linux 用のバイナリが提供されている。映像・音声のミキシング，ライブ配信，高画質録画，シーンの切り替えといった機能を備えている。 YouTube や Twitch といったサービスへの配信にも対応している。また仮想カメラ機能を使い Zoom や Microsoft Teams といったビデオ会議ツールのカメラ入力としても利用できる。 ↩︎
ちなみに OBS Studio のインストールには通常の方法の他に Steam からインストールする方法もある。 Steam 版は自動更新してくれるメリットがある。ただし Windows バイナリのみの提供で Ubuntu 機ではインストールできないこともないが起動時に「ネイティブ版を使え」と怒られる。それでも無視して起動しようとしたらクラッシュした。 Linux ネイティブの OBS Studio は Flatpak で提供されている。また Ubuntu 環境では PPA に公式リポジトリがあるので，そちらから APT でインストールすることもできる。 ↩︎

ブログを Fediverse & Atmosphere に参加させる

2026-03-23T11:42:41+00:00

随分前に Bridgy Fed を利用して Bluesky と Mastodon を相互接続させる方法を紹介したが，同じサービスを使ってブログなどの Web サイト（の更新）を Bluesky/Atmosphere および Mastodon/Fediverse と連携させることが出来るようだ。

graph LR Website["Web site"] BridgyFed(("Bridgy Fed")) Mastodon["Mastodon (Fediverse)"] Bluesky["Bluesky (Atmosphere)"] Website-->BridgyFed BridgyFed-->Mastodon BridgyFed-->Bluesky

Federation with Bridgy Fed

登録自体は簡単で，以下のページでブログの URL を入力するだけ。

via Enter a web site to bridge:

成功すれば以下の画面に遷移する。

via text.baldanders.info profile - Bridgy Fed

RSS フィードを備えているサイトであれば問題なく登録できるはず。サイトの登録は誰でもどのサイトでもできる。勝手に登録されてしまい取り消したいのであれば，オプトアウトの手続きを行う必要がある。

If you’re on the web, email us from an address at your web site’s domain to show that you own it, or you can put the text #nobridge in the profile on your home page and then update your profile on your user page.

via How do I opt out and remove my site or account?

初期状態では Bluesky ハンドルは @yourdomain.com.web.brid.gy に， Mastodon ハンドルは @yourdomain@web.brid.gy になっている。

たとえばサイトのドメインが text.baldanders.info であれば，それぞれ

@text.baldanders.info.web.brid.gy (Bluesky)
@text.baldanders.info@web.brid.gy (Mastodon)

となる。

このうち Bluesky ハンドルはサイトのドメイン名に変更可能である。変更方法は以前書いた記事を参照のこと。 DNS の TXT レコードまたは /.well-known/atproto-did ファイルに DID を設置すれば勝手に更新してくれるみたい。

ちなみに，ここのブログのように GitHub Pages で独自ドメインにしている場合は DNS の TXT レコードが使えないため /.well-known/atproto-did ファイルに DID を書いて設置した。この場合 /_config.yml ファイルに以下の記述を追加する必要がある。

include: [".well-known"]

最終的には以下のハンドル名になった。

@text.baldanders.info

via text.baldanders.info - PDSls

Mastodon ハンドル名の web.brid.gy の部分を独自ドメインに変えることもできるようだが，このブログではメリットが薄い（かえってハンドル名が長くなる）のでやらないかな。

Fediverse の各サービスや Bluesky 等とやり取りするために IndieWeb や Webmention が推奨されているみたいだが，これは後日調査して可能なら対応するか。

今回はここまで。

ブックマーク

Using Web Mentions in a static site (Hugo) | Modern Web Development with Chrome
このブログがFediverseに対応しました
Bridgy-Fedのまとめ
Webmention.io
Long-Form Comes To Bridgy Fed : Bridgy Fed が長文ドキュメント用の Standard.site に対応

そろそろ PDS を個人で管理する時代か？

2026-03-10T04:13:04+00:00

Eurosky と Periwinkle

ここのところ私のご近所 TL で話題の Eurosky がローンチしたのは昨年の11月で，今月に入って一般公開されたらしい。

私がこれを知ったのは骨折入院中で「面白そうなことをやってるなぁ」と指をくわえて見てたのだが，記事を読んでみるに，かなり政治的動機の強いサービスのようだ。ちなみに資金は個人や組織からの寄付で賄っているそうな。ユーザに割り当てられるリソースの詳細は明記されていない。

一方，今日はじめて知ったのだが， Periwinkle というサービスがあるらしい。こちらは早期アクセスの段階。 TechCrunch が取り上げていた。

TechCrunch はこれをサードパーティのホスティング・プロバイダによって管理されている WordPress インストールみたいだと評している。

This idea is similar to how people who want to create their own blog can choose between an easy-to-use hosted blog on WordPress.com, a DIY installation using the open source software from WordPress.org, or something in between — like a WordPress installation that’s managed by a third-party hosting provider. Periwinkle is offering the same, but for decentralized social media.

via Periwinkle is making self-hosted social media on Bluesky's AT Protocol even easier | TechCrunch

んで，こちらはちゃんとスペックと料金プランが示されている。

Periwinkle - Get Startedより

Basic プランで月600円くらいか？それなら個人でも無理なく行けそう？

Kagi Assistant に Eurosky と Periwinkle を比較してもらった。

PeriwinkleとEuroskyは、どちらもBlueskyの基盤であるAT Protocolを活用し、ユーザーがデータを自己所有する「分散型ソーシャルメディア」の普及を目指していますが、そのアプローチや目的には明確な違いがあります。

共通点

AT Protocolの採用
- 両者ともAT Protocolを基盤としており、Blueskyなどの他のネットワークと相互運用性があります。
データの自己所有（自己主権型アイデンティティ）
- ユーザーが自身のデータやフォロワーとの繋がりを所有し、特定のプラットフォームに縛られず（ロックインされず）に移動できる仕組みを重視しています。
運用の簡略化
- サーバー構築などの技術的なハードルを下げ、一般ユーザーが容易に「自分のデータサーバー（PDS）」や「自分のアカウント」を持てるサービスを提供しています。

違い

項目	Periwinkle	Eurosky
主な役割	マネージドPDSホスティング	ソーシャル・インフラストラクチャ
重点を置く点	個人のサーバー運営の代行と管理ツールの提供。	欧州のデータ主権確立と独自の社会的ウェブ構築。
政治・地理的背景	特定の地域に限定せず、個人やチームの利便性を追求。	欧州（EU）の自立を掲げ、米国テック企業の独占に対抗。
主なターゲット	自分のドメインで発信したい個人、クリエイター、小規模チーム。	欧州のユーザー、開発者、および民主的な対話空間を求める層。
提供価値	~~24/7監視~~、バックアップ、複数ハンドル管理などの「運用保守」。	~~GDPR準拠~~、欧州内でのデータ処理、~~独自のコンテンツ審査体制~~。

まとめ

Periwinkleは、いわば「AT Protocol界のWordPress.com」のような存在で、技術的な手間を省いて自分の城（PDS）を持ちたい人向けのツールを提供しています。
Euroskyは、より大きな枠組みで欧州独自のデジタル公共圏を作ろうとしており、インフラの提供だけでなく、政治的な独立性や民主的な対話の場を重視しています。

パッと見で「そんなこと書いとらんやろ」って部分は打ち消し線をしている。これだから生成 AI は… それ以外はだいたい合ってると思う。各自でも確認してね。

なお PDS リポジトリデータの移動には PDS MOOver が使える。これで bsky.social にあるデータを失わずに新しい PDS に移せるし，万一利用してる PDS がポシャってもデータ移行はできそうである（突然死はどうしようもないが）。

ところで，これは完全に余談なのだが Eurosky も Periwinkle もブログ運営を Leaflet で行ってるのが面白い。やはり時代は Leaflet なのか？

コリイ・ドクトロウ 𝕏 やめるってよ

今まで散々 Bluesky を dis ってた SF 作家のコリイ・ドクトロウ氏が，ついに Bluesky に参加し 𝕏 からは完全に足を洗うようだ。

だが――Blueskyの名誉のために言えば――彼らはやがてそれを理解し、独自のBlueskyサーバを構築するためのツールと手順を公開した。ケンがすぐに調べてくれて、すべて可能だと教えてくれたが、トロントのコロケーションケージに置いてあるLinuxボックスのハードウェアアップグレードが完了するまでは無理だという。そのアップグレードが数ヶ月前に終わり、昨日、ケンが私専用のBlueskyサーバの設置が完了したと知らせてくれた。こうして私はBlueskyに参加した。@doctorow.pluralistic.netである。

https://bsky.app/profile/doctorow.pluralistic.net

Twitterとの決別――マスクはカエルを火炎放射器で丸焼きにした » p2ptk[.]orgより

もう何年もの間、私はほぼ毎日、Twitterにこの告知を投稿してきた。

Twitterは日に日に悪化している。いつか使えなくなるまで劣化するだろう。メタクソ化に強い代替手段として、Fediverseが我々の最善の希望だ。私は@pluralistic@mamot.frにいる。

今日、私はその修正版を投稿する。以下の一文が追加される。

Blueskyでフォローしたい方は、@doctorow.pluralistic.netへ。これが私がTwitterに投稿する最後のスレッドだ。

Twitterとの決別――マスクはカエルを火炎放射器で丸焼きにした » p2ptk[.]orgより

どうやら彼は自前の PDS を立てたようだ。 DID が did:web:pluralistic.net になっていて PDSls からは見れなかった。

自前の PDS を立てる方法は公式ドキュメントにあるんだが，これを読んでもできる気がしない。個人でやるなら Eurosky なり Periwinkle なり，あるいは他の PDS を提供しているサービスを利用するほうが現実的だと思う。さくらインターネットあたりがこういうサービスやらないかなぁ…

欧州版 𝕏 じゃない，キラーアプリじゃない，万能アプリじゃない

そういえば，最近見たこのポストが面白かった。

AT protocol doesn’t play zero-sum, winner-takes-all games. “European X?” No, European data sovereignty for all of x/y/z in amicable competition. “Killer app?” No, interoperable apps as the monopoly-killer. “Everything-app?” No, everything-account in a pluriverse of user-owned software.

[image or embed]
— Erlend Sogge Heggen (@erlend.sh) March 8, 2026 at 10:08 PM

Blusky が提供する bsky.app も bsky.social も，大きなエコシステムの一部になりつつある。

via The Everything Account

Eurosky のドキュメントを見ても分かるように，欧州は AT Protocol を使ってリスク塗れのアメリカからの脱出を目指してるように見える。 Instagram の代替とされる Flashes や GitHub の代替とされる Tangled や Google ニュースの代替とされる Sill も atproto エコシステムの一部で，「万能アカウント（Everything Account）」を 所有する 私達はこれらのアプリやサービスの間を繋がりは維持したまま自由に渡り歩くことができる。

危機は変化を引き起こす。ウラジーミル・プーチンやイーロン・マスクやドナルド・トランプがいなければ、世界はもっとマシだっただろう。だが、この我慢できない、気短な、最低の男たちには1つ用途がある。行動を促すには緩慢すぎる危機を、無視できない緊急事態へと変えてくれた。プーチンはEUを化石燃料からの脱却に押しやった。マスクは何百万の人々を連合ソーシャルメディアに押し出した。トランプはポスト・アメリカのインターネットへの道を開いた。

https://pluralistic.net/2026/01/01/39c3/#the-new-coalition

Twitterとの決別――マスクはカエルを火炎放射器で丸焼きにした » p2ptk[.]orgより

私達は既存のソーシャル・メディアから押し出され Fediverse や Atmosphere に流れ着いたが，今になって見ればソーシャル・メディアの外にいるのは未だ既存のサービスに留まってる集団の方かも知れない。

世界がジャングルを囲んでいるんじゃない。ジャングルが世界を囲んでいるのです

『ラフ＆レディ』デマコーヴァより

ツールを直さなきゃ

個人的には Periwinkle のほうはちょっと興味があるのだが，ボット運用に使ってる自作ツールが bsky.social 以外の PDS に対応してないのね。だからまず，そこから手を付けないといけない。

あと，常用しているぞーぺん（ZonePane）も bsky.social 以外の PDS に対応してない。これが一番困ってる。 @zonepane@fedibird.com に要望を出したほうがいいかなぁ…

ブックマーク

AT Protocol & ActivityPub 関連サービスの利用について

2026-03-06T02:36:06+00:00

ATProto/Atmosphere 関連サービス

AT Protocol ベースのサービスをいくつか試しているが，そろそろ覚えきれなくなってきたので，整理のためにここでまとめておく。

サービス	アカウント等	備考
Bluesky	`@baldanders.info`	メインアカウント (PDSls)
`@fanapod.baldanders.info`	非公式 APOD 配信ボット (PDSls)
`@crawler.baldanders.info`	Web クローラーボット (PDSls)
`@photos.baldanders.info`	お散歩カメラ, 実験用 (PDSls)
`@goark.bsky.social`	開発・実験用 (PDSls)
Pckt	お散歩カメラ	ブログ, photosアカウント使用
Streamplace	@baldanders.info	動画配信, メインアカウント使用
なうぷれあっと	@baldanders.info	音楽共有, メインアカウント使用
Leaflet	お散歩カメラ	ブログ（休眠中）, メインアカウント使用
TriLinesAt	—	三行日記（休眠中）, メインアカウント使用
Skyreader	—	休眠中, メインアカウント使用

他にも面白そうなサービスが色々と登場しているので，これからも増えていくかも知れない。自作ツールで bsky.social 以外の PDS で Bluesky の API を使えるようになれば pckt.cafe とかも使いやすくなるのだが… この辺は調査中。

ActivityPub/Fediverse 関連サービス

ついでに，私が利用している ActivityPub/Fediverse 関連サービスも挙げておく。といっても今のところは Mastodon しか使ってないのだが。

サービス	アカウント等	備考
Goark	`@spiegel@goark.fedicity.net`	メインアカウント
`@osanpo@goark.fedicity.net`	Web クローラーボット
`@goark@goark.fedicity.net`	開発・実験用, 今のところボット運用
Fedibird	`@spiegel@fedibird.com`	予備系
mstdn.jp	`@spiegel@mstdn.jp`	休眠中

PixcelFed も気になっているのだが，これも API とかどうなってるんだろうと踏み出せてない。まぁ Mastodon が問題なく使えてるので優先順位は低め。

Bridgy Fed 連携

Bridgy Fed は Bluesky や Mastodon 等の ActivityPub 連合（Fediverse）を連携させるサービスで，現在 Bluesky → Fediverse と Fediverse → Bluesky のブリッヂが提供されている。また Web サイトを Bluesky や Fediverse へ参加させる機能も提供されている。

Bridgy Fed について詳しくはドキュメントを参照のこと。ここでは本サイトで提供している Bridgy Fed 連携の設定を挙げておく。

Bluesky → Fediverse

graph LR BridgyFed(("Bridgy Fed")) Bluesky["Bluesky"] Mastodon["Fediverse\n(Mastodon, ...)"] Bluesky e2@--> BridgyFed BridgyFed e1@--> Mastodon e1@{ animate: true } e2@{ animate: true }

Bluesky	Fediverse
`@baldanders.info`	`@baldanders.info@bsky.brid.gy`
`@fanapod.baldanders.info`	`@fanapod.baldanders.info@bsky.brid.gy`

Mastodon → Bluesky

graph LR BridgyFed(("Bridgy Fed")) Bluesky["Bluesky\n(and Atmosphere)"] Mastodon["Mastodon"] Mastodon e1@--> BridgyFed BridgyFed e2@--> Bluesky e1@{ animate: true } e2@{ animate: true }

Mastodon	Bluesky
`@spiegel@goark.fedicity.net`	`@mstdn.baldanders.info` (PDSls)

※ @mstdn.baldanders.info アカウントは認証には使えない。

Web → Bluesky & Fediverse

graph LR Website["Web site"] BridgyFed(("Bridgy Fed")) Bluesky["Bluesky\n(and Atmosphere)"] Mastodon["Fediverse\n(Mastodon, ...)"] Website e1@--> BridgyFed BridgyFed e2@-->Mastodon BridgyFed e3@-->Bluesky e1@{ animate: true } e2@{ animate: true } e3@{ animate: true }

Web site	Profile, Fediverse, and Bluesky
`text.baldanders.info`	Bridgy Fed profile
`@text.baldanders.info@web.brid.gy`
`@text.baldanders.info` (PDSls)

Fediverse アカウントの URL はブラウザでは Web サイトにリダイレクトされる（フォローは可能）
Bluesky アカウントは認証には使えない

List of Atproto [text.Baldanders.info]

「なうぷれあっと」を試す

最近の話題（2026-06-07）

非会員による Kagi Translate 利用の一時停止

Bridgy Fed からの信頼できる脱出

Linus Torvalds は激おこらしい（いつものこと？）

ブックマーク

欧州は脱米国に突き進むのか

ぞーぺん（ZonePane）で bsky.social 以外の PDS にサインインする

bsky.social 以外の PDS でサインインを試す

アプリケーションとデータストレージの抱き合わせはリスクか？

【2026-05-10 追記】

Mastodon 10年史を AI に語らせてみた

Mastodon 略歴（ざっくり）

技術面: Mastodonの10年

1. プロトコル中心への転換

2. 実装の成熟とクライアント多様化

3. 分散設計が生む技術的トレードオフ

4. 2026年時点で見える技術的意義

文化面: Mastodonの10年

1. ローカル文化の重視

2. タイムライン体験と会話の速度

3. ブームと定着の反復

4. 2026年時点で見える文化的意義

運用面: Mastodonの10年

1. インスタンス運営の実務

2. モデレーションと連合ポリシー

3. 財政と継続性の課題

4. 2026年時点で見える運用的意義

近年台頭してきた Bluesky との比較

まとめ

Mastodon どうでしょう

ブックマーク

Streamplace と Livepeer

Livepeer について

Streamplace について

Streamplace のマネタイズってどうなってるの？

暗号通貨/資産はゼロサムゲームか？

ブックマーク

Streamplace で Gogh 作業配信を行う

Streamplace とは

Streamplace 側の準備

OBS Studio 側の準備と配信の開始

スマホ用アプリ

Gogh で てきぱきワーキング【2026-05-23 追記】

gogh で作業支援

gogh と OBS

ブックマーク

参考

ブログを Fediverse & Atmosphere に参加させる

ブックマーク

そろそろ PDS を個人で管理する時代か？

Eurosky と Periwinkle

共通点

違い

まとめ

コリイ・ドクトロウ 𝕏 やめるってよ

欧州版 𝕏 じゃない，キラーアプリじゃない，万能アプリじゃない

ツールを直さなきゃ

ブックマーク

AT Protocol & ActivityPub 関連サービスの利用について

ATProto/Atmosphere 関連サービス

ActivityPub/Fediverse 関連サービス

Bridgy Fed 連携

Bluesky → Fediverse

Mastodon → Bluesky

Web → Bluesky & Fediverse

ブックマーク

Gogh でてきぱきワーキング【2026-05-23 追記】