The graph is free.
The products are yours.

Porque la data de tu comunidad — los negocios de tu calle, los eventos del barrio, la gente que organiza cosas — hoy vive dentro de plataformas que pueden cerrarse, cambiarle las reglas, o venderte de vuelta lo que ya era tuyo. ceiba.to es un lugar donde eso mismo vive en terreno propio, y sigue funcionando aunque la plataforma de moda desaparezca mañana.

No. Es más parecido al email o a WhatsApp a nivel protocolo: no es un producto, son reglas para que muchos productos hablen el mismo idioma. Tu ceiba puede ser una página, un dashboard, una app de reservas, un bot de Telegram — lo que necesites. Todas se entienden entre sí sin pasar por un servidor central.

Solo si tu activas esa capa, sobre una fuente de ingreso que tu declaras (no sobre todo tu revenue), y solo sobre ediciones validadas — la persona que actualiza el horario de un negocio recibe compensación si el titular confirma que la información es correcta. Sin validación, no hay karma. Hoy no fluye dinero: la capa económica está en fase de diseño.

Cada ceiba es autónoma. El protocolo no tiene dueño central, igual que nadie es dueño del email o del HTTP. Hay un grupo que mantiene el spec (nosotros, por ahora), pero cada comunidad decide sus reglas, modera su contenido, y se lleva lo que genera. Federarse con otras es opcional.

No. ceiba.to no emite token, no usa blockchain, no necesita wallet.

Lo que sí permite — si tu ceiba lo activa — es pagar a quien contribuye datos. Eso pasa por los rails que ya existen: stablecoin (USDC), pagos por API (x402), o transferencia local con factura. Cada operador elige el suyo según su jurisdicción y su comunidad.

Internamente cada ceiba puede llevar un contador de karma — funciona como las horas en un banco de tiempo o las millas de aerolínea. Es contabilidad, no especulación: solo se redime contra el tipo de cambio que la ceiba publica, y solo dentro de esa comunidad. No se transa, no flota, no entra a un exchange.

La resiliencia del protocolo viene de copias compartidas entre servidores de confianza, no de una cadena distribuida. Todo lo que necesitas para correr una ceiba cabe en un VPS de $5/mes.

El mapa es de todos. Lo que construyes encima es tuyo.

Se puede cobrar: productos (dashboards, ticketing, POS, booking, CRM), comisiones de transacción, APIs premium / x402, curación destacada, exports masivos, soporte, white-label.

No se puede cobrar: acceso de lectura al commons, reclamar tu propio perfil, edits aceptados, cobrar a otra ceiba por leer datos públicos, ocultar info ya pública a cambio de pago.

La regla decidible: si el dato existiría sin tu producto, es del commons. Si solo existe porque alguien usó tu producto, es tuyo.

Estamos en alpha super-temprano. Lo que sí funciona en producción: el protocolo (spec v0.5 publicada, additive sobre v0.4), el schema JSON formal, endpoints /.well-known/ceiba.json, /health y /v1/stats vivos en varias ceibas, y la primera con datos verificados — lacartelera.app: 227 perfiles de comediantes claimables por OTP WhatsApp + 188 venues + 66 eventos próximos.

Lo que empezó a funcionar el 2026-05-14: la primera federación push productiva entre dos ceibas — NDNS empuja eventos de comedia confirmados a lacartelera.app en tiempo real vía Postgres trigger + pg_net, con un cron de 5 min como red de seguridad. Patrón canónico para parejas futuras (ver whitepaper técnico §6.2.1).

Lo que aún no funciona en producción: federación bidireccional entre N ceibas (la primera es push 1→1), la economía de karma 80/20 (está en spec, pendiente implementar como piloto en cartelera), el CLI koa-gen-ceiba init self-serve, y un agregador activo que mantenga este registro al día sin edits manuales.

Estado de las demás ceibas: boda.market tiene 84 entidades seed con websites verificables (real, chico); fotografos.lat tiene 279 importados por scrape sin verificar humanamente; botmarket.bot indexa 1841 MCPs y agents (infra, no comunidad humana); sociales.lat arrancó con seed procedural sin fuente y estamos purgando esa DB (de ahí va a 0 visible); montessori.koa.dev está offline pendiente reconectar.

Si quieres armar una ceiba contigo, este es el mejor momento — pero entra sabiendo que vas a chocar con cosas a medio terminar.

Hoy no. El spec (actualmente v0.5) lo escribe y mantiene KOA Labs (un equipo chico en México). El repo de referencia, el schema y este sitio viven en infra que controlamos nosotros. La narrativa de "protocolo abierto sin dueño central" es aspiracional: queremos llegar ahí, pero v0.5 todavía es un proyecto con maintainer único.

Lo que sí es abierto hoy: el spec es público y libre de usar, el schema está versionado, cualquiera puede correr una ceiba sin pedirnos permiso, y los cambios al protocolo pasan por RFC pública. Lo que falta para ser realmente descentralizado: un steward council con voz formal de las ceibas grandes (objetivo v0.6+), independencia financiera del protocolo respecto a KOA Labs, y al menos 3 implementaciones independientes del schema. No vamos a fingir lo contrario.

Because your community's data — the businesses on your street, the events in your neighborhood, the people running things — today lives inside platforms that can shut down, change the rules, or sell you back what was already yours. ceiba.to is a place where the same data lives on ground you control, and keeps working even if the trendy platform vanishes tomorrow.

No. It's closer to email or WhatsApp at the protocol level: it's not a product, it's the rules that let many products speak the same language. Your ceiba can be a page, a dashboard, a booking app, a Telegram bot — whatever you need. They all understand each other without going through a central server.

Only if you turn that layer on, on a revenue source you declare (not on all your revenue), and only on validated edits — the person who updates a business's hours gets paid only if the owner confirms the info is correct. No validation, no karma. No money flows today: the economic layer is still in design phase.

Each ceiba is autonomous. The protocol has no central owner, just like nobody owns email or HTTP. There's a group that maintains the spec (us, for now), but each community decides its own rules, moderates its own content, and keeps what it generates. Federating with other ceibas is optional.

No. ceiba.to does not issue a token, does not use blockchain, does not need a wallet.

What it does enable — if your ceiba turns it on — is paying contributors for the data they provide. That happens over rails that already exist: stablecoin (USDC), API payments (x402), or local bank transfer with invoice. Each operator picks what fits their jurisdiction and their community.

Internally each ceiba can keep a karma counter — it works like the hours in a time bank or airline miles. It's accounting, not speculation: it only redeems against the rate the ceiba publishes, and only inside that community. It's not traded, not floated, not listed on any exchange.

Protocol resilience comes from shared copies across trusted servers, not from a distributed chain. Everything you need to run a ceiba fits on a $5/month VPS.

The map belongs to everyone. What you build on top of it is yours.

You can charge for: products (dashboards, ticketing, POS, booking, CRM), transaction fees, premium / x402 APIs, featured curation, bulk exports, support, white-label.

You cannot charge for: read access to the commons, claiming your own profile, accepted edits, charging another ceiba to read public data, hiding already-public info behind a paywall.

The decision rule: if the data would exist without your product, it belongs to the commons. If it only exists because someone used your product, it's yours.

We're in very early alpha. What does work in production: the protocol (spec v0.5 published, additive over v0.4), the formal JSON schema, /.well-known/ceiba.json, /health and /v1/stats endpoints live in several ceibas, and the first one with verified data — lacartelera.app: 227 comedian profiles claimable via WhatsApp OTP + 188 venues + 66 upcoming events.

What started working on 2026-05-14: the first productive push federation between two ceibas — NDNS pushes confirmed comedy events to lacartelera.app in real-time via Postgres trigger + pg_net, with a 5-min cron as safety net. Canonical pattern for future pairs (see technical whitepaper §6.2.1).

What doesn't yet work in production: bidirectional N-way federation (the first one is 1→1 push), the 80/20 karma economy (it's in the spec, pending pilot implementation in cartelera), the self-serve koa-gen-ceiba init CLI, and an active aggregator that keeps this registry up to date without manual edits.

State of the other ceibas: boda.market has 84 seed entities with verifiable websites (small but real); fotografos.lat has 279 scrape-imported entries without human verification; botmarket.bot indexes 1841 MCPs and agents (infra, not human community); sociales.lat launched with procedural seed without source attribution and we're purging that DB (so it's headed to 0 visible); montessori.koa.dev is offline pending reconnection.

If you want to build a ceiba with us, this is the best moment — but come in knowing you'll bump into half-finished things.

Not today. The spec (currently v0.5) is written and maintained by KOA Labs (a small team in Mexico). The reference repo, the schema, and this site all live on infra we control. The narrative of "open protocol with no central owner" is aspirational: we want to get there, but v0.5 is still a project with a single maintainer.

What is open today: the spec is public and free to use, the schema is versioned, anyone can run a ceiba without asking us, and protocol changes go through public RFC. What's missing to be truly decentralized: a steward council with formal voice from the larger ceibas (target v0.6+), financial independence of the protocol from KOA Labs, and at least 3 independent implementations of the schema. We're not going to pretend otherwise.