Transversal · lo técnico
La plataforma
Además de una idea de moneda, Moneda Comunitaria es una plataforma informática, el software en el que las comunidades llevan su moneda. Su primera versión está construida y funciona en una versión de prueba. En esta página se describe ese software, lo que garantiza y quién lo sostiene hoy. La última sección, con su rótulo, trata hacia dónde apunta la arquitectura del diseño completo.
1 · Qué es, hoy
Es una sola plataforma para todas las comunidades. Cada comunidad (técnicamente, un nodo) tiene su moneda, sus miembros y sus reglas, y está aislada de las demás, de modo que nadie de una comunidad ve ni mueve nada de otra. Una comunidad no necesita su propio software ni su propio servidor. El software es uno solo, compartido, y hoy lo opera quien opera la plataforma.
Tiene tres apps, una por tipo de cuenta. Cada una tiene su propio servidor y su propia sesión, así que entrar en una no abre las otras.
La app del miembro. Se usa en el celular para ver el saldo, pagar, cobrar y recibir dinero.
El panel de gestión. El admin de la comunidad lo usa para gestionar los miembros, la emisión y la configuración.
El panel de plataforma. Desde ahí el admin de la plataforma crea las comunidades y las supervisa.
Una comunidad nace en tres pasos, desde el panel de plataforma: se le pone nombre, se escribe su constitución y se crea su admin. La plataforma muestra la clave temporal de ese admin una sola vez, para entregársela.
2 · El libro
Todo lo que mueve dinero queda en un libro. Cada movimiento es un asiento que no se borra ni se edita. Los asientos de cada cuenta van encadenados, porque cada uno lleva una huella que incluye la del anterior. Por eso, si se altera un asiento viejo, la cadena se rompe desde ese punto.
Cada miembro tiene una cuenta en cada comunidad donde está. El libro anota esa membresía y nunca el nombre, el email ni el DNI, de modo que en el libro no hay datos personales.
Hoy ninguna pantalla muestra la cadena. Su función es permitir que se audite el libro.
3 · Reglas con versión
Cada comunidad tiene dos clases de reglas. La constitución fija la moneda y los sobregiros, y no cambia. La configuración (cómo se entra, los topes, los tipos de usuario, cuánto dura una oferta) la cambia el admin de la comunidad. Cada cambio es una versión nueva, y la anterior no se sobrescribe.
Cada movimiento guarda bajo qué versión de las reglas se hizo. Además, el admin ve en su panel la huella de la versión vigente.
Las reglas del día a día no quedan fijas en el programa, así que se ajustan sin tocar el software. Cada ajuste queda registrado.
4 · Sin doble cobro
Si un pago se corta a mitad de camino y lo volvés a intentar, no se cobra dos veces.
Tampoco pueden gastar el mismo saldo dos pagos que salen al mismo tiempo desde la misma cuenta. Uno se completa, y el otro se encuentra con el saldo que quedó.
5 · Quién ve qué
Cada cuenta ve solo lo que le toca.
Un miembro ve de los demás solo el alias, el nombre y el apellido, y nunca su email, su DNI, su teléfono ni su saldo.
El admin de la comunidad ve los datos y los saldos de sus miembros, porque los necesita para administrarla.
El admin de la plataforma no ve los datos de los miembros.
Además, ninguna pantalla pública revela si un email o una comunidad existen.
6 · Si algo se cae
Si se cae una de las piezas de las que depende, como la base de datos, el servidor se detiene. Decidimos que no intente arreglarse solo, porque preferimos un sistema que se para y avisa antes que uno que sigue andando a medias.
La app tampoco reintenta por su cuenta. Muestra «Sin conexión» con un botón «Reintentar», y sos vos quien decide cuándo volver a probar. Reintentar un pago es seguro, porque no se cobra dos veces.
Lo único que se reconecta solo es la actualización en vivo: el saldo, los movimientos y las solicitudes.
7 · Energía
No es blockchain y no hay minería. La minería gasta enormes cantidades de energía, y eso es insostenible para un sistema que aspira a ser ecológicamente responsable. La plataforma funciona en servidores comunes y no gasta nada en validar pagos por fuerza bruta.
8 · Quién sostiene la máquina, hoy
Hoy la plataforma la sostiene quien opera el servidor. Esa persona o equipo crea, desde el propio servidor, la primera cuenta de admin de la plataforma. A partir de ahí, el admin de la plataforma crea las comunidades y le da a cada una su admin.
Su código se publicará como software libre. En Estado del proyecto se cuenta en qué punto está el proyecto.
Próximas versiones
Hacia dónde va la arquitectura
Esta arquitectura es la del diseño completo, el Modelo de Moneda Social Confederable, y la plataforma todavía no la tiene.
El diseño completo deja abierto con qué tecnología construir la plataforma y fija qué tendría que ser verdad en una red distribuida, operada por las propias comunidades y no por un servidor central. En lenguaje claro, sus requisitos son los siguientes:
- Todo acto iría firmado y encadenado. Persona, cuenta y clave serían cosas distintas. La identidad cívica se avalaría al entrar, la cuenta llevaría el saldo y la clave, que se podría rotar, firmaría cada acto junto al estado previo de la cuenta.
- El orden sería local y la finalidad sería colectiva. El servidor-hogar de cada cuenta ordenaría sus movimientos, y un acto sería final cuando quedara replicado en un quórum de servidores del nodo. Si un servidor firmara dos versiones del mismo paso, la equivocación quedaría detectada y atribuida, y ese servidor perdería su autoridad.
- El modelo de amenaza sería explícito. Se declararía cuántos servidores maliciosos tolera un nodo (por defecto, menos de un tercio), y la auditoría cruzada entre federaciones actuaría como segunda línea de control, porque una emisión fuera de la regla se podría detectar desde afuera.
- La privacidad tendría su lugar exacto. Dentro del nodo las cuentas serían seudónimas. Hacia afuera solo cruzarían agregados (total emitido, total oxidado), acompañados de pruebas que no revelan a nadie.
- El historial sería completo y exportable. Si una persona o un nodo se va, se llevaría su libro. De ese modo, la salida inalienable quedaría garantizada también por el software.
Lo técnico también se gobernaría.
El umbral de tolerancia, el quórum de replicación o el mínimo de servidores por nodo
serían parámetros con etiqueta [Nivel · Naturaleza], como cualquier regla monetaria, así que se
cambiarían por el mismo consenso que cambia una tasa.
06 Documento Maestro §3.A (R1–R7) · 09-10 Parámetros §T
Confianza distribuida
Ni hoy ni en el diseño completo el sistema es trustless. Hoy hay que confiar en quien opera la plataforma. El diseño repartiría esa confianza entre instituciones que se controlan entre sí: confianza social, redundancia técnica y auditoría externa, en ese orden. 06 §3.3
Quién sostendría la máquina
El diseño crea el rol de operador, la persona o el equipo que sostendría la infraestructura de un nodo. Cobraría del primer tramo de la cascada del fondo común, es decir que la comunidad le pagaría, con reglas claras, por mantener la máquina funcionando. Como toda autoridad funcional del modelo, sería revocable y de mandato finito. 12 Procesos §P7 · 10 §E4
La primera versión ya deja preparada parte del camino. Su libro encadenado es la cadena que después se firmaría y se replicaría, guarda el historial de cada cuenta sin datos personales, y cada comunidad ya está separada como lo necesitaría la federación. Para lo que falta todavía no hay fecha.