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, dann die SDK-Tour | 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 | Ein initialisiertes Device mit einem verfügbaren Verbindungspfad |
| Automatisierung in deinem eigenen Netzwerk | Operator-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 (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 und nutze dann den Beispiel-Browser 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 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 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, 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.
Der MCP-Server 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.