# Cómo funciona URnetwork

URnetwork es una red de privacidad impulsada por sus miembros. Tu tráfico sale
a internet por el dispositivo de otro miembro, no por un servidor VPN en un
centro de datos. Los sitios web ven la dirección IP de ese dispositivo en
lugar de la tuya. Esta visión general explica la ruta y lo que cada parte
puede ver.

Las salidas son miles de dispositivos de miembros repartidos por más de 2.000
ciudades reales en más de 90 países, no IPs virtuales servidas desde un puñado
de centros de datos. Los recuentos en vivo se publican en
`api.bringyour.com/stats/last-90`.

## La ruta

El tráfico recorre cuatro tramos: tú → extensor → operador → proveedor →
internet.

- **Cliente.** La app o la instancia del SDK en tu dispositivo. Una *red*
  (*network*) es el término de URnetwork para tu cuenta, la unidad de
  identidad y facturación; puede contener varios usuarios, dispositivos y
  clientes.
- **Extensor.** Un salto de reenvío gestionado por voluntarios en una
  dirección independiente, y el primer tramo. Reenvía tu sesión cifrada a la
  plataforma sin terminarla, así que transporta bytes que no puede leer. Como
  es tu primer salto, sí ve tu dirección IP.
- **Operador.** BringYour, Inc., la parte que coordina la red. Su plataforma
  (`connect.bringyour.com`, `api.bringyour.com`) autentica a los clientes, te
  empareja con proveedores, retransmite el tráfico y gestiona los contratos y
  los pagos.
- **Proveedor.** El dispositivo de un miembro que comparte su conexión y
  reenvía tu tráfico a internet, de modo que los sitios web ven una dirección
  residencial en la ciudad del proveedor.

El operador y el proveedor son las dos partes retransmisoras, y el diseño
reparte el conocimiento entre ellas. El extensor es un salto de conectividad
fuera de ese reparto y no añade cifrado propio. Mantiene la red accesible
donde la plataforma está bloqueada.

![La ruta: cuatro tramos y conocimiento repartido — qué puede ver cada parte y qué no](/docs-assets/diagram-the-path.svg)

## Quién puede ver qué

En la ruta por defecto, ninguna parte por sí sola reúne tu identidad y tu
actividad. Esa afirmación descansa en dos propiedades con alcances distintos.

**El proveedor nunca sabe quién eres.** El operador se interpone entre tú y el
proveedor, así que el proveedor ve un identificador de dispositivo y los
destinos que sirve, nunca tu dirección. Esto se cumple en toda ruta
retransmitida, sin ningún ajuste que puedas configurar mal.

**El operador no puede leer lo que envías.** La sesión cliente↔proveedor va
sellada de extremo a extremo, activada por defecto en las apps nativas, así
que el operador transporta texto cifrado más tiempo y volumen. Esto se cumple
en la ruta sellada por defecto; los modos de abajo muestran las rutas sin
sellado.

La extensión de navegador y los endpoints proxy no tienen sesión sellada en
absoluto. Es una cuestión de alcance, no un valor por defecto, y es
arquitectónica: un navegador o un cliente proxy corriente no pueden ejecutar
el motor de la red, así que el operador ejecuta el dispositivo del cliente de
forma remota y traduce entre protocolos — un sellado iniciado desde ese
dispositivo empezaría dentro del operador, la parte a la que el sellado existe
para cegar. La implementación cambió el sellado por llegar siquiera a esas
plataformas. Allí, lo que impide que el operador acumule tus destinos es una
disciplina de almacenamiento fijada por un test, no el cifrado
([modelo de amenazas](/docs/threat-model) §2.4).

| Modo | El operador ve | El proveedor ve | Valor por defecto y disponibilidad |
|---|---|---|---|
| **Retransmitido sellado** | conexión de cuenta/origen, asociación con proveedores, texto cifrado y tiempo/volumen | tráfico de destino, id de dispositivo/contrato, **no** tu IP de origen real | el valor por defecto nativo, de fábrica |
| **Retransmitido estándar** | conexión de cuenta/origen, asociación con proveedores, destinos interiores y bytes de los paquetes | tráfico de destino, id de dispositivo/contrato, **no** tu IP de origen real | las rutas del navegador y del proxy, o el sellado desactivado; con el sellado activado, un proveedor con el que no se puede sellar se omite en vez de atenderte en este modo |
| **Directo** | menos intervención en la retransmisión | **tu IP de origen real** y el tráfico de destino | opcional, desactivando Anonimización fuerte (Strong Anonymization) |

La tabla es canónica. El [modelo de amenazas](/docs/threat-model) aplica el
mismo reparto frente a adversarios con nombre, incluidos un operador hostil y
proveedores en connivencia.

## Por qué cuatro tramos

La velocidad es un objetivo de diseño, no una concesión. Cada salto adicional
alarga el viaje de ida y vuelta entre tú e internet, y por eso las cadenas
largas duelen en el uso diario. Acotar la ruta a cuatro tramos mantiene el
reparto de conocimiento a velocidad apta para streaming. URnetwork sitúa la
velocidad media de streaming en la red en más de 40 Mbps.

La descripción formal es un multisalto acotado en latencia con separación de
datos. El protocolo de transmisión admite encadenar proveedores intermedios
adicionales; la red en producción usa la ruta de un solo proveedor. Otros
diseños hacen otros intercambios. Tor paga las cadenas más largas con
latencia. Private Relay de Apple es un reparto cifrado entre dos partes,
dentro de implementaciones cerradas, con ambas partes elegidas y pagadas por
una sola empresa. La mayoría de las VPN no intentan reparto alguno. El
[mapa de comparativas](/docs/comparison) los recorre producto a producto.

## Qué ocurre cuando te conectas

1. **Inicio de sesión.** La app inicia sesión con un token que caduca en
   torno a un día y se renueva automáticamente, así que un token robado se
   vuelve inútil rápido. Los ingenieros lo llaman JWT. Las cuentas pueden usar
   correo o teléfono, inicio de sesión con Google o Apple, la firma de una
   cartera Solana o Bittensor, una frase de recuperación (seedphrase), o una
   Cuenta instantánea (Instant Account) de un toque y sin correo cuya
   credencial completa es una frase de recuperación. La frase es comparable a
   las cuentas numeradas de Mullvad y sobrevive a una reinstalación; el
   servidor la genera, la muestra una sola vez y guarda solo hashes, así que
   perderla es perder la cuenta.
2. **Llegar a la plataforma.** El cliente abre un canal cifrado hasta la
   plataforma: TLS sobre WebSocket, o QUIC/HTTP-3 donde la red lo permite. El
   canal atraviesa un extensor y termina en la plataforma. Primero compiten
   las rutas directas; el tramo del extensor toma el relevo cuando fallan.
3. **Encontrar proveedores.** El cliente pide proveedores que encajen con tu
   selección: el mejor disponible, un país de la lista o una ciudad que
   encuentras tecleando su nombre en el buscador. La plataforma puntúa a los
   candidatos de forma continua por fiabilidad y velocidad medida y devuelve
   un conjunto ordenado.
4. **Abrir contratos y listo.** El cliente mantiene una *ventana* de varios
   proveedores y equilibra tus conexiones entre ellos. El perfil por defecto
   ejecuta dos ventanas: un conjunto de calidad de 2–6 proveedores para HTTPS
   y un conjunto de velocidad de 1–2 para todo lo demás. Lo habitual es tener
   entre tres y ocho proveedores activos. Las conexiones a un sitio dado
   quedan fijadas a un proveedor, de modo que ese sitio ve una sola dirección
   estable durante toda tu sesión. Un proveedor que rinde poco o se cae es
   reemplazado; el resto de la ventana absorbe su trabajo. Cada byte viaja
   bajo un *contrato de transferencia*, la unidad contable que mide lo que
   transporta cada proveedor.

![Identidad de salida plural: la ventana de proveedores — afinidad por sitio y relevo ante fallos](/docs-assets/diagram-provider-window.svg)

Tu identidad de salida es plural: varios proveedores a la vez, rotando con el
tiempo, así que ninguna salida ve más que una porción de tu navegación. La
ventana es también la estrategia de velocidad: las conexiones residenciales
varían más que los servidores de centro de datos, y descartar las lentas
mantiene el streaming fluido.

## Cifrado

El canal cliente↔plataforma siempre va cifrado: TLS 1.3 o QUIC.

**La sesión sellada.** La app cifra el tráfico hasta el proveedor, de modo que
el operador retransmite bytes que no puede leer. Lo que le llega es texto
cifrado más tiempo y volumen. El control se llama **Cifrado poscuántico**
(Post Quantum Encryption) en el panel de conexión de las apps de Android, iOS,
macOS, Windows y Linux, activado por defecto en las cinco. El sellado es un
handshake TLS 1.3 directo entre cliente y proveedor, con el intercambio de
claves poscuántico híbrido **X25519MLKEM768** y AES-256-GCM por mensaje. Las
claves de identidad son Ed25519; "poscuántico" se refiere solo al intercambio
de claves.

Alcance: con el sellado activado, un proveedor que no consiga establecerlo no
transporta tu tráfico en absoluto. El cliente se niega a enviar datos de
aplicación en claro en vez de recurrir en silencio al respaldo — un proveedor
con el que no se puede sellar se omite, no se usa sin sellar. Todas las
compilaciones actuales de proveedor admiten el sellado, así que esto afecta
sobre todo a las antiguas, y cuesta disponibilidad, no confidencialidad.
Desactiva Cifrado poscuántico y vuelve el comportamiento anterior: el tráfico
puede entonces tomar la ruta estándar, donde la plataforma puede leer las
direcciones y los contenidos de los paquetes.

Límite: ninguna app informa aún de si una conexión concreta va sellada. Esa
carencia es real, pero ya no es la peligrosa — no te pueden degradar en
silencio mientras el sellado esté activado. Esto, y todo lo demás contra lo
que URnetwork no defiende, está recogido en el
[modelo de amenazas](/docs/threat-model).

**Anonimización fuerte, y el modo directo.** Un proveedor ve las direcciones
de destino del tráfico que sirve, como hace hoy tu ISP. No sabe quién eres:
por defecto nunca ve tu IP real; solo la plataforma la ve. Ese valor por
defecto es el interruptor **Anonimización fuerte** del panel de conexión, que
viene activado. Desactivarlo activa el *modo directo*: el cliente habla
directamente con el proveedor y el rendimiento sube. El coste: ese proveedor
pasa a ver tu dirección real. Los perfiles alojados fuerzan el modo directo a
desactivado en cualquier caso.

![Qué cambia la sesión sellada — ruta estándar frente a sesión sellada, y qué pasa cuando no se puede sellar con un proveedor](/docs-assets/diagram-sealed-session.svg)

## Qué puede ver cada parte

| Parte | Ve | No ve, o no guarda |
|---|---|---|
| Operador (plataforma) | tu cuenta; tu dirección en el momento de conectar; una ciudad/región/país aproximados derivados de ella; qué proveedores usaste; recuentos de bytes; texto cifrado con su tiempo y volumen | destinos y contenidos de los paquetes (sellados por defecto); tu dirección en crudo (en su lugar, un hash de bloque con clave); ningún campo de destino en el registro de transferencias |
| Proveedor | IPs de destino/SNI del tráfico que saca a internet; un id de dispositivo que acompaña al contrato | tu identidad o tu IP real en las rutas retransmitidas; solo el operador puede resolver el id de dispositivo a una cuenta |
| Extensor | bytes cifrados; tu IP | nada del interior del túnel |
| Sitio web | una dirección residencial del proveedor | tu IP; la identidad de tu ISP |

Detrás de la fila del operador:

- La forma almacenada de tu dirección de conexión es un hash unidireccional
  con clave del bloque /29 (IPv4) o /56 (IPv6) que la rodea, no la dirección
  en sí. Una ciudad/región/país aproximados derivados de la dirección se
  guardan por conexión.
- La disciplina está en el código, no solo en la política. El registro HTTP
  pasa por una lista de cinco cabeceras permitidas. El registro de
  transferencias anota ids de cliente y de red y recuentos de bytes, sin
  ningún campo de destino, host, URL, SNI, puerto o dominio donde escribir.
  La ruta de datos del proxy no registra nada, fijado por un test de
  regresión.
- El sellado hace tu tráfico ilegible para el operador. La disciplina de
  almacenamiento cubre lo que el operador sigue viendo (asociaciones con
  proveedores, recuentos de bytes, ubicación aproximada) y lo sustituye donde
  no hay sellado: la extensión de navegador, los endpoints proxy y las apps
  nativas con el sellado desactivado.
- Límite: estas son propiedades de los registros que escribe el código. Los
  logs de acceso del balanceador de carga de entrada nunca se auditaron, y
  líneas con direcciones y SNI llegan al stderr de los servicios, cuyo
  destino en producción no está establecido. El registro completo: el
  [modelo de amenazas](/docs/threat-model).

![Qué almacena el operador — y qué nunca llega a existir](/docs-assets/diagram-what-is-stored.svg)

## Código abierto, y qué no está auditado

Toda la pila es de código abierto: las apps, el SDK, el motor del protocolo y
el propio código de servidor del operador, así que los mecanismos descritos
aquí pueden leerse en lugar de tomarse en confianza. El código abierto
demuestra el diseño, no qué compilación está desplegada.

Ninguna auditoría independiente cubre el protocolo, el motor connect ni el
código de servidor del operador, que es donde viven las afirmaciones de
privacidad. Dos evaluaciones de terceros de 2025 cubren otras superficies.
Una es una prueba de penetración independiente de la aplicación web y la API
(abril–mayo de 2025). La otra es una evaluación MASA AL2 de Leviathan
Security Group sobre la app de Android, que la superó; Leviathan la acota
como no siendo una evaluación de seguridad integral. Código abierto bajo
escrutinio permanente es la respuesta de URnetwork a la auditoría anual de un
momento dado. Registro completo: el [modelo de amenazas](/docs/threat-model).

## Compartir sin riesgo: la capa ip_security

Compartir tu conexión no debería significar heredar el riesgo legal de un
desconocido. El cliente proveedor incluye `ip_security`, una capa de
seguridad de tráfico de código abierto dentro del motor connect y uno de sus
componentes más grandes. Inspecciona la propia salida del proveedor, su
salida a internet. El tráfico de riesgo se bloquea antes de salir por la
conexión del miembro:

- **Filtrado de clase DMCA.** Un detector con seguimiento de estado reconoce
  firmas de BitTorrent y de intercambio de archivos y descarta el tráfico
  opaco que no encaja con ningún protocolo legítimo, de modo que las
  transferencias P2P infractoras no salen por la línea del miembro.
- **Filtrado de clase CFAA.** Los patrones de acceso no autorizado, escaneo y
  explotación se descartan sin respuesta, de modo que la conexión no es el
  punto de partida de la intrusión de otro.
- **Un detector construido para no ver.** La comprobación de intercambio de
  archivos borra el nombre del servidor de su propia clave de flujo. Decide
  con direcciones, puertos y los bytes iniciales de un flujo, y lleva sus
  contadores por protocolo y puerto, nunca por dirección.

Una coincidencia produce un paquete descartado. Una coincidencia de
BitTorrent emite además una señal de abuso al operador: el id de dispositivo
del par y un booleano, sin destino, dominio ni contenidos. El operador no
incluye hoy ningún gestor para esa señal, así que no se guarda nada al
recibirla. Los descartes de protocolo opaco son silenciosos, sin informe.

La capa se ejecuta en el borde, a ambos lados de él: en tu dispositivo cuando
te conectas, para que el tráfico que la red no va a transportar nunca llegue
a un proveedor, y en el dispositivo del proveedor, donde el tráfico sale. El
operador no inspecciona el tráfico de forma central, y el sellado no esquiva
el filtro, porque el filtro se ejecuta en los extremos que el sellado
conecta. Con el kill switch (interruptor de corte) activado (un conmutador
explícito en todas las apps, activado por defecto en la extensión de
navegador), el tráfico bloqueado se detiene en lugar de recurrir a tu propia
conexión. La mayoría de los países tienen leyes de las familias CFAA y DMCA;
un mismo estándar las responde en cada salida, y URnetwork cumple la ley allí
donde distribuye. El filtro se mantiene, no está congelado: sus listas de
amenazas se regeneran en cada versión a partir de feeds públicos de malware,
abuso y botnets (Spamhaus DROP, el rastreador de botnets de abuse.ch,
Emerging Threats y otros), así que una app al día bloquea el espacio de
direcciones malicioso conocido más reciente. Los
[términos del servicio](/terms) cubren compartir conexión.

![ip_security: aplicación en el borde, sin vigilancia — el tráfico con coincidencias se descarta en la propia salida del proveedor](/docs-assets/diagram-ip-security.svg)

## Atravesar bloqueos

Los extensores llevan la ruta a través de cortafuegos locales y regionales.
Cada uno responde TLS en puertos de servicio verosímiles (443, DNS-over-TLS
853, LDAPS 636 y otros) y ante los escáneres parece una CDN mal configurada.
Cada uno lleva codificado de fábrica reenviar el flujo cifrado a la
plataforma desde una dirección propia, así que bloquear
`connect.bringyour.com` no bloquea la vía de entrada. El cliente rota por
identidades de extensor generadas, con fragmentación y reordenación
aleatorias de paquetes, hasta que una funciona. Donde solo escapa el DNS, un
transporte con forma de DNS remodela los paquetes QUIC como consultas y
respuestas DNS. Cualquiera puede ejecutar un extensor.

![Atravesar bloqueos: extensores y el transporte con forma de DNS](/docs-assets/diagram-getting-through.svg)

## Proveedores y cobertura

Las ubicaciones están respaldadas por presencia: una ciudad se ofrece solo
mientras el dispositivo de un miembro está en línea en ella. La plataforma
geolocaliza la conexión que observa; un proveedor no puede declarar su propia
ciudad. Una dirección que parece un centro de datos, una VPN o un rango
reanunciado se degrada en lugar de recibir confianza. Límite: ninguna parte
externa ha medido la flota, y nada verifica que los proveedores ofrecidos a
un cliente sean independientes entre sí o del operador. Ver el
[modelo de amenazas](/docs/threat-model).

Compartir conexión es voluntario y consiste en ceder ancho de banda sobrante:
está apagado hasta que lo enciendes, va solo por Wi-Fi salvo que permitas
datos móviles, y apunta al tráfico público o únicamente a tus propios
dispositivos. El tráfico público se mide: la plataforma estampa en cada
contrato de transferencia un secreto que solo ese proveedor posee, de modo
que el proveedor puede comprobar que un contrato es genuino y para la
audiencia que aceptó. El depósito en garantía se denomina en bytes; ambos
extremos declaran lo que transportaron, y la cifra liquidada es su promedio
dentro de una tolerancia. Los proveedores participan en el protocolo UR;
[ur.xyz](https://ur.xyz) documenta las recompensas, y esta página no las
repite. Los niveles gratuitos existen porque los miembros de pago financian
el crecimiento de la red. Cualquiera puede ser proveedor.

## Planes y la API del operador

Hay dos planes: uno gratuito con una cuota de datos diaria, y Pro con una
cuota mensual grande, más clientes simultáneos y las comodidades de proxy y
WireGuard. Pro puede pagarse con USDC en cadena desde una cartera. La cuota
se mide, no se estrangula: cuando se agota, la red deja de abrir
transferencias nuevas en lugar de ralentizarte. El túnel se queda en
silencio, tu propia conexión queda intacta y la cuota se rellena en su ciclo.
Los números vigentes están en [ur.io/products](https://ur.io/products),
legibles por máquina en `GET https://api.bringyour.com/x402/skus`.

Todo lo que hacen las apps pasa por la API REST pública del operador
(autenticación, dispositivos, descubrimiento de proveedores, suscripciones,
estadísticas), documentada en la [referencia de la API](https://ur.io/docs/api).
Los agentes tienen acceso de primera clase: un servidor MCPv2 en
`mcp.bringyour.com` (OAuth; herramientas `providerLocations` y `fetch`) y
compras x402 de pago según necesidad. Ver
[ur.io/agents](https://ur.io/agents).

## Endpoints de respaldo: HTTPS, SOCKS5, WireGuard

Para el software que no puede integrar el SDK, el operador mantiene endpoints
puente: un proxy HTTPS CONNECT, SOCKS5 y un endpoint WireGuard para apps
WireGuard estándar. SOCKS5 admite CONNECT y UDP associate; BIND no está
soportado, y los datagramas UDP de más de 2 KiB se descartan por diseño.
Límite: la ruta WireGuard asigna una dirección de túnel estable de un pool
privado asignado por la plataforma, no tu IP real. Esa dirección estable
permite correlacionar a un cliente entre proveedores, y el endpoint entrega
al cliente un resolvedor público fijo (1.1.1.1). Las apps y el SDK siguen
siendo la forma más privada de usar la red.

## Adónde ir ahora

- Configuración: las [guías de primeros pasos](/docs) para Android, iOS,
  macOS, Windows, Linux, la extensión de navegador y el SDK.
- Profundidad por plataforma: los recorridos de cada app.
- Otros productos: los docs comparativos y el
  [mapa de comparativas](/docs/comparison).
- El protocolo: [ur.xyz](https://ur.xyz) para el whitepaper, la economía y
  las recompensas a proveedores.