atprotoでozoneを動かした

2025-12-04 ja

.md

最近は、atprotoとai.card(ios)の連携を作っていました。ozoneが必要そうになったので動かしてみます。

atprotoをゲームアカウントに

ゲームのアカウントシステムを作る際、atprotoが便利だと思っています。独自にシステムを作るのではなく、既にあるものを使って構築します。

しかし問題もあります。atprotoはユーザーがデータを自由に書き換えられます。もちろん、知識があればですが、そう難しいことではありません。

そのため、ゲームのアカウントシステムとして使う場合、ユーザーがデータを改ざんできないようにする必要があります。これは、rustで書いた独自のシステムと連携し、ユーザーに一部のデータしか操作できないuuidを発行することで解決することにしました。

ゲームアカウントの仕組み

ゲームアカウントの仕組みは非常にシンプルです。

[新規登録] handleを入力すると自動でアカウントが作成される
パスワードは自動生成され、dbに保存。ユーザーには表示しない
uuidを発行し、それを用いてユーザーはsessionを復元できる

この仕組みをiosアプリに実装することで、ゲームデータの改ざんを防止するゲームアカウントとして利用します。

ゲームアカウントの特典

私はゲームデータが改ざんされるとは考えていません。知識を持った大半も、そんな面倒なこと普通しません。ほとんどの人は普通に遊ぶだろうと考えています。

とはいえ、それも楽しみ方も一つとして許容する気持ちもあります。

また、改ざんされたとしてそれで壊れるような仕組みではいけません。ですからそれをされてもいいようゲームを構築しなければいけません。要は前提をどう考えるかです。

私が作っているゲームはai.cardが改ざんできないローカルデータのみを扱い、ai.rseはリモートデータを使うという構造です。したがって、改造もai.rseでしか有効ではありません。

そのため、結果としてより重視されるのはai.cardの方になるだろうと思っています。ai.rseはおまけみたいなものと認識されるのでは。

ai.rseでのデータの扱いは以下のような形になります。

管理者のpdsで作成されたアカウントはゲームデータ改ざんがないものとみなし

maxの値を通常アカウントより大きく設定
{user}.syu.isのドメイン部分を省略して表示

ozoneの導入

そうなるとユーザー管理も大変なので、ozoneがあったほうが良いと判断し、ozoneを動かしてみることにします。

backend, frontend

ozoneはback, frontの2つがあり、これらを動かす必要があります。

1 ozone /xrpc/* :2585
2 ozone /.well-known/* :2585
3 ozone * :2586

このようにすればよいでしょう。

atproto_pds

注意書きがあり、通常のアカウントは好ましくないようです。

AtprotoPersonalDataServer

diff --git a/lib/identity.ts b/lib/identity.ts
index a8ec3a7..8e4d171 100644
--- a/lib/identity.ts
+++ b/lib/identity.ts
@@ -83,7 +83,7 @@ export function didDocToData(doc: {
             const [, id] = s['id'].split('#')
             acc[id] = {
               type: s['type'],
-              serviceEndpoint: s['serviceEndpoint'],
+              endpoint: s['serviceEndpoint'],
             }
           }
           return acc

その他のpatchはこちらが参考になります。

https://github.com/itaru2622/bluesky-selfhost-env/tree/master/patching

user verify

OZONE_VERIFIER_URL=https://{PDS}
OZONE_VERIFIER_DID=${ADMIN_DID}
OZONE_VERIFIER_PASSWORD=${APP_PASSWORD}