Découverte de services | LMSP 1.0 Brouillon

3.1 Méthodes de découverte

Un client découvre un service en essayant ces méthodes dans l’ordre :

Configuration manuelle. L’utilisateur saisit directement l’adresse du service.
Sondage des adresses locales conventionnelles. Le client demande /.well-known/lmsp.json à des adresses candidates. Les candidates conventionnelles sont http://127.0.0.1:17832 et http://[::1]:17832.
Découverte sur le réseau local. Le client recherche _lmsp._tcp.local. avec mDNS et DNS-SD.

Une méthode réussit lorsqu’elle fournit une description de service valide (section 3.3). Une adresse saisie manuellement par l’utilisateur l’emporte toujours sur celles qui sont découvertes.

3.2 Annonce sur le réseau local

DNS-SD utilise des enregistrements PTR pour trouver les instances de service, des enregistrements SRV pour obtenir l’hôte et le port, et des enregistrements TXT pour transporter un peu d’information supplémentaire. Combiné à mDNS, il permet une découverte sans configuration sur un réseau local (RFC 6763, RFC 6762).

Voici un exemple d’annonce :

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

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

Clé TXT	Signification
`v`	Version du format d’annonce. `1` pour LMSP 1.0.
`id`	L’identifiant du service, égal à `service.id` dans la description du service.
`path`	Chemin d’URL de la racine du service. Les clients demandent `{path}.well-known/lmsp.json`.
`auth`	Indication d’authentification. `pairing` signifie qu’un client doit s’appairer avant d’utiliser le service.

Règles :

Un service NE DOIT PAS placer de jetons d’accès, de listes de modèles, de chemins de fichiers ni aucune autre information sensible dans l’enregistrement TXT. L’enregistrement sert seulement à localiser le service. Les capacités réelles DOIVENT être lues dans la description du service.
Un service DOIT laisser l’annonce mDNS désactivée par défaut. Elle n’est activée que lorsque l’utilisateur active explicitement la découverte sur le réseau local. Un service utilisé uniquement sur la machine locale ne s’annonce pas.
Un service qui s’annonce sur le réseau local doit écouter au-delà de loopback, ce qui n’est permis qu’en mode LAN (section 10.5).
Un client DOIT traiter l’enregistrement TXT comme une indication non vérifiée, et confirmer le service en lisant sa description.

3.3 Description du service

GET /.well-known/lmsp.json

Un service DOIT servir ce document avec le type application/json, sans exiger d’authentification.

{
  "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"
}

Champ	Signification
`protocol`	Toujours `"lmsp"`.
`versions`	Les versions de LMSP prises en charge par le service, sous forme de chaînes `major.minor`.
`service`	`id` est un identifiant de service stable, `name` un nom d’affichage et `version` la version du logiciel du service.
`interfaces`	Les interfaces proposées. Chacune a un `kind` (`lmsp`, `openai` ou `ollama`), une `version`, une `url` de base et un `transport`. Pour `openai`, `version` nomme les familles d’API servies, comme `responses+chat`.
`capabilities`	Indicateurs booléens de fonctionnalités, énumérés ci-dessous.
`authentication`	`type` vaut `bearer`. `pairing_url` est l’adresse où les clients échangent un code d’appairage contre un jeton (section 10.2).
`openapi`	URL du document OpenAPI qui décrit l’interface LMSP.

Indicateurs de capacité :

Indicateur	Signification
`streaming`	Les réponses peuvent être diffusées sous forme d’événements envoyés par le serveur. DOIT valoir `true` dans la version 1.0.
`tasks`	Les tâches asynchrones sont disponibles. DOIT valoir `true` dans la version 1.0.
`event_resume`	On peut s’abonner aux flux d’événements des tâches et les reprendre (`GET /lmsp/v1/tasks/{task_id}/events`).
`conversations`	Le service stocke les réponses : `store` et `previous_response_id` fonctionnent et `GET /lmsp/v1/responses/{response_id}` est disponible.
`model_management`	Les modèles peuvent être chargés et déchargés explicitement.

3.4 Comportement du client

Un client :

DEVRAIT sélectionner la version la plus élevée de versions qu’il prend lui aussi en charge.
DEVRAIT choisir l’interface LMSP ou l’interface OpenAI dans interfaces, selon ce qu’il sait parler.
DOIT utiliser uniquement les capacités que la description déclare. Un indicateur absent signifie false.
DOIT ignorer les champs d’extension qu’il ne reconnaît pas.
DEVRAIT relire périodiquement la description du service, ainsi que lorsqu’une requête échoue, au lieu de la mettre en cache indéfiniment.
DEVRAIT mémoriser un service choisi par service.id plutôt que par son adresse, car les adresses peuvent changer.