v0.70b-eSE 8.1.0 — Anonymous LiveTV control plane

v0.70b-eSE 8.1.0 — Plano de control tunelizado para LiveTV

⚠️ Corrección de honestidad (2026-06-13)

Estas notas originales daban a entender un anonimato del viewer más fuerte del que v8.1 entrega. Una
auditoría posterior del código encontró que los circuitos de v8.1 son de UN SOLO SALTO. A 1 salto el
exit está conectado directo al viewer y ve su IP (y qué canal pide). v8.1 oculta al viewer del
emisor y de la red Kad, pero NO del exit. El anonimato onion real exige ≥2 saltos — eso llega en
v8.1.1 ("reenvío 2-hop real"). Lee la sección de privacidad, corregida abajo. Disculpas por el
optimismo de la primera versión.

v8.1.0 — validado en vivo el 2026-06-12 con 3 PCs (Tailscale). Plano de control tunelizado (1 salto), estable a 12000 kbps. Backward-compatible con vanilla 0.70b y v8.0.0.

En una frase

v8.1 añade un plano de control tunelizado al P2P LiveTV: la búsqueda Kad por palabra clave y la suscripción a un canal pueden viajar por un circuito onion dentro de la propia red eD2K/Kad, ocultando quién busca qué y quién se suscribe a quién al emisor y a la red — sin VPS, sin dominios, sin terceros. ⚠️ A 1 salto, el nodo exit sí ve al viewer (ver privacidad).

Qué es nuevo

• Transporte onion tunelizado (Sprint A): celdas multi-cell sobre OP_EMULEPROT, dispatcher en el exit, API asíncrona, sweeper de buffers abandonados.
• Búsqueda Kad por el túnel (Sprint B): el exit ejecuta una CSearch real en nombre del viewer; los resultados vuelven por el circuito. La IP del que busca no se expone al emisor ni a la red Kad (pero sí al exit, a 1 salto).
• Suscripción y control de LiveTV por el túnel (Sprint C): el exit hace de proxy multicast (C7) — se suscribe UNA vez al emisor en nombre de N viewers tunelizados; el emisor ve al exit, nunca al viewer. ⚠️ A 1 salto, el exit sí ve la IP del viewer.
• Selector de modo de privacidad (Sprint D): Directo / Tunelizado / Adaptive, persistente, con política de fallback (strict / balanced / best-effort) y panel web.
• Estabilidad a bitrate alto: fragmentación de chunks por encima del límite de 2 MB de eMule (OP_LIVE_CHUNK_FRAG, gated por capacidad) + segmentos HLS de 2 s → emisión fluida validada a 12000 kbps (4K) en malla de varios viewers.

⚠️ Alcance honesto de la privacidad (léelo) — CORREGIDO 2026-06-13

A 1 salto no hay separación de relés: el exit es el único relé y está conectado directo al viewer,
así que ve su IP y sabe qué canal pide. El anonimato onion real exige ≥2 saltos para que ningún relé
vea a la vez quién eres y qué pides. Por eso v8.1 oculta al viewer del emisor y de la red Kad, pero
NO del exit. Un exit malicioso/comprometido desanonimiza al viewer por completo.

Qué	¿Oculto frente a…?	Estado real v8.1 (1 salto)
Quién BUSCA un canal	emisor + red Kad	🟢 oculto · 🔴 el exit ve la IP + la keyword
Quién se SUSCRIBE a un canal	emisor (broadcaster)	🟢 el emisor ve al exit, no a V · 🔴 el exit ve la IP de V
La IP del viewer al recibir los CHUNKS	—	🔴 visible (el plano de datos sigue directo)

El modo Tunelizado NO satisface G1 (anonimato real del viewer) por dos razones: (1) los datos van
directos, y (2) el exit ve al viewer (1 salto). Ambas las cierra el roadmap:

• v8.1.1 "Reenvío 2-hop real": circuitos de 2 saltos de verdad (hop1 ≠ exit) → el exit deja de ver la IP del viewer en el plano de control.
• v8.1.2 (Sprint E / E-α): chunks por el túnel de 2 saltos a bitrate nativo → cierra G1 también en los datos.

Hasta entonces, usa Tunelizado entendiendo que confías en el nodo exit. No es anonimato fuerte todavía.

Compatibilidad hacia atrás (F2 — auditado, PASA)

Todo el wire/formato de v8.1 degrada con gracia frente a eMule vanilla 0.70b y al fork previo v8.0.0:

• Las celdas de túnel (OP_LIVE_TUNNEL_CELL) y los chunks fragmentados (OP_LIVE_CHUNK_FRAG) solo se envían a peers que anunciaron la capacidad (TAG_ESE_CAPS 0x6C, bits PRIVACY_TUNNELING/LIVE_CHUNK_FRAG). Un peer antiguo nunca los recibe.
• Un opcode OP_EMULEPROT desconocido se descarta en silencio (sin OnError, sin desconexión).
• Los registros Kad usan tags estándar (TAG_SOURCEIP/TAG_SOURCEPORT) + tags eSE con nombre-string que los holders desconocidos ignoran y conservan. Por debajo del umbral de fragmentación el wire es byte-idéntico al de hoy.

Rendimiento (F5 — coste del anonimato)

Honestidad sobre el coste: el túnel es más lento que la búsqueda directa. Medido en vivo (3 PCs, Tailscale):

Métrica	Directo	Tunelizado (1 hop)
Latencia búsqueda Kad (inicio → 1er lote de resultados)	~3-5 s (rango típico Kad) †	~8 s (medido) ‡

† No medible de forma limpia en el banco de 3 PCs (la única stream queda cacheada en el directorio local + cooldown de búsqueda); el valor es el rango habitual de una búsqueda Kad por keyword.
‡ Medido en vivo: Search BEGIN [tunneled] → Tunneled search fed 15 result(s) = 8 s. Incluye que el exit ejecuta una CSearch real, espera su ventana de acumulación, y devuelve los resultados por el circuito. El sobrecoste (~3-4 s sobre el directo) es el precio del anonimato del control.

Problemas conocidos

• Solo 1 salto: el nodo exit ve la IP del viewer y el canal que pide. El anonimato real frente al exit llega en v8.1.1 (reenvío 2-hop real).
• Datos directos: la IP del viewer se expone al servir chunks (ver alcance). → v8.1.2.
• Duplicados de malla: con varios viewers, un segmento puede pedirse a 2 fuentes y llegar 2× (se descarta, desperdicia ancho de banda). Optimización pendiente (dedup PUSH/PULL).
• Steering de exit: para que el circuito NO salga por el propio emisor, el emisor debe arrancar en modo Directo (la capacidad se fija al arranque). Si arrancó en otro modo, reinícialo en Directo.

Despliegue

• emule.exe + ese-server.exe deben ser del mismo build en todos los nodos.
• Solo Release x64.