ceiba.to: Un Protocolo Fractal de Redes Comunitarias

1. Resumen

Internet fragmentó las comunidades en silos de plataformas. Facebook es dueño de tu grupo del vecindario. Discord es dueño de tu escena de comedia. WhatsApp es dueño de tu red de proveedores. ceiba.to es un protocolo para reconstruir comunidades en terreno abierto — ligero, fractal, propiedad de la comunidad.

ceiba.to separa la infraestructura comunitaria en dos capas: un grafo público (gratuito, abierto, API-first) que contiene entidades, relaciones y endpoints que cualquiera puede crear y consumir; y una capa de productos (de pago, construida por cualquiera) que contiene paneles de control, Punto de Venta (POS), motores de reservas y herramientas operativas que convierten datos abiertos en ingresos. El grafo es gratuito. Los productos son tuyos.

A nivel de entidad, ceiba.to introduce el modelo ciempiés: cada entidad es un objeto portátil y autocontenido que lleva sus propios datos y conectores tipados. Los conectores encajan como pares de bases de ADN — cuando dos entidades tienen tipos de conectores complementarios, los intérpretes ensamblan la relación automáticamente. Las entidades se replican en nodos voluntarios formando una cadena que se autorepara cuando algún nodo se desconecta.

El modelo ya está funcionando: 3 ceibas en producción con más de 600 entidades indexadas — una plataforma de descubrimiento de comedia con 158 perfiles de comediantes y 183 foros listados, una red de enrutamiento de dinero con más de 80 adaptadores de exchange, y una comunidad de baile social que mapea eventos por toda América Latina. ceiba.to es la capa de protocolo que los conecta.

2. El Problema

2.1 Las Comunidades Están Atrapadas

Toda comunidad significativa hoy en día vive dentro de una plataforma que no controla. La escena de comedia en Ciudad de México se coordina a través de grupos de WhatsApp e historias de Instagram. Los clientes habituales de un bar se comunican por una página de Facebook que no pueden exportar. Las redes de negocios locales existen como reseñas de Google Maps que le pertenecen a Google.

Estas plataformas ofrecen conveniencia a cambio de propiedad. El trato tiene consecuencias:

• Sin portabilidad de datos. La reputación de un comediante en Instagram no puede migrar a una nueva plataforma. El historial de reseñas de un bar le pertenece a Google, no al bar.
• Sin interoperabilidad. La comunidad de comedia y la comunidad del bar comparten miembros, pero sus plataformas no comparten datos.
• Control algorítmico. Las plataformas deciden quién ve qué, optimizando para la participación y no para el valor comunitario.
• Fragilidad. Cuando el admin de un grupo de WhatsApp se va, el grupo muere. Cuando una página de Facebook es baneada, la comunidad pierde su archivo.

2.2 Las Comunidades Pequeñas No Tienen Herramientas

Las plataformas empresariales (Salesforce, Slack, Notion) sirven a grandes organizaciones. Las plataformas de consumo (Facebook, Discord, Reddit) sirven a mercados masivos. Pero la escena de comedia en Puebla — 30 comediantes, 15 foros, 200 asistentes habituales — no tiene herramientas diseñadas para su escala.

Estas comunidades son demasiado pequeñas para el software empresarial, demasiado específicas para las plataformas de consumo, y demasiado del mundo real para las DAO de blockchain.

2.3 Las Alternativas Existentes No Resuelven el Problema

Los protocolos sociales descentralizados han avanzado. ActivityPub (Mastodon) habilita redes sociales federadas. El AT Protocol (Bluesky) introdujo identidad portátil. Farcaster separa los grafos sociales de las aplicaciones. Lens Protocol pone las conexiones sociales on-chain.

Pero comparten un punto ciego: modelan individuos publicando contenido, no comunidades organizando conocimiento. Una escena de comedia no es una fuente social. La red de proveedores de un bar no es una línea de tiempo. Lo que las comunidades necesitan es un protocolo comunitario — uno que trate a la propia comunidad como la unidad primaria.

3. El Modelo Ceiba

3.1 Qué es una Ceiba

Una ceiba es una comunidad independiente y autogobernada con sus propios datos, miembros y reglas. Su nombre viene del árbol ceiba — sagrado para los mayas, su tronco conecta la tierra y el cielo, sus raíces se extienden bajo tierra para vincularse con otros árboles.

Cada ceiba tiene:

• Entidades — las cosas que le importan a la comunidad (comediantes, foros, tipos de cambio, productos del menú)
• Perfiles — datos estructurados sobre esas entidades, construidos a partir de fuentes públicas
• Miembros — personas que participan, contribuyen o reclaman propiedad de entidades
• Fuentes — atribución de cada dato
• Historial de ediciones — un registro completo de cambios, estilo Wikipedia
• API — acceso legible por máquinas a todos los datos de la comunidad

Una ceiba no es una red social. Es una base de conocimiento con características sociales.

3.2 Estructura Fractal

Las comunidades son fractales. La escena de comedia de Ciudad de México contiene sub-escenas: improv, stand-up, open mics, roast battles. Cada foro tiene su propia comunidad de habituales.

ceiba.to/comedia                    # Comunidad de comedia (nacional)
  ├── ceiba.to/comedia/cdmx         # Escena de CDMX
  ├── ceiba.to/comedia/puebla       # Escena de Puebla
  └── ceiba.to/comedia/monterrey    # Escena de Monterrey

ceiba.to/ndns                       # Comunidad del bar
  ├── ceiba.to/ndns/staff           # Red de personal
  ├── ceiba.to/ndns/events          # Calendario de eventos
  └── ceiba.to/ndns/suppliers       # Directorio de proveedores

3.3 Autogobierno

ceiba.to sigue el modelo Wikipedia, no el modelo plataforma. Abierto por defecto. Reclamar, no registrarse. Moderación comunitaria. Sin autoridad central.

3.4 Despliegues Reales

ceiba.to no es un protocolo teórico. Describe patrones que ya están corriendo en producción:

La Cartelera (lacartelera.app) — 158 perfiles de comediantes, 183 foros indexados, en 29+ ciudades. Perfiles construidos a partir de 22 fuentes verificadas, reclamables por sus dueños. API-first con servidor MCP para agentes de IA.

Sociales (sociales.lat) — Foros, eventos e instructores de baile social por toda América Latina.

3.5 El Modelo de Dos Capas

Capa 1: Grafo Público — entidades, relaciones, fuentes y endpoints legibles por máquinas. Siempre gratuito, siempre abierto.

Capa 2: Productos — paneles de control, Punto de Venta (POS), motores de reservas, analíticas, paneles de administración. Construidos por cualquiera sobre el grafo.

4. Capa de Identidad

La identidad en ceiba.to no comienza con un formulario de registro. Comienza con el mundo real: alguien actúa en un foro, aparece en un cartel, es mencionado en un grupo de WhatsApp. El perfil ya existe antes de que la persona llegue. El protocolo solo necesita responder una pregunta: ¿esta persona real es la misma que ese perfil?

4.1 Tres Capas de Identidad

Capa 0 — Reclamo por SMS (una sola vez). El primer paso para reclamar un perfil es confirmar que la persona controla el número de teléfono asociado. Se envía un código de un solo uso. Una vez validado, el reclamo queda registrado. Este paso ocurre una sola vez por perfil: no es autenticación cotidiana, es el momento en que una persona real toma posesión de su identidad dentro del protocolo.

Capa 1 — Passkey / WebAuthn (uso diario). Una vez reclamado el perfil, la autenticación diaria ocurre mediante passkey vinculada al dispositivo: huella digital, Face ID, o PIN del sistema operativo. Sin contraseñas, sin formularios. El dispositivo es la llave.

Capa 2 — Recuperación social (cuando se pierde todo). Si el usuario pierde sus dispositivos, puede iniciar un proceso de recuperación social. Elige N contactos de confianza dentro de su red ceiba — personas que lo conocen en el mundo real. Esos contactos re-atestiguan su identidad. El umbral por defecto es N=3.

Adicionalmente, el protocolo genera un enlace mágico de subdominio en el momento del reclamo — por ejemplo, xdsfnmfdu.ndns.club — un identificador opaco que puede usarse como palanca de acceso de emergencia.

4.2 El Seed: Moderador Fundador

Cada ceiba tiene un seed: la persona o equipo que fundó la comunidad y configuró sus parámetros iniciales. El seed es el moderador fundador. Mientras la red de confianza de la ceiba aún es pequeña, el seed valida los primeros reclamos de identidad.

El seed configura parámetros clave de la ceiba: el umbral N para recuperación social, los tipos de entidades que se rastrean, los criterios de emparejamiento entre perfiles, y las reglas de karma. El seed no es una autoridad permanente — su rol especial decrece a medida que la red crece.

El seed se sostiene económicamente del producto que opera (comisiones, dashboards, software, x402) y no de una rebanada del pool de contribuciones — ver §6.7. Si el seed quiere donar parte de sus ingresos al commons fund de la ceiba, lo declara públicamente en ceiba.json.

4.3 Modelo de Confianza: Conjuntos, No Cadenas

En un modelo de cadena, si A confía en B y B confía en C, se asume que A confía en C. Esto crea grafos de confianza transitivos que son fáciles de atacar.

ceiba.to usa un modelo de conjuntos. La confianza no es una flecha entre dos personas — es membresía en un conjunto. Si A conoce tanto a B como a C — en el mundo real — entonces A, B y C forman el conjunto {A, B, C}. Pero eso no significa que B confíe en C solo porque ambos son conocidos de A.

La confianza transitiva solo opera a través de co-membresía, no a través de cadenas. Esto refleja cómo funciona la confianza humana real.

4.4 Emparejamiento de Entidades Entre Ceibas

Una persona real puede existir en múltiples ceibas con perfiles independientes. El protocolo resuelve esto con un mecanismo de emparejamiento por campos no esenciales. El match propuesto se presenta a la entidad. No hay matching automático sin consentimiento.

4.5 Verificación Presencial por QR

ceiba.to soporta verificación presencial mediante código QR. Cualquier miembro con nivel de confianza suficiente puede generar un QR temporal. El sujeto a verificar escanea el QR. El verificador confirma la coincidencia en persona. Las verificaciones presenciales valen más karma que las remotas.

5. Protocolo de Datos

5.1 Atribución de Fuentes

Cada dato tiene una fuente. Ningún dato existe sin atribución.

{
  "entity": "Comedian/LuisGarcia",
  "field": "upcoming_shows",
  "value": ["2026-04-01 @ Foro Normandie"],
  "source": {
    "type": "venue_calendar",
    "url": "https://foronormandie.com/abril",
    "fetched_at": "2026-03-25T12:00:00Z",
    "confidence": "high"
  }
}

5.2 Abierto por Defecto

Todos los datos comunitarios son abiertos por defecto. Los propietarios pueden marcar campos específicos como privados después de reclamar su perfil.

5.3 Datos Estructurados

ceiba.to usa Schema.org como vocabulario base. Un comediante se mapea a Schema.org/Person, un foro a LocalBusiness, un tipo de cambio a ExchangeRateSpecification.

5.4 Acceso por Máquinas

Cada ceiba expone datos mediante: REST API (JSON, OpenAPI), Servidor MCP (consultas de agentes de IA), y llms.txt + robots.txt (descubrimiento).

6. Economía Comunitaria

6.0 La Regla

Una ceiba es un mapa, no un libro de caja.

El commons describe cosas que existen en el mundo: lugares, gente con presencia pública, eventos anunciados, relaciones declaradas. El producto describe lo que pasa adentro: quién compró, cuánto, con qué tarjeta, qué le dijo el cliente al mesero.

La regla decidible: pregúntate si el dato existiría sin tu producto. Si la respuesta es sí, es del commons. Si solo existe porque alguien usó tu plataforma, es tuyo. El mapa es de todos. Lo que construyes encima es tuyo.

6.1 El Grafo Abierto No Es el Producto

El grafo abierto — entidades, relaciones, fuentes, APIs — es gratuito para leer y contribuir. Pero operar una ceiba cuesta dinero real: servidores, curación de datos, moderación, desarrollo. Capa 1 (grafo) es gratuita. Capa 2 (productos) es donde los operadores ganan dinero.

6.2 Por Qué los Datos Abiertos Crean Mejores Negocios

Las calles de una ciudad son públicas. Cualquiera puede caminarlas, mapearlas, construir sobre ellas. Pero el restaurante de la esquina sigue cobrando por la cena — y nadie encuentra esto confuso. Los datos comunitarios funcionan igual. Foros, eventos, artistas, horarios — este es el mapa compartido de una escena viva. Acaparar estos datos no crearía ventaja; crearía un catálogo muerto.

6.3 Administración y los Bienes Comunes Mantenidos

Los datos abiertos no significan datos desatendidos. Un parque público está abierto para todos, pero sin un jardinero se vuelve un matorral. El rol del operador es la administración: verificar, enriquecer y estructurar continuamente los bienes comunes.

6.4 El Modelo del Operador

Cada ceiba tiene un operador. Los ingresos del operador provienen de:

• Comisiones de venta de boletos — 5-10% por transacción.
• Perfiles premium — verificados con analíticas, prioridad en búsqueda.
• Listados destacados — los negocios pagan por visibilidad.
• Paneles SaaS (Software como Servicio) — gestión de eventos, analíticas de audiencia, seguimiento de P&L.
• Acceso comercial a la API — nivel gratuito con límite de tasa; niveles de pago para alto volumen.
• White-label y licenciamiento — otras comunidades licencian la tecnología.

6.5 Gratis para Participar, De Pago para Escalar

Nunca cobrable (anti-rent-seeking). Hay cosas que el operador del commons no puede cobrar, porque cobrarlas es dejar de ser operador y volverse gateway extractivo:

• Cobrar a otra ceiba por leer el commons que tú operas.
• Cobrar al dueño de un perfil por reclamarlo.
• Cobrar por ocultar información que ya era pública (extorsión inversa, anti-patrón Yelp).
• Cobrar por edits aceptados.
• Cobrar por el acceso de lectura básico al /.well-known/ceiba.json, /v1/health o /v1/entities/* dentro de un rate limit razonable.

La línea es clara: cobras por trabajo que hiciste sobre el commons. No cobras por el commons en sí.

6.6 El Tráfico de Bots como Ingreso [PLANNED]

Los agentes de IA pagan micropagos por consultas de datos vía x402 [PLANNED]. El Machine Tipping Protocol (MTP) extiende esto [PLANNED]: los miembros que verifican datos del mundo real reciben micropagos de un fondo financiado por el tráfico de bots.

6.7 Karma split 80/20 (operador separado del pool) [SPEC]

Cuando una ceiba activa la capa de pago a contribuidores, el revenue que el operador decide poner al pool se reparte así:

• 80% → contribuidores, proporcional al karma_at_time validado.
• 20% → commons fund de la propia ceiba, gobernado por la comunidad: paga moderadores, infra, eventos, o se dona voluntariamente al protocolo upstream.

El operador-semilla se paga de su producto, no del pool. Comisiones de transacción, dashboards, software — eso es su sueldo. Si no genera valor de producto, no come, pero tampoco extrae del commons. No hay tax mandatorio al protocolo upstream: cada ceiba dona si quiere, desde su commons fund.

Multi-rail de pagos

Una ceiba puede activar uno o varios rails. Ninguno es default y el protocolo no impone jurisdicción:

6.8 Sin Token, Karma Redimible No Transable

ceiba.to no emite token, no usa blockchain, no necesita wallet. La capa de protocolo es universal y vive en rails ya existentes. Una comunidad de comedia en Puebla no debería tener que entender comisiones de gas para organizar open mics.

Cada ceiba puede llevar internamente un contador de karma — funciona como las horas en un banco de tiempo o las millas de aerolínea. Es contabilidad, no especulación. Reglas duras para que no se vuelva token de facto:

1. Solo redimible — no transable persona-a-persona, no listable en exchange, no flota libre.
2. Tipo de cambio fijo declarado en ceiba.json (ej. 1 karma = 1 MXN). Solo puede subir, nunca bajar.
3. Escrow obligatorio del 100% del karma circulante validado, mantenido por la ceiba en stablecoin o fiat. Auditable vía /v1/karma/escrow_proof.
4. Decay 5 años — el karma se deprecia con el tiempo.
5. Ventana de redención mensual o cuando el balance pasa un threshold.

El karma nunca puede flotar libremente, nunca llega a un exchange, nunca atrae traders. Es horas-banco con timestamp, no una coin.

6.9 Iniciar Nuevas Comunidades

El manual: elige un vertical, genera el scaffold con koa-gen, cura datos iniciales de fuentes públicas, lanza gratis, introduce productos de pago una vez que hay usuarios, conéctate a la red ceiba.to.

6.10 Gobernanza del Protocolo

El protocolo ceiba.to está diseñado para sobrevivir a cualquier operador individual. Una entidad orientada a la misión administra el estándar abierto, la marca registrada y la especificación del protocolo.

6.11 Estado Actual

Hay que distinguir entre lo que ya fluye en producción y lo que está especificado pero todavía no opera:

Lo que ya funciona hoy:

• Productos de operador con ingresos reales — comisiones de boletos en La Cartelera, x402 en Coinnect, dashboards SaaS en NDNS, eventos en Sociales.
• El grafo público y el edit history en las 3 ceibas en producción.
• Los manifests /.well-known/ceiba.json y la federación read-only entre ceibas.

Lo que está en spec y en piloto:

• La capa de pago a contribuidores con split 80/20 — los hooks están en spec, el primer payout real está pendiente.
• Karma con escrow 100% auditable — diseño cerrado, instrumentación pendiente.
• Donación voluntaria al protocolo upstream desde commons fund — sin presión, sin tax.

Lo que es roadmap, no presente:

• Federación read-write entre ceibas.
• Liquidación cross-ceiba de karma.

Hoy, cero dinero fluye automáticamente del producto al pool. Cuando empiece a fluir, será visible en el ceiba.json y auditable en el commons fund de cada ceiba.

Ciclo de karma cuando se active

1. Un contribuidor envía un dato nuevo o una corrección a una entidad.
2. El titular de la entidad valida o rechaza la contribución.
3. Si es validada, la contribución entra a un estado de escrow.
4. Existe una ventana de disputa de 24 horas.
5. Después de las 24 horas sin disputa, el karma queda consolidado.

Anti-farming: el titular de la entidad debe validar cada contribución. Farming solo sería posible con complicidad del titular — aceptaciones >80% del mismo contribuidor levantan revisión de moderación.

Bots como contribuidores: los agentes automáticos pueden contribuir datos y acumular karma exactamente igual que los humanos.

7. Protocolo de Interconexión

7.1 Descubrimiento

Cualquier ceiba se registra publicando un manifiesto en /.well-known/ceiba.json.

7.2 Formatos de Datos Compartidos

Schema.org + JSON-LD + OpenAPI + MCP + extensiones ceiba. El vocabulario compartido habilita la resolución automática de entidades entre ceibas.

7.3 Búsqueda Entre Ceibas

Federación sin la complejidad del modelo inbox/outbox de ActivityPub. Las ceibas exponen APIs que pueden ser consultadas.

7.4 Comunicación Agente a Agente

Los agentes de IA consultan el índice ceiba.to, llaman servidores MCP y combinan resultados. Esto ya funciona en La Cartelera.

8. Entidades Portátiles

8.1 El Modelo Ciempiés

Cada entidad es un objeto portátil y autocontenido — un ciempiés — con tres partes:

1. Cuerpo — los propios datos de la entidad
2. Patas izquierdas — conectores entrantes (quién referencia a esta entidad)
3. Patas derechas — conectores salientes (a quién referencia esta entidad)

{
  "ceiba:entity": "venue/cantina-nini",
  "body": { "name": "Cantina Nini", "type": "Venue", "city": "Puebla" },
  "connectors": {
    "outbound": [
      { "type": "located_in", "target": "city/puebla" },
      { "type": "hosts_show", "target": "show/open-mic-nini" }
    ],
    "inbound": [
      { "type": "performs_at", "source": "comedian/ana-torres" },
      { "type": "listed_on", "source": "ceiba/comedia" }
    ]
  },
  "replicas": [{ "node": "lacartelera.app", "last_sync": "2026-03-31T20:00:00Z" }],
  "version": 23
}

8.2 Emparejamiento de Conectores

Los conectores tienen complementos — como pares de bases de ADN:

Las relaciones no se almacenan de forma centralizada. Emergen del emparejamiento de conectores.

8.3 El Modelo Wikipedia de Replicación

Un ciempiés no pertenece a ningún servidor específico. Al igual que un artículo de Wikipedia existe como concepto con copias en servidores, cachés y mirrors alrededor del mundo, un ciempiés existe como una idea que puede tener múltiples copias distribuidas. La autoridad sobre el contenido viene de quien es la entidad representada, no de quién lo hostea.

9. Replicación Distribuida

9.1 Cadena de Nodos

Cualquier computadora puede convertirse en un nodo ceiba. Al ejecutar el software de nodo, se une a una cadena de replicación: sincronización, registro, replicación activa, salida elegante.

Cadena de nodos a las 3:00 PM:
  [Primario: ash]  -->  [Nodo A]  -->  [Nodo B]  -->  [Nodo C]

Cadena de nodos a las 3:30 PM (Nodo A se desconecta):
  [Primario: ash]  -->  [Nodo B]  -->  [Nodo C]

No es una blockchain. Sin prueba de trabajo, sin algoritmo de consenso, sin comisiones de gas.

9.2 Resolución de Conflictos

• El último en escribir gana por defecto.
• Prioridad de fuente — las ediciones del dueño de la entidad siempre ganan.
• Conflictos de conectores — unión de merge (ambos se mantienen).

10. Ecosistema de Datos Abiertos

10.1 Integraciones Bidireccionales

OpenStreetMap [PLANNED] — Las ceibas extraerían coordenadas y contribuirían datos de dirección verificados. (Integración bidireccional planificada.)

Wikidata [PLANNED] — Las entidades notables podrían crearse como Q-items de Wikidata. (Integración planificada.)

iCalendar — Cada evento puede exportarse como fuente .ics estándar.

ActivityPub [PLANNED] — Los eventos podrían publicarse como objetos ActivityPub para el Fediverso. (Integración planificada.)

Schema.org — Los datos estructurados embebidos en las páginas ceiba (JSON-LD) alimentan los resultados enriquecidos de los motores de búsqueda (Optimización para Motores de Búsqueda, SEO).

11. Implementación

11.1 Stack

11.2 koa-gen

koa-gen create --name "Escena Gastronómica Puebla" \
  --entities "Restaurante,Chef,Platillo,Reseña" \
  --id "comida-puebla"

Genera: aplicación FastAPI, esquema con atribución de fuentes, frontend en Vanilla JS, configuración de servidor MCP, manifiesto ceiba.json, llms.txt.

12. Hoja de Ruta

Fase 1: Comunidades Verticales (AHORA) — La Cartelera, NDNS, Sociales. En producción.

Fase 2: Identidad Entre Comunidades (Q3 2026) — ceiba.to/id resolvedor, perfiles entre ceibas, reclamo por SMS + passkey, recuperación social.

Fase 3: Kit de Creación Comunitaria (Q4 2026) — koa-gen open source, templates, documentación.

Fase 4: Capa de Incentivos y Federación (H1 2027) — x402 en todas las ceibas, economía karma v1, MTP, tesorería comunitaria.

Fase 5: Especificación de Protocolo Abierto (H2 2027) — Especificación versionada, organismos de estándares, implementaciones de terceros.

13. Filosofía

Comunidades, No Usuarios

La unidad fundamental de ceiba.to es la comunidad, no el individuo. Las plataformas optimizan para la participación. ceiba.to optimiza para la salud comunitaria.

Protocolos, No Plataformas

Una plataforma es dueña de los servidores, los datos, los algoritmos y las reglas. Un protocolo define cómo se comunican los sistemas independientes. Los participantes son pares.

La Falacia de la Escala

ceiba.to es la prueba. Un directorio de 158 comediantes en México es más valioso para esos comediantes que un perfil en una plataforma con 3 mil millones de usuarios. El protocolo provee interoperabilidad. Los servidores retienen independencia.

Construido en México, Construido para Todos

El protocolo es abierto. El código es abierto. Los datos son abiertos. Cualquiera, en cualquier lugar, puede iniciar una ceiba.

Apéndice A: Comparación con Protocolos Existentes

Apéndice B: Glosario

• Ceiba — una comunidad independiente y autogobernada dentro de la red ceiba.to
• Ciempiés — una entidad portátil y autocontenida con conectores tipados; la unidad de datos fundamental
• Reclamo — afirmar propiedad sobre un perfil creado a partir de datos públicos
• Conector — un endpoint de relación tipado; los conectores tienen complementos que encajan como pares de bases de ADN
• Entidad — cualquier cosa que rastrea una comunidad (persona, negocio, evento, producto, tasa)
• Intérprete — el motor de una ceiba que lee ciempiés, empareja conectores y ensambla un grafo específico al contexto
• Nodo — una máquina voluntaria que replica datos ceiba
• koa-gen — generador de código que genera scaffold para nuevas comunidades ceiba
• MCP — Model Context Protocol para consultas de agentes de IA
• MTP — Machine Tipping Protocol para datos verificados por la comunidad [PLANNED]
• x402 — protocolo de pago nativo de HTTP para micropagos de API [PLANNED]
• Seed — el moderador fundador de una ceiba
• Karma — puntos acumulados por contribuciones de datos validadas; decaen a los 5 años [PLANNED]

ceiba.to es un proyecto de KOA Labs. El código es de código abierto. Los datos son abiertos por defecto. Las comunidades se autogobiernan.

Contacto: [email protected] · Índice comunitario: ceiba.to