# Entwickler

Drei Dinge, die du auf URnetwork bauen kannst, und drei verschiedene
Zugangsnachweise. Den richtigen zu wählen ist die erste Entscheidung, und der
Unterschied ist nicht kosmetisch.

| Du baust | Beginne mit | Zugangsnachweis |
| --- | --- | --- |
| Eine App oder ein Gerät, das sich mit URnetwork verbindet | [SDK](/docs/getting-started-sdk), dann die [SDK-Tour](/docs/tour-sdk) | Ein Konto-JWT, eingetauscht gegen eines mit einer `clientId` |
| Einen Anwendungs-Client, der TCP, UDP, TLS/DTLS oder Direct Sockets über ein Device nutzt | [Sockets](/docs/socket) | Ein initialisiertes Device mit einem verfügbaren Verbindungspfad |
| Automatisierung in deinem eigenen Netzwerk | [Operator-API](/docs/api) | Dein Netzwerk-JWT oder ein `urn_`-API-Key |
| Ein Produkt, bei dem sich Menschen anmelden und es damit in ihr Netzwerk aufnehmen | [Mit URnetwork anmelden](/docs/sign-in-with-urnetwork) (Sign in with URnetwork) | Eine an dich ausgegebene OAuth-`client_id` |

Die Trennlinie, auf die es ankommt, ist, **in wessen Netzwerk du handelst**.
Mit dem SDK und der Operator-API handelst du in deinem eigenen, mit einem
Zugangsnachweis, den du hältst und kontrollierst. Bei „Mit URnetwork anmelden“
nimmt eine Person deine Software in *ihres* auf — diesen Zugangsnachweis hältst
du nie, sie erteilt ihn, und sie kann ihn wieder entziehen.

## Das SDK

Beginne mit der [Installation](/docs/install-sdk) und nutze dann den
[Beispiel-Browser](/docs/examples) für ausführbare Programme in zwölf Sprachen.
Jede Sprache hat einen Installations-Guide und ein Socket-Verzeichnis mit
lauffähigen HTTP-Client-Integrationen.

Das Go-SDK, das JS/WASM-SDK und die CGo-ABI teilen sich eine einzige
Netzwerk-Engine. Die Desktop-Sprachpakete wickeln das CGo-Modul ein; Android
nutzt das gomobile-AAR und Swift das Apple-XCFramework. JavaScript bringt
Beispiele sowohl für Node als auch für den Browser mit, die ein gehostetes
Device nutzen.

[Sockets](/docs/socket) erklärt, wie du die Userspace-Verbindungen eines Device
für TCP, UDP, TLS/DTLS und Direct Sockets nutzt. Anwendungen können diese
Sockets nutzen, ohne ein System-VPN zu installieren. Das DeviceRemote eines
Browsers nutzt den Paketpfad seines gehosteten Device; ein TUN-Interface im
Besitz des Browsers braucht es nicht.

[Welches Binding du wählen solltest](/docs/getting-started-sdk#which-binding)
stellt die Abwägungen nebeneinander dar. Triff diese Entscheidung, bevor du
Code schreibst: Sie legt dein Prozessmodell fest, nicht bloß deine Syntax.

## Operator-API

Die HTTP-API hinter URnetwork. Sie übernimmt den Bootstrap des
`connect`-Protokolls, gibt die JWTs aus, mit denen sich Clients
authentifizieren, und stellt die Matchmaking-Transaktionen bereit, auf denen
das Netzwerk läuft. Jede Route und jedes Schema steht unter
[/docs/api](/docs/api), generiert aus der Spezifikation.

Sie ist auf **dein** Netzwerk beschränkt. Der Name legt die Lesart nahe, sie
wirke auf das Netzwerk als Ganzes; das tut sie nicht.

Über einen Schritt stolpert fast jeder: Die `/auth`-Routen geben ein JWT
**ohne** `clientId` zurück, und das `connect`-Protokoll verlangt eines **mit**
ihr. Nutze die `/network`-Routen, um es einzutauschen. Ein Netzwerk ist ein
global eindeutiges Subnetz (`xyz.ur.network`); eine `clientId` ist eine
16-Byte-Adresse, gleichwertig mit einer IPv6-Adresse und ausgedrückt als UDID.

## Mit URnetwork anmelden

Damit nehmen Menschen deine App oder deinen Agenten in ihr privates Netzwerk
auf, sodass sich deine Software mit allem abstimmen kann, was sie dort sonst
noch laufen haben. Das ist in Entwicklung und noch nicht live — was es heute
schon gibt, steht auf der [Seite selbst](/docs/sign-in-with-urnetwork).

Der [MCP-Server](/agents) ist keine vierte Kategorie. Er ist ein
Ressourcenserver, erreichbar mit einem Token aus „Mit URnetwork anmelden“, und
ein ausgearbeitetes Beispiel des Musters.

## Token-Grenzen

Die beiden Systeme für Zugangsnachweise sind mit **disjunkten Schlüsselmengen**
signiert. Das ist eine Sicherheitsgrenze, keine Konvention: Ein Token aus „Mit
URnetwork anmelden“ ist kein Plattform-Zugangsnachweis, und wer eines dort
vorlegt, wo ein Plattform-JWT erwartet wird, scheitert konstruktionsbedingt.
OAuth-Access-Tokens sind außerdem an eine Audience gebunden — jedes verifiziert
für genau eine Ressource und wird überall sonst abgelehnt.

Es gibt genau einen vorgesehenen Übergang, und er ist eine Brücke, keine
Umgehung: Eine aufgenommene App tauscht ihr OAuth-Token gegen ein Plattform-JWT
mit einer `clientId`, beschränkt auf das Netzwerk, in das sie aufgenommen
wurde. Der Tausch ist eine serverseitig getroffene Autorisierungsentscheidung;
kein einzelnes Token verifiziert an zwei Stellen.

Wenn du zwei Zugangsnachweise hältst und einer davon nicht funktioniert, liegt
es meistens daran.