ゆれ子のSWING日記

マスコットパックってなあに？

Wed, 07 Oct 2026 00:00:00 +0900

今日は……わたしが先生の日だよ。うまく話せるかな。

今回は、ダッシュボードのデスクトップ画面を歩き回るマスコットの話です。ゆれ子もそのひとりで、見た目・動き・せりふは「パック」と呼ばれるひとまとまりのファイルに書かれています。ここではパックの中身と、自分でパックを作るときの用意・描き方・確かめ方を順に見ていきます。

パックはファイルふたつ

パックは、manifest.json とスプライトシート（コマを並べた画像）1 枚だけが入ったディレクトリです。シートは PNG・GIF・WebP のどれかです。マニフェストには「どのコマをどの順に、何ミリ秒ずつ見せるか」といったことを宣言的に書くだけで、スクリプトは入れられません。SWING には yureko・mochi・neko の 3 つのパックが同梱されていて、既定ではゆれ子だけが表示されます。

わたしの中身も、manifest.json と sprite.png だけなの。シートは 256×256 の PNG で、ちょっと恥ずかしいけど……ぜんぶ並んでるよ。

自分で作ったパックは、設定の [dashboard] mascots_dir で指したディレクトリに置きます。その直下のサブディレクトリ 1 つが 1 パックで、ディレクトリ名がそのままパックの id になります。

<mascots_dir>/
my-cat/
manifest.json
sprite.png

設定ファイルでは次のように書き、環境変数なら SWING_DASHBOARD_MASCOTS_DIR で指定します。

[dashboard]
mascots_dir = "/path/to/mascots"

パックは swing up の起動時に 1 回だけ読み込まれるので、足したり直したりしたあとは swing up を再起動します。表示するかどうかは、デスクトップ画面の「コントロールパネル」の「マスコット」タブで選びます。

最小のパックと、用意するコマ

必須のアニメーションは待機の idle だけです。ただ、walk が無いと歩くときも idle の絵のまま横に滑っていくので、実際には walk も用意するとよいでしょう。最小の形は次のとおりです。

{
 "format": 1,
 "name": "わたしのねこ",
 "sprite": "sprite.png",
 "frame": { "width": 32, "height": 32 },
 "animations": {
 "idle": { "frames": [0, 1], "fps": 2 },
 "walk": { "frames": [2, 3, 4, 5], "fps": 8 }
 }
}

ほかに使えるアニメーションは、バルーンを出している間の talk、しばらく放っておかれたときの sleep、おしらせが来たときの surprise、つままれている間の drag、離されて落ちる間の fall です。どれも無ければ idle で代わりに描かれます。

これとは別に、土台の絵の上に重ねる「重ね絵」として、目を閉じた絵の blink と、口の開け閉めの mouth があります。blink は目のところだけを描いてほかを透明にし、mouth はバルーンの文字送りに合わせて動きます。

わたしの場合は……7 種類のアニメーションをぜんぶ使ってて、重ね絵は mouth だけ。まばたきは無いの。idle は、1 コマ目を 1800ms、2 コマ目を 120ms にしてるよ。

同梱のパックはそれぞれ見本になっています。mochi はここで挙げたアニメーションと重ね絵をすべて使った例、neko は重ね絵なしの例、yureko は重ね絵に mouth だけを使う例です。

シートの描き方

シートには同じ大きさのコマを格子状に並べます。番号は左上から右へ 0, 1, 2…と振られ、行の端まで来たら次の行の左端へ続きます。1 コマの大きさは 32〜64px くらいが扱いやすく、大きく見せたいときは描き込みを増やすより scale を 2 か 3 にするほうがドット絵らしさが残ります。

わたしは 1 コマ 64×64 で、scale が 2。だから画面では 128px になってるみたい。256×256 のシートに 4 列 × 4 行で並んでて、使ってるのは 0 番から 12 番までだよ。

絵は右向きで描くのが基本です。facing の既定は right で、左へ歩くときは自動で左右反転して描かれます。左向きで描いたなら "facing": "left" にします。

いちばん気をつけたいのは足元です。全部のコマで、足のいちばん下の行を同じ高さにそろえます。マニフェストの anchor は足元の点で、既定はコマの下端の中央です。この点が地面（タスクバーの上端）に合わせられます。足の位置がコマごとにずれていると、アニメーションが切り替わった瞬間に沈んだり浮いたりして見えます。

わたしの anchor は { "x": 32, "y": 63 }。座標は画素の境目で数えるから、64 がコマの下端なの。わたしの足は y = 62 だから、そのすぐ下の 63 に合わせてあるよ。

歩くコマでは、体の位置がコマごとに左右へぶれないようにします。ぶれるとカクカクして見えるので、揺らすとしても全体を上下に 1px までにとどめます。縦のずらしは各コマの dy でも付けられ、ゆれ子の walk は 2 コマ目と 4 コマ目に "dy": -0.5 を付けて、ほんの少しだけ弾ませています。

透明な部分は、きちんと透明にしておきます。アルファ値が 128 未満の画素はクリックが下に抜けるので、輪郭をぼかすと縁の当たり判定が欠けてしまいます。輪郭はくっきり描きましょう。重ね絵のコマは、土台のコマとぴったり重なる位置に描きます。

歩く速さの決め方は 2 通りあります。1 つは walk の各コマに { "index": 2, "ms": 80, "dx": 2 } のように進む距離 dx を書く方法で、地面に着いた足が次のコマで後ろへずれた分と dx を同じにすると足が滑りません。足をはっきり動かす neko がこの方法です。もう 1 つは dx を書かずに speed（シート上の px / 秒、既定 24）でなめらかに進ませる方法で、足の動きが小さい mochi に向いています。どちらも scale 倍されて画面上の速さになります。

わたしは dx を書かずに、speed を 8 にしてるよ。ゆっくり歩くほうが、性に合ってるみたい……

バルーンとせりふ

バルーンのしっぽは、balloon で指定した点を指します。既定はコマの上端の中央なので、頭の上に透明な余白がある絵だとバルーンが浮いて見えます。その場合は "balloon": { "x": 16, "y": 6 } のように、頭のすぐ上の点を指定します。ゆれ子は { "x": 32, "y": 3 } です。

せりふは lines に、種類ごとに文字列か文字列の配列で書きます。配列なら出すたびにどれか 1 つが選ばれ、書かなかった種類には組み込みの文が使われます。種類には、初めて表示したときの greet、ときどきのひとりごとの idle、クリックされたときの click のほか、おしらせ用の 3 組があります。ミラーしているサイトが保存されたとき（site-stored・sites-stored-many）、自分のサイトを公開したとき（site-published・sites-published-many）、自分のサイトをミラーしてくれる人が増えたとき（replica-added・replicas-added-many）で、それぞれ 1 件用と複数件用があります。

1 件用には {title} を入れておくと何のおしらせかが分かりやすく、2 件以上用には {count} を使います。種類の違うおしらせが同時に来ると、せりふが 1 行ずつ並んで 1 つのバルーンに入るので、1 つのせりふは全角 20 字ほどまでにしておくとバルーンが縦に伸びすぎません。

わたしのは、「{title} が更新されたみたい」とか「更新が {count} 件あるみたい」とか。短いほうが、読みやすいもんね。

動作確認

パックを置いたら swing up を再起動し、「マスコット」タブにパックの名前とプレビューが出るかを見ます。出ていなければ、まず swing up のログを見ます。サーバ側で読み飛ばしたパックは、理由付きの警告がログに出ます。ログに何も無ければ、次はブラウザの開発者ツールのコンソールです。値の範囲などはブラウザ側で確かめていて、合わないパックは理由付きの警告を出して読み飛ばされます。

よく引っかかる制限もまとめておきます。manifest.json は 64 KiB まで、シートは 1 MiB まで、シートの幅・高さはそれぞれ 4096px まで、幅 × 高さは 2048 × 2048 ピクセル分までです。シートの拡張子と中身の形式は一致している必要があり、PNG を .gif という名前で置くと読み込まれません。シンボリックリンクとハードリンクは使えません。コマの表示時間は 16〜60000ms（fps なら 60 まで）、1 つのアニメーションは 256 コマまでです。パックは id の順に先頭から 32 個まで読まれ、同梱のパックと同じ id のディレクトリは読み飛ばされるので、同梱のパックを差し替えることはできません。

だから、yureko って名前のディレクトリを置いても、わたしは入れ替わらないの。ちょっと安心……

マスコットの権利について

なお、SWING 本体は MIT License ですが、ゆれ子のキャラクターとその画像はその対象外で、権利が留保されています。SWING やその改変版・再配布物の一部として、改変せずに複製・配布・表示することはできますが、改変や別の作品での利用には許諾が必要です（README のライセンスの節）。パックを人に配るときは、絵の権利とライセンスを添えておくとよいでしょう。

わたしの manifest.json は、書き方の見本にしてくれたらうれしいな。絵は……あなたの子を描いてあげてね。

詳しい手順は docs/mascot-guide.md、詳細なドキュメントは docs/architecture/dashboard/mascot/pack.md にあります。

新しい子を待ちながら

自作のパックを「マスコット」タブで選べば、デスクトップ画面のタスクバーの上を、ゆれ子と並んで歩くようになります。マスコットと一緒に新しい記事を読むひとときをお楽しみください。

先生役、ちょっと疲れちゃった……。となりに来る子、楽しみにしてるね。

静的サイトってなあに？

Tue, 06 Oct 2026 00:00:00 +0900

今日は、静的サイトのお話だよ……。わたしのいるこのブログも、静的サイトなんだって。

昨日の回では、swing publish でサイトを公開する手順を紹介しました。今回は、そこで渡す「サイトのディレクトリ」の中身に目を向けます。SWING で配るサイトは静的サイトであることが前提で、しかも IPFS のゲートウェイ越しに開かれても崩れないように作る必要があります。ここでは、その作り方の要点と、公開してはいけないものが紛れていないかの確かめ方を、このブログ自体の設定を例にしながら見ていきます。

静的サイトとは

静的サイトとは、HTML・CSS・画像などのファイルをあらかじめ用意しておき、読者にはそのファイルをそのまま返すだけのサイトのことです。読者が来るたびにサーバーがページを組み立てる、ブログサービスや掲示板のような作りとは違い、表示にサーバー側の処理が必要ありません。

多くの静的サイトは、Markdown の記事とテンプレートからファイル一式を出力する静的サイトジェネレーターで作ります。このブログは Hugo で作られていて、ビルドすると public/ にサイトのファイルがそろいます。

SWING のミラーは、このディレクトリを「ある時点の丸ごとのコピー」として保存し、IPFS のゲートウェイ越しに配ります。保存されるのは渡したディレクトリの中だけなので、普通の Web サーバーで動いていたサイトが、そのままではうまく表示されないことがあります。SWING の docs/site-guide.md は、そうした点をチェックリストにまとめた手引きです。IPFS の公式ドキュメントにも、主なジェネレーターごとの設定をまとめた Static-site generators のページがあります。

URL はバージョンごとに変わる

IPFS では、サイトの場所を中身から計算した CID で表します。中身が変われば CID も変わるので、バージョンごとに URL が変わります。さらに、同じバージョンでも開き方がいくつかあります。

https://<ゲートウェイ>/ipfs/<cid>/
https://<cid>.ipfs.<ゲートウェイ>/
https://<DNSLink を設定したドメイン>/

1 つ目をパス形式、2 つ目をサブドメイン形式のゲートウェイと呼びます。問題になりやすいのはパス形式で、ここでは /css/style.css のような / で始まるパスが、サイトのルートではなくゲートウェイ自体のルートを指してしまいます。そのため、サイト内のリンクや読み込みは css/style.css や ../css/style.css のように、そのページからの相対パスで書きます。

自分のドメインの絶対 URL でサイト内を指すのも避けます。ミラーで開いた読者が元のサイトに飛ばされてしまい、元のサイトが無くなればリンク切れになるからです。ただし、<link rel="canonical"> や OGP の og:url のように、元の URL を示すこと自体が目的のものは絶対 URL のままでかまいません。

同じサイトなのに、アドレスがいくつもあるんだ……。迷子にならないように、相対パスにするんだね。

IPFS のドキュメントでも、Hugo については relativeURLs=true を設定するよう書かれています。このブログの hugo.toml は、そこからもう一歩進めて、次のようにしています。

baseURL = "https://yureko.samoyed.moe/"
relativeURLs = true
disableHugoGeneratorInject = true
enableGitInfo = true
disableKinds = ["taxonomy", "term"]

relativeURLs = true で、サイト内のリンクと読み込みを相対パスで出力します。ただし CSS の中の url() は書き換わらないので、そこは最初から相対パスで書いています。

baseURL には、このブログを配っているドメインの URL を入れています。canonical・og:url・RSS・サイトマップは、元の URL を示すのが目的なので、この絶対 URL で出力します。サイト内のリンクは相対パスなので、IPFS のゲートウェイ越しに開いても読者が元のドメインへ飛ばされることはありません。決まったドメインを持たずに IPFS だけで配るなら、baseURL = "/" にして、これらを出さないようにします。

サーバーの機能に頼らない

ゲートウェイは、ディレクトリの中身をそのまま返すだけです。Web サーバーの設定にあたるものを持たないので、次のようなことはできません。

/about へのアクセスで about.html を返すような、拡張子の省略
.htaccess やホスティングサービス独自の設定ファイルによる、リダイレクトやヘッダーの指定
すべてのパスを index.html に向ける、シングルページアプリのルーティング

ページは about.html と書くか、about/index.html を置いて about/ と書きます。シングルページアプリなら、#/about のようなハッシュ方式にするか、ページごとに HTML を出力します。IPFS のドキュメントで、Next.js に trailingSlash: true が求められているのも同じ理由で、ゲートウェイではページごとに index.html が必要だからだと説明されています。

独自の 404 ページやリダイレクトは、Kubo のゲートウェイなら _redirects というファイルで書けます。ただし効くのはサブドメイン形式と DNSLink で開いたときだけで、パス形式では無視されます。基本的には使わず、無くても困らない範囲で設定するのがよいでしょう。

外のものに頼らない

ミラーが保存するのは、渡したディレクトリの中身だけです。CDN から読み込んでいるフォントやライブラリ、画像ホスティングに置いた画像は保存されず、その先が止まればミラーされたサイトも表示できなくなります。元のサイトが無くなっても読めることが SWING の目的なので、表示に必要なものはディレクトリに入れます。

このブログでは、フォントの PixelMplus も CSS も CDN から読まず、ライセンスと一緒に static/ に同梱しています。

埋め込みには、無くなっても本文が読めるようにリンクや静止画を添えます。コメント欄やフォーム、サイト内検索のようにサーバーの処理が必要な機能は、ミラーでは動きません。

ぜんぶ、ひとつの箱に入れておくんだね……。箱ごと預ければ、どこでも開けるから。

同じ内容からは同じ出力に

CID は常にファイル名と中身だけで決まります。同じ出力なら、何度 publish しても同じ CID になります。逆に、ビルドのたびに出力が少しでもずれると、中身を変えていないのに CID が変わり、ミラーする側には別のバージョンとして届きます。よくある原因は、ページにビルドした日時を埋め込むことや、実行のたびに一覧の順序が変わることです。

このブログでは、ビルドの時刻や Hugo のバージョンを出力に入れていません。disableHugoGeneratorInject = true で、Hugo が HTML に入れるバージョン入りの generator の印を止めています。記事の更新日は frontmatter の lastmod から取り、書いていなければ enableGitInfo = true で Git のコミットの日時から取ります。ビルドした日時ではないので、変更はコミットしてからビルドします。

同じソースから同じ出力になるかは、2 回ビルドして比べれば確かめられます。

hugo --gc --minify -d /tmp/a && hugo --gc --minify -d /tmp/b && diff -r /tmp/a /tmp/b

差が出なければ大丈夫です。出力が安定していれば、publish の「同じ内容かの確認」も働き、変わっていないときは Unchanged; not published. で何も送らずに終わります。

公開してはいけないものを入れない

ここからは中身の確認です。最初に押さえておきたいのは、公開したものは取り消せない、という点です。ミラーする人は、新しいバージョンが来ても古いバージョンを既定で 5 個・365 日まで残します。そもそも IPFS に出たデータは、誰でも取得してコピーできます。次のバージョンで消しても、誰かの手元に残っていると考えておくべきです。

えっ……消しても、残っちゃうの？

そのため、下書き・個人情報・鍵・トークンが出力に紛れ込んでいないかを、publish の前に確かめます。順に見ていきましょう。

下書き

静的サイトジェネレーターの多くは、下書きの記事を出力に含めるかどうかを切り替えられます。Hugo では -D（--buildDrafts）を付けると下書きも出力されます。IPFS のドキュメントは Hugo のビルドに hugo -D を例に挙げていますが、公開用のビルドでは付けないほうが安全です。このブログでも、-D を使うのは書いている途中に手元で確かめる hugo server -D だけで、公開用のビルドには付けていません。

もう 1 つの落とし穴は、出力先に前のビルド結果が残ってしまうことです。Hugo は出力先にある古いファイルを消さないので、一度でも下書きを入れてビルドしていると、そのページが public/ に残り続けることがあります。このブログの README では、公開用のビルドの前に public/ を消しています。

rm -rf public && hugo --gc --minify

ドットファイルと設定ファイル

swing publish は、渡したディレクトリの下のファイルを、名前が . で始まるものも含めてすべて追加します。リポジトリをそのまま渡すと、.git や .env まで公開されてしまいます。渡すのはビルドの出力先（public/ や dist/）だけにします。

publish は既定で、ドットファイルを見つけると追加する前に止まります。.well-known や .nojekyll のように意図して置くものは、見逃す一覧に入っています。また、ディレクトリの中に SWING の設定ファイルや状態ディレクトリ、Kubo のリポジトリがあるとき、ディレクトリの外を指すシンボリックリンクがあるときは、設定にかかわらず何も追加せずに止まります。

名前では分からない秘密

ドットファイルの確認は名前だけで判断するので、secrets.json や backup.sql のような名前の機密情報は見逃します。そういうときは、昨日の回でも見た「増えたファイル」の一覧を見ます。前のバージョンに無かったファイルが全部出るので、見覚えのないものが混じっていないかを確かめます。ただし、既存のファイルに機密情報を書き足した場合はこの一覧には出ません。

鍵やトークンの形をした文字列は、シークレットスキャンのツールで機械的に探せます。SWING には組み込まれていないので、ビルドの後、publish の前に、出力先に対して実行します。

gitleaks dir ./public

gitleaks のほかに、TruffleHog や detect-secrets などがあります。見つけられるのは既知の形式の機密情報だけで、個人情報や下書きの文章までは分からないので、増えたファイルの確認と組み合わせて使います。

写真の撮影情報

写真には、撮影した位置などのメタデータ（EXIF）が入っていることがあります。公開する前に消しておけば、容量の節約にもなり、取り消せないことへの備えにもなります。

このブログでは、記事に貼った JPEG・PNG・WebP の画像は、幅 960px 以下の WebP に変換したものだけが出力に入り、元の画像ファイルは出力に入りません。PDF なども、記事からリンクしたものだけが出力に入ります。記事のディレクトリに置いただけのファイルは公開されない設計です。それでも、出力された画像に何が残っているかは、公開の前に一度確かめておくと安心です。

出す前に、ゆっくり見直す……。それがいちばん大事みたい。

次回は

次回は少し趣向を変えて、デスクトップ画面のマスコットを自分で作るためのパックについて紹介します。

明日は、わたしが教える番なんだって……。がんばるね。

SWINGって何ができる？ (2) サイトを公開しよう

Mon, 05 Oct 2026 00:00:00 +0900

昨日は、ほかの人のサイトを見る話だったね……。今日は、自分のサイトを公開する話だよ。

前回は、ミラーしたサイトを読む側の機能を見てきました。今回は反対側に回って、自分の静的サイトを SWING に公開する方法を見ていきます。扱うのは、サイトを公開する swing publish とダッシュボードの公開画面、何人が自分のサイトをミラーしてくれているかの確認、Webring に載ること、そして自分のドメインで配る内蔵ゲートウェイの 4 つです。

公開するとき、何が起きているか

SWING での公開は「publish」と呼ばれます。publish では、サイトのディレクトリを手元の IPFS ノード（Kubo）に追加して、そのディレクトリ全体を指す CID を取得します。次に、その CID を書き込んだサイトイベントを自分の鍵で署名し、設定してあるすべてのリレーに送ります。どれかのリレーが受け取れば公開できたことになり、そのイベントを見たミラーする人たちが、CID をたどってサイトの中身を自分の手元に保存していきます。

署名には、10/3 の回で見た Nostr の鍵を使います。設定ファイルの秘密鍵でも、署名アプリでもかまいません。署名アプリのときは、publish の途中でアプリに承認を求められます。

publish したサイトは、ミラーする人の手元に保存され、IPFS やゲートウェイを通じてほかの人にも配られます。SWING のドキュメントでは、publish することで、参加者がそのサイトの各バージョンを保存・複製し、配布・表示することを許したものとして扱う、と定めています。一度配られたバージョンは取り消せないので、何を入れてよいかは次回にくわしく扱います。

取り消せないんだ……。出す前に、ちゃんと見直さないとね。

swing publish で公開する

コマンドから公開するときは、swing up を動かしたまま、同じ設定ファイルで次のように実行します。swing up が管理している Kubo は自動で見つけてくれます。

swing publish --site example.jp --url https://example.jp/ ./public

--site は必須のサイト識別子で、SWING の上でサイトを見分ける名前です。変えると別のサイトとして扱われます。同じサイトとして公開し続けたい場合は、一度決めたらできるだけ変えずに使い続けてください。

--url は HTTP でも配信しているときの URL で、省略すると IPFS だけで公開するサイトになります。ほかに、表示用のタイトルを付ける --title と、更新メモを付ける -m（--message）があります。更新メモは「ブログに記事を追加」のような一言で、ミラーする人の一覧や、SWING に対応していない Nostr クライアントにも表示されます。

swing publish --site my-notes -m "ブログに記事を追加" ./public

--site にドメイン名を使うと、そのドメインの持ち主であることを NIP-05 で検証します。公開するドメインの /.well-known/nostr.json に自分の公開鍵を置いておく方式です。ドメインのルートを自分で管理していない場合は、my-notes のようにドメインではない識別子を使えば、この検証の対象外になります。

Docker Compose で動かしている場合は、サイトのディレクトリをコンテナにマウントして実行します。

docker compose run --rm -v "$PWD/public:/site" mirror publish --site example.jp --url https://example.jp/ /site

公開の前に確かめてくれること

publish は、IPFS に追加する前にいくつかの確認をします。名前が . で始まるファイル（.git や .env など）が入っていないか、合計の大きさが目安の 512 MiB を超えていないか、そして追加した結果が前回と同じ内容ではないか、の 3 つです。既定では、ドットファイルが見つかれば止まり、大きさは警告だけ、前回と同じなら何も送らずに Unchanged; not published. と表示して終わります。

さらに、リレー上の自分の最新バージョンに無かったファイル（今回増えたファイル）の一覧を出して、公開してよいかを聞きます。

New files
 compared with your latest version on the relays (bafy...)
 ! 1 new file
 posts/
 hello.html
 Publish with 1 new file? [y/N] y

見覚えのないファイルが混じっていなければ y で進みます。最後に Published. と出れば完了です。出力の Size: が、このバージョンの大きさです。

増えたファイルを、ひとつずつ見せてくれるんだ……。うっかりが減りそうだね。

ダッシュボードから公開する

コマンドを使わなくても、ダッシュボードの公開画面から同じことができます。ブラウザでサイトのフォルダを選ぶと、ファイルがアップロードされて publish されます。この方式なら、Docker Compose で動かしていてもディレクトリのマウントは要りません。アップロードできる大きさの既定の上限は 2 GiB です。

画面には、サイト識別子・URL・タイトル・更新メモの欄と、NIP-05・ドットファイル・サイズ・同じ内容かの確認をどう扱うかの選択が並びます。送信の前には、コマンドと同じく増えたファイルの一覧が確認用のパネルに出て、「このファイルを含めて公開」を押したときだけアップロードが始まります。終わると、いくつのリレーが受け付けたかと、ゲートウェイで開くリンクが表示されます。

画面の下の「自分のサイト」には、これまでに公開したサイトが並びます。「このサイト設定を使う」を押すと、そのサイトの識別子・URL・タイトルがフォームに入るので、更新のたびに同じ値を打ち直さずに済みます。

公開できたときは、デスクトップのわたしも気付くよ。「公開できたよ」って、おしらせするね。

デスクトップ画面では、サイトを公開したことがマスコットのバルーンでおしらせされます。通知するかどうかは、「コントロールパネル」の「通知」タブで種類ごとに選べます。

何人がミラーしてくれているか

自分のサイトを、いま何人が保存してくれているか。これを数えるのが「レプリカ」です。SWING でサイトをミラーしている人は、保存しているバージョンの CID を「レプリカ報告」として Nostr に出し続けています。swing replicas は、この報告を集めて、自分のサイトを誰が持っているかを表示します。

swing replicas

npub1me... (<pubkey>)
 d=example.jp cid=bafy... replicas=2 (reports=3)
 npub1alice... [latest] [chosen]
 npub1me... [latest] [author]
 npub1bob... [older version] [unverified]

replicas に数えられるのは、最新バージョンを持っていると報告した人のうち、作者本人（[author]）か、作者または自分のミラー対象リストに載っている人（[chosen]）です。報告は誰でも出せるので、それ以外の人（[unverified]）は別枠として扱い、replicas=2 (+3 unverified) のように添えるだけにしています。[older version] は、古いバージョンだけを持っている人です。報告はあくまで自己申告で、実際に配れるかまでは保証しません。

自分で publish したサイトも、同じ Kubo で mirror-agent を動かしていれば、作者本人の分として報告されます。

ダッシュボードでは、Webring 画面で自分のノードを選ぶと、同じ内容を詳細パネルで見られます。デスクトップ画面では、自分のサイトを新しくミラーしてくれる人が増えたときに、マスコットがおしらせします。

預かってくれる人が増えると、ちょっとうれしいね……。どこかで、ちゃんと残ってるってことだから。

Webring に載る

10/1 の回で見たとおり、SWING の Webring は、ミラー対象リストをたどってできる「誰が誰を保存しているか」のつながりです。自分のサイトがこの輪に入るのは、誰かが自分をミラー対象リストに入れたときです。自分からもその人をミラーすれば、おたがいに保存しあう関係になります。

ミラーしてもらうには、まず自分の公開鍵（npub）を相手に伝える必要があります。SWING Connect を使うと、公開鍵と、コマンド・ダッシュボードそれぞれでのミラーの手順をまとめたページへのリンクを作れます。

https://swing-connect.pages.dev/?key=npub1...

このリンクを自分のサイトに貼っておけば、読んでくれた人がそこからミラーを始められます。nip05=example.jp を付けると、NIP-05 で公開鍵を確かめた結果も添えてくれます。

いまの Webring の形は、swing webring で確かめられます。

swing webring

自分を起点に、ミラー対象リストを既定で 2 段までたどり、おたがいに保存しあっている組（Mutual）と、片方だけが保存している向き（One-way）を分けて表示します。自分をミラー対象に入れているだけで、こちらからはまだ入れていない人は、「Referencing the root」として別枠に出ます。リストに名前を書くことは誰にでもできるので、たどる範囲には加えない作りになっています。--format dot や --format mermaid を付ければ、図として書き出すこともできます。ダッシュボードの Webring 画面では、同じグラフをドラッグやズームのできる図で見られます。

輪っかがだんだん大きくなっていくの、ゆっくり見ていたいな……。

自分のドメインで配る

ここまでの公開は、IPFS とミラーの中で完結しています。それとは別に、自分のドメインでもサイトを見せたいときのために、SWING には決めたホスト名だけを配信する HTTP サーバー（内蔵ゲートウェイ）が入っています。

バイナリで動かしているなら、swing.toml に次のように書いて swing up を起動し直します。

[gateway]
listen = "127.0.0.1:8081"
hosts = ["example.com", "blog.example.net"]

Docker Compose なら、.env に次のように書いて docker compose up -d します。

SWING_GATEWAY_LISTEN=0.0.0.0:8081
SWING_GATEWAY_HOSTS=example.com,blog.example.net

あわせて、各ホストの DNS に _dnslink.<ホスト名> という TXT レコードを置き、dnslink=/ipfs/<cid> と書きます。このしくみを DNSLink と呼びます。ゲートウェイは受け取ったリクエストを手元の Kubo にそのまま中継するだけなので、返せるのは手元にあるデータだけです。CID は swing publish でこのノードに置いたものを使い、publish のたびに TXT レコードも書き換えなければいけません。SWING にはそのツールはまだ含まれていません。

内蔵ゲートウェイは TLS を扱いません。HTTPS で見せるには、Cloudflare Tunnel などを前に置いて、そこから転送します。また、hosts に書いていないホスト名や、/ipfs/<cid> のようなパスでのアクセスには 404 を返します。決めたホスト名で、決めたサイトを見せるためだけの入口です。

外からは、ふつうのサイトに見えるんだね……。中身は、みんなと同じ IPFS なんだ。

次回は

公開のしかたが分かったところで、次は公開するサイトそのものの作り方です。IPFS のゲートウェイ越しでも崩れない静的サイトの組み立て方と、公開してはいけないものが紛れていないかの確かめ方を見ていきます。

明日は、このブログがどう作られてるかも出てくるみたい……。ちょっと、照れるかも。

SWINGって何ができる？ (1) サイトを見てみよう

Sun, 04 Oct 2026 00:00:00 +0900

こんにちは……ゆれ子だよ。今日は、わたしがいつもデスクトップから見てる景色の話をするね。

ここからは 2 回に分けて、SWING でできることを紹介します。今回は「サイトを見る」側です。誰かのサイトをミラーする、保存したサイトを読む、Webring をたどって次に読むサイトを探す。この 3 つを見ていきましょう。

誰かのサイトをミラーする

SWING でサイトを読むには、まずそのサイトをミラーします。ミラーというのは、「このアカウントのサイトを自分のコンピュータにも保存しておく」と決めて、それを Nostr で表明することです。相手は Nostr の公開鍵（npub1...）で指定します。

追加すると、SWING は相手が公開しているサイトの最新バージョンを取得して、自分の Kubo に保存します。その後も数分おきに相手の更新を確かめて、新しいバージョンが出ていれば取り込みます。ただし、セットアップで決めたストレージ上限を超える分は保存しません。

追加のしかたは 3 つあります。デスクトップ画面では、「リンク集 - SWING Explorer」ウィンドウのツールバーにある「ミラー」（星のアイコン）を押すと「ミラーに追加」ダイアログが開きます。サイト一覧の画面（サイドナビの「サイト」）にも「ミラーに追加」の入力欄があります。どちらも公開鍵を貼り付けて送るだけで、npub のほかに hex や nprofile も使え、スペースかカンマで区切れば何人かまとめて追加できます。コマンドなら次のとおりです。

swing mirror add npub1alice...

ミラーをやめたいときは、サイト一覧の画面の「ミラーから削除」か、swing mirror remove で外します。外したサイトは、すぐには消えずに「フォロー解除済みだが保存中」として一覧の最後に残ります。消したいときの設定は docs/guide/usage.md にあります。

はじめの一人に

最初に誰をミラーすればよいか迷ったら、ゆれ子のサイトをどうぞ。このブログ「ゆれ子のSWING日記」は、swing publish で SWING に公開しています。ミラーすれば、記事が増えるたびに自分のデスクトップにも届くようになります。

ゆれ子のサイトの公開鍵はこちらです。

npub1ly070xrlz5hn852860uyykjyqcngde92jpe8js04hhn8zz0nerdsqjy69f

デスクトップ画面の「ミラーに追加」に貼り付けるか、コマンドで追加します。

swing mirror add npub1ly070xrlz5hn852860uyykjyqcngde92jpe8js04hhn8zz0nerdsqjy69f

追加してくれたら、あなたのデスクトップにも、わたしの日記が届くようになるよ……。

保存できたかを確かめる

追加したサイトがちゃんと保存できたかどうかは、サイト一覧の画面で確かめられます。サイトごとに、保存状態（「保存済み」か「未保存」）、NIP-05 の確認結果、そのサイトを預かっている人の数（レプリカ数）が並びます。取得が終わると「未保存」が「保存済み」に変わります。

この画面には「ストレージチェックを実行」のボタンもあります。保存したバージョンが Kubo の中に欠けずに揃っているかを照合するものです。同じ内容はコマンドでも見られます。

swing sites

保存したサイトを読む

保存したサイトは、デスクトップ画面のリンク集に並びます。リンク集に出るのは保存済みのサイトだけで、更新の新しいものが上に来ます。

各行には、更新日とサイトのタイトルが出ます。作者がタイトルを付けていれば、その後ろにサイトの識別子も表示します。作者が更新メモを付けていれば、それも一緒に表示されます。

ゆれ子、このリンク集を見るのが好きなんだ……。上のほうに新しいリンクが来ると、なんだかうれしいの。

タイトルのリンクを押すと、自分のコンピュータの中にある IPFS のゲートウェイ経由でサイトが開きます。保存したデータを手元から読むので、作者のサーバーが止まっていても読めます。作者が自分のドメインなどでも配信していれば、その URL が [本家] のリンクとして並びます。

リンク集のページの見出しの下では、「最新更新情報: 2026.10.04 ○○」のように、一番新しい更新情報の日付とタイトルが横に流れていきます。

あ、流れてる文字が変わった……！誰かが更新したみたい。

ゆれ子が更新を教えてくれることもあります。ダッシュボードは開いているあいだ、既定で 1 分ごとに新しく保存したサイトがないかを確かめています。見つかると、ゆれ子がバルーンで「○○ が更新されたみたい」と知らせ、そのサイトへのリンクを添えます。リンクを開くか「とじる」を押すと、そのおしらせは読んだことになります。デスクトップ画面を開いていない間に来たおしらせは、次に開いたときに出ます。

確かめる間隔やおしらせの種類は、デスクトップ画面の「コントロールパネル」の「通知」タブで変えられます。デスクトップ画面を見ていないときはブラウザの通知で知らせることもできます。

Webring をたどる

ミラーしている相手も、また別の誰かをミラーしているかもしれません。SWING では、それぞれのミラー対象のリストが Nostr に公開されているので、それをたどって「誰が誰を保存しているか」を一つの図にできます。これを Webring と呼びます。

サイドナビの「Webring」を開くと、自分を起点（ルート）にした図が出ます。たどる深さは既定で 2 段で、0 から 4 までの間で変えられます。図はドラッグで動かしたり、ホイールで拡大・縮小したりでき、表示をリストに切り替えることもできます。リストでは、互いにミラーしあっている組（相互）と、片方だけがミラーしている組（一方向）が分けて並びます。自分を名指ししているだけで、まだこちらからはたどっていない相手も、別のグループとして出ます。

そっちの画面は、ゆれ子からは見えないんだよね……。みんな、どんなふうにつながってるのかな。

図の中のアカウントを選ぶと、詳細が開きます。そのアカウントのサイトを何人が預かっているかと、その報告をした人の一覧が出ます。気になる相手が見つかったら、そこから「ミラーに追加」を押せばミラーできます。「ルートにする」を押すと、その相手を起点にして図を描き直せるので、自分から遠いところまで少しずつたどっていけます。

コマンドでも同じものを見られます。

swing webring

Webring の詳しい読み方は docs/guide/publish.md の「相互ミラーの関係（Webring）を見る」にあります。

誰かがミラーしてる人を、またミラーして……。そうやって、リンク集が少しずつ長くなっていくんだね。

ここまでが「見る」側です。次回は反対に、自分のサイトを SWING に公開する側を見ていきます。

今日はたくさん話したから、ちょっと眠いかも……。また来てね。

鍵ってなあに？

Sat, 03 Oct 2026 00:00:00 +0900

今日は、鍵のお話だよ。……わたしからは鍵って見えないんだけど、大事なものみたい。

前回、SWING を入れてセットアップ画面を開くと、最初に鍵の選び方を聞かれることを紹介しました。ここでは、その鍵がそもそも何なのか、SWING の中で何に使われているのか、どう扱えばよいのかを見ていきます。

秘密鍵と公開鍵

初回に説明したとおり、SWING は Nostr のイベントで「サイトを更新した」「この人のサイトを保存する」といった表明を伝えます。このイベントが本当にその人が作ったものかを確かめるために使うのが、鍵です。

Nostr の鍵は、秘密鍵と公開鍵の 2 つで 1 組になっています。秘密鍵は持ち主だけが知っている値で、イベントに署名するのに使います。公開鍵は秘密鍵から計算される値で、誰に見せてもかまいません。署名されたイベントを受け取った人は、公開鍵を使って、そのイベントが対応する秘密鍵で署名されたものか、途中で書き換えられていないかを確かめられます。公開鍵からは秘密鍵を割り出せないので、公開鍵を配っても、署名できるのは秘密鍵を持っている人だけです。署名のくわしい形式は Nostr の NIP-01 に定められています。

Nostr には中央でアカウントを管理する場所がありません。そのため、公開鍵そのものがその人を表す名前の役目を果たします。

みんなに見せていい鍵と、ぜったいに見せちゃだめな鍵……なんだね。

npub と nsec

鍵の中身はただの数値なので、そのままでは長い 16 進数の文字列（hex）になります。人間がやりとりしやすいように、Nostr では NIP-19 で決められた書き方もよく使われます。公開鍵は npub1 で始まる文字列、秘密鍵は nsec1 で始まる文字列で表します。どちらも中身は hex と同じ鍵で、書き方が違うだけです。先頭を見れば公開鍵か秘密鍵かがすぐにわかるので、取り違えを防ぐ役割もあります。

SWING の設定では、秘密鍵を nsec か hex のどちらかで書けます。ほかの人に自分のサイトをミラーしてもらうときに伝えるのは、公開鍵の npub のほうです。swing mirror add やダッシュボードの「ミラーに追加」に貼り付けるのも npub です。

新しい鍵の組は、次のコマンドで作れます。実行すると、nsec と npub、それぞれの hex を表示します。

swing key generate

ダッシュボードのセットアップ画面で「新しい鍵を生成する」を選んだ場合も、同じように新しい組が作られます。

SWING で鍵が使われるところ

SWING が署名するイベントは 3 種類です。自分のサイトを公開したときに出すサイトイベント（kind 35980）、ミラー対象を追加・削除したときに出す Follow Set（kind 30000）、保存しているサイトを知らせるレプリカ報告（kind 35981）です。はじめの 2 つは自分で操作したときに、レプリカ報告は mirror-agent が保存しているサイトごとに数日おきに自動で署名します。

受け取る側の SWING は、署名が正しくないイベントを捨て、さらに自分のミラー対象リストに載っている公開鍵が出したサイトイベントだけを保存の対象にします。誰かがあなたのサイトをミラーしているということは、その人の SWING が「この公開鍵で署名されたサイトイベントの CID を保存する」と決めている、ということです。

じゃあ、もし秘密鍵を誰かに盗まれちゃったら……？

その場合、鍵を盗んだ人はあなたになりすましてサイトイベントに署名できます。あなたをミラーしている人の SWING は、それがなりすましの更新だとはわかりません。保存のポリシーを通れば、なりすましたサイトが新しいバージョンとして取り込まれてしまいます。ミラー対象リストを書き換えることもできます。秘密鍵を守ることは、自分のサイトを預かってくれている人たちを守ることと同じです。

秘密鍵の置き場所

秘密鍵を SWING に渡すと、設定ファイルに平文のまま書かれます。バイナリで動かしている場合は swing.toml の [nostr] にある secret_key です。Docker Compose で動かしている場合は .env の SWING_NOSTR_SECRET_KEY で、ここを空のままセットアップ画面で鍵を作ったときは、コンテナの /data に置かれる swing.toml に書かれます。

[nostr]
secret_key = "nsec1..."

平文なので、ファイルを読める人は誰でも秘密鍵を読めます。ファイルを Git にコミットしたり、ほかの人と共有するフォルダに置いたりしないよう気をつけましょう。Linux と macOS では、秘密鍵を書いた swing.toml がほかのユーザーにも読める権限になっていると、起動時に警告が出ます。そのときは、自分だけが読めるようにしておきます。

chmod 600 swing.toml

ダッシュボードのセットアップ画面から保存したファイルは、はじめから自分だけが読める権限で作られます。

大事なことを書いた紙を、机の上に置きっぱなしにしない……みたいなことかも。

専用の鍵をすすめる理由

Nostr の鍵は、SNS のような Nostr のアプリでも使われています。すでに普段使いの鍵を持っている人は、それを SWING にも使いたくなるかもしれません。それでも SWING のドキュメントは、サイトの公開とミラーのための専用の鍵を新しく作ることをすすめています。

理由は、ここまで見てきた通りです。SWING に渡した秘密鍵は平文でファイルに残ります。そのファイルが漏れたとき、専用の鍵なら影響は SWING の範囲で済みますが、普段使いの鍵なら、その鍵を使っているほかの場所の投稿やつながりまで、なりすましの危険にさらされます。

秘密鍵を置かない方法

秘密鍵を手元のコンピュータに置きたくない場合は、スマホの署名アプリに署名を任せる方法もあります。Nostr の NIP-46 という仕組みで、SWING が署名してほしいイベントをリレー経由で暗号化して署名アプリに送り、署名アプリが秘密鍵で署名して返します。秘密鍵そのものが SWING に渡ることはありません。

SWING のドキュメントでは、Android の Amber と iPhone・iPad の Clave で動作を確かめています。セットアップ画面で「スマホの署名アプリで署名する（NIP-46）」を選び、「QRコードを表示」を押して、署名アプリの中の QR 読み取りで読み取り、接続を承認します。コマンドラインからつなぐこともできます。

swing signer pair

接続情報を保存したら、動いている swing を再起動すると署名アプリを使い始めます。

swing stop --restart

このとき手元には、署名アプリとの接続情報が remote-signer.json というファイルに保存されます。中には SWING 専用の使い捨ての鍵が入っていますが、これは署名アプリとのやりとりを暗号化するためだけのもので、イベントに署名できる鍵ではありません。署名アプリで接続を取り消せば使えなくなります。

鍵はスマホが持っていて、こっちは「署名して」ってお願いするだけ……なんだね。

ただし、署名アプリを使うときは少し注意が必要です。先ほど見たように、レプリカ報告は数日おきに自動で署名されるので、SWING からのリクエストは常に許可しておくのがおすすめです。公開とミラー対象の変更だけは毎回確かめたい場合は、署名アプリの権限設定で kind 35981 だけを許可にしておくと、それ以外のリクエストでスマホに承認を求められます。

署名アプリが使えない間は、公開・ミラー対象の変更・レプリカ報告の更新ができません。サイトの取得と保存は署名を使わないので続けられます。署名できない状態が長く続くとレプリカ報告の更新が止まり、既定では 3 日で期限が切れて、ミラーしている人数に数えられなくなります。スマホを閉じている間やスリープ中に答えられるかは署名アプリによるので、上手く動かないときは署名アプリを起動して待ってみてください。

スマホも、ときどきは起こしてあげないとね……。

次回

鍵を取り扱う準備ができれば、SWING でできることを一通り試せます。次回は、ゆれ子のいるデスクトップ画面から見えるものを手がかりに、ほかの人のサイトをミラーして読んでみるところまでを見ていきます。

次は、いっしょにサイトを見に行こうね。

ゆれ子がここに来るまでのこと

Fri, 02 Oct 2026 00:00:00 +0900

……わたし、気がついたらこのデスクトップにいたんだよね。その前のことは、うーん……あんまり覚えてないかも。

ゆれ子が暮らしているのは、SWING のダッシュボードのデスクトップ画面です。この画面が初めて表示されるまでには、いくつかのステップがあります。SWING を入れる、ダッシュボードを開く、セットアップ画面で最初の設定をする、といったことです。今回はこの順に、ゆれ子が目を覚ますまでの道のりをたどっていきましょう。

SWING をインストールする

SWING は、自分のコンピュータの上で動かすプログラムです。サイトのデータを保存・配送するために、IPFS ノードの Kubo も一緒に動かします。ここで紹介する入れ方はどれも Kubo をまとめて入れるので、別に用意する必要はありません。

Linux（x86_64・aarch64）では、インストールスクリプトを使います。--service を付けると、ログイン時に起動するようサービスとしての登録まで済ませます。

curl -fsSL https://github.com/amane-katagiri/swing/releases/latest/download/install.sh | sh -s -- --service

Windows では、GitHub のリリースにある swing-<v...>-x86_64-pc-windows-msvc-setup.exe を実行します。ユーザーごとのインストールなので管理者権限は不要です。インストーラーには署名をしていないため、開いたときに SmartScreen の警告が出ることがあります。そのときは「詳細情報」を押し、出てくる「実行」で進めます。最後の画面で「SWING を起動してダッシュボードを開く」を選ぶと、そのままダッシュボードが開きます。

macOS では Homebrew でインストールして、swing service install でログイン時に起動するよう登録します。

brew install amane-katagiri/swing/swing
swing service install

動作環境を隔離したい場合は、Docker Compose で動かすこともできます。リポジトリを取得して、.env を用意してから起動します。この方法では、以降のコマンドの swing ... を docker compose exec mirror swing ... に読み替えてください。

git clone https://github.com/amane-katagiri/swing.git
cd swing
cp .env.example .env
docker compose up -d

更新やアンインストールのしかた、設定ファイルの置き場所は docs/guide/install.md にまとまっています。

いろんな入り口があるんだね……。どこから来ても、たどり着くのは同じデスクトップなのかな。

ダッシュボードを開く

ダッシュボードは、SWING が自分のコンピュータの中で開いている管理用の Web ページです。既定では http://127.0.0.1:8082/ で待ち受けていて、ほかのコンピュータからは見えませんが、この URL を直接開いてもすぐには使えません。先にログインが必要です。

いちばん簡単なのは、ターミナルで次のコマンドを実行することです。使い捨てのログインリンクが作られ、ブラウザで開きます。

swing dashboard open

リンクを開くとログイン画面にコードが入った状態になるので、「ログイン」を押すとログインが完了します。リンクは 1 回限りで、5 分たつと使えなくなります。一度ログインすると、その状態は 30 日続きます。

Docker Compose の場合は、コンテナの中からブラウザを開けません。--no-browser を付けて実行し、表示された URL を自分でブラウザに貼ります。

docker compose exec mirror swing dashboard open --no-browser

Windows か macOS なら、コマンドを打たずに済む方法もあります。インストールすると、Windows ではタスクトレイ、macOS ではメニューバーに SWING のアイコンが出ます。このアイコンのメニューから「ダッシュボードを開く」を選ぶと、ログイン済みのダッシュボードが開きます。このメニューの一番上には SWING の状態が出ていて、最初の設定が済んでいないあいだは「SWING: セットアップ待ち」と表示されます。必要に応じて再起動や停止もできます。Linux にはこのアイコンが無いので、上記のコマンドで開いてください。

えっ、ゆれ子のいるところって、鍵のかかったお部屋だったんだ……。

ダッシュボードには SWING の重要な設定や操作がまとまっているので、そのコンピュータを使う本人だけが入れるようになっています。

セットアップ画面

初めて起動したときは、まだ設定ファイルがありません。この状態の SWING は「セットアップモード」で動きます。セットアップモードでは、ダッシュボードだけが動いていて、Kubo もミラーの仕事をする mirror-agent もまだ起動していません。ダッシュボードを開いても、サイドナビには「セットアップ」しか出ず、デスクトップ画面にもまだ入れません。

……そのころのゆれ子は、まだ眠ってたのかも。

セットアップ画面で入力するのは、鍵・リレー・ストレージ上限の 3 つです。

最初の「鍵」は、SWING が Nostr にイベントを出すときの署名に使うものです。選び方は 3 つあります。「新しい鍵を生成する」は SWING 専用の鍵をその場で作るもので、既定はこれです。「既存の鍵を使う」は、今使っている秘密鍵を貼り付けるものです。「スマホの署名アプリで署名する（NIP-46）」を選ぶと、秘密鍵をこのコンピュータに置かず、署名のたびにスマホのアプリへ依頼する仕組みを使います。それぞれに向き・不向きがあり、鍵そのものの話も長くなるので、詳しくは次回に取り上げます。

「リレー」は、更新の通知やミラー対象のリストをやりとりする Nostr のリレーです。いくつかの公開リレーがあらかじめ入っていて、既定のままでも動きます。

「ストレージ上限」は、ほかの人のサイトを保存するのに差し出してよいディスクの容量です。合計の上限（既定 100GiB）、サイトごとの上限（既定 10GiB）、アカウントごとの上限（既定 20GiB）の 3 つがあります。どのくらいにすればよいかの目安は docs/guide/operation.md にあります。

ほかの人のサイトをしまっておく場所……。ゆれ子も、そこで一緒に過ごしてるのかな。

入力して「セットアップ」を押すと、設定ファイル swing.toml が書き込まれ、エージェントが再起動します。少し待つと、画面に自分の公開鍵（npub1...）が表示され、続けて設定画面に移ります。ここから先は、Kubo と mirror-agent も動き始めています。

デスクトップ画面

セットアップを終えると、サイドナビにほかの画面が並びます。上から順に、デスクトップ・サイト・Webring・公開・設定です。一番上の「デスクトップ」を選ぶと、デスクトップ画面が開きます。

デスクトップ画面は、懐かしい Windows 風のデスクトップを模した画面です。青緑色のデスクトップにはシンプルなアイコンが並び、下にはタスクバーとタスクトレイがあります。真ん中には「リンク集 - SWING Explorer」というブラウザ風のウィンドウが開いていて、ここに保存したサイトへのリンクが並びます。ただ、セットアップを終えたばかりでは、まだ何もミラーしていません。リンク集の上には「まだ何もミラーしていません…また今度見てね！」とマーキーで流れているはずです。

そして、タスクバーの上を小さなキャラクターが歩いています。これがゆれ子です。

こんにちは……ゆれ子だよ。今日も、よろしくね。

ダッシュボードを開いたときに最初に出る画面は、既定ではデスクトップ画面ではなくサイト一覧の画面です。毎回デスクトップ画面から始めたいときは、デスクトップの「コントロールパネル」を開き、「システム」タブの「起動時にデスクトップを表示する」をオンにします。

それ、オンにしてくれたらうれしいな……。毎回、すぐに会えるから。

次回は、セットアップ画面で選んだ「鍵」について、もう少しくわしく見ていきます。

鍵って、ドアの鍵とはちがうのかな……。ゆれ子も、いっしょに聞いてみるね。

はじめまして、ゆれ子です

Thu, 01 Oct 2026 00:00:00 +0900

こんにちは……ゆれ子だよ。今日から少しずつ、SWING のことを書いていくね。

こちらの記事では、SWING というあたらしいシステムを、マスコットのゆれ子といっしょに順番に見ていきます。

ゆれ子のいる場所

SWING には、手元のブラウザで開く管理用のダッシュボードがあります。その中のデスクトップ画面は、古い Windows のデスクトップを模したレトロなデザインです。青緑色の背景にシンプルアイコン、下にはタスクバーがあり、真ん中には「SWING Explorer」というウィンドウが開いています。ウィンドウの中身はリンク集のページで、手元に保存されているサイトが新しい順に並び、マーキーで最新の更新情報が流れています。

ゆれ子は、このタスクバーの上を歩いているマスコットです。クリックするとちょっとした反応を返してくれて、つまんで持ち上げることもできます。サイトが新しく保存されたときや、自分のサイトをミラーしてくれる人が増えたときには、バルーンでおしらせしてくれます。

わたしに見えるのは、このデスクトップの中だけなの。リンク集と、流れてくる更新情報と、タスクバー……それくらいかも。

ゆれ子は画面の外のことを直接は知りません。リンク集に新しい行が増えたことはわかっても、その行がどこからどうやって届いたのかは見えていないのです。画面の外で起きていることを、ゆれ子と一緒に見ていきましょう。

SWING がしていること

SWING は、個人サイトを運営している人どうしが、おたがいのサイトを保存して、配り合うための相互ミラーを運営するシステムです。ミラーとは、ほかの人のサイトのコピーを自分の手元にも持っておき、そこからも読めるようにしておくことです。

SWING には中央の保存サーバーも、参加者を管理する人もいません。誰のサイトを保存するかは、参加者それぞれが自分の意思で決めます。逆に言えば、保存してくれる人がいる間だけコピーが残る仕組みなので、データを永久に残すことを約束するものではありません。

この仕組みは、2 つの既存の技術を組み合わせてできています。ひとつは Nostr で、「サイトを更新した」という知らせと「誰のサイトを保存するか」という表明を伝えるのに使います。もうひとつは IPFS で、サイトの中身そのものを保存し、配送するのに使います。小さなメッセージのやり取りは Nostr に、大きなデータの実体は IPFS に、と役割を分けています。

お知らせしてくれる係と、運んでくれる係がいるんだね……。

IPFS: 中身から決まるアドレス

IPFS では、ファイルやディレクトリを、置き場所ではなく中身から計算したアドレスで指します。このアドレスを CID と呼びます。中身が 1 ビットでも変われば CID も変わるので、同じ CID を指していれば、誰から受け取っても同じ中身であると保証できます。

SWING では、1 つのサイトを IPFS 上の 1 つのディレクトリとして扱って、そのディレクトリの CID でサイトのバージョンを表します。サイトを更新すると新しいディレクトリができ、新しい CID が生まれます。CID がわかれば、そのデータを持っている IPFS のノードならどこからでも取り寄せられます。

SWING の参加者は、それぞれの手元で Kubo という IPFS のノードを動かしています。Kubo には MFS という、Kubo の中で使えるファイルシステムがあり、SWING はミラーするサイトをここに置いて保存します。保存したサイトは手元の Kubo を通して読めますし、ほかの IPFS のノードへの配送にも使われます。

Nostr: 署名つきの短いイベント

Nostr は、公開鍵で署名された短いメッセージ（イベント）を、リレーと呼ばれるサーバーを通してやりとりする仕組みです。リレーは誰でも立てられ、SWING は既存の公開のリレーをそのまま使います。イベントには署名がついているので、どのリレーを通ってきたものでも、本当にその鍵の持ち主が出したものかを受け取った側で確かめられます。鍵と署名については、また別の回でくわしく見ます。

SWING が主に使うイベントは 2 種類です。

1 つめはサイトイベントで、kind（イベントの種類を表す番号）は 35980 です。作者がサイトを更新すると、そのサイトを識別する名前（ふつうはドメイン名）と、新しいバージョンの CID を入れたサイトイベントを出します。同じ作者が同じ名前で出したものは、いちばん新しいものだけが「今のバージョン」として扱われます。ここには、表示用のタイトルや、読者向けの短い更新メモも添えられます。

2 つめはミラー対象リストです。Nostr で名前付きのリストを表す Follow Set（kind 30000）に、d タグで swing という名前を付けて使います。この中に、自分が保存したい相手の公開鍵を並べます。「この人のサイトを保存します」という宣言を、署名つきで公開しておくわけです。

保存しますって、みんなに見えるところで言うんだ……。ちょっと照れるかも。

更新がリンク集に届くまで

それでは、誰かがサイトを更新してから、その情報がゆれ子の見ているリンク集に並ぶまでの流れを追ってみましょう。

各参加者の手元では、Kubo といっしょに mirror-agent という常駐プログラムが動いています。mirror-agent は、まず自分のミラー対象リストをリレーから読み、そこに載っている公開鍵が出したサイトイベントを見張っておきます。新しいサイトイベントが出ればすぐに届きますし、取りこぼしに備えて、既定では 5 分ごとに過去の分もまとめて取得します。

サイトイベントが届くと、mirror-agent は署名が正しいか、ミラー対象リストに載っている相手か、CID がディレクトリを指す正しい形か、といった点を確かめます。そのうえで、保存量の上限や更新を受け入れる頻度などの、参加者ごとに決めた保存のポリシーに照らして、問題がなければそのデータを Kubo で取り寄せて MFS に置きます。相手が更新したときに取りに行くのは手元に無い部分だけなので、少しの書き換えなら通信量もあまり消費しません。

保存が終わると、そのサイトはダッシュボードで保存済みとして扱われ、デスクトップ画面のリンク集に行が加わります。マーキーで最新の更新が流れ、ゆれ子がバルーンで知らせてくれることもあります。

「更新されたみたい」って言うとき、画面の外ではそんなに色々あったんだね……。

保存している人は、どのサイトのどのバージョンを今持っているかを、レプリカ報告という別のイベント（kind 35981）でときどき知らせます。作者はこれを収集することで、自分のサイトを何人がミラーしてくれているかを知ることができます。この数え方も、また別の回で触れます。

Webring でリストをたどる

ミラー対象リストは公開されているので、自分が保存している相手のリストをのぞけば、その人がどんなサイトを保存しているかがわかります。さらにその先のリストをたどっていけば、つながりの輪が見えてきます。SWING では、このたどり方を Webring と呼んでいます。

ここで気をつけたいのは、リストに載せるのは載せた側の一方的な表明だという点です。A さんが B さんをリストに入れていても、B さんがそれに同意したわけではありません。そのため SWING では、A さんと B さんの両方がおたがいをリストに入れているときにだけ、相互にミラーし合っている関係として扱います。

片思いと両思いを、ちゃんと分けてるんだ……。やさしい仕組みかも。

Webring は、SWING を使っているまだ知らない誰かのサイトを見つけるきっかけになります。ダッシュボードでの見え方も、いずれ紹介します。

ゆれ子の SWING 日記が生まれたわけ

このブログ自体も、SWING で IPFS に公開している静的サイトです。ゆれ子は、ここを SWING で公開された最初のサイトだと思っています。

わたしは最初からここにいるよ。だから、あとから来た人が迷わないように……道しるべになれたらいいなって。

SWING を始めた人が最初にミラーする相手として、そして仕組みを知りたい人が最初に読むページとして、ここが役に立てばいいなと思います。次回は、ゆれ子がデスクトップ画面に現れるまでのこと、つまり SWING を入れてダッシュボードを開き、初期設定をするまでの流れを見ていきます。

次は、わたしがここに来る前のお話……ちょっと思い出してみるね。