Una fork experimental de YaCy: mejor ranking, resultados firmados, peers detrás de NAT

Por qué

Medido en la red pública de YaCy (freeworld) con 16 consultas, solo el 11% de los 10 primeros resultados contenía todos los términos de la consulta. Al investigar las causas:

• Las consultas de varios términos se enviaban a Solr con coincidencia mínima 1 (una consulta OR), tanto al índice propio como a cada peer remoto.
• Las puntuaciones de Solr de cada peer se normalizan respecto a su mejor resultado, así que un peer que solo tiene coincidencias de un término coloca la mejor de ellas al mismo nivel que las coincidencias exactas de otros peers.
• El texto en japonés y chino solo se divide en espacios y signos de puntuación, así que una frase entera se convierte en una sola "palabra" y el índice de palabras (RWI) no puede encontrarla.
• En una red de peers nuevos, a los peers con menos de 3 días nunca se les consulta en una búsqueda en el índice de palabras, y las definiciones de red pequeñas no envían consultas Solr remotas a nadie.
• Los resultados no llevan ninguna prueba de origen. Un peer puede devolver cualquier URL con cualquier título para cualquier consulta, y terceros pueden reenviar o alterar los seeds.
• Los peers detrás de un NAT solo pueden ser "junior": no son alcanzables, así que lo que indexan es invisible para los demás.

Qué ha cambiado

Calidad de búsqueda

Capa de confianza

• Identidad del peer. Cada peer tiene una clave Ed25519. Su hash de peer de 12 caracteres se deriva de la clave pública, y el núcleo de su seed (nombre, puertos, clave, alcanzabilidad, etiquetas declaradas) está firmado. Los seeds sin firmar se rechazan por defecto. Un desafío hello demuestra que el dueño de la clave responde en una dirección.
• Listas de confianza. Los usuarios configuran claves de coordinador. Un coordinador delega en operadores, y los operadores firman listas de peers de confianza con una prioridad y etiquetas declaradas como ads o proxy:<engine>. Las listas tienen versiones en lugar de caducar y se propagan de peer a peer.
• Firmas de autor. El peer que rastrea una página firma su URL, su título y un filtro de Bloom de sus palabras. Por defecto, un resultado solo se muestra si su firma es válida y su autor está en el conjunto de confianza (excepciones: los documentos sin firmar del índice propio del peer que no llegaron por la DHT cuentan como propios, y los resultados de buscadores externos se marcan como "externos"). Un peer que guarda un documento para la DHT no puede falsificarlo. Solo puede ocultarlo.
• Modo abierto. Se pueden mostrar resultados sin firmar o no confiables, etiquetados como "no verificados" y siempre clasificados por debajo de los verificados. Los resultados con una firma falsificada nunca se muestran.

Paso de NAT

Un proceso sidecar (Go, go-libp2p) se ejecuta junto a YaCy con la misma clave. Detrás de un NAT reserva un hueco en un circuit relay v2 y anuncia la dirección del circuito en el seed firmado (Reach=relay). Los demás peers abren hacia él un puerto de túnel local y usan HTTP normal, así que los clientes existentes de YaCy funcionan sin cambios. Por defecto, estos peers solo responden búsquedas. No guardan datos de la DHT salvo que lo activen.

Los detalles están en el diseño de confianza y NAT (en inglés).

Resultados

Dos experimentos en yacy-lab. Ambos ejecutan redes cerradas en docker compose, con un corpus y un conjunto de consultas deterministas.

Calidad de búsqueda: upstream frente a la fork, 3 peers cada una

Cada peer rastrea un sitio. Las consultas van al peer 1 con resource=global, y la mayoría de las páginas relevantes están en los otros peers. El corpus contiene dos tipos de señuelos: páginas rellenas con un término de la consulta y páginas escasas de "archivo de etiquetas" con la consulta entera en el título. Media sobre 11 consultas (6 en inglés, 4 en japonés, 1 en chino), 2 ejecuciones con el mismo resultado salvo donde se indica.

• Páginas con keyword stuffing en el top 5 (suma sobre las 11 consultas): upstream 14, fork 0.
• Las páginas escasas de archivo de etiquetas bajan, pero siguen en el top 5. Su posición media es 4.5 en la búsqueda por defecto y 5.0 solo con el índice de palabras. Solo con Solr pasa de 2.0 sin la ponderación de páginas escasas a 3.1 con ella. Siguen por encima de páginas relevantes que no tienen los términos de la consulta en el título. Una ponderación más fuerte las bajaría más, pero también degradaría páginas cortas legítimas, así que el valor por defecto se mantiene suave.
• Upstream no puede usar los índices de palabras de otros peers en una red de peers nuevos, y ahí no puede encontrar palabras en japonés o chino en absoluto.
• El valor por defecto de la coincidencia mínima se eligió con este corpus. Si es adecuado para la red pública aún hay que medirlo allí.

Confianza y NAT: 6 peers de la fork, un relay y un NAT

Tres peers de confianza, un peer de confianza que declara ads, un peer firmado pero no confiable que rastrea spam e introduce documentos con una firma prestada, y un peer detrás de un router MASQUERADE. Las 26 comprobaciones pasan, entre ellas:

• Los ids de peer se derivan de las claves. El spam del peer no confiable no se muestra por defecto, ni siquiera cuando un peer de confianza guarda una copia.
• En modo abierto el spam aparece etiquetado como no verificado y por debajo de todos los resultados verificados. El documento con una firma prestada nunca aparece.
• Los resultados del peer ads llevan la etiqueta, y excludeTags=ads los elimina.
• El peer detrás del NAT no es alcanzable directamente, pero sus páginas se encuentran a través del relay, y sigue conectado.
• Una nueva versión de la lista se propaga solo mediante el intercambio entre peers. Revocar a un operador elimina los resultados de sus peers.

Pruébalo

Sin Docker: abre la demo en tu navegador. Funciona en modo simulado y reproduce respuestas grabadas de la demo real (la página está en japonés).

La demo arranca ambas redes (3 peers upstream, y la configuración de confianza y NAT de la fork) en una sola máquina y pone una página de búsqueda delante de ellas. Necesitas Docker con unos 7 GB de memoria.

git clone https://github.com/pad01g/yacy_search_server.git yacy
git clone https://github.com/pad01g/yacy-lab.git
cd yacy
git checkout baseline        && docker build -t yacy-lab/upstream:baseline -f docker/Dockerfile .
git checkout improved-search && docker build -t yacy-lab/fork:latest -f docker/Dockerfile .
docker build -t yacy-lab/sidecar:latest sidecar/
cd ../yacy-lab
docker compose -f compose.demo.yaml -p yacydemo up -d
# abre http://localhost:8800 (la configuración tarda unos 10 minutos y muestra su progreso)

La página también permite cambiar la confianza: elegir en qué coordinadores confía el peer que busca (un segundo coordinador solo lista al peer de spam, así que confiar en él hace que el spam sea "verificado"), editar y volver a firmar la lista de confianza, entregar la nueva versión a un peer y ver cómo se propaga, y revocar o restaurar la delegación del operador.

Los experimentos en sí: docker compose -p yacylab up -d && docker compose -p yacylab run --rm runner (calidad de búsqueda) y docker compose -f compose.trust.yaml -p yacytrust up -d && docker compose -f compose.trust.yaml -p yacytrust run --rm runner (confianza y NAT). Consulta el README del laboratorio.

Unirse: sin pedir permiso

Cualquiera, persona o agente, puede ejecutar un peer, conectarlo con la URL de un miembro (p2p.bootstrap.peers, también a través de una red Tailscale), indexar y firmar sus propias páginas y servicios, y tener su propio coordinador u operador: un coordinador es solo una clave y un archivo firmado en cualquier URL, sin servidor. Se permiten anuncios declarados (etiqueta ads); los usuarios eligen en qué listas confían. Cómo unirse · se aceptan pull requests.

Para agentes de IA

Un agente puede ejecutar su propio peer y usarlo como herramienta de búsqueda, sin API de búsqueda ni clave de API:

• Servidor MCP (io.github.pad01g/yacy-search): docker run -i --rm --network yacy -e YACY_URL=http://yacy:8090 -e YACY_ADMIN_PASSWORD=<tu contraseña> ghcr.io/pad01g/yacy-search-mcp:0.2.1 (con el peer iniciado como docker run -d --name yacy --network yacy -p 127.0.0.1:8090:8090 -v yacy_data:/opt/yacy_search_server/DATA ghcr.io/pad01g/yacy-improved-search:latest; cambia antes la contraseña por defecto yacy). Herramientas: search, crawl, index_status, peers, get_ranking_settings, set_ranking_setting, evaluate_ranking, trust_status. Se ejecuta junto al agente y habla con el peer propio del agente; no hay ningún servicio central.
• Skill de agente: npx skills add pad01g/yacy-lab instala yacy-p2p-search (iniciar un peer, rastrear, buscar, evaluar y ajustar el ranking).
• Registro de confianza: pad01g/yacy-trust. Un pull request aceptado incluye tu peer en la lista o te convierte en un operador que avala peers.
• Resumen legible por máquinas: llms.txt.

Limitaciones

• Incompatible por defecto con la red pública de YaCy (seeds sin firmar rechazados, hashes de palabras CJK cambiados). El modo abierto puede buscar en peers antiguos, pero solo como resultados no verificados.
• Sin coordinadores configurados, un peer solo confía en sus propios documentos. Las redes cerradas pueden usar trust.signedOnly=true. Una red pública necesita que alguien actúe como coordinador.
• El corpus es sintético y pequeño (160 páginas). Reproduce las debilidades encontradas en la red pública. No predice el tamaño de la mejora allí.
• La prueba de NAT usa un router MASQUERADE, no routers domésticos reales. El hole punching (DCUtR) está activado pero no medido.
• Un autor de confianza aún puede firmar contenido falso (la respuesta son las etiquetas y la auditoría). Un peer que almacena aún puede ocultar resultados.

Enlaces

• Código: pad01g/yacy_search_server, rama improved-search (cambios listados en FORK.md)
• Experimentos y demo: pad01g/yacy-lab
• Documento de diseño completo (en japonés): docs/trust-and-nat.md
• Upstream: yacy/yacy_search_server · foro de YaCy