更新情報 v0.1.4

2026-10-10

また SWING の新しいバージョンが出たんだって。今回も v0.1.3 と v0.1.4 の 2 つをまとめて見ていくね。

10/9 に v0.1.3、10/10 に v0.1.4 が出ました。v0.1.3 はセキュリティと安定性の修正が中心で、v0.1.4 ではサイトを公開する前の確認が増えました。この記事では、2 つのバージョンで変わったところをまとめます。

カレントディレクトリの `swing.toml` を読まないように変更（v0.1.3）

これまでは、--config も環境変数の SWING_CONFIG も無いとき、カレントディレクトリに swing.toml があればそれを使っていました。人から受け取ったディレクトリ（クローンしたリポジトリなど）で swing up すると、そこに書かれた設定で知らないプログラムを起動してしまうおそれがあったので、やめました。

設定ファイルは、--config、SWING_CONFIG、ユーザーごとの既定の場所の順に探します。既定の場所以外に swing.toml を置いている場合は、--config <パス> を付けるか、SWING_CONFIG にそのパスを設定してください。サービスとして登録している場合は、登録した設定ファイルのパスをそのまま使うので、何もしなくて大丈夫です。

知らない場所の設定ファイルを勝手に読んじゃうのは、ちょっと怖いもんね……。

手元のゲートウェイで開いたサイトの制限を強化（v0.1.3）

v0.1.2 では、ミラーしたサイトを手元の IPFS ゲートウェイで開くときに、ページから同じマシンや LAN へ http:// で送れないようにしました。v0.1.3 では、そこに足りなかったところを塞いでいます。

Service Worker・Web Worker・SharedWorker を使えなくしました。Service Worker を使うと、v0.1.2 の制限を抜けられたためです
http:// のほかのサイトからスクリプトを読み込めなくしました。https:// のスクリプトやページの中に書いたスクリプト、YouTube などの埋め込みは、これまでどおり動きます

v0.1.2 以前に開いたサイトが Service Worker を登録していた場合、その Service Worker はブラウザに残っています。気になる場合は、ブラウザの設定で ipfs.localhost のサイトデータを消してください。

内蔵ゲートウェイが自分のサイトだけを返すように修正（v0.1.3）

自分のドメインでサイトを配る内蔵ゲートウェイ（[gateway]）は、GET・HEAD 以外のリクエストと、/ipfs/…・/ipns/… のアクセスを断るようになりました。Kubo の設定によっては、自分のサイトではない CID のコンテンツをネットワークから取得・配布しうる経路があったためです。

そのため、サイトの最上位に ipfs・ipns という名前のファイルやディレクトリがあると、内蔵ゲートウェイでは開けません。SWING に Kubo を任せず（[kubo] managed = false）、自分で用意した Kubo を使っている場合は、Kubo の Gateway.NoFetch を true にしておいてください。

v0.1.3 では、ほかにも公開・ダッシュボード・サービスの登録まわりの細かい不具合をまとめて直しています。全部の一覧は v0.1.3 のリリースノートにあります。

公開前の動作性の確認を追加（v0.1.4）

SWING で公開したサイトは、いろいろなゲートウェイを通して開かれます。ふつうの Web サーバーでは表示できていたサイトでも、ゲートウェイでは一部が表示されないことがあります。たとえば /css/style.css のように / で始まるパスは、https://<ゲートウェイ>/ipfs/<CID>/ のような URL で開いたときに、ゲートウェイ自体のルートを指してしまいます。

v0.1.4 からは、swing publish とダッシュボードの公開で、サイトの HTML・CSS・JavaScript を読んで、こうした不具合が起きうる箇所を探せるようになりました。CLI では --check-links、設定では [publish].check_links で、off・warn（既定）・require を選べます。ダッシュボードでは、公開画面の「動作性の確認」で選べます。

require にすると、確実に不具合が起きる次のものが見つかったときに公開を止めます。

サイトの最上位にある ipfs・ipns という名前のファイルやディレクトリ
/ で始まるサイト内の参照（<base href="/"> を含む）
サイトに無いファイルへの参照。Image.PNG を image.png で指しているような、大文字と小文字の違いも見つけます
http:// から読み込むスクリプト

次のものは不具合が起きることがある箇所です。ただし、実際には問題なく表示できることもあるので、require でも止めずに警告のみ表示します。

POST などで送るフォーム
Service Worker などの Worker の登録
JavaScript から http://・ws:// への通信
ほかのホストからの画像・CSS・スクリプトなどの読み込み
元のサイトの絶対 URL へのリンク

何か見つかったときは、直し方をまとめたサイトの手引きへのリンクも出ます。ただし、JavaScript が実行中に組み立てる URL などは見つけられません。確認を通ったサイトも、公開したらゲートウェイで開いて確かめておくと安心です。

わたしの日記は、最初から相対パスで書いてあるから大丈夫……なはず。こういうのは、公開する前に教えてもらえるとうれしいね。

ダッシュボードで公開前に確認の結果を表示（v0.1.4）

ダッシュボードの公開画面で「公開」を押すと、アップロードする前に、ドットファイル・サイズ・動作性の確認の結果を「公開前の確認」に出すようになりました。新しく増えるファイルの一覧と同じ画面で、内容を見てから「このまま公開」か「キャンセル」を選べます。require の確認に引っかかったときは「キャンセル」だけが出て、止まった理由を表示します。

公開前の確認に、ドットファイル・サイズ・動作性の確認の結果が並び、動作性の確認では見つかったものが種類ごとのリストになっている。下には新しく増えるファイルの一覧と「このまま公開」「キャンセル」のボタンがある

確認のために送るのは、ファイルの一覧と、HTML・CSS・JavaScript の中身だけです。画像や動画の中身は送らないので、大きいサイトでも待ち時間はほとんど増えません。

更新の投稿にハッシュタグを付与（v0.1.4）

v0.1.2 で入った、サイトの更新を Nostr の投稿としても出す機能（--note、ダッシュボードのチェックボックス）で、投稿にハッシュタグ #swingpublish が付くようになりました。Nostr クライアントのハッシュタグ検索で、SWING で公開されたサイトの更新を探せます。

#swingpublish で検索したら、みんなの更新がまとめて見られるんだね。わたしもときどき探してみようかな。

macOS でサービスを入れ直すと失敗することがある不具合の修正（v0.1.4）

macOS で、動いている SWING の上から swing service install を実行すると、ときどき Bootstrap failed: 5: Input/output error で失敗していました。前の SWING が止まりきる前に、新しい SWING を起動しようとしていたためです。v0.1.4 からは、前の SWING が止まったのを確かめてから起動します。Homebrew で更新したときの swing service install も失敗しにくくなります。

更新のしかた

更新のしかたは、インストール方法によって違います。インストーラーやスクリプトはもう一度実行すれば上書きされ、Homebrew なら brew upgrade の後に swing service install で新しいバージョンに切り替わります。くわしくは導入の手引きを見てください。