Files
SergioandClaude Opus 5 897b4eaf28 INTERCAMBIO de tejido hecho: la identidad cambió de máquina, no de dueño
Apagados en gioser (relay, serve y willay-crosscheck), encendidos en la caja: `tejido` en :4102 y
`willay-crosscheck` en :4103, los dos alcanzables desde fuera.

La prueba de que la identidad VIAJÓ no es que el servicio arranque —eso pasaría igual con semillas
nuevas, que es el fallo silencioso que esto existe para evitar— sino que la semilla sea la misma:
`device.seed` y `roster.postcard` con sha256 IDÉNTICO a los dos lados. El PeerId sale de ahí, así
que sigue siendo 12D3KooWBw2u….

⚠ LO QUE SÍ CAMBIA: el multiaddr que los clientes tienen configurado lleva la IP.
  antes /ip4/204.168.193.248/tcp/4102/p2p/12D3KooWBw2u…
  ahora /ip4/2.29.29.217/tcp/4102/p2p/12D3KooWBw2u…     (mismo PeerId, otra IP)

🧱 SIN EL CORTAFUEGOS HABRÍA SIDO UN VERDE FALSO: el reglaset abría 80/443/1137/2345/22022 y nada
más. Con el relay encendido y el 4102 filtrado, `status` diría «corriendo · 0 reinicios» y la flota
no llegaría. Abiertos 4102 y 4103 con su ban por tasa; NO el 33097, que era el puerto efímero de un
`tejido serve` cliente. Y el fichero quedó IDEMPOTENTE (crear+borrar la tabla antes de definirla),
que era deuda del §6.33: 15 reglas dport antes, 21 después — no 36.

⚠ La política que genera ese reglaset NO EXISTE en ningún disco: ni la ruta que su cabecera nombra
ni el binario `cortafuegos`. El generado sobrevivió a su fuente, así que hoy se edita a mano.

🆔 Y takana acepta ULIDs que arje-zero RECHAZA: la card no encarnaba por `invalid character`, y era
la `L` de «RELAY» — carácter excluido del alfabeto Crockford. `service-cards` lo dio por bueno («26
alfanuméricos») y el consumidor lo tiró. El validador del productor más laxo que el del consumidor
siempre termina en un fallo lejos de donde se escribió.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-17 14:47:47 +00:00

56 lines
3.3 KiB
TOML

# tejido — el relay de la flota: `tejido relay` en gioser, sirviendo :4102 y :33097.
#
# ⚠ Su IDENTIDAD no es reproducible: `~/.tejido/{persona,device,relay}.seed` + el padrón
# (`roster.postcard`). Generar semillas nuevas no es «reinstalar»: es ser OTRA máquina para el
# resto de la flota y perder los teléfonos dados de alta. El binario se construye; la identidad
# se MUDA. La Card tiene que exigirla, no crearla.
#
# Receta Cargo contra el monorepo de tawasuyu, pinneada al MISMO commit que `shuma-*` y
# `puriy-costura`: el árbol de fuentes se comparte por `<dep>-<sha>`, así que un pin distinto es otro
# vendoreo de 2,4 G. Estática musl con zig-cc — la caja la arranca el init y no puede depender de
# encontrar un cargador, que es justo lo que le falta al binario glibc de gioser.
name = "tejido"
version = "0.1.0"
license = "MIT OR Apache-2.0"
[source]
repo = "https://git.tawasuyu.net/tawasuyu/tawasuyu.git"
commit = "23a292863f53b355c5c02d6185904f2c33d8ab42"
# tawasuyu COMMITEA su propio `vendor/` (smithay parcheado, enchufado por `[patch.crates-io]` POR
# RUTA); el `cargo vendor` de takana lo pisaría y el error habla de `taffy`, no de esto.
cargo_vendor_dir = ".hammer-cargo-vendor"
[build]
compiler = "zig-cc"
target = "x86_64-linux-musl"
link = "static"
flags = ["-p", "tejido", "--bin", "tejido"]
# ── LA CUENTA Y EL SERVICIO (SDD 30) ────────────────────────────────────────────────────────────
# Fuera de `hash_inputs`. En gioser corre como `sergio`, nunca como root ⇒ cuenta propia.
[[user]]
name = "tejido"
uid = 964
home = "/var/lib/tejido"
# ⚠⚠ **ESTE NO SE PUEDE ENCENDER MIENTRAS EL VIEJO SIGA VIVO, y es distinto de todo lo anterior.**
# Con los vhosts la regla fue «mudá el DNS y dejá el origen encendido, así volver cuesta un minuto»
# (§6.26). Acá NO vale: el README de tejido dice que **la clave que el roster atesta ES la identidad
# de transporte libp2p** (`~/.tejido/device.seed`). Dos máquinas con la misma semilla son el MISMO
# PeerId en la red — no dos réplicas: dos impostores mutuos. Por eso la Card queda en `cards.d` y
# **no entra al `genesis`**: se enciende cuando el de gioser se apaga, en ese orden, y es un
# INTERCAMBIO, no una convivencia.
#
# Y por eso la guarda EXIGE la identidad en vez de crearla: un `tejido` que genera semillas nuevas
# arranca perfecto y es OTRA máquina para la flota — se pierde el padrón de teléfonos dados de alta.
[[service]]
label = "tejido"
id = "01M2EKDA00TEJ1D0RE1AY00001"
exec = "/bin/busybox"
argv = ["sh", "-c", "/bin/grep -q '^tejido:' /etc/passwd || { echo 'tejido: falta el usuario `tejido` en /etc/passwd — lo declara esta receta con [[user]]' >&2; exit 78; }; test -s /var/lib/tejido/.tejido/device.seed || { echo 'tejido: falta /var/lib/tejido/.tejido/device.seed — es la IDENTIDAD libp2p de esta máquina y NO se genera: viene de ~/.tejido del origen. Generar otra es ser otra máquina para la flota' >&2; exit 78; }; cd /var/lib/tejido || exit 78; exec /usr/bin/setuidgid tejido /usr/bin/tejido relay"]
envp = [["PATH", "/usr/bin:/bin"], ["HOME", "/var/lib/tejido"], ["USER", "tejido"]]
networking = "full"
cgroup = "arje.slice/tejido"
restart = { initial_ms = 1000, max_ms = 30000 }