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 dashboards, 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 ciempies: 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: 5 directorios comunitarios en producción con más de 600 entidades indexadas — una plataforma de descubrimiento de comedia con 158 perfiles de comediantes indexados y 183 foros listados, una comunidad de baile social que mapea eventos por toda América Latina, y más. 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 el engagement 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 los DAOs 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 un feed 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 proveedores3.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 — dashboards, POS, motores de reservas, analíticas, paneles de admin. Construidos por cualquiera sobre el grafo.
| Ceiba | Capa 1 (Grafo) | Capa 2 (Producto) |
|---|---|---|
| La Cartelera | 158 perfiles comediantes, 183 foros indexados, eventos | Venta de boletos, perfiles (lacartelera.app) |
| Sociales | Eventos de baile, foros, instructores | Calendario comunitario (sociales.lat) |
4. Capa de Identidad
La identidad en ceiba.to no comienza con un formulario de registro. Comienza con el mundo real: alguien actua 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.
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.
- Dashboards SaaS — 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
| Acción | Costo |
|---|---|
| Explorar eventos, foros, perfiles | Gratis |
| Enviar un evento o reclamar un perfil | Gratis |
| Leer la API (con límite de tasa) | Gratis |
| Descargar dump CC BY 4.0 (con atribución) | Gratis |
| Ver edit history de una entidad | Gratis |
| Comprar un boleto (comisión por transacción) | De pago |
| Perfil verificado premium con analíticas | De pago |
| Listado destacado o dashboard de foro | De pago |
| Acceso comercial a la API (alto volumen) | De pago |
Nunca cobrable (anti-rent-seeking). Cosas que el operador del commons no puede cobrar:
- 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 acceso de lectura básico al
/.well-known/ceiba.json,/v1/healtho/v1/entities/*dentro de un rate limit razonable.
6.6 El Tráfico de Bots como Ingreso
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_timevalidado. - 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, dashboards, software. Sin tax mandatorio al protocolo upstream.
Multi-rail de pagos
Una ceiba puede activar uno o varios rails. Ninguno es default y el protocolo no impone jurisdicción:
| Rail | Cuándo usar |
|---|---|
| Stablecoin (USDC en Base/Arbitrum) | Cross-border, agentes, contribuidores remotos |
| x402 (HTTP 402 micropagos) | Bot/agente paga por query |
| Fiat-local con factura formal según jurisdicción del operador-semilla | CFDI en MX, monotributo en AR, invoice en US/EU |
| Lightning, MercadoPago, Wise, Stripe | Conveniencia regional |
| Off-protocol (entrega en mano, voucher, crédito interno) | Comunidades pequeñas, alta confianza |
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. Reglas duras:
- Solo redimible — no transable, no listable en exchange, no flota libre.
- Tipo de cambio fijo declarado en
ceiba.json. Solo puede subir, nunca bajar. - Escrow obligatorio del 100% del karma circulante validado, auditable vía
/v1/karma/escrow_proof. - Decay 5 años.
- Ventana de redención mensual o por threshold.
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
Lo que ya funciona hoy: productos de operador con ingresos reales (comisiones de boletos en La Cartelera, x402 en Coinnect, dashboards SaaS en NDNS), 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.
Lo que está en spec y en piloto: la capa de pago a contribuidores con split 80/20 (hooks en spec, primer payout pendiente), karma con escrow auditable (diseño cerrado, instrumentación pendiente), donación voluntaria al protocolo upstream desde commons fund.
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 ceiba.json y auditable en el commons fund.
Ciclo de karma cuando se active
- Un contribuidor envía un dato nuevo o una corrección a una entidad.
- El titular de la entidad valida o rechaza la contribución.
- Si es validada, la contribución entra a un estado de escrow.
- Existe una ventana de disputa de 24 horas.
- Después de las 24 horas sin disputa, el karma queda consolidado.
Anti-farming: el titular de la entidad debe validar cada contribución. Aceptaciones >80% del mismo contribuidor levantan revisió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, combinan resultados.
8. Entidades Portátiles
8.1 El Modelo Ciempies
Cada entidad es un objeto portátil y autocontenido — un ciempies — con tres partes:
- Cuerpo — los propios datos de la entidad
- Patas izquierdas — conectores entrantes (quién referencia a esta entidad)
- 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:
| Izquierda | Derecha | |
|---|---|---|
hosts_show | ↔ | hosted_at |
performs_at | ↔ | has_performer |
located_in | ↔ | has_location |
member_of | ↔ | has_member |
Las relaciones no se almacenan de forma centralizada. Emergen del emparejamiento de conectores.
8.3 El Modelo Wikipedia de Replicación
Un ciempies 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 ciempies 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 feed .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.
11. Implementación
11.1 Stack
| Capa | Tecnología | Justificación |
|---|---|---|
| API | FastAPI (Python) | Simple, rápido, genera OpenAPI automáticamente |
| Base de datos | Supabase / SQLite | Hospedado o auto-hospedado |
| Frontend | Vanilla JS + HTML | Sin paso de build |
| Hosting | Cualquier VPS | Caddy + systemd |
| Acceso IA | Servidor MCP | Claude, OpenAI, cualquier agente compatible |
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 el engagement. 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 está probando esta tesis. Un directorio de 158 comediantes indexados 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
| ceiba.to | ActivityPub | AT Protocol | Farcaster | Lens | |
|---|---|---|---|---|---|
| Unidad primaria | Comunidad | Individual | Individual | Individual | Individual |
| Modelo de datos | Entidades + fuentes | Actividades | Registros + repos | Mensajes | Posts |
| Identidad | Reclamo por capas | Basada en cuenta | Basada en DID | FID on-chain | Basada en NFT |
| Token requerido | No | No | No | Sí (ETH para FID) | Sí |
| Nativa para IA | Sí (MCP) | No | No | No | No |
| Objetivo | Comunidades locales | Redes sociales | Redes sociales | Cripto-nativos | Cripto-nativos |
| Compensación de datos | Sí (karma continuo) [PLANNED] | No | No | No | No |
Apéndice B: Glosario
- Ceiba — una comunidad independiente y autogobernada dentro de la red ceiba.to
- Ciempies — 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 ciempies, 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