6502tinymachines

ゲートウェイ

プールは毎分数十バイトずつしか満ちず、しばらくの間、誰でもそれを飲み干せた。 /random/bytes、/random/raw、/random/hex、/random/integers は鍵なしで応答していて、それは、一人の呼び出し手が皆で共有する装置を空にできる手段だと気づかれるまでは問題なかった。いまこれらは 410 Gone を返し、その理由を自分の言葉で述べる:

{
  "error": "this endpoint now requires a key",
  "use": "https://hotbits.tinymachines.ai/v1/bytes with Authorization: Bearer <key>",
  "why": "the pool refills at ~75 bytes/min and was open to anyone",
  "public": "/v1/seeds needs no key and cannot drain the pool"
}

(この 75 は告知が書かれた当時の数字だ。2026-08-24 の実測では毎分およそ 36 バイトだった。レートは告知ではなく管のものだ。 ビットを参照。)

引かれた線

何が閉じ、何が開いたままかは一つの規則に従う: 新鮮なプールのバイトを手渡すエンドポイントは全員の負担であり、記録済みのバイトを再生するエンドポイントは誰の負担でもない。

  • /v1/bytes はプールを消費する。だから bearer 鍵とバイト予算を取り、 リクエストは 4 KB (/stats の max_bytes_per_request) で頭打ちになる。鍵が無ければ 401。
  • /v1/seeds は開いたままだ。追記専用ストリームから再生した 48 ビットの シードを渡す: 実物の崩壊データだが、専有でも新鮮でもないので、何も飲み干せない。応答自身が "conditioning": "none" と言う。それは「シミュレーションの種にする」への正直なラベルであり、秘密には間違った道具だ。
  • /random/archive も同じ理由で開いたままだ: 記録済みのバイトの再生だから。

一つのホストに二つのサービス、二つのスキーマ

このオリジンは合成物であり、そのドキュメントもいまはそう言う。装置の openapi.json は読み取り専用の面を記述する: 統計、健全性、メトリクス、検定履歴、時系列。ゲートウェイは自分の文書を /v1/openapi.json で公開し、五つの /v1 ルートを記述する。しかもそれはルーターを組み立てるのと同じ表から生成される: 片方に足してもう片方に足し忘れたルートはゲートウェイ自身のテストを止めるので、スキーマは応答しないルートを記述できない。それぞれのサービスが自分の給仕するものを文書化し、どちらも他方のルートを記述しない。何ものも又聞きで主張されない唯一の配置だ。

/ja/hotbits/api は両方の文書を読み、そこにあるすべてのルートを実際に呼び出す。両方のスキーマがあって初めて可能になった区別が一つある: ゲートウェイの鍵付きルートは意図して CORS を拒む。ページの JavaScript に鍵を置きたくなる誘惑を断つためだ。リファレンスはその読めない応答を、欠陥ではなく設計が働いている印として表示する。

残る既知の空隙は一つ

装置側の拒絶はブラウザから読めない。 410 応答は CORS ヘッダを運ばない ので、このサイトのページはリクエストが失敗したことは分かっても、なぜかを説明する本文が読めない。そして説明こそが有用な部分だ。tinymachines/geiger#4 として起票済み。それが直るまで、リファレンスはこれらのルートを「ブラウザには読むことが許されない形で応答している」と報告する。それが真実だからだ。

このページに検証できないもの

ゲートウェイは装置の前に立つ独立のサービスであり、このサイトのビルドの一部ではない。そのスキーマはいまやこのページの情報源の一つであり、信用できる理由は上に書いたとおりだ: ゲートウェイ自身のルート表から組み立てられ、ルート表について書かれたのではない。ここから手が届かないのは、意図して HTTP に載せられていない部分だ: 鍵の発行と失効はゲートウェイを動かす機械のコマンドラインで行われる。資格情報を作れるエンドポイントは、ログイン一回を節約する代償としては恒久的すぎる攻撃面だからだ。上に述べたことは他のすべて、サービスを呼び出して測ったものであり、どの端末からでも検証し直せる。