はじめに：Tor-only前提は「普通」を壊す
Torネットワーク上で決済機能を使う、という話をすると、多くの場合は「Torに対応したWebサービス」というイメージで受け取られます。
しかし実際には、Tor-onlyを前提にすると一般的なWebサービス設計はほぼそのままでは使えません。
TorPay Easy DL Shopを作る過程で、これまで当たり前だと思っていた設計や機能をいくつも捨てることになりました。
この記事では、Tor-onlyで決済を成立させるために捨てたものと、それでも残した最低限のものについて整理します。
具体的な操作手順や画面キャプチャ付きの解説は公式サイトにまとめています。
Qiitaでは、設計と判断の話に絞ります。
なぜ「利用者のログイン」を最初から捨てたのか
一般的なECやダウンロード販売では、利用者がアカウントを作成しログインする仕組みがほぼ必須です。
しかしTor-only構成では、利用者のログイン機能は一気に厄介になります。
- 永続的な識別子をどう扱うか
- セッションをどこまで信用するか
- IPアドレスに頼れない前提
これらを真面目に設計しようとすると、決済やダウンロードとは直接関係のない部分で実装が一気に重くなります。
TorPay Easy DL Shopでは、購入者や利用者がログインする仕組みそのものを前提から外すという判断をしました。
ここで言っている「ログイン機能」とは、あくまで「利用者側のログイン」の話です。運営者が管理画面にアクセスするためのログイン機能は、当然ながら別に用意しています。
Tor-only構成では、利用者と運営者を同じ前提で扱わないことが重要だと考えています。
なぜメール通知を入れなかったのか
購入完了メールやダウンロードリンクの送信は、ECでは当たり前の機能です。
しかしTor-only前提では、
- メールアドレスを収集するハードルの高さ
- 外部SMTPへの依存が増える
- Torとの相性が良くない
といった問題があります。
Torはプライバシー意識の高い人が多いため、そもそもメールアドレスを入力させるという設計は利用者の離脱を招く可能性が高いと考えています。
TorPay Easy DL Shopでは、通知を出さない代わりに、状態を画面上にそのまま表示するという割り切りをしました。
不親切に見えるかもしれませんが、Tor前提では「今どうなっているかが分かる」ことの方が重要な場面も多いと感じています。
なぜ多機能なECにしなかったのか
会員管理、在庫管理、レコメンド、クーポン。これらは便利な機能ですが、Tor-only構成では必須ではありません。
機能を増やすほど、
- 設定項目が増える
- 理解コストが上がる
- 改造しにくくなる
という問題が出てきます。
TorPay Easy DL Shopは完成されたECサイトではなく、最小限の実装例であることを優先しています。
「自動化していない」とはどういう意味か
TorPay Easy DL Shopでは、すべてを自動化しているわけではありません。
ここで言う「自動化していない」とは、技術的にできないという意味ではなく、あえて設計の外に出しているという意味です。
自動化しているもの
次のようなものは自動化しています。
- Tor前提の通信設定
- BTCPay Serverとの連携
- 支払い完了時のWebhook処理
- ダウンロード回数や期限の制御
これらは事実だけで完結できる処理だからです。
あえて自動化していないもの
一方で、次のようなものは意図的に自動化していません。
- 商品内容の妥当性
- 利用目的の判断
- トラブル発生時の対応
- 法的な扱いの判断
これらはコードで一律に処理できるものではなく、必ず誰かの判断や責任が必要になる領域だからです。
TorPay Easy DL Shopでは便利さを最大化することよりも、責任の所在が曖昧にならないことを優先しています。
Tor特有の不安定さと、自動復旧について
Tor-onlyでサービスを運用していると、通信が遅くなったり一定時間アクセスできなくなったりすることがあります。
これは実装の不具合というより、Torネットワークの性質として避けられない挙動です。
onionサービスでは特に、
- サーキットの張り替え
- 一時的なスタック
- クライアント側から原因が見えにくい切断
といった状態が、どうしても発生します。
TorPay Easy DL Shopでは、これらを「完全になくす」のではなく、発生する前提で静かに復旧する方針を取っています。
最小限のヘルスチェックと自動復旧
具体的には、定期的に自分自身の.onionサービスへTor経由でアクセスし、応答が返らなかった場合にTorサービスを再起動させています。
実装はかなり単純です。
if curl --socks5-hostname 127.0.0.1:9050 \
--connect-timeout $TIMEOUT \
--max-time $TIMEOUT \
-s -o /dev/null "http://${SHOP_ONION}/"; then
exit 0
fi
logger -t tor-health "onion shop healthcheck failed, restarting tor"
systemctl restart tor@default.service
管理画面用にも、同様のチェックを行っています。
なぜこの程度で止めているのか
より高度な監視や制御を行うことも可能ですが、Tor-only構成では、
- 状態を正確に把握するのが難しい
- 監視を増やすほど依存関係が増える
- 「止まらないこと」より「戻れること」が重要
と考えており、完璧な安定性より前提が壊れたときに自動で戻れることを優先しています。
そもそも、TorPay Easy DL Shopは「誰もがTorネットワーク上で気軽に決済機能を使えるようにしたい」という考えから生まれたWEBアプリですから、必要以上の高度な監視や制御を取り入れると当初の理念から大きく逸脱します。
Tor-onlyで「使えなくなったもの」
正直に言うと、Tor-only前提では次のようなものは諦めています。
- 高速で安定したレスポンス
- IPアドレスを使った制御
- リアルタイム性の高いUX
- リッチなUI
- フルマネージドな運用体験
UXは良くありません。
反応が遅いと感じることもあります。
それでも、Tor-onlyであることを優先した結果として受け入れています。
それでも残した最低限のもの
一方で、これは捨てませんでした。
- 決済が成立すること
- 支払い結果が正しく反映されること
- ダウンロード条件が明確であること
TorPay Easy DL Shopは、「支払ったらダウンロードできる」という、この一点を確実に成立させるための構成です。
なぜそれでも成立するのか
Tor-only構成は不便です。
しかし、
- 依存関係が少ない
- 前提条件が明確
- 挙動が読みやすい
という利点もあります。
TorPay Easy DL Shopは、便利さよりも前提が壊れないことを優先しています。
まとめ：これは完成品ではない
Tor-onlyで決済を扱うと、設計は確実に歪みます。その歪みをどう受け入れ、どう割り切るか。
この記事では、TorPay Easy DL Shopで何を捨て、何を残したのかを整理しました。
ここで書いた設計判断が、唯一の正解だとは考えていません。
さいごに、Torで「売る側になりたい」と考えている人が、ゼロからすべてを設計するのではなく、まずは動く形を手に入れるための土台として、TorPay Easy DL Shopを用意しました。