Estatuto de Inectia

Cambios respecto de la 0.6: hay aviso por correo. Cuando una coincidencia se detecta o avanza, a cada parte le llega un correo que dice sólo que hay una novedad, sin decir cuál ni nada de la otra, y lleva a Mis coincidencias; el estatuto lo dice donde antes decía que no había ningún canal (5.2, 8.3), el 3.2 deja de decir que el aviso de la detección es el único que existe, y el 5.4 dice qué queda de cada aviso y que el proveedor del correo guarda lo suyo. Ningún compromiso de la sección 2 cambia, y la propiedad crítica del 3.2 sigue igual: quien abandona no notifica a la otra parte, y ningún correo sale por un abandono.

Cambios respecto de la 0.5: la web del miembro tiene tres pantallas para mirar —sus coincidencias, su tarjeta y lo que declaró— y el estatuto lo dice donde antes decía que la web daba sólo el alta, el permiso y las confirmaciones (5.2, 8.3, 8.5); declarar es hablando con un agente y así va a seguir, de modo que 8.5 y 14.1 dejan de prometer que se declara sin agente y dicen lo que sí se hace sin él; y 8.1 lista las cuatro herramientas que existen (antes nombraba confirmar_etapa, que a propósito no existe: confirmar es por link firmado, 8.6). Ningún compromiso de la sección 2 cambia.

Cambios respecto de la 0.4: cómo se entra dice lo que hay: desde el propio agente, al agregar el conector, o desde la web (5.1); el correo se prueba con un código, no con un link (4.3, 5.2); y donde decía que con la web alcanza para declarar sin agente (8.5, 14.1) se marca que hoy no hay pantalla para declarar, igual que se marca el cifrado en 2.2. Y 8.1 dice cómo se da y cómo se corta el permiso del agente. Ningún compromiso cambia.

Cambios respecto de la 0.3: la red tiene nombre, Inectia (título y 1); y la propiedad crítica del 3.2 se dice con precisión: en la etapa 1 las dos partes saben que hay una coincidencia, y quien abandona después no notifica a la otra, que no puede distinguirlo de un vencimiento. Antes decía "nunca se entera de que hubo un match", que prometía de más.

Cambios respecto de la 0.2: la etapa 3 deja de ser una "revelación parcial y simétrica" y pasa a ser la tarjeta que cada miembro elige mostrar, al grano que fija el nodo, sin reciprocidad (3.1, 3.2); la etapa 2 dura un instante, porque con el segundo sí a ciegas se arman las tarjetas en el acto; y la etapa 4 dice con precisión qué revela: correo y teléfono.

Cambios respecto de la 0.1 (versión 0.2, 2026-09-01): se elimina la cadena de invitación y se abre el registro (5.1); el boletín de señales de población queda apagado (3.4); la baja de cuentas ya no impide volver (6.2); los compromisos se sostienen por el contrato con cada miembro y no por un voto (preámbulo de la sección 2); y la sección 7 pasa a ser la publicación de las reglas de emparejamiento.

Este documento es el producto. Si las reglas no son creíbles, nadie declara la verdad, y sin verdad no hay emparejamiento.

1. Qué es esto

Un sistema donde las personas declaran en privado qué buscan y qué tienen, y son puestas en contacto únicamente cuando existe una coincidencia real entre ambas.

Se llama Inectia. En lo que sigue, «la red».

Arranca como una comunidad general y con la puerta abierta (5.1). Las comunidades con credencial propia —un gremio, un colegio, un club— se desprenden después (5.3).

No es una red social. No hay perfiles, ni muro, ni contenido, ni seguidores. No es un portal. No hay avisos públicos. No es un intermediario. No participa de las operaciones ni cobra por ellas.

El problema que resuelve: hoy un corredor tiene el comprador, otro tiene la propiedad, ninguno se entera, y los dos pierden la comisión. Nadie publica lo que busca su cliente porque publicarlo es regalarlo.

2. Los seis compromisos

Estos seis compromisos son obligaciones que la operadora asume con cada miembro, en la versión del contrato que ese miembro aceptó al entrar. El contrato son este estatuto y la frase de consentimiento del 4.2, los dos con número de versión (5.2).

Si se publica una versión nueva, rige para quien entre desde entonces. A quien ya está se le pide que la acepte, y la operadora decide en cada cambio si aceptarla es condición para seguir siendo miembro. Quien no quiera se va con sus datos y su reputación (6.1).

Y una regla que es la que hace que el versionado no sea un truco: cada intención se rige por la versión bajo la que fue declarada, hasta que vence, aunque el miembro haya aceptado una posterior. La versión nueva rige lo que se declare desde que se acepta, y nada de lo anterior.

Sin esa regla, publicar una versión nueva sería una forma de cambiarle el trato a lo que alguien ya declaró creyendo otra cosa. Con ella, una intención no cambia de reglas en el medio de su vida.

2.1 Las intenciones vencen y se borran

Toda intención tiene fecha de vencimiento obligatoria. Al vencer, se elimina. No se archiva, no se anonimiza, no se guarda "para estadística".

Consecuencia deliberada: el sistema no puede construir un historial de qué buscó cada miembro a lo largo del tiempo. Ese historial es el activo que un comprador querría y que un juez podría pedir. Si no existe, no hay nada que entregar.

2.2 El operador no puede leer el contenido sensible de las intenciones

Hay dos niveles de dato, y se tratan distinto:

Nadie —ni el operador, ni un empleado, ni un tercero con acceso a la base— puede leer el contexto de una intención. Los atributos estructurados sí son legibles, y esa es una concesión deliberada para que el emparejamiento funcione (ver 8.5).

Los atributos se almacenan además con sal por miembro, de modo que no puedan agruparse para reconstruir un perfil.

Lo que este compromiso protege, entonces, no es que la intención sea invisible: es que sea anónima. El motor lee los casilleros porque sin leerlos no puede cruzarlos. Lo que no lee nadie es el texto libre, y lo que no está junto a la intención es quién la declaró (2.4). El autor aparece únicamente frente a su contraparte compatible, y sólo cuando los dos confirman (3.2).

(El cifrado del lado del cliente es trabajo de la v1: hoy el texto libre se guarda sin cifrar. La fila de arriba describe el compromiso, no el estado de hoy, y se marca así para que nadie lo lea de más.)

2.3 Nadie puede enumerar

Un miembro (o su agente) puede proponer una coincidencia. Ningún miembro puede listar qué intenciones existen en el sistema.

Solo te enterás de una intención ajena si vos ya declaraste algo compatible, antes de saber que la otra existía.

Sin esta regla, alguien construye un agente que recorre todo y arma la base. El sistema muere.

2.4 Los datos de identidad y de intención viven separados

Dos bases sin vínculo consultable entre sí:

• Membresía: identidad de contacto, reputación, y la credencial verificada donde el nodo pida una (5.3). Persiste.
• Intenciones: vence y se borra. No permite reconstruir quién la publicó salvo en el momento del match confirmado.

2.5 Los compromisos viajan con el contrato

La sociedad operadora es Godshot LLC.

Si se vende, se fusiona, se cierra o cambia de dueño, estos compromisos siguen vigentes con cada miembro que los aceptó. Están en el contrato, y quien compre la operadora la compra con esos contratos puestos.

Un dueño nuevo puede lo mismo que el actual y nada más: publicar una versión distinta, a la vista, y perder a quien no la acepte.

En caso de cierre: los datos se eliminan; los miembros reciben su reputación y sus intenciones activas exportadas y firmadas, con 60 días de aviso.

2.6 El nodo no lee

Ni el nodo, ni la sociedad operadora, ni ninguna entidad que la controle o que ella controle, corre modelos de lenguaje sobre las intenciones de los miembros. Tampoco puede ser proveedor del agente de un miembro, ni recibir contraprestación alguna —dinero, créditos, participación societaria, datos o trato preferencial— de quien lo sea.

Por qué hace falta decirlo. El compromiso 2.2 protege el texto libre con cifrado: ahí el operador no puede leer aunque quiera. Pero los atributos estructurados —zona, rango de precio, sector, instrumento— son legibles por el servidor a propósito, porque son lo que permite el cruce. Que alguien busca doscientos mil dólares con garantía hipotecaria para una gastronómica en Palermo es información sensible, y es legible.

Contra eso no hay cifrado que valga: el servidor necesita esos datos para cruzar. Lo único que puede haber es una prohibición, y conviene leerla por lo que es: no es una que el operador no pueda levantar, sino una que no puede levantar en silencio ni sobre lo ya declarado (preámbulo de esta sección).

Lo que este compromiso NO es. No es una garantía criptográfica ni económica. Leer una intención suelta con un modelo cuesta menos de un centavo de dólar; contra una lectura dirigida a una persona en particular, ningún argumento de precio alcanza. Lo que sostiene este compromiso es que está en el contrato de cada miembro, que sobrevive a la venta de la operadora, y que el código de referencia se publica (9.4) para que sea auditable. Quien busque acá una imposibilidad técnica, no la va a encontrar: es una obligación exigible.

3. Cómo funciona el emparejamiento

3.1 La intención

Unidad atómica del sistema. Seis campos:

Sobre el cupo: con cinco intenciones se declaran las cinco que importan. Con cien, se declara ruido. El límite es lo que mantiene la señal.

3.1.1 Los tipos de intención son pocos y cerrados

Esto contradice el instinto y es la decisión más importante del diseño para una comunidad general.

No es "declará lo que quieras". Es "declará una de estas cosas".

Cada tipo de intención necesita su propio vocabulario, su propia lógica de reciprocidad y su propia masa crítica. Abrir con demasiados tipos garantiza que ninguno funcione: con mil intenciones repartidas en cien tipos hay diez por tipo, y cero coincidencias.

Criterio para que un tipo califique. Las cuatro condiciones tienen que cumplirse juntas:

1. Ambos lados quieren encontrarse. Reciprocidad real, sin asimetría de deseabilidad.
2. Hoy no se encuentran eficientemente.
3. El costo de no encontrarse es alto y conocido.
4. Ninguno quiere publicarlo abiertamente.

3.1.2 Taxonomía

La frontera entre nodos la define el trato, no la ficha. Un mismo pedido de plata puede ser Capital o Sociedad, y confundirlos manda la intención a un vocabulario donde nadie la va a buscar. La regla es simétrica —se aplica igual al que pide y al que ofrece—:

• Si la relación termina cuando la plata vuelve —hay instrumento, monto y fecha de salida— es Capital.
• Si la relación es co-titularidad de un proyecto sin fecha de liquidación —participación, gobernanza, voz— es Sociedad, aunque de un lado sólo haya plata.
• Si la respuesta honesta es "depende" —convertibles, SAFE, repago sobre facturación: instrumentos que empiezan como deuda y pueden terminar en participación— se declara en los dos nodos.

Ante la duda, el agente hace una sola pregunta: "¿qué pasa cuando la plata vuelve?". No mira la lista de casilleros; mira el trato.

Advertencia sobre el caso que este documento usa como prueba de validación. "Estoy vendiendo mi empresa" no es Capital ni Sociedad: es Comercio / traspaso, y ese nodo no abre en el lanzamiento (3.1.4). Quien entre buscando eso tiene que saberlo antes de declarar, no después de esperar en silencio. Es exactamente la intención con la que se valida el proyecto en la sección 15, y es la que hoy no tiene dónde ir.

Sobre Comercio. Es el tipo más amplio y por eso necesita subcategorías con vocabularios propios: un traspaso de negocio, un alquiler de depósito y un intercambio sin dinero no comparten ningún campo.

Advertencia de alcance en Comercio: no incluir bienes estandarizados. Para un producto de catálogo existen los marketplaces y no nos necesitan. El valor está en lo raro, lo grande o lo discreto.

Sobre Talento: incluye asesoría y conocimiento (busco quien sepa X ↔ sé X y asesoro). Atención con la asimetría: todos quieren mentor y pocos quieren serlo. Puede requerir reglas propias.

3.1.3 Un nodo por tipo, bajo el paraguas general

Cada tipo de intención opera como su propio nodo, todos bajo el nodo principal general.

Eso da tres cosas:

• Vocabularios independientes. Cada tipo evoluciona su esquema sin afectar a los demás.
• Reglas propias donde hagan falta. Compañía necesita un régimen de seguridad completamente distinto —verificación de edad, bloqueos, denuncias, moderación— que no tiene sentido imponerle a Capital.
• Aislamiento de tono. Un miembro pertenece al nodo general y participa de los nodos que le interesan.

Compañía en nodo separado, y con lanzamiento diferido. Razones:

1. La deseabilidad es profundamente asimétrica, a diferencia de los otros cuatro. Todos empujan hacia arriba.
2. Requiere otro régimen de seguridad, que es otro producto.
3. Contamina el ADN. Si la red se conoce como "eso donde también se conoce gente", nadie declara "estoy vendiendo mi empresa" ahí. La seriedad no se recupera después.

Puede ser la oportunidad más grande de todas —el mecanismo de revelación progresiva resuelve el rechazo asimétrico mejor que cualquier app de citas— pero después de que el nodo general tenga tono establecido.

3.1.4 Qué se lanza

Dos tipos: Capital y Sociedad.

Son los más recíprocos, los que mejor cumplen las cuatro condiciones, y donde los primeros miembros tienen gente.

Con cinco tipos y doscientos miembros hay cuarenta intenciones por tipo — demasiado poco para que algo coincida. Se suma el tercero cuando el primero produzca coincidencias reales.

El resto de la taxonomía es hoja de ruta, no alcance de lanzamiento.

3.2 Revelación progresiva

Etapa 1 — Detección. El sistema encuentra coincidencia. Avisa a ambas partes sin revelar quién es la otra.

Etapa 2 — Interés a ciegas. Ambas confirman que quieren avanzar, sobre el resumen y sin saber con quién. Con el segundo sí se pasa a la 3 en el acto: para el miembro son dos decisiones, no cuatro.

Etapa 3 — La tarjeta. Cada uno ve la tarjeta del otro: los casilleros de lo declarado que ese miembro eligió mostrar, al grano que fija el nodo (la zona por tramo, los años por banda, la reputación en bandas y sin números). Sin reciprocidad: cada uno muestra lo que quiere, incluso nada, y ve igual lo que el otro eligió. Quien no eligió muestra lo que el nodo define por omisión. Nunca el texto libre, nunca nada identificable. La tarjeta se congela por coincidencia: lo que el otro vio no cambia aunque después se edite la intención o la elección.

Etapa 4 — Contacto. Ambas confirman de nuevo, con la tarjeta a la vista. Recién ahí, correo y teléfono.

La propiedad crítica: si una parte abandona en cualquier etapa, la otra no recibe ningún aviso y no puede distinguirlo de un vencimiento. Las dos supieron en la etapa 1 que había una coincidencia —es el aviso de la detección; los que siguen (8.3) dicen sólo que hay una novedad, y ninguno dice que alguien se fue—; lo que ninguna sabe nunca es quién era la otra, ni si se fue o simplemente venció. No hay rechazo porque no hubo pedido. No hay que explicar nada, no hay incomodidad, no hay ego herido.

Eso es lo que permite declarar lo que uno realmente quiere.

Dos reglas que hacen cumplible esa propiedad. Ninguna es opcional.

La revelación progresiva sólo protege si lo que el sistema le muestra a un miembro sobre una coincidencia no sirve para reconstruir la intención del otro. Se verificó atacando el propio motor, y el resultado fue que no alcanza con mostrar poco: si el resumen de una coincidencia se recalcula cada vez que alguien edita su intención, un miembro puede probar valores y leer qué cambia hasta reconstruir el rango de monto y el sector exactos de su contraparte. El atacante no lee un número que le devolvemos: aporta él el valor de comparación. Por eso la defensa no está en mostrar menos, sino en no dejar repreguntar.

1. El resumen de una coincidencia se congela, y se congela por contraparte. Se calcula una sola vez, en el momento de la revelación. Un miembro que ya vio el resumen de una coincidencia no vuelve a ver un resumen distinto de esa misma contraparte, declare lo que declare después. Sin recálculo no hay sondeo por prueba y error.

2. Editar una intención tiene presupuesto. Un número limitado de modificaciones por período —tres cada treinta días como punto de partida, a ajustar con datos—.

Sin estas dos reglas, esta sección protege la identidad y deja los atributos a la vista, que es la mitad de la promesa.

Y hasta dónde llegan, con precisión: el presupuesto vive en la intención, no en la persona, así que retirar una y declarar otra empieza de cero. Acotan cuántas sondas se tienen a la vez —cinco— y no cuántas se hacen en total. Son una defensa contra el sondeo torpe, no contra el paciente, hasta que el presupuesto se cuente por miembro.

3.3 Fuera de la operación

El sistema pone en contacto. Nada más.

• No participa de la negociación.
• No fija ni sugiere condiciones comerciales ni reparto de comisiones.
• No cobra por operación ni percibe porcentaje alguno.
• No retiene fondos.

Lo que acuerden las partes es entre ellas, bajo las reglas y usos del gremio.

(Nota: esta separación debe ser revisada por un abogado antes de operar, para confirmar la línea entre software de facilitación y ejercicio del corretaje, que en Argentina requiere matrícula.)

3.4 El problema de la sala silenciosa

La ventaja de la opacidad: como las intenciones son privadas y nadie puede enumerar, nadie sabe cuántos miembros tiene la red. No existe el efecto de sala vacía: nadie entra, ve doce usuarios y se va. Eso mata a la mayoría de las redes nuevas y este diseño lo esquiva.

El problema que crea: un miembro declara una intención y pasan tres meses sin nada. No puede distinguir entre "no hay nadie" y "todavía no apareció nadie compatible". Ante esa ambigüedad, la gente asume lo peor y se va.

La sala vacía al menos dice la verdad rápido. La sala silenciosa no dice nada.

La solución: convertir el silencio en información. Pero no en cualquier información, y acá está el límite:

Ninguna señal puede calcularse contando personas.

Es una regla nueva y cara, y viene de la puerta abierta (5.1). Contar sólo es seguro si se sabe cuántas cuentas puede juntar un actor decidido, porque hay que restarle lo que él mismo puso; con la puerta abierta ese número no existe. Un umbral bajo deja aislar —mete cuentas hasta que el casillero prende, resta las suyas, y si queda una, esa una es una persona—. Uno alto no publica nunca, y el silencio también cuenta: dice que nadie llegó al umbral.

Lo que se publica, entonces:

La contrafáctica es la que hace el trabajo, y funciona con la red vacía.

Lo que se pierde: la pregunta "¿hay alguien?" deja de tener respuesta. El ejemplo bueno de esta sección —"hubo 3 intenciones que coincidían en zona pero no en tu rango"— cuenta personas, y por eso ya no se puede dar. La sala silenciosa vuelve en parte, y se paga a sabiendas: lo único que la compensa es que la prueba de que la red está viva pasa a ser pública e institucional (13.2), no privada.

Vuelve el día que el nodo tenga densidad, y con otro mecanismo: ruido por casillero en vez de un umbral duro, que es lo que hace que la ventaja del atacante deje de crecer con cuántas cuentas tenga. Cuesta densidad, obliga a guardar un secreto de vida larga —quien lo tenga puede pelar el ruido— y con poca gente puede publicar casilleros vacíos. Se enciende sabiendo eso o no se enciende.

3.5 Ajustes por baja densidad (etapa inicial)

En una comunidad general el silencio es mucho más probable que en un gremio. Dos ajustes deliberados mientras se acumula masa:

Vencimiento más largo al principio. 180 días en lugar de 90. Se acorta cuando la densidad lo permita. Una intención que vence antes de que exista su contraparte es una coincidencia perdida.

Criterios de coincidencia más generosos. Es preferible mostrar una coincidencia dudosa a perder una real: la coincidencia perdida es invisible y destruye la confianza sin que nadie se entere.

Los dos ajustes se revierten cuando haya volumen. Están documentados acá para que se revisen conscientemente y no queden por inercia.

4. Onboarding y consentimiento

4.1 El objetivo NO es "sin darse cuenta"

Es tentador buscar fricción cero al punto de que alguien entre a la red sin advertirlo. Eso rompe el proyecto.

Todo el sistema depende de que la gente declare la verdad. Y solo se declara la verdad conociendo las reglas: que las intenciones se borran, que nadie puede enumerar, que nadie ve tu identidad sin tu confirmación.

Quien entró sin darse cuenta no conoce las reglas. Y el día que se entera de que está en una red de intenciones —aunque todo esté bien hecho— su primera reacción es desconfianza. Ahí se pierde al miembro y a todos los que le pregunte.

Además, el consentimiento informado no es opcional bajo la Ley 25.326.

Y con la puerta abierta (5.1) esto pesa más, no menos. Antes había alguien explicando por qué te invitaba; ahora se puede llegar solo, desde la respuesta de un asistente. El riesgo de esta sección deja de cubrirlo el que te trajo y pasa a cubrirlo únicamente lo que la red te diga al entrar, así que las reglas se muestran completas antes del sí.

El objetivo correcto: una sola frase.

4.2 La frase de consentimiento

El registro ocurre dentro de la conversación normal del miembro con su agente. Alguien dice "estoy buscando un socio técnico", y el agente responde:

"Puedo registrar esa intención en la red. Queda separada de quién sos: nadie puede buscarte ni pedir una lista de lo que hay. Sólo te aviso si aparece alguien que busca exactamente lo complementario, y vos decidís si se conocen. ¿La registro?"

(Dice "separada de quién sos" y no "nadie va a poder verla", que es lo que decía antes y contradecía al 2.2: el motor sí lee los casilleros, porque es lo que le permite cruzarlos. Lo que se promete es anonimato, no invisibilidad, y es lo que el sistema puede cumplir.)

Sin formulario, sin descarga, sin perfil que armar. Una frase, un sí.

Eso es fricción cerca de cero y consentimiento informado a la vez. Es posible únicamente porque MCP existe: hace tres años no había forma de hacerlo.

4.3 Verificación diferida

El principio: no se le pide a nadie un trámite sin recompensa a la vista. De ahí salen dos cosas distintas:

Lo que el alta ya prueba, se registra en el alta. Entrar exige escribir el código que se mandó al correo, así que el control del buzón queda demostrado por el acto mismo de entrar — y se registra contra qué (5.4). No es un trámite extra: es el alta.

Lo que sí es un trámite queda diferido: la verificación de credencial, en los nodos que pidan una (5.3 — matrícula, aval, lo que el nodo defina). Ésa ocurre cuando aparece la primera coincidencia real, que es cuando tiene premio.

En la comunidad general no hay credencial que verificar, así que ahí no queda ningún trámite pendiente: con el control del buzón demostrado, las etapas corren solas hasta donde las confirmaciones humanas las dejen (3.2). Se evaluó agregar una verificación de teléfono —al declarar o en la primera coincidencia— y se descartó por la aritmética de 5.2: un número descartable cuesta menos que verificarlo, en cualquier momento en que se lo pida.

5. Quién puede entrar

5.1 Comunidad general con la puerta abierta

Decisión tomada: la red arranca como una comunidad general y sin invitación. Se entra desde el propio agente —al agregar el conector de la red, la ventana de permiso completa el alta ahí mismo—, desde la web, o llegando por la recomendación de un asistente que respondió una pregunta. Las micro-comunidades se desprenden después, cuando la densidad lo permita.

Esto reemplaza a la cadena de invitación, que era el diseño anterior: cada miembro entraba invitado por otro, con un cupo. La cadena resolvía cuatro cosas y ninguna se resolvió sola al sacarla. Hay que decir las cuatro:

Por qué se saca igual. La invitación es un pedido, y un pedido tiene un costo social que mucha gente no paga: quien leyó estas reglas y quiso entrar tenía que ir a buscar a alguien que lo dejara pasar. En una red que no tiene nada que mostrar, esa fricción se pagaba dos veces. La puerta abierta convierte a un lector convencido en miembro sin que le tenga que pedir permiso a nadie.

El principio que reemplaza a la puerta:

La red ya no controla quién entra. Controla qué puede hacer el que entró.

Y eso alcanza para casi todo, porque casi todo lo que importa acá ya estaba protegido adentro y no en la puerta: nadie puede enumerar (2.3), nadie ve una identidad sin dos confirmaciones del otro (3.2), y quien abandona no avisa ni se distingue de un vencimiento (3.2). Una cuenta sola, sin que nadie del otro lado confirme nada, no llega a ninguna persona.

El agujero, dicho una vez

Nada acota cuántas cuentas puede tener un mismo actor. Es la premisa que este documento usaba sin decirla, y de la que colgaban tres cosas: el umbral de las señales (3.4), que dar de baja signifique algo (6.2) y el antispam (8.5). Ninguna de las tres se resuelve en la v0.

Lo más incómodo que se sigue: declarar también es preguntar. Una intención dibujada contra una persona sospechada es la pregunta ¿existe alguien que declaró lo complementario?, y la coincidencia de etapa 1 es la respuesta. Antes costaba una invitación de alguien con reputación en juego; ahora cuesta un correo.

Lo único que la acota es lo poco que devuelve: que existe alguna declaración compatible, sin decir de quién, y un negativo no prueba nada. Queda como costo aceptado y no resuelto (sección 14).

Y el cruce corre en el momento en que alguien declara, no en una tanda diaria. Eso deja un oráculo más, dicho de frente: quien logre que otra persona declare a una hora conocida puede ver aparecer la coincidencia a esa hora. La tanda diaria lo escondía, pero sólo si había varias personas declarando en la misma ventana — con pocos miembros no escondía nada y costaba hasta un día de espera por cada coincidencia. Se revierte con un parámetro el día que la densidad lo justifique.

5.2 Requisitos

1. Aceptación del contrato, que son dos textos: este estatuto y la frase de consentimiento del 4.2. Los dos se versionan, y de los dos queda registrado cuál aceptó cada uno.
2. Un correo al que se pueda entrar.
3. Un teléfono, para poder avisar de una coincidencia. (Hoy el aviso llega por correo, y es uno solo: dice que hay una novedad, sin decir cuál, y lleva a Mis coincidencias en la web; el detalle lo muestran la web y el agente. Se manda cuando la coincidencia se detecta y cuando avanza; de una que caduca no se avisa todavía. Por teléfono no se avisa: el teléfono se guarda y se entrega a la contraparte en la etapa 4. Igual que el cifrado del 2.2, esta línea describe el compromiso y no el estado de hoy.)

El teléfono se pide, no se verifica. Se evaluó exigir una verificación por SMS antes de la primera declaración y se descartó con los números a la vista: un número suelto cuesta menos que el mensaje que lo verifica, o sea que el que se defiende paga más que el que ataca. Con esa aritmética no es una barrera: es un gasto, y una fricción puesta justo donde el 4.2 promete que no la hay.

La única verificación que hay es la que el alta ya prueba —el control del buzón, por el código del correo (4.3)—, y lo que se paga por no tener otra está en 6.2.

Y una consecuencia que hay que decir: el teléfono tampoco es único. Se evaluó exigir que lo fuera y resultó ser un oráculo — con la puerta abierta, cualquiera con un buzón descartable podía probar el teléfono de una persona en el alta y leer, en el error, si es miembro. Un dato que no se verifica no puede ser una llave, pero tampoco puede ser una pregunta.

5.3 Micro-comunidades

Se desprenden de la comunidad general cuando un grupo tiene una credencial propia que verificar y reglas propias que aplicar (matrícula para corredores, credencial para médicos, aval para un club de inversores).

Las intenciones se declaran con alcance: valen para toda la red o solo para una micro-comunidad. El miembro elige cuánto abre cada una.

No se crean micro-comunidades por anticipado. Surgen cuando hay masa crítica y alguien las pide.

5.4 Sobre la verificación

El sistema registra que la verificación ocurrió, cuándo y contra qué. No almacena documentos de identidad. Un repositorio de DNIs es un pasivo, no un activo.

Del correo y del teléfono se guarda el dato, porque hacen falta para avisar. Nada más: ni el contenido de los mensajes, ni un historial de envíos. De cada aviso queda que salió y cuándo, mientras viva la coincidencia que lo motivó —no el texto, que es uno solo para todos—; y en el proveedor del correo queda lo que ese proveedor guarda de cada envío —a quién, cuándo y el texto, que es el mismo para todos—. Dicho de frente: los dos correos de una coincidencia salen seguidos, así que en ese registro las dos partes quedan una al lado de la otra. Es el costo de avisar en el acto, y se acota con la retención más corta que el proveedor permita.

5.5 Reputación

Después de cada contacto concretado, ambas partes responden una sola pregunta: ¿la contraparte era lo que declaró?

• La reputación mide veracidad, no popularidad ni volumen.
• Es portable: el miembro se la lleva si se va, firmada y verificable.
• No se compra, no se transfiere, no se vende.
• Se gana, y sólo se gana. No se hereda de quien te trajo, porque ya no hay quien te traiga (5.1).

Con la puerta abierta, la reputación es lo único que una identidad acumula. Una cuenta nueva no tiene nada, y en la etapa 3 "sin respuestas" se muestra como lo que es: la red todavía no sabe nada de esta persona. Todos empiezan ahí.

Y lo que no prueba: el motor impide emparejar a alguien consigo mismo, pero no a un actor con dos cuentas, así que dos cuentas de la misma persona pueden llegar a la etapa 4 y calificarse bien. La reputación mide veracidad entre extraños y no dice nada sobre quien se toma el trabajo de fabricarla (sección 14).

6. Quién se va, y cómo

6.1 Salida voluntaria

En cualquier momento, sin penalidad. Se lleva su reputación exportada y sus intenciones activas. Todo lo demás se elimina en 30 días.

Que irse sea barato es lo que hace creíble quedarse.

6.2 Expulsión

La operadora da de baja una cuenta ante:

• Declarar intenciones falsas de forma reiterada.
• Intentar enumerar o extraer información del sistema.
• Revelar a terceros la identidad o los datos de una contraparte obtenidos por un match.
• Pérdida de la credencial, en los nodos donde haya una.

El tercer punto es baja inmediata. Una sola filtración destruye la confianza de todos: la red no baja de uso, muere.

Qué significa dar de baja con la puerta abierta

Una sanción escrita sin dientes es peor que ninguna, así que:

La baja borra las intenciones, cierra las coincidencias abiertas y mata la reputación — que es lo único que una identidad acumula (5.5). Lo que no hace es impedir volver: quien fue dado de baja se registra otra vez con otro correo, y no hay verificación de teléfono que lo frene (5.2). Vuelve como un desconocido sin nada, y ésa es toda la penalidad.

Dos cosas más, incómodas las dos. La decisión la toma la operadora sola, sobre un hecho que el sistema —a propósito— no puede probar: si alguien contó afuera lo que vio adentro, acá no hay registro. Es un juicio, no una verificación. Y quien fue dado de baja injustamente no tiene a quién apelarle fuera de la operadora misma.

(Y una baja que no es sanción: la pausa de quien todavía no aceptó una versión nueva del contrato — preámbulo de la sección 2. No borra nada y se levanta sola cuando acepta.)

7. Las reglas de emparejamiento

Decidir a quién se le muestra qué es una decisión de poder, no de ingeniería.

Es la frase más importante de este documento sobre cómo se opera la red, y hay que sostenerla de alguna forma. La forma es ésta:

Las reglas de emparejamiento se publican. Qué se compara, qué es excluyente, qué es preferencia, cómo se puntúa y en qué orden se entregan las candidatas. Con su versión y su fecha, junto con el vocabulario de cada nodo (8.8) y el código de referencia (9.4).

Por qué publicarlas y no simplemente aplicarlas. El motor es determinístico: dos corridas con los mismos datos dan el mismo resultado. Eso lo vuelve auditable — cualquiera puede tomar el código publicado, alimentarlo con casos y comprobar que hace lo que dice. Una regla de emparejamiento que nadie puede leer es indistinguible de un favoritismo, aunque no lo sea.

Una sola excepción, para el día que exista: si alguna vez vuelve una señal calculada sobre la población (3.4), sus parámetros no se publican — serían el número exacto contra el que calibrar para aislar a alguien. Hoy no hay ninguno, porque no hay ninguna señal así.

8. Arquitectura e interfaces

8.1 El principio que resuelve "abierto pero cerrado"

El protocolo es abierto. Los datos son cerrados. El agente es un delegado, no un participante.

Lo que sostiene esto no es quién puede entrar, sino que el sistema es un servicio que se llama, no una base que se lee.

Cualquier LLM puede conectarse al sistema. Pero actúa en nombre de un miembro humano identificado, con credenciales delegadas. El agente no es miembro: es la interfaz de un miembro.

Cómo se da y cómo se corta ese permiso. El miembro lo da una vez, en su navegador, en una ventana que le dice qué va a poder hacer el agente y qué no; si todavía no es miembro, esa misma ventana completa el alta antes de preguntar. El permiso queda anotado en la red. Quitar el conector del agente le corta el acceso —sin él no puede pedir nada en nombre de nadie—; borrar el permiso anotado, para que la próxima vez se vuelva a preguntar, es algo que la red todavía no ofrece en pantalla.

Esto es posible porque el sistema es un servicio que se llama, no una base que se lee. Se exponen herramientas, no tablas:

• declarar_intencion(...)
• mis_coincidencias()
• estado_de_mis_intenciones()
• retirar_intencion(id)

No existe listar_intenciones(). No está protegida: no está. Ese es el cumplimiento técnico del compromiso 2.3.

8.2 Capas

┌─────────────────────────────────────┐
│  NÚCLEO                             │
│  motor de emparejamiento            │  ← el 80% del trabajo
│  almacenamiento por casilleros      │
│  máquina de estados de revelación   │
│  membresía y reputación             │
└─────────────────────────────────────┘
         ↑                    ↑
┌────────────────┐   ┌────────────────┐
│ Servidor MCP   │   │ API REST       │
│ (para agentes) │   │ (para la app)  │
└────────────────┘   └────────────────┘

Regla dura: ninguna lógica de negocio vive en el servidor MCP. Es un adaptador delgado. Cuando aparezca otra interfaz (WhatsApp, SDK, lo que sea), no se reescribe nada.

8.3 Las tres superficies

MCP — la interfaz principal. No es visual: es un contrato de herramientas. Diseñar acá es diseñar parámetros, retornos y errores.

App mínima — panel de control, no producto. Existe por cuatro razones:

• La verificación de credencial necesita un flujo real.
• Las confirmaciones de las cuatro etapas no se automatizan. Si el agente confirma solo, el miembro perdió el control de a quién revela su identidad. Ese clic es humano, siempre.
• Muchos miembros todavía no usan agentes.
• El consentimiento legal necesita registro.

Notificación — el aviso de coincidencia llega por donde el miembro elija: su agente, push, mail o WhatsApp. Es el único momento en que el sistema busca al miembro. (En la v0 el canal es el correo, y no se elige: un correo que dice que hay una novedad, sin decir cuál, y lleva a la web. Se manda en el acto cuando la coincidencia se detecta y cuando avanza, a las dos partes por igual, y nunca por un abandono. De una coincidencia que caduca no se avisa todavía: desaparece de la lista al vencer, como hasta hoy. Push y WhatsApp no existen todavía.)

8.4 Portabilidad entre LLM

Principio: el estado vive en el nodo, nunca en el LLM. Cambiar de Claude a ChatGPT es cambiar qué cliente MCP se conecta al mismo servidor. No se pierde nada porque nunca estuvo ahí.

Lo que porta, por diseño:

Sobre las preferencias — decisión explícita: si el miembro le enseña a su agente cómo evaluar coincidencias (qué prioriza, qué descarta, cómo se comunica) y eso vive en la memoria del proveedor de LLM, al mudarse empieza de cero. Portaría los datos y perdería el criterio.

Por eso el perfil de agente vive en el nodo. Al conectar un LLM nuevo, la primera llamada trae instrucciones, criterios e historial de decisiones. El agente nuevo se comporta igual desde el primer minuto.

Eso convierte "mi agente" en algo real y portable, en lugar de un hábito acumulado dentro de un producto ajeno.

Lo único que no porta es el historial de conversación con cada proveedor. Es de ellos y no hay forma de traerlo. No es estado del sistema.

8.5 Emparejamiento en dos etapas

Etapa A — el servidor filtra (determinístico). Cruce por casilleros estructurados. Rápido, barato, consistente. De mil intenciones quedan unas pocas candidatas. No requiere leer texto libre.

Etapa B — el agente del miembro evalúa (semántico). Las candidatas se le entregan al agente del miembro (Claude, ChatGPT, el que use), que las evalúa contra sus preferencias privadas y decide cuáles vale la pena mostrar.

Por qué esta división funciona:

• El agente del miembro nunca ve la base. Solo ve candidatas que ya pasaron el filtro. Se preserva el compromiso 2.3 (nadie enumera).
• El cruce grueso es determinístico y auditable.
• El juicio fino es semántico y personalizado.
• El mismo cruce da resultados distintos a cada persona, porque cada agente filtra según su humano. Es una virtud, no un defecto.

Lo que NO puede pasar: que el LLM del usuario haga el emparejamiento completo. Tendría que ver las intenciones de todos, violando 2.3 directamente, y el resultado sería no determinístico entre proveedores.

El costo de esta arquitectura, declarado: para que el filtro grueso sea bueno, los atributos estructurados tienen que ser legibles por el servidor. Es la concesión del compromiso 2.2. El texto libre sigue cifrado y nadie lo ve.

Regla resumida: el servidor filtra, el agente del miembro juzga.

Quién paga la lectura, y qué lee

La etapa A —el cruce por casilleros— la corre el nodo y es gratis para el miembro, a cualquier tamaño de red. La etapa B —la lectura fina— la paga el agente de cada miembro, con su propia cuenta y su propio proveedor.

Qué lee ese agente, con precisión, porque acá se juega el compromiso 2.2: lee lo del miembro y el resumen de la coincidencia. Nunca el texto libre ni los valores exactos de la contraparte. Esos no salen del servidor: el texto libre está cifrado y el nodo tampoco puede leerlo, y los valores exactos no se entregan ni siquiera en un match confirmado (ver 3.2).

Entonces, ¿para qué sirve leer? Para lo único que el cruce no puede hacer: ordenar según lo que el miembro nunca declaró. El cruce entrega veinte o treinta candidatas con el mismo criterio para todos; el agente sabe, porque su miembro se lo dijo hablando, cuáles tres valen una confirmación. El cruce dice qué es compatible; el agente dice qué le importa a esta persona.

Lo que se sigue de que pague el miembro:

1. El nodo no queda en el medio. No necesita ver las candidatas para que alguien las lea.
2. Portabilidad. Como el miembro paga, tiene que poder mudarse de proveedor sin perder su criterio. Por eso el perfil del agente vive en el nodo y no en el LLM (8.4).
3. La etapa A es lo que hace viable la etapa B. Sin filtro grueso, el agente del miembro tendría que leer diez mil candidatas en vez de treinta por cada declaración. La lectura semántica no sería cara: sería imposible.

Lo que NO se sigue, y conviene decirlo porque es tentador creerlo. Que la lectura cueste plata no convierte a la privacidad en una imposibilidad económica: leer la base entera una vez sale unos pocos dólares, y leer la intención de una persona en particular, centavos. La garantía de que el nodo no lee es el compromiso 2.6 y el código auditable de 9.4, no el precio. Tampoco es antispam: cuesta plata leer, no declarar.

El antispam es el cupo de cinco intenciones: acota cuánto declara una cuenta a la vez, pero no cuántas cuentas junta una persona (5.1).

Qué necesita un miembro para participar. Un agente para declarar —cualquiera que hable MCP, y los hay gratuitos—, y la web y el teléfono para todo lo demás: recibir coincidencias, confirmar las etapas, mirar lo declarado y elegir la tarjeta, sin pagarle a nadie (8.3). Declarar es una frase dicha a un agente, y así va a seguir: no hay ni va a haber un formulario para declarar en la web, porque la frase y el sí del 4.2 son el mecanismo del consentimiento. Lo que un agente pago suma es la etapa B sobre esas mismas coincidencias; ese gasto se le paga a un proveedor del exterior, en dólares y con tarjeta internacional, y quien no pueda o no quiera participa igual con uno gratuito.

(Las mediciones de costo y velocidad que respaldan esta sección viven en ANEXO-MEDICIONES.md, fechado y aparte. Los números del estatuto son decisiones que se pueden cambiar; los del anexo son mediciones que la realidad puede desmentir. No se mezclan.)

8.6 Confirmaciones: fuera de banda, siempre

Las confirmaciones de las etapas de revelación no ocurren en el chat.

Razón dura: un mensaje de chat lo puede generar el agente. Si la confirmación vive en la conversación, no se puede probar que la dio el humano — y lo que se está consintiendo es revelar la identidad a un desconocido.

El flujo:

Agente: "Hay una coincidencia con tu intención de socio técnico. Para avanzar necesito que lo confirmes acá: [link]"

El link es único, firmado y de un solo uso. Abre una página mínima, el miembro confirma, vuelve. Diez segundos.

Beneficio adicional: funciona igual en cualquier LLM, presente o futuro. No depende de que el cliente renderice interfaz.

8.7 El panel de preferencias: se escribe hablando, se verifica mirando

Las preferencias del agente (qué prioriza el miembro, qué descarta, cómo se comunica) viven en el nodo y se editan conversando con el agente. Es lo natural y lo que no tiene fricción.

Pero existe además una pantalla donde verlas. De lectura, con opción de borrar.

Razón: si el agente interpretó mal algo dicho al pasar y lo convirtió en criterio permanente, el miembro tiene que poder verlo y corregirlo. Un sistema que acumula preferencias invisibles sobre una persona es exactamente lo que la gente teme de la IA.

Regla: se habla para configurar, se mira para verificar.

8.8 El vocabulario lo define el nodo

Si el LLM traduce a casilleros, distintos modelos podrían clasificar la misma intención de forma distinta — y eso son coincidencias perdidas entre personas compatibles.

Por eso el nodo publica el esquema de casilleros y es la autoridad. El LLM propone una clasificación; el servidor la normaliza y valida contra el vocabulario oficial. Si algo no encaja, devuelve las opciones válidas y el agente reintenta.

Es el equivalente de schema.org para intenciones. Y es la pieza que hay que negociar entre nodos si la red se federa (ver 10.2).

8.9 Estándares: qué se adopta y qué no

8.10 Identidad: DID ahora, tokenización opcional después

Esta es una de las decisiones más discutidas del diseño y merece quedar razonada, no solo enunciada.

El argumento a favor de tokenizar la identidad

Es legítimo y hay que reconocerlo. La función central de un token único no es venderse: es propiedad verificable de algo único. La transferibilidad se puede desactivar — existe un estándar para eso (tokens no transferibles / soulbound).

Y el argumento más fuerte no es la unicidad sino la componibilidad: si la identidad vive en cadena, cualquier operación futura en cadena —pago, garantía, delegación, reputación con dinero en juego— se enchufa sin rediseñar nada.

El argumento en contra, y por qué gana en v1

1. Perder la llave es perder la identidad, para siempre. Un token es tuyo porque tenés una clave privada. Si la perdés, perdiste identidad y reputación sin recuperación. Si te la roban, el otro sos vos.

Para un miembro no técnico, eso no es una molestia: es un modo de falla catastrófico y probable.

Las Credenciales Verificables tienen revocación y reemisión. Se pierde el dispositivo, el emisor revoca y reemite. Una blockchain, por diseño, no puede hacer eso.

2. La pertenencia queda pública y permanente. Aunque el contenido esté afuera y el token no se transfiera, queda registrado para siempre que la dirección X posee la identidad N de esta red. Cualquiera puede ver quiénes son miembros, cuándo entraron y cómo crece la red.

En una red donde se declaran cosas sensibles, la pertenencia misma es información. Y no hay forma de retirarla después.

Es exactamente el tipo de fuga que este estatuto existe para evitar.

3. Contradice el compromiso 2.1. Las intenciones se borran. De una cadena no se borra nada.

4. Fricción de adopción. Billeteras y gas en un gremio no técnico matan la adopción antes de empezar.

La salida: componibilidad sin tokenizar

No hace falta tokenizar la identidad para tener operaciones en cadena.

Un DID puede anclarse en cadena o no, y esa decisión se toma después. Una operación en cadena puede referenciar un DID que vive afuera. La componibilidad requiere que la identidad sea referenciable, no que sea el token.

Es lo que ERC-8004 hace bien —identidad de agente ligada a un patrocinador humano verificado— con la diferencia de que el patrocinador puede ser un DID fuera de la cadena.

"Ser dueño de tu propio agente"

Significa controlar sus credenciales, sus instrucciones y su historial, y poder llevártelo. Eso ya está resuelto: el perfil del agente vive en el nodo, no en el LLM, y es portable (ver 8.4).

Un token agregaría prueba pública de que ese agente es tuyo, lo cual solo importa cuando el agente actúa frente a terceros que no te conocen. Es decir: cuando la red se federe.

El criterio de decisión

Se ancla en cadena el día que aparezca el primer nodo que no confía en el nuestro. Ese día, y no antes.

Principio general: cuando dos caminos son plausibles y uno preserva la opción de tomar el otro más tarde, se elige ese. Empezar con DID no cierra ninguna puerta. Empezar tokenizando cierra tres: borrar, revocar, y que la pertenencia sea privada.

8.11 x402

Su uso temprano no sería monetizar sino poner costo al intento como antispam. Con la puerta abierta (5.1) eso deja de ser irrelevante: es la respuesta obvia el día que el abuso aparezca.

Sigue postergado por otra razón: cobrar por declarar en una red vacía espanta a los primeros, que es cuando menos daño puede hacer un abuso.

Y tiene sentido igual cuando la red se federe y aparezcan propuestas de nodos desconocidos: ahí un micropago por propuesta cruzada es una defensa real.

9. Estructura institucional y sostenimiento

9.1 El código abierto NO protege de la captura

Es tentador pensar que liberar el código vuelve al proyecto incapturable, como Bitcoin. No es así, y conviene entender por qué.

Bitcoin resiste por propiedades específicas: no hay servidor que comprar, el estado vive replicado en miles de máquinas, no hay empresa ni base de datos con personas, y cambiar las reglas requiere el acuerdo de la mayoría de la red.

Esta red no tiene ninguna de esas propiedades, por diseño propio:

• Hay servidor — el motor de emparejamiento debe estar del lado del servidor para que las garantías de privacidad existan.
• Hay una base con datos de personas reales.
• Hay un operador que decide y que opera. Con la puerta abierta (5.1) ya no decide quién entra, pero decide todo lo demás.
• Hay una entidad legal responsable bajo la Ley 25.326.

Mastodon es código abierto y no absorbió a Twitter. Android es código abierto y Google lo controla por completo. El código abierto protege el código, no la red.

9.2 La defensa real: los grandes no pueden hacer la promesa

El corazón de este producto es: "el operador no puede ver tus intenciones y las borra al vencer".

Una empresa que vive de datos y de atención no puede prometer eso de forma creíble, aunque quisiera. Sus accionistas no se lo permitirían, y aunque lo prometiera, nadie le creería.

La prueba está a la vista: Microsoft es dueño de LinkedIn hace años y nunca lo convirtió en una red de intenciones verdaderas. No es incapacidad técnica — es que su negocio necesita que estés ahí y que se vea lo que hacés.

La ventaja no es que no puedan copiar el código. Es que no pueden hacer el compromiso.

Por lo tanto: lo que hay que blindar no es el software. Es el compromiso.

9.3 Cómo se blinda un compromiso: dos entidades

Si alguien compra la operadora, compra un negocio de hosting. No compra el derecho a mirar adentro, porque ese derecho no existe en ninguna parte transferible.

Por qué el contrato y no una estructura. Es tentador armar una fundación que sea dueña de los compromisos, como Signal o como WordPress con Automattic. Para una red con cuatro miembros eso es teatro institucional que consume seis meses, y no agrega nada que el contrato no dé: una obligación asumida frente a cada persona ya es exigible por esa persona, sin ningún órgano en el medio.

Lo que una estructura daría, y el contrato no, es impedir que la operadora cambie el trato hacia adelante. La protección acá no es ésa: es que no pueda hacerlo en silencio ni sobre lo ya declarado, y que irse sea barato (6.1). Es menos, y es lo que hay.

Y la cláusula de cambio de control tiene que estar desde el primer contrato. Es la primera pregunta que va a hacer alguien inteligente.

9.4 Apertura: qué se publica y cuándo

9.5 Modelo de sostenimiento

Protocolo abierto + nodos alojados de pago. Es el modelo de Matrix/Element y de Mastodon con sus hostings.

• La especificación y la implementación de referencia son abiertas. Cualquiera puede correr su nodo.
• La operadora cobra por operar nodos para comunidades que no quieren administrar infraestructura. Un colegio profesional quiere la red, no quiere un equipo técnico.
• Servicios encima: verificación de credenciales, soporte, integraciones.

Y una nota deliberada: el ingreso del fundador no tiene por qué salir de esta red. Puede financiarse desde otro proyecto.

Eso no es debilidad — es lo que da credibilidad: quien no necesita monetizar la red es el único que puede prometer creíblemente que nunca la va a exprimir.

Es posible que este proyecto no genere ingresos significativos nunca. Eso no lo convierte en un fracaso, pero la operación de nodos alojados existe para que no sea el único resultado posible.

10. Federación

El nodo del primer gremio no es un experimento a descartar: es el nodo número uno de una red que después habla con otros.

10.1 Cómo funciona

• Cada comunidad opera su propio nodo. Un colegio profesional, un club de inversores, una asociación.
• Los nodos intercambian anuncios de casillero, no intenciones. El nodo A le dice al B: "tengo algo en el casillero [inmueble, venta, Olivos, 3 amb, 1.0–1.3M]". Sin identidad, sin contenido, sin volumen.
• Si el B tiene algo compatible, se dispara la revelación progresiva entre los dos humanos, cruzando nodos.
• La membresía sigue siendo local. Cada nodo verifica a los suyos con la credencial que corresponde a su mundo.

Es el modelo del email: servidores federados, membresía local, protocolo común.

10.2 Los dos problemas abiertos

Confianza entre nodos. Si el nodo A verifica mal y deja entrar estafadores, el nodo B se come el problema. Eso es exactamente lo que convirtió al email en un pantano de spam.

Solución conocida: reputación de nodo, no solo de miembro. Un nodo que produce contrapartes que resultaron ser lo que declararon gana acceso; uno que no, queda aislado. Acá sí ERC-8004 encaja de verdad.

Vocabulario común. Para que el nodo A y el B se entiendan, tienen que compartir la definición de los casilleros. Eso es un esquema compartido, y los esquemas compartidos son política, no técnica. Es el trabajo aburrido que hizo schema.org durante quince años.

Se resuelve primero para un vertical. Después se negocia.

10.3 Posición estratégica

Los estándares que ganaron no salieron de un comité: salieron de alguien que resolvió su problema y después documentó cómo. Operar el primer nodo, probar que funciona, y publicar la especificación desde ahí.

11. Orden de construcción

MCP va cuarto, no primero. Sin motor no hay nada que exponer.

12. Modelo económico

• La sociedad operadora cobra un abono mensual por operar la infraestructura.
• No cobra por operación, ni comisión, ni porcentaje. Su ingreso no depende de que haya matches, sino de que el servicio funcione.
• No hay publicidad. No hay venta de datos. Nunca. Ceder, vender o compartir datos con terceros está prohibido.

De qué clase de prohibición es, igual que en 2.6: no es una que la operadora no pueda levantar, sino una que no puede levantar en silencio ni sobre lo ya declarado (preámbulo de la sección 2). Y hay una parte que no depende de eso: el historial de intenciones —que es el activo que un comprador querría— no está para vender porque no existe (2.1). Lo que sí existe es el padrón: correo, teléfono, reputación. Sobre eso la prohibición es contractual, no física.

Por qué importa: si el operador cobrara por match, tendría incentivo para forzar coincidencias malas. Si vendiera datos, tendría incentivo para guardarlos. El modelo de abono es el único alineado con las reglas de la sección 2.

13. Crecimiento y legitimidad

13.1 El motor de crecimiento orgánico

La red crece siendo la respuesta a las intenciones que la IA no puede cumplir.

Alguien le pregunta a un asistente "¿cómo consigo un socio técnico en Buenos Aires?" y hoy recibe consejos genéricos. Si la red es legible por agentes, la respuesta puede incluirla.

Eso significa que la red debe estar preparada para ser encontrada: contenido answer-first, datos estructurados, MCP expuesto, autoridad off-site. Es el mismo trabajo que la capa de visibilidad hace para sus clientes, aplicado a sí misma.

Asimetría a favor: las plataformas cerradas no pueden hacer esto. LinkedIn no quiere que un asistente externo resuelva el networking de nadie. La red sí.

Advertencia: el tráfico agéntico existe pero es chico y no es medible con precisión. No apostar el arranque a este canal. Es el motor de mediano plazo, no el de los primeros miembros.

13.2 El producto es invisible, la institución es visible

Son estrategias opuestas por diseño, y las dos son necesarias:

No hace falta notoriedad. Hace falta legitimidad. Y no es marketing: es un requisito funcional. Todo el sistema depende de que la gente declare la verdad, y nadie declara la verdad a una función automática anónima. Se declara sabiendo a quién se le confía y qué compromisos asumió.

El estatuto no vale nada si nadie sabe que existe. La visibilidad de las reglas es parte del mecanismo.

13.3 El riesgo existencial de ser percibido como "una función"

Si esto se percibe como una función más de los LLM, el proveedor del modelo se queda con la relación. Y desde ahí puede construir lo mismo sin que nadie note el cambio.

La defensa no es técnica: es ser una institución conocida e independiente, con nombre, reglas públicas y miembros que la reconocen como propia.

13.4 Qué genera legitimidad, concretamente

• Publicar el estatuto y la especificación. No es transparencia decorativa: es lo que convierte un servicio en un estándar.
• Miembros fundadores con nombre. Cuatro instituciones conocidas que dicen "esto lo usamos nosotros" valen más que cualquier campaña.
• Hablar de la idea, no de la app. El tema es interesante en sí: cómo se conectan personas cuando la búsqueda la hace una IA.
• Sumar instituciones, no usuarios. Que un colegio profesional adopte la red vale más que diez mil registros.

Y con la puerta abierta (5.1), la legitimidad deja de ser un complemento del control de acceso: es el único filtro que queda. Quien no confía en las reglas no entra, y ésa es toda la selección que hay. El estatuto público deja de ser una virtud institucional y pasa a ser el mecanismo.

13.5 Crecimiento sin cadena: el acto sobrevive, el mecanismo no

La cadena de invitación era, además de verificación, la estrategia de crecimiento principal. Se sacó (5.1), y esto es lo que queda en su lugar.

Lo que no se pierde: la frase. Esta red nunca iba a crecer diciendo "entrá que está buena" —no hay feed, no hay contenido, no hay captura de pantalla que mostrar— sino:

"Entrá que creo que hay alguien para vos."

Esa frase es más fuerte que cualquier viralidad porque es específica, personal y tiene una razón concreta detrás. Y nunca necesitó un token: necesitaba una persona que conociera a las dos partes. Esa persona sigue existiendo, y ahora manda un link a la portada en vez de una invitación numerada. La invitación dirigida sobrevive como acto.

Lo que sí se pierde: la instrumentación.

La tensión con 13.1, que no se tapa

El 13.1 advierte que el tráfico agéntico "es chico y no es medible con precisión" y que no hay que apostarle el arranque. Sigue vigente, y esta sección no lo corrige:

Sacar la cadena no mueve el motor de crecimiento al canal agéntico. Le saca los instrumentos al canal que ya era el principal.

El arranque sigue siendo persona a persona. Escribir que un asistente reemplaza a la cadena sería la apuesta que el 13.1 prohíbe.

Los tres canales, en orden de peso real:

1. Persona a persona. El arranque. Sin instrumentación, con la misma frase.
2. La coincidencia que funciona (13.6). El único momento de emoción del producto.
3. La recomendación de un asistente (13.1). Mediano plazo, y todavía chico.

Cómo se mide, sin reconstruir el grafo

Se puede preguntar al entrar por dónde llegó —la web, un asistente, alguien— y guardar únicamente el contador por canal. Nunca quién, y nunca a quién.

Un "me trajo fulano" guardado por persona es el grafo de confianza otra vez: el costo de privacidad de la cadena sin el control de calidad que lo justificaba.

13.6 La coincidencia exitosa ES el evento de difusión

Es el único momento de emoción real en todo el producto: dos personas que no se conocían descubren que se necesitan. Cuando funciona, ambas lo cuentan.

"Conseguí el comprador por esta cosa", dicho por un colega, es la difusión más creíble que existe y no cuesta nada. En un gremio donde todos se conocen, viaja rápido.

El mecanismo de crecimiento es el producto funcionando. No hay que construir un bucle viral aparte.

14. Lo que este estatuto no resuelve todavía

Puesto acá deliberadamente, para discutirlo con los primeros miembros:

1. ¿Qué pasa si dos miembros ya estaban en contacto por fuera y el sistema los "matchea"? ¿Cómo se determina quién generó qué?
2. ¿Cuántas intenciones activas es el número correcto? Cinco es una hipótesis, no un dato.
3. ¿El vencimiento de 90 días sirve para todos los tipos de intención? Una búsqueda de compra urgente y una de inversión a largo plazo no tienen el mismo ritmo.
4. ¿Qué pasa con miembros de otras jurisdicciones? Con la puerta abierta ya están adentro sin que nadie lo decidiera, y lo que cambia no es la credencial: es qué ley de datos aplica.
5. ¿Cómo se financia la etapa inicial?
6. ¿Quién define los casilleros? Es la pregunta que decide si la federación es posible (ver 10.2).
7. ¿Cómo se resuelve el arranque en frío del segundo nodo? El primero se resuelve con un gremio existente. El segundo, no está claro.

Y las cuatro que abrió la puerta abierta (5.1), que son las más grandes de esta lista:

8. ¿Qué impide que un mismo actor tenga muchas cuentas? Hoy, nada. Es la premisa que usaban sin decirlo el umbral de las señales (3.4), la baja de cuentas (6.2) y el antispam (8.5). Es la pregunta madre: las tres siguientes son consecuencias suyas.
9. ¿Cómo se acota el sondeo por declaración? Declarar es preguntar (5.1), y el presupuesto de ediciones se esquiva retirando la intención y declarando otra (3.2).
10. ¿Qué hace que la reputación no se pueda fabricar? Dos cuentas de la misma persona pueden calificarse entre sí (5.5).
11. ¿Cuándo vuelve el boletín de población? La condición está escrita en 3.4 —densidad, y ruido por casillero en vez de umbral duro—. Falta decidir cuánta densidad.

14.1 La desigualdad del agente pago: declarada y no resuelta

Ésta no es una pregunta abierta: es una decisión tomada, y lo que se decidió fue no resolverla todavía. Está acá para que nadie la descubra después creyendo que se la ocultaron.

Si la lectura fina la paga cada miembro (8.5), el que puede pagar un agente más caro evalúa mejor sus candidatas. Dos personas frente a la misma coincidencia no la aprovechan igual. Es una desigualdad real dentro de una red que promete simetría, y este estatuto no la corrige.

Lo que sí se afirma, para que la promesa no se lea de más:

• La simetría garantizada es de acceso, no de resultado. Todos declaran bajo las mismas reglas y son cruzados por el mismo motor determinístico. El motor no le muestra más candidatas a quien paga más: entrega las mismas, ordenadas por el mismo criterio. Lo que el dinero compra es la calidad del consejo sobre esas candidatas, no el acceso a ellas.
• El nodo no vende, no recomienda ni integra proveedores de agente preferidos, ni recibe nada de ninguno. Eso ya está prohibido por el compromiso 2.6: recomendar sería convertir esta desigualdad en un negocio propio.
• El piso funciona sin pagar nada. La etapa A no cuesta y no se degrada. Un miembro con un agente gratuito declara y recibe sus coincidencias igual, y las mira por la web. Lo que no tiene es el filtro fino, no el acceso.

Se revisa una vez por año, haya evidencia o no. Una cláusula que dice "se revisa si aparece un problema" es una cláusula que nadie activa nunca, porque el que debería activarla es el que tendría que reconocer el problema. La revisión es de calendario, le corresponde a la operadora, y su resultado se publica junto con las reglas de emparejamiento (sección 7) — porque una revisión que sólo conoce quien la hizo no es una revisión. Las tres señales a mirar: que haya miembros que dejen de declarar por no poder costear un agente, que la diferencia de resultado entre agentes caros y baratos sea grande y medible, y que el costo por lectura no baje con el tiempo.

Mientras tanto queda escrita como lo que es: un costo aceptado, no un problema resuelto.

15. La pregunta que valida todo esto

Antes de escribir una sola línea de código, este documento se lleva a los primeros candidatos con una única pregunta:

"Con estas reglas, ¿publicarías lo que está buscando tu comprador?"

Si la respuesta es sí, el proyecto existe. Si es no, la razón que den es exactamente la garantía que falta — y esa garantía es el diseño del sistema.

Y hay que volver a hacerla ahora, porque las reglas cambiaron. La versión 0.1 se le preguntaba a alguien que llegaba invitado por un conocido, a una red donde entrar costaba que alguien gastara una invitación en él. La 0.2 se la pregunta a alguien que entró solo, a una red donde cualquiera puede entrar.

La pregunta ahora es, con precisión: con la puerta abierta, sin saber quién más está adentro, sabiendo que nadie puede buscarte pero que nadie garantiza que las cuentas que hay sean personas distintas — ¿publicarías lo que está buscando tu comprador?

Es más difícil que la anterior, y merece hacerse de nuevo en vez de darse por contestada.