Colectivizaciones libertarias · Auditoría de OASIS 1.0.7 contra los ocho criterios colectivistas

Revisión 0 — 2026-09-09. La semilla (draft.md) fijó el corpus, los ocho criterios y las premisas técnicas. Este documento audita el código real y propone once parches CL-1…CL-11 y un backlog por carriles.

0. Qué cambia respecto de la semilla

Metodología. Todo lo que aquí se afirma sobre Oasis está verificado contra el código fuente, no contra su documentación. Árbol auditado: vendor/oasis (ignorado por git; clónalo con git clone --depth 1 https://github.com/epsylon/oasis.git). Commit auditado: 9a657b776fcafc7c24bf3ad61825316385ecf513, "Oasis release 1.0.7", 2026-09-08. Cada afirmación lleva fichero:línea; cuando cito la web y no el disco, lo digo; la doctrina colectivista va marcada [doctrina, sin verbatim] hasta que el carril D' la verifique en las fuentes.

1. Estado del arte verificado

1.1 OASIS 1.0.7

• Paquete @krakenslab/oasis v1.0.7, AGPL-3.0, Node.js + HTML sin JavaScript en el navegador, sobre SSB. 70 ficheros en src/models/ (32.849 líneas).
• Los módulos que importan a una colectividad son los que la auditoría trevijanista dejó «en una línea»: tribes_model.js (939 líneas), industry_model.js (991), la parte de reparto de banking_model.js (1.479), el parlamento de tribu de parliament_model.js (1.615), votes_model.js (390), polls_model.js (440), market_model.js (641), transfers_model.js (428), jobs_model.js (558), housing_model.js (551), school_model.js (1.404) e inhabitants_model.js (505).
• Vocabulario. En 33.000 líneas de modelos y 60 vistas no aparece ni una vez assembly, council, delegate, recall, commons, cooperative ni mutual aid. Federation significa «conectarse a un PUB». La única aparición de «collective» está en un mensaje automático de backend.js#L6214: la instalación «ha sido disuelta por voto colectivo». En cambio salary aparece en doce sitios (§2.6). El código habla el idioma del mercado con un acento cooperativo.

1.2 La capa económica

• faircoin/faircoin: último push 2022-02-05 (verificado vía API de GitHub el 2026-09-09); dominios de FairCoop y Bank of the Commons caídos. Bitcoin 0.12 con Proof-of-Cooperation, sin contratos. No es un sustrato vivo.
• Lo vivo es ECOin a través del módulo Banking, que habla con la cadena por RPC (sendtoaddress, banking_model.js#L1004) desde la cartera del PUB. La oferta monetaria la lee de fuera; Oasis no emite.
• Consecuencia: todo reparto colectivista se implementa en Oasis (reglas de Banking, Industry, Transfers), no en la cadena.

1.3 El corpus colectivista (recordatorio operativo)

Los ocho criterios de draft.md §2, [doctrina, sin verbatim]:

1. Asamblea soberana: toda decisión nace de la asamblea de miembros; las comisiones ejecutan.
2. Cargos rotatorios y revocables, sin poder propio.
3. Propiedad colectiva de los medios de producción.
4. Distribución según necesidades (salario familiar), no según rendimiento.
5. Derechos sociales garantizados: educación, sanidad, jubilación, jornada.
6. Federación de abajo arriba con delegados mandatados.
7. Intercambio sin moneda o con vales; compensación entre colectividades.
8. Voluntariedad de entrada y salida.

Con estos ocho criterios se puede auditar cualquier institución. Los aplico al código en la §3.

2. Anatomía de los módulos que importan aquí

2.1 Tribes — tribes_model.js · 939 líneas

La tribu nace como propiedad de una persona. createTribe inicializa members: [userId] e invites: [] (L337-L338) y fija author: userId (L345); parentTribeId (L341) permite anidar tribus en jerarquía padre-hijo. La jerarquía es descendente: la subtribu la crea el padre (en modo estricto solo su autor, backend.js#L7799-L7801), hereda su privacidad (L490, backend.js#L7806-L7807) y no puede cambiarla ni cambiar de padre (backend.js#L7819-L7822), muere en cascada si el padre recibe tombstone (L218-L225) y no tiene parlamento: el backend rechaza candidaturas, votos y reglas de toda tribu con padre («Sub-tribes have no governance», backend.js#L8305, L8323, L8339, L8353, L8364). Los campos estructurales (title, description, inviteMode, status, parentTribeId…) están enumerados en STRUCTURAL_FIELDS (L11).

Quién manda: el autor. No hay rol de administrador ni de asamblea: hay una comparación tribe.author !== userId. En modo estricto solo el autor genera invitaciones (L554-L556, repetido en L612-L617); en modo abierto, cualquier miembro. El autor no puede abandonar su tribu (L721) y, si se le fuerza y no queda nadie, la tribu recibe un tombstone (L726-L729): la comunidad muere con su fundador. No existe sucesión.

La pertenencia es una clave. updateTribeMembers (L533-L541) recalcula altas y bajas y rota la clave de cifrado en cada expulsión. Es un buen mecanismo de privacidad y un mal mecanismo político: quien controla la lista controla quién puede leer.

No hay patrimonio. Cero apariciones de treasury, wallet, balance o ecoin en todo el fichero. La tribu tiene miembros, claves e invitaciones; no tiene nada que repartir.

2.2 Industry — industry_model.js · 991 líneas

Tres niveles: instalación (medio de producción) → plano (blueprint) → lote (build). Políticas de admisión open | vote | invite (L16).

El steward es el autor del mensaje raíz (L164), miembro inamovible (L187, L205), el único que edita la instalación (L457), no puede irse (L510), es el único que da por terminado o fallido un lote (L808-L809) y el único que reparte (L980). La propiedad del medio de producción se deriva de la autoría de un mensaje.

Lo que sí es colectivo. Admisión y disolución se deciden por voto con quórum y mayoría (L211-L223); una instalación con miembros no puede borrarse, «debe disolverse por voto» (L484-L485). passesThreshold (L98-L101) exige el máximo entre quórum y mayoría; clampMajority acota la mayoría a [0,5, 1] (L23-L27): nunca menos de la mitad. Con un solo miembro todo se aprueba solo (L121). Materias votables: admit, dissolve, pause, bpUpdate, bpDelete, buildUpdate, buildDelete (L532). Ni el steward ni el reparto están en la lista.

Cómo se reparte: a cada cual según su aportación. computeShares (L306-L321) convierte trabajo (hours × laborRate), material (value) y ECOin (eco) en la misma bolsa de puntos; la participación es puntos / total. laborRate, la tasa que convierte horas en puntos, la fija el steward al crear la instalación (L438) y solo él la cambia (L457): la relación entre trabajo y capital es una decisión unipersonal del propietario. computeDistributionPlan (L960-L970) reparte pot × share a cada uno, sin suelo, sin tope y sin parte reservada al común; la «tesorería» del lote es solo la suma de aportes ECO (L378). El resultado se publica como industryAllocation (L986). El único gesto anticapitalista del fichero es el license: "copyleft" por defecto de los planos (L439).

2.3 Banking: la renta básica — banking_model.js · 1.479 líneas

Reglas por defecto (L14-L21): épocas mensuales, alpha 0.2, reserva mínima 500, tope 2.000 por época, tope 50 por persona y época, suelo 1, pesos entre 0,2 y 6, 30 días de gracia.

El fondo (L913-L917): el 20 % del saldo del PUB, nunca por debajo de la reserva ni por encima del tope de época. El común es la cartera del operador del PUB.

El reparto (computeEpoch, L920-L947): el peso de cada persona es 1 + karma/100, acotado a [0,2, 6] (L932); la cantidad bruta es max(suelo, min(pool × w / W, tope)) (L941); el impuesto de carbono y archivo se descuenta solo del excedente sobre el suelo (L942-L947). La interfaz lo declara doctrina: «the base UBI value is set as an immovable minimum» (banking_views.js#L246, L486). La misma fórmula de peso se repite en la estimación (L1300) y en el pago real (L1413-L1416), aunque en el pago real el denominador no es la suma de pesos W sino el número de elegibles con peso 1 cada uno (L1414): el karma pondera solo al reclamante y la cantidad pagada no coincide con la asignación calculada. La asignación de cada época nace UNCLAIMED con 30 días de plazo (L982) y pasa a EXPIRED a los doce meses si nadie la reclama (L1331-L1341): la renta hay que pedirla. El impuesto de archivo grava los días de antigüedad del feed (L32, L38, L759-L768): cuanto más viejo el miembro, más paga sobre su excedente. (Nota 2026-09-09: en el pago real el numerador es el peso del reclamante, pero el denominador suma 1 por cada dirección elegible (L1414), no el peso de cada uno como en L932; el importe enviado por sendtoaddress (L1416) no coincide con el asignado en L941. TK-B'06 lo unifica.) Cada época se sella con un hash (L960-L962).

El karma es un escalar único: actividad menos gramos de carbono (L840), publicado en el log (L501-L506); impuestos en L30-L36. Es una renta por notoriedad con suelo, no una renta por necesidad. No hay hogar, no hay dependientes, no hay edad.

2.4 El parlamento de tribu y canPropose — parliament_model.js · 1.615 líneas

Toda tribu nace en anarquía. tribePublishInitialTerm (L1354-L1374) publica un mandato con method: 'ANARCHY' y leaderId: null (L1363-L1364). El quórum de la tribu es max(2, ceil(miembros × 0,25)) (L1376-L1384); si nadie lo alcanza, chosen = null (L1402-L1403) y el mandato vuelve a ANARCHY (L1409-L1410). ANARCHY es un método de voto pero no es elegible como candidatura (L22-L23): solo se llega a ella por ausencia.

Quién propone. canPropose (L1298-L1311): bajo ANARCHY, todos; con gobierno de persona, solo ella; con gobierno de tribu, todos los miembros de la tribu. Es lo más parecido a una asamblea que hay en el código, y solo se activa cuando no hay gobierno o cuando gobierna una facción. Un gobierno de tribu es una colectividad gobernando toda la red: cualquier tribu raíz puede presentarse en bloque al parlamento general (backend.js#L8300-L8316; resolveTarget acepta tribus, L216-L226; winnerTribeId, L1206), y al subir su ANARCHY se convierte en DEMOCRACY (backend.js#L8314). Es lo contrario de una federación de delegados (CL-8).

Umbrales generales (L240-L242): 80 % / 20 % / mitad más uno; quórum general max(2, 25 % del censo) (L257-L259). La prohibición de autovoto solo aplica a personas (L756): una tribu puede votarse a sí misma en bloque.

Lo decisivo: el parlamento de tribu es un órgano sin competencias. No toca STRUCTURAL_FIELDS, no expulsa, no elige steward, no reparte. Vota leyes que son texto. Tampoco revoca: el único mecanismo llamado revocación en el fichero, parliamentRevocation con REVOCATION_DAYS = 15 (L19; createRevocation, L638-L649), revoca leyes del parlamento general, nunca personas, y no tiene tipo de tribu (L14). Un líder de tribu solo cae al expirar los 60 días de TERM_DAYS (L17, isExpiredTerm L68-L72, tribeEnsureTerm L1433-L1437) y puede reelegirse sin límite: la única traba es una candidatura por candidato y ciclo (L1449-L1452). El código rota por calendario y no revoca por voluntad (ficha 02, hueco 1).

2.5 Votes, Polls y Opinions

• votes_model.js: plazo mínimo de 7 días (L10); opciones por defecto YES, NO, ABSTENTION, CONFUSED, FOLLOW_MAJORITY, NOT_INTERESTED (L173). FOLLOW_MAJORITY es la única delegación de todo el sistema, y es una delegación al agregado anónimo, no a una persona revocable. Sin quórum: la votación se cierra por fecha y muestra el recuento.
• polls_model.js: consultas cifrables por tribu (L45-L60), un voto por autor sobreescribible (L84-L86), caducidad (L143). Sin duración mínima, quórum ni umbral.
• opinions_model.js: una reacción tipificada por persona y objeto, irrevocable (L59, L67). Alimenta el karma y, por tanto, la renta.

2.6 Mercado, trabajo y vivienda

• market_model.js: if (p <= 0) throw new Error("Invalid price") (L182); stock también positivo (L185). No se puede publicar un bien gratuito ni un don. Lo mismo en shops_model.js#L414-L415.
• transfers_model.js: categorías ECONOMIC, TIME, TRUST (L25); importe positivo obligatorio (L230-L231). TIME es el único carril no monetario: vales de tiempo, crédito mutuo.
• jobs_model.js: tres relaciones de producción, freelancer | employee | exchange (L192); dos son asalariadas y salary se propaga a vistas, búsquedas y estadísticas de la red. Pero el salario puede ser 0: se guarda como 0.000000 cuando no es número (L201) y la edición solo rechaza negativos (L334); un puesto sin salario ya es representable, al contrario que un bien sin precio en Market. job_time partial | complete (L203-L204) y hoursOffered/hoursRequested (L228-L229) describen la jornada sin acotarla.
• housing_model.js: sale | rent | couchsurfing sobre apartment | house | room | land | other (L9-L10); solo couchsurfing fuerza precio cero (L317). La tierra es una mercancía con tres regímenes y ninguno por necesidad. Nota 2026-09-09 (ficha 03): la tribu no puede ser titular de un anuncio; solo el autor lo edita (L374) y fija el precio (L388). Sin tarea propia hasta CL-5 (tribeAsset) y TK-G'07.

2.7 School e Inhabitants

• school_model.js: un curso sin precio se guarda como 0.000000 (L320) y solo se protege si el precio es positivo o la visibilidad es INVITE (L392-L393): la educación gratuita es el caso por defecto. El certificado solo lo emite el autor del curso (L1222). Pero «gratuito» significa aquí «sin cobrar al alumno», no «pagado por el común»: la matrícula de pago es una transferencia ECONOMIC del alumno al autor (L613-L616) y nadie mantiene al maestro del curso gratuito. Y los exámenes solo existen en cursos de pago o por invitación (L745): el curso gratuito certifica lecciones completadas (L1242-L1243), no pruebas.
• inhabitants_model.js: el censo es el conjunto de autores que han publicado algo (L86-L88). Un feed, una persona. No hay hogar, familia ni dependientes en ningún modelo.

2.8 Lo demás, en una línea

Courts (juicio cifrado, jueces electos, ya auditado en otro nodo), L.A.R.P. (turno por casas), Projects (financiación con objetivo), Tasks (autoasignación), Events y Calendars (precio 0 posible), Multiverse (puentes a Mastodon y Telegram), AI 42.

3. Confrontación: los ocho criterios contra el código

Recuento. 0 cumplen, 3 parciales, 5 fallan. Y sin embargo el sistema tiene, sin proponérselo, la pieza que más cuesta construir: una asamblea que existe por defecto. Los hallazgos que siguen ordenan el diagnóstico.

A. La tribu es propiedad de su fundador

tribes_model.js no tiene ninguna noción de asamblea, junta ni administrador: tiene un author. Ese autor genera invitaciones en modo estricto (L554-L556), no puede irse (L721) y su marcha forzada disuelve la comunidad (L726-L729). La rotación de claves al expulsar (L533-L541) convierte la lista de miembros en un dispositivo de lectura: quien la controla, controla quién puede ver. Es una monarquía con cifrado de extremo a extremo. Lo que una colectividad necesita es exactamente lo inverso: que la lista de miembros, los campos estructurales y las expulsiones sean actos de la asamblea.

B. La asamblea existe y no manda

Cada tribu nace con un tribeParliamentTerm en ANARCHY, sin líder (L1363-L1364), con quórum del 25 % (L1384) y con retorno automático a la anarquía si nadie lo alcanza (L1402-L1410). Bajo ANARCHY todos proponen (L1298-L1311). Eso es una asamblea permanente: cualquiera propone, nadie preside, la mayoría decide. Pero sus decisiones son texto en el log. No hay una sola función en tribes_model.js, industry_model.js ni banking_model.js que lea un resultado del parlamento de tribu. La asamblea tiene voz y no tiene manos. El parche no es inventarla: es darle competencias (CL-1, CL-5, CL-7). Y hay un segundo riesgo: el parlamento de tribu admite candidaturas con cualquier método de METHODS (L1443-L1445), así que una asamblea puede votarse un dictador de tribu. En la doctrina colectivista la asamblea elige comisiones, no gobiernos: CL-1 cierra esa puerta.

C. Cooperativa de aportantes: trabajo y capital en la misma bolsa

computeShares (L306-L321) es la fórmula de una sociedad de capital: una hora vale laborRate puntos, un euro de material vale un punto, un ECOin vale un punto, y quien más puntos tiene más se lleva (L960-L970). El laborRate lo fija el propietario (L438, L457). En una colectividad el reparto no sale de la aportación sino de la necesidad, y lo decide la asamblea (crit. 1 y 4). La estructura de votación de Industry (L98-L101, L211-L223) es reutilizable; lo que sobra es el steward vitalicio (L164-L205, L510, L980) y lo que falta es una disposition de necesidades (CL-2, CL-3). Tres costuras más (ficha 03, 2026-09-09): el aporte material se capitaliza como participación (industry_model.js:824-831, «Material contributions require a value above zero»), de modo que quien entra con una herramienta cobra por ella en cada lote; el valor del producto (outputValue) lo declara el steward al repartir (:961, :986) y nadie lo vota; y updateFacility propaga cualquier campo del patch, license y laborRate incluidos (:457, :463), sin voto. CL-2 y TK-G'07 los cierran. Hay un segundo cargo que esta auditoría no había nombrado: el proposer del lote (L341). El lote se aprueba por voto de los miembros (L352-L353), pero quien lo propone se nombra a sí mismo responsable: solo él o el steward lo hacen avanzar (L809) o lo editan (L869); es el delegado de grupo de trabajo, sin elección ni revocación. Y el steward conserva un poder propio que ningún voto toca: declara solo el outputValue que forma el bote (pot = treasury + outputValue, L961, L985); CL-3 lo incorpora al plan votable (ficha 02, huecos 4 y 5).

D. Renta por mérito, no por necesidad

La RBU es el único mecanismo con suelo y con techo (L941), y por eso es la mejor base para un salario familiar. Pero el peso 1 + karma/100 (L932) multiplica por hasta treinta la diferencia entre el más notorio y el más silencioso, y el karma premia publicar vídeos y comentar (§2.3). Un anciano que no publica cobra el suelo. Un hogar de cinco cobra lo mismo que uno de uno, porque el hogar no existe (L86-L88 de inhabitants_model.js). El parche es doble: coeficiente de necesidad en lugar de karma (CL-4) y unidad familiar declarada (CL-9). Hay un tercer defecto, anterior a la fórmula: el censo de la RBU no es la tribu ni el hogar, sino el conjunto de feeds con dirección ECOin válida (L924); la asignación nace UNCLAIMED y caduca a los 30 días si nadie la reclama (L20, L982): quien no pide, no cobra. En la industria pasa lo mismo por otra vía: solo entra en el plan quien tiene importe positivo (L966-L968) y sin puntos no hay reparto (L984). El salario familiar se cobraba sin haber trabajado y sin pedirlo: CL-3 y TK-B'06 cierran ambas puertas.

E. El precio cero está prohibido

market_model.js:182 y shops_model.js:415 rechazan cualquier precio no positivo. El don, el trueque y el reparto sin contrapartida no tienen representación en los módulos de intercambio. Existen dos grietas: transfers con categoría TIME (L25) y couchsurfing (L317). El criterio 7 se construye ensanchando esas grietas (CL-6), no inventando un módulo. Nota (2026-09-09, ficha 06): las grietas son más de dos. jobs admite salary 0 en cualquier tipo (jobs_model.js:200-201, :334) y su tipo exchange lleva hoursOffered, hoursRequested y exchangeSkill (:228-230): es un banco de tiempo ya escrito. housing admite precio 0 también en rent y sale (nonNeg, housing_model.js:25-28, :317). Market tiene un item_type: "exchange" (market_model.js:391-392) obligado a precio positivo (:182, :252): el trueque existe como etiqueta y está prohibido como número. Y ninguna compra liquida en cadena: marketPurchase y shopPurchase son mensajes sin pago (market_model.js:634, shops_model.js:614) y PAID lo declara el vendedor (shops_model.js:26, :734); en los cinco módulos no aparece sendtoaddress, ecoin ni wallet. El precio es un número declarado, no un cobro: quitar el > 0 no rompe ninguna liquidación. Lo que ya está escrito para nosotros: el vale caduca (deadline obligatoria, transfers_model.js:233-234; DISCARDED al vencer, :182-183) y la RBU ya se paga como transfer etiquetado UBI (banking_model.js:974-986).

F. No hay hogar: un feed, una persona

El censo es la lista de autores con mensajes (L86-L88). Toda la aritmética de reparto (Banking, Industry) opera sobre feeds. El salario familiar histórico se calculaba por hogar, con escala por edad y dependientes. Sin una unidad familiar declarada y validada por la asamblea, el criterio 4 no puede ni formularse (CL-9). Y el censo, además de individual, es por actividad: la lista de habitantes oculta por defecto a quien lleva seis meses sin publicar (bucket: 'red', L65-L72; filtro en L120). El anciano silencioso no solo cobra el suelo: deja de verse. El household de CL-9 no puede depender de la actividad de sus miembros.

G. La anarquía como estado normal (donde el código ya es colectivista)

ANARCHY no es elegible (L22-L23) y solo se alcanza por ausencia de quórum. Para un modelo estatal eso es un fallo; para una colectividad es la descripción exacta de su régimen: sin gobierno permanente, con asamblea abierta a todos y decisiones por mayoría. Este nodo no toca ANARCHY por defecto ni canPropose universal bajo ANARCHY. Es la única parte del código que ya estaba escrita para nosotros.

4. Especificación CL-OASIS: la bifurcación colectivista

Lo que no se toca, y por qué. ANARCHY como estado por defecto y canPropose universal bajo ANARCHY (parliament_model.js:1298-1311): es la asamblea permanente. El quórum de tribu max(2, 25 %) (:1376-1384): un suelo razonable hasta que el carril D' diga otra cosa. El copyleft por defecto de la instalación (industry_model.js:439) y de los planos (:638, :670); nota 2026-09-09 (ficha 03): el default se conserva, pero la licencia es cadena libre sin enumeración y el steward puede cambiarla sin voto (:463), de ahí TK-G'07. El cifrado de tribu y la rotación de claves como mecanismo (no como poder). El censo por actividad. El suelo inmovible de la RBU (banking_model.js:941). El registro de horas de trabajo por lote (industry_model.js:827, :85) y el laborHours de los planos (:288): es la cuenta de «cada uno según sus facultades», que CL-3 desliga del cobro pero no borra. Que computeEpoch reciba las reglas como parámetro (banking_model.js:920): la escala votada por la asamblea entra por ahí. Son buena economía moral escrita en aritmética.

5. Backlog v0

Leyenda: T = tamaño (S/M/L) · P = prioridad (C crítica, H alta, M media). Cada tarea D' tiene camino por defecto: si no se investiga, el carril siguiente usa el default; si se investiga y la respuesta difiere, la tarea dice qué cambia aguas abajo.

Carril D' · Investigación en fuentes

OP-01 · Autogobierno de la colectividad

La asamblea de tribu recibe competencias sobre lo que hoy decide el fundador: campos, miembros, expulsiones, consultas vinculantes y cargos revocables. Carril G'.

OP-02 · Reparto por necesidades

Salario familiar sobre la RBU y sobre la industria; unidad familiar; tesoro de tribu. Carril B'.

OP-03 · Intercambio sin precio

Don, trueque y vales dentro de la colectividad. Carril E'.

OP-04 · Federación

Colectividad → comarcal → regional con delegados mandatados y compensación entre colectividades. Carril F'.

OP-05 · Derechos sociales

OP-06 · Voluntariedad y censo

Resumen de prioridades v0

Mapa de carriles: D' → G' → B' → E' → F'; OP-05 y OP-06 corren en paralelo sobre B' y G'. El carril de cadena (Faircoin3 o ECOin) no se abre en este nodo: todo el reparto vive en Oasis.

6. Fuentes

Código auditado (disco): vendor/oasis @ 9a657b776fcafc7c24bf3ad61825316385ecf513 (release 1.0.7, 2026-09-08). Clonado con git clone --depth 1 https://github.com/epsylon/oasis.git.

Red: faircoin/faircoin (último push 2022-02-05, API de GitHub, 2026-09-09).

Doctrina: draft.md §1 (Souchy 1937, Leval 1972, Casanova 1988, Ovejero 2015, Vela 2013, Redalyc 2016). Sin páginas: todo lo doctrinal es [doctrina, sin verbatim] hasta que el carril D' lo verifique.

Grado de certeza. Cuatro niveles: verificado en código con fichero y línea (todo §2 y §3) · fuente primaria del proyecto, no verificada de forma independiente (README de Oasis) · inferido de la actividad del repositorio (estado de Faircoin) · paráfrasis marcada, no cita (criterios 1-8).