サービス発見 | LMSP 1.0 ドラフト

3.1 発見方法

クライアントは、次の方法を順に試してサービスを発見する。

手動設定。 ユーザーがサービスのアドレスを直接入力する。
慣例のローカルアドレスのプローブ。 クライアントは候補アドレスに /.well-known/lmsp.json を要求する。慣例の候補は http://127.0.0.1:17832 と http://[::1]:17832 である。
LAN での発見。 クライアントは mDNS と DNS-SD で _lmsp._tcp.local. を探索する。

有効なサービス記述（3.3 節）が得られた時点で、その方法は成功となる。ユーザーが手動で入力したアドレスは、発見されたアドレスより常に優先される。

3.2 LAN でのアドバタイズ

DNS-SD は、PTR レコードでサービスインスタンスを見つけ、SRV レコードでホストとポートを得て、TXT レコードで少量の追加情報を運ぶ。mDNS と組み合わせると、ローカルネットワークでゼロ構成の発見が可能になる（RFC 6763、RFC 6762）。

アドバタイズの例:

Service type:   _lmsp._tcp.local.
Instance name:  Workstation LMSP._lmsp._tcp.local.

TXT record:
  v=1
  id=svc_01J8M4Y8K6M5E6K6Z7Z0Y8W3M2
  path=/
  auth=pairing

TXT キー	意味
`v`	アドバタイズ形式のバージョン。LMSP 1.0 では `1`。
`id`	サービス ID。サービス記述の `service.id` に等しい。
`path`	サービスルートの URL パス。クライアントは `{path}.well-known/lmsp.json` を要求する。
`auth`	認証のヒント。`pairing` は、利用前にクライアントがペアリングする必要があることを示す。

規則:

サービスは、アクセストークン、モデル一覧、ファイルパス、その他の機微な情報を TXT レコードに入れてはならない。TXT レコードはサービスの場所を示すだけである。実際の機能は、サービス記述から読み取らなければならない。
サービスは、mDNS アドバタイズを既定で無効にしておかなければならない。ユーザーが LAN 発見を明示的に有効にした場合にのみ有効になる。ローカルマシンだけで使うサービスはアドバタイズしない。
LAN でアドバタイズするサービスは、ループバック以外でも待ち受ける必要があり、これは LAN モードでのみ許される（10.5 節）。
クライアントは、TXT レコードを検証されていないヒントとして扱い、サービス記述を読んでサービスを確認しなければならない。

3.3 サービス記述

GET /.well-known/lmsp.json

サービスは、このドキュメントを認証を要求せずに application/json として提供しなければならない。

{
  "protocol": "lmsp",
  "versions": ["1.0"],
  "service": {
    "id": "svc_01J8M4Y8K6M5E6K6Z7Z0Y8W3M2",
    "name": "Workstation Local Models",
    "version": "1.0.0"
  },
  "interfaces": [
    {
      "kind": "lmsp",
      "version": "1.0",
      "url": "http://127.0.0.1:17832/lmsp/v1",
      "transport": "http+json"
    },
    {
      "kind": "openai",
      "version": "responses+chat",
      "url": "http://127.0.0.1:17832/v1",
      "transport": "http+json"
    }
  ],
  "capabilities": {
    "streaming": true,
    "tasks": true,
    "event_resume": true,
    "conversations": true,
    "model_management": true
  },
  "authentication": {
    "type": "bearer",
    "pairing_url": "http://127.0.0.1:17832/lmsp/v1/pair"
  },
  "openapi": "http://127.0.0.1:17832/lmsp/v1/openapi.json"
}

フィールド	意味
`protocol`	常に `"lmsp"`。
`versions`	サービスが対応する LMSP のバージョン。`major.minor` 形式の文字列。
`service`	`id` は安定したサービス識別子、`name` は表示名、`version` はサービスソフトウェアのバージョン。
`interfaces`	提供しているインターフェース。それぞれ `kind`（`lmsp`、`openai`、`ollama`）、`version`、ベース `url`、`transport` を持つ。`openai` の場合、`version` は提供している API ファミリーを示す（例: `responses+chat`）。
`capabilities`	真偽値の機能フラグ。下に示す。
`authentication`	`type` は `bearer`。`pairing_url` は、クライアントがペアリングコードをトークンと交換する場所である（10.2 節）。
`openapi`	LMSP インターフェースを記述する OpenAPI ドキュメントの URL。

機能フラグ:

フラグ	意味
`streaming`	レスポンスをサーバー送信イベントとしてストリーミングできる。1.0 では `true` でなければならない。
`tasks`	非同期タスクが利用できる。1.0 では `true` でなければならない。
`event_resume`	タスクのイベントストリームを購読・再開できる（`GET /lmsp/v1/tasks/{task_id}/events`）。
`conversations`	サービスがレスポンスを保存するため、`store` と `previous_response_id` が機能し、`GET /lmsp/v1/responses/{response_id}` が利用できる。
`model_management`	モデルを明示的にロード・アンロードできる。

3.4 クライアントの動作

クライアントは次のようにする。

versions のうち、自分も対応している最も高いバージョンを選択するべきである。
自分が話せるものに応じて、interfaces から LMSP インターフェースまたは OpenAI インターフェースを選択するべきである。
サービス記述が宣言している機能だけを使わなければならない。フラグがなければ false を意味する。
認識できない拡張フィールドは無視しなければならない。
サービス記述を永久にキャッシュせず、定期的に、またリクエストが失敗したときに再読み込みするべきである。
選択したサービスは、アドレスではなく service.id で記憶するべきである。アドレスは変わり得るためである。