# So funktioniert URnetwork

URnetwork ist ein Privacy-Netzwerk, getragen von seinen Mitgliedern. Dein
Datenverkehr verlässt das Netz über das Gerät eines anderen Mitglieds, nicht
über einen VPN-Server im Rechenzentrum. Websites sehen die IP-Adresse dieses
Geräts statt deiner. Dieser Überblick erklärt den Pfad und was jede Partei
sehen kann.

Die Exits sind Tausende Mitgliedsgeräte in mehr als 2.000 echten Städten in
über 90 Ländern, keine virtuellen IPs aus einer Handvoll Rechenzentren. Die
Live-Zahlen stehen unter `api.bringyour.com/stats/last-90`.

## Der Pfad

Der Datenverkehr nimmt vier Etappen: du → Extender → Operator → Provider →
Internet.

- **Client.** Die App oder SDK-Instanz auf deinem Gerät. Ein *Netzwerk* ist
  URnetworks Wort für dein Konto, die Abrechnungs- und Identitätseinheit; es
  kann viele Nutzer, Geräte und Clients umfassen.
- **Extender.** Ein von Freiwilligen betriebener Weiterleitungs-Hop auf einer
  unabhängigen Adresse, und die erste Etappe. Er leitet deine verschlüsselte
  Sitzung an die Plattform weiter, ohne sie zu terminieren, und trägt damit
  Bytes, die er nicht lesen kann. Als dein erster Hop sieht er allerdings
  deine IP-Adresse.
- **Operator.** BringYour, Inc., die Partei, die das Netzwerk koordiniert.
  Ihre Plattform (`connect.bringyour.com`, `api.bringyour.com`)
  authentifiziert Clients, vermittelt dir Provider, leitet Datenverkehr
  weiter und wickelt Verträge und Zahlungen ab.
- **Provider.** Ein Mitgliedsgerät, das seine Internetverbindung teilt und
  deinen Datenverkehr ins Internet weiterleitet — Websites sehen also eine
  Privatanschluss-Adresse in der Stadt des Providers.

Operator und Provider sind die beiden Relay-Parteien, und das Design teilt
das Wissen zwischen ihnen auf. Der Extender ist ein Erreichbarkeits-Hop
außerhalb dieser Aufteilung und fügt keine eigene Verschlüsselung hinzu. Er
hält das Netzwerk erreichbar, wo die Plattform blockiert ist.

![Der Pfad: vier Etappen, aufgeteiltes Wissen — was jede Partei sehen kann und was nicht](/docs-assets/diagram-the-path.svg)

## Wer was sehen kann

Auf dem Standardpfad hält keine einzelne Partei zugleich deine Identität und
deine Aktivität. Diese Aussage ruht auf zwei Eigenschaften mit
unterschiedlicher Reichweite.

**Der Provider erfährt nie, wer du bist.** Der Operator steht zwischen dir
und dem Provider, also sieht der Provider eine Geräte-ID und die Ziele, die
er bedient — nie deine Adresse. Das gilt auf jedem Relay-Pfad, ohne eine
Einstellung, die man falsch setzen könnte.

**Der Operator kann nicht lesen, was du sendest.** Die Sitzung zwischen
Client und Provider ist Ende-zu-Ende versiegelt, in den nativen Apps
standardmäßig an — der Operator trägt also Chiffretext plus Timing und
Volumen. Das gilt auf dem versiegelten Standardpfad; die Modi unten zeigen
die Pfade ohne Versiegelung.

Die Browser-Erweiterung und die Proxy-Endpunkte haben gar keine versiegelte
Sitzung. Das ist Geltungsbereich, kein Standardwert, und es liegt an der
Architektur: Ein Browser oder ein einfacher Proxy-Client kann die Engine des
Netzwerks nicht ausführen, also betreibt der Operator das Client-Gerät aus
der Ferne und übersetzt zwischen den Protokollen — eine Versiegelung, die von
diesem Gerät ausginge, begänne im Inneren des Operators, also genau der
Partei, die sie blind machen soll. Die Implementierung hat die Versiegelung
dafür eingetauscht, diese Plattformen überhaupt zu erreichen. Dort hält nicht
Verschlüsselung, sondern eine per Test festgenagelte Speicherdisziplin den
Operator davon ab, deine Ziele anzusammeln
([Bedrohungsmodell](/docs/threat-model) §2.4).

| Modus | Operator sieht | Provider sieht | Standard und Verfügbarkeit |
|---|---|---|---|
| **Relay, versiegelt** | Konto/Quellverbindung, Provider-Zuordnung, Chiffretext sowie Timing/Volumen | Ziel-Datenverkehr, Geräte-/Vertrags-ID, **nicht** deine echte Quell-IP | der native Standard, ab Werk |
| **Relay, Standard** | Konto/Quellverbindung, Provider-Zuordnung, innere Ziele und Paketbytes | Ziel-Datenverkehr, Geräte-/Vertrags-ID, **nicht** deine echte Quell-IP | Browser- und Proxy-Pfade oder Versiegelung aus; ist sie an, wird ein Provider, zu dem sie sich nicht aufbauen lässt, übersprungen statt hier bedient |
| **Direkt** | weniger Relay-Beteiligung | **deine echte Quell-IP** und Ziel-Datenverkehr | opt-in, durch Ausschalten von Starke Anonymisierung (Strong Anonymization) |

Die Tabelle ist maßgeblich. Das [Bedrohungsmodell](/docs/threat-model)
spielt dieselbe Aufteilung gegen benannte Angreifer durch, einschließlich
eines feindseligen Operators und kolludierender Provider.

## Warum vier Etappen

Geschwindigkeit ist ein Designziel, kein Zugeständnis. Jeder zusätzliche Hop
verlängert den Hin- und Rückweg zwischen dir und dem Internet — deshalb tun
lange Ketten im Alltag weh. Den Pfad bei vier Etappen zu begrenzen hält das
Wissen aufgeteilt, bei Geschwindigkeit auf Streaming-Niveau. URnetwork
beziffert die durchschnittliche Streaming-Geschwindigkeit im Netzwerk mit
40 Mbps+.

Die formale Beschreibung: ein latenzbegrenztes Multi-Hop-Design mit
Datentrennung. Das Wire-Protokoll unterstützt das Verketten weiterer
Provider-Zwischenstationen; das ausgelieferte Netzwerk nutzt den Pfad mit
einem einzelnen Provider. Andere Designs machen andere Abwägungen. Tor
bezahlt längere Ketten mit Latenz. Apples Private Relay ist eine
verschlüsselte Aufteilung auf zwei Parteien, in geschlossenen
Implementierungen, bei der ein Unternehmen beide Parteien auswählt und
bezahlt. Die meisten VPNs versuchen gar keine Aufteilung. Die
[Vergleichskarte](/docs/comparison) geht sie Produkt für Produkt durch.

## Was beim Verbinden passiert

1. **Anmelden.** Die App meldet sich mit einem Token an, das nach etwa einem
   Tag abläuft und sich automatisch erneuert — ein gestohlenes Token wird
   also schnell wertlos. Techniker nennen es JWT. Konten können E-Mail oder
   Telefonnummer nutzen, Google- oder Apple-Anmeldung, eine Solana- oder
   Bittensor-Wallet-Signatur, eine Seedphrase oder ein Sofort-Konto (Instant
   Account): ohne E-Mail, in einem Tipp erstellt, dessen ganzer
   Zugangsnachweis eine Wiederherstellungs-Seedphrase ist. Die Phrase ist mit
   Mullvads Nummernkonten vergleichbar und übersteht eine Neuinstallation;
   der Server erzeugt sie, zeigt sie genau einmal und behält nur Hashes —
   sie zu verlieren heißt, das Konto zu verlieren.
2. **Die Plattform erreichen.** Der Client öffnet einen verschlüsselten Kanal
   zur Plattform: TLS über WebSocket, oder QUIC/HTTP-3, wo das Netz es
   zulässt. Der Kanal läuft durch einen Extender und terminiert an der
   Plattform. Direkte Routen werden zuerst im Wettlauf probiert; die
   Extender-Etappe übernimmt, wenn sie scheitern.
3. **Provider finden.** Der Client fragt nach Providern passend zu deiner
   Auswahl: bester verfügbarer, ein Land aus der Liste oder eine Stadt, die
   du findest, indem du ihren Namen ins Suchfeld tippst. Die Plattform
   bewertet Kandidaten laufend nach Zuverlässigkeit und gemessener
   Geschwindigkeit und liefert eine sortierte Auswahl zurück.
4. **Verträge öffnen und los.** Der Client hält ein *Fenster* aus mehreren
   Providern und verteilt deine Verbindungen darüber. Das Standardprofil
   fährt zwei Fenster: ein Qualitäts-Set aus 2–6 Providern für HTTPS und ein
   Geschwindigkeits-Set aus 1–2 für alles andere. Typischerweise sind drei
   bis acht Provider gleichzeitig aktiv. Verbindungen zu einer bestimmten
   Website bleiben auf einen Provider gepinnt, sodass diese Website für deine
   ganze Sitzung eine stabile Adresse sieht. Ein Provider, der schwächelt
   oder wegfällt, wird ersetzt; der Rest des Fensters fängt seine Arbeit auf.
   Jedes Byte bewegt sich unter einem *Transfervertrag* (transfer contract),
   der Abrechnungseinheit, die misst, was jeder Provider trägt.

![Plurale Exit-Identität: das Provider-Fenster — Bindung pro Website und Failover](/docs-assets/diagram-provider-window.svg)

Deine Exit-Identität ist plural: mehrere Provider zugleich, mit Wechsel über
die Zeit, sodass kein einzelner Exit mehr als einen Ausschnitt deines Surfens
sieht. Das Fenster ist zugleich die Geschwindigkeitsstrategie:
Privatanschlüsse schwanken stärker als Server im Rechenzentrum, und das
Abwerfen langsamer Provider hält Streaming flüssig.

## Verschlüsselung

Der Kanal zwischen Client und Plattform ist immer verschlüsselt: TLS 1.3
oder QUIC.

**Die versiegelte Sitzung.** Die App verschlüsselt den Datenverkehr bis zum
Provider durch, sodass der Operator Bytes weiterleitet, die er nicht lesen
kann. Bei ihm kommen Chiffretext plus Timing und Volumen an. Der Schalter
heißt **Post-Quanten-Verschlüsselung** (Post Quantum Encryption) im
Connect-Drawer der Android-, iOS-, macOS-, Windows- und Linux-Apps,
standardmäßig an in allen fünf. Die Versiegelung ist ein TLS-1.3-Handshake
direkt zwischen Client und Provider, mit dem hybriden
Post-Quanten-Schlüsselaustausch **X25519MLKEM768** und AES-256-GCM pro
Nachricht. Identitätsschlüssel sind Ed25519; „Post-Quanten“ meint nur den
Schlüsselaustausch.

Geltungsbereich: Bei eingeschalteter Versiegelung trägt ein Provider, der sie
nicht aufbauen kann, deinen Datenverkehr überhaupt nicht. Der Client weigert
sich, Anwendungsdaten im Klartext zu senden, statt still zurückzufallen — ein
Provider, zu dem sich keine Versiegelung aufbauen lässt, wird übersprungen
und nicht unversiegelt genutzt. Jeder aktuelle Provider-Build unterstützt die
Versiegelung, das betrifft also überwiegend ältere Builds, und es kostet
Verfügbarkeit statt Vertraulichkeit. Schalte die Post-Quanten-Verschlüsselung
aus, und das alte Verhalten kehrt zurück: Der Datenverkehr kann dann den
Standardpfad nehmen, auf dem die Plattform Paketadressen und -inhalte lesen
kann.

Grenze: Noch meldet keine App, ob eine bestimmte Verbindung versiegelt ist.
Diese Lücke ist real, aber nicht mehr die gefährliche — still herabgestuft
werden kannst du bei eingeschalteter Versiegelung nicht. Das und alles
Übrige, wogegen URnetwork nicht schützt, steht im
[Bedrohungsmodell](/docs/threat-model).

**Starke Anonymisierung, und der Direktmodus.** Ein Provider sieht die
Zieladressen des Datenverkehrs, den er bedient — wie heute dein
Internetanbieter. Wer du bist, erfährt er nicht: Standardmäßig sieht er nie
deine echte IP, nur die Plattform sieht sie. Dieser Standard ist der Schalter
**Starke Anonymisierung** im Connect-Drawer, ab Werk an. Ihn auszuschalten
wählt den *Direktmodus*: Der Client spricht direkt mit dem Provider, und der
Durchsatz steigt. Der Preis: Dieser Provider sieht jetzt deine echte Adresse.
Gehostete Profile erzwingen unabhängig davon, dass der Direktmodus aus ist.

![Was die versiegelte Sitzung ändert — Standardpfad vs. versiegelte Sitzung, und was passiert, wenn sich zu einem Provider keine Versiegelung aufbauen lässt](/docs-assets/diagram-sealed-session.svg)

## Was jede Partei sieht

| Partei | Sieht | Sieht nicht, oder behält nicht |
|---|---|---|
| Operator (Plattform) | dein Konto; deine Adresse im Moment des Verbindens; grob Stadt/Region/Land, daraus abgeleitet; welche Provider du genutzt hast; Bytezahlen; Chiffretext mit Timing und Volumen | Paketziele und -inhalte (standardmäßig versiegelt); deine rohe Adresse (stattdessen ein Block-Hash mit geheimem Schlüssel); irgendein Zielfeld im Transferregister |
| Provider | Ziel-IPs/SNI des Datenverkehrs, den er nach außen trägt; eine Geräte-ID am Vertrag | deine Identität oder echte IP auf den Relay-Pfaden; nur der Operator kann die Geräte-ID zu einem Konto auflösen |
| Extender | verschlüsselte Bytes; deine IP | irgendetwas im Inneren des Tunnels |
| Website | eine Privatanschluss-Adresse des Providers | deine IP; die Identität deines Internetanbieters |

Hinter der Operator-Zeile:

- Die gespeicherte Form deiner Verbindungsadresse ist ein Einweg-Hash mit
  geheimem Schlüssel über den umgebenden /29-Block (IPv4) bzw. /56-Block
  (IPv6), nicht die Adresse selbst. Ein aus der Adresse abgeleitetes grobes
  Stadt/Region/Land wird pro Verbindung behalten.
- Die Disziplin steckt im Code, nicht nur in einer Richtlinie. HTTP-Logging
  läuft durch eine Allowlist aus fünf Headern. Das Transferregister
  verzeichnet Client- und Netzwerk-IDs und Bytezahlen — ohne ein Feld für
  Ziel, Host, URL, SNI, Port oder Domain, in das man schreiben könnte. Der
  Proxy-Datenpfad loggt nichts, festgenagelt durch einen Regressionstest.
- Die Versiegelung macht deinen Datenverkehr für den Operator unlesbar. Die
  Speicherdisziplin deckt ab, was der Operator weiterhin sieht
  (Provider-Zuordnungen, Bytezahlen, groben Standort), und springt ein, wo
  es keine Versiegelung gibt: die Browser-Erweiterung, die Proxy-Endpunkte
  und die nativen Apps mit ausgeschalteter Versiegelung.
- Grenze: Das sind Eigenschaften der Datensätze, die der Code schreibt. Die
  Zugriffslogs des vorgelagerten Load-Balancers wurden nie geprüft, und
  Zeilen mit Adressen und SNI erreichen das stderr der Dienste, dessen Ziel
  in Produktion nicht geklärt ist. Vollständige Aufstellung: das
  [Bedrohungsmodell](/docs/threat-model).

![Was der Operator speichert — und was nie existiert](/docs-assets/diagram-what-is-stored.svg)

## Open Source, und was nicht auditiert ist

Der gesamte Stack ist Open Source: die Apps, das SDK, die Protokoll-Engine
und der eigene Server-Code des Operators — die hier beschriebenen
Mechanismen lassen sich also nachlesen statt glauben. Open Source belegt das
Design, nicht, welcher Build deployt ist.

Kein unabhängiges Audit deckt das Protokoll, die Connect-Engine oder den
Server-Code des Operators ab — die Schicht, auf der die Privacy-Zusagen
liegen. Zwei externe Prüfungen aus 2025 decken andere Flächen ab. Die eine
ist ein unabhängiger Penetrationstest der Web-Anwendung und der API
(April–Mai 2025). Die andere ist eine MASA-AL2-Prüfung der Android-App durch
die Leviathan Security Group, die bestanden wurde; Leviathan grenzt sie
selbst als keine ganzheitliche Sicherheitsbewertung ein. Offener Code unter
dauerhafter Beobachtung ist URnetworks Antwort auf das jährliche
Stichtags-Audit. Vollständige Aufstellung: das
[Bedrohungsmodell](/docs/threat-model).

## Sicher teilen: die ip_security-Schicht

Die eigene Verbindung zu teilen sollte nicht heißen, das rechtliche Risiko
eines Fremden zu erben. Der Provider-Client bringt `ip_security` mit, eine
quelloffene Traffic-Sicherheitsschicht in der Connect-Engine und eine ihrer
größten Komponenten. Sie inspiziert den eigenen Ausgang des Providers,
seinen Exit ins Internet. Riskanter Datenverkehr wird blockiert, bevor er
die Verbindung des Mitglieds verlässt:

- **Filterung der DMCA-Klasse.** Ein zustandsbehafteter Detektor erkennt
  BitTorrent- und Filesharing-Signaturen und verwirft opaken Datenverkehr,
  der zu keinem legitimen Protokoll passt — rechtsverletzende
  Peer-to-Peer-Übertragungen verlassen die Leitung des Mitglieds also nicht.
- **Filterung der CFAA-Klasse.** Muster von unbefugtem Zugriff, Scans und
  Ausnutzung werden ins Leere geleitet — die Verbindung wird so nicht zur
  Startrampe für den Einbruch eines anderen.
- **Ein Detektor, gebaut, um nicht zu sehen.** Die Filesharing-Prüfung
  löscht den Servernamen aus ihrem eigenen Flow-Schlüssel. Sie entscheidet
  anhand von Adressen, Ports und den ersten Bytes eines Flows und führt ihre
  Zähler nach Protokoll und Port, nie nach Adresse.

Ein Treffer erzeugt ein verworfenes Paket. Ein BitTorrent-Treffer sendet
zusätzlich eine Missbrauchsmarkierung an den Operator: die Geräte-ID des
Peers und ein Ja/Nein — ohne Ziel, Domain oder Inhalte. Der Operator liefert
heute keinen Handler für die Markierung aus, beim Empfang wird also nichts
gespeichert. Verwürfe opaker Protokolle bleiben still, ohne Meldung.

Die Schicht läuft am Rand, und zwar auf beiden Seiten davon: auf deinem
Gerät, wenn du dich verbindest — Datenverkehr, den das Netzwerk nicht tragen
wird, erreicht so nie einen Provider — und auf dem Gerät des Providers, wo
der Datenverkehr austritt. Der Operator inspiziert Datenverkehr nicht
zentral, und die Versiegelung umgeht den Filter nicht, denn der Filter läuft
an den Endpunkten, die die Versiegelung verbindet. Mit eingeschaltetem Kill
Switch (ein expliziter Schalter in jeder App, in der Browser-Erweiterung
standardmäßig an) stoppt blockierter Datenverkehr, statt auf deine eigene
Verbindung zurückzufallen. Die meisten Länder haben Gesetze der CFAA- und
DMCA-Familie; ein Standard beantwortet sie an jedem Exit, und URnetwork hält
sich an das Recht überall dort, wohin es ausliefert. Der Filter wird
gepflegt, nicht eingefroren: Seine Bedrohungslisten werden bei jedem Release
aus öffentlichen Malware-, Missbrauchs- und Botnetz-Feeds neu erzeugt
(Spamhaus DROP, der Botnetz-Tracker von abuse.ch, Emerging Threats und
andere) — eine aktuelle App blockiert also den zuletzt bekannten bösartigen
Adressraum. Die [Nutzungsbedingungen](/terms) regeln das Teilen.

![ip_security: Durchsetzung am Rand, ohne Überwachung — erkannter Datenverkehr wird am eigenen Ausgang des Providers ins Leere geleitet](/docs-assets/diagram-ip-security.svg)

## Durch Netzsperren hindurch

Extender tragen den Pfad durch lokale und regionale Firewalls. Jeder
antwortet mit TLS auf glaubwürdigen Dienst-Ports (443, DNS-over-TLS 853,
LDAPS 636 und andere) und wirkt auf Scanner wie ein falsch konfiguriertes
CDN. Jeder ist fest darauf verdrahtet, den verschlüsselten Strom über eine
eigene Adresse an die Plattform weiterzuleiten — `connect.bringyour.com` zu
blockieren versperrt also nicht den Weg hinein. Der Client rotiert durch
generierte Extender-Personas, mit zufälliger Paketfragmentierung und
-umordnung, bis eine funktioniert. Wo nur DNS herauskommt, formt ein
DNS-förmiger Transport QUIC-Pakete zu DNS-Anfragen und -Antworten um. Einen
Extender betreiben kann jeder.

![Durch Netzsperren hindurch: Extender und der DNS-förmige Transport](/docs-assets/diagram-getting-through.svg)

## Provider und Abdeckung

Standorte sind präsenzgestützt: Eine Stadt wird nur angeboten, solange dort
das Gerät eines Mitglieds online ist. Die Plattform geolokalisiert die
Verbindung, die sie beobachtet; ein Provider kann nicht selbst eine Stadt
deklarieren. Eine Adresse, die nach Rechenzentrum, VPN oder neu
announciertem Adressblock aussieht, wird herabgestuft statt geglaubt.
Grenze: Keine außenstehende Partei hat die Flotte vermessen, und nichts
weist nach, dass die einem Client angebotenen Provider voneinander oder vom
Operator unabhängig sind. Siehe das [Bedrohungsmodell](/docs/threat-model).

Das Teilen der Verbindung ist opt-in und gibt ungenutzte Bandbreite ab: aus,
bis du es einschaltest, nur über WLAN, sofern du Mobilfunk nicht erlaubst,
und wahlweise auf öffentlichen Datenverkehr oder allein auf deine eigenen
Geräte gerichtet. Öffentlicher Datenverkehr wird gemessen: Die Plattform
stempelt jeden Transfervertrag mit einem Geheimnis, das nur dieser Provider
hält — der Provider kann also prüfen, dass ein Vertrag echt ist und für das
Publikum, dem er zugestimmt hat. Die Treuhand ist in Bytes bemessen; beide
Enden melden, was sie übertragen haben, und der abgerechnete Wert ist ihr
Mittel innerhalb einer Toleranz. Provider nehmen am UR Protocol teil;
[ur.xyz](https://ur.xyz) dokumentiert die Vergütung, und diese Seite
wiederholt sie nicht. Kostenlose Tarife gibt es, weil zahlende Mitglieder
das Wachstum des Netzwerks finanzieren. Teilen kann jeder.

## Tarife und die Operator-API

Es gibt zwei Tarife: einen kostenlosen mit täglichem Datenkontingent und Pro
mit einem großen monatlichen Kontingent, mehr gleichzeitigen Clients und den
Proxy- und WireGuard-Extras. Pro lässt sich mit On-Chain-USDC aus einer
Wallet bezahlen. Das Kontingent wird gezählt, nicht gedrosselt: Ist es
aufgebraucht, öffnet das Netzwerk keine neuen Transfers mehr, statt dich
auszubremsen. Der Tunnel wird still, deine eigene Verbindung bleibt
unberührt, und das Kontingent füllt sich in seinem Zyklus wieder auf.
Aktuelle Zahlen stehen auf [ur.io/products](https://ur.io/products),
maschinenlesbar unter `GET https://api.bringyour.com/x402/skus`.

Alles, was die Apps tun, läuft über die öffentliche Operator-REST-API
(Auth, Geräte, Provider-Discovery, Abos, Statistiken), dokumentiert in der
[API-Referenz](https://ur.io/docs/api). Agents bekommen erstklassigen
Zugang: einen MCPv2-Server unter `mcp.bringyour.com` (OAuth; die Tools
`providerLocations` und `fetch`) und x402-Kauf nach Bedarf. Siehe
[ur.io/agents](https://ur.io/agents).

## Fallback-Endpunkte: HTTPS, SOCKS5, WireGuard

Für Software, die das SDK nicht einbetten kann, betreibt der Operator
Brücken-Endpunkte: einen HTTPS-CONNECT-Proxy, SOCKS5 und einen
WireGuard-Endpunkt für unveränderte WireGuard-Apps. SOCKS5 unterstützt
CONNECT und UDP-Associate; BIND wird nicht unterstützt, und UDP-Datagramme
über 2 KiB werden bewusst verworfen. Grenze: Der WireGuard-Pfad vergibt eine
stabile Tunnel-Adresse aus einem privaten Pool der Plattform, nicht deine
echte IP. Diese stabile Adresse erlaubt es, einen Client über mehrere
Provider hinweg zu korrelieren, und der Endpunkt gibt dem Client einen
festen öffentlichen Resolver mit (1.1.1.1). Die Apps und das SDK bleiben der
privateste Weg, das Netzwerk zu nutzen.

## Wie es weitergeht

- Einrichten: die [Erste-Schritte-Guides](/docs) für Android, iOS, macOS,
  Windows, Linux, die Browser-Erweiterung und das SDK.
- Tiefe pro Plattform: die Tour-Docs.
- Andere Produkte: die Compare-Docs und die
  [Vergleichskarte](/docs/comparison).
- Das Protokoll: [ur.xyz](https://ur.xyz) für Whitepaper, Ökonomie und
  Provider-Vergütung.