comunes/tane
1
0
Fork 0
Code Issues Pull requests Projects Releases 7 Packages Wiki Activity Actions
tane/PLAN.md

36 KiB
Raw Blame History

Tanemaki — Plan de análisis y desarrollo

App descentralizada para la gestión personal y la compartición de semillas y plantel

Documento de trabajo · Julio 2026 · Autor del proyecto: vjrj (Comunes) Licencia sugerida del documento y del proyecto: copyleft (ver §7)

0. Resumen ejecutivo

Tanemaki es una app local-first, multilingüe y descentralizada para que personas y colectivos gestionen su banco de semillas y plantel, decidan qué ofrecen, y lo compartan localmente sin un intermediario central. La motivación es política además de práctica: contrarrestar el monopolio de las semillas privativas y sostener las variedades tradicionales, en la línea de Plantare y del relato "Las semillas del conocimiento libre" que ya escribiste en Diagonal (2005).

La decisión de partida acordada:

  • MVP = inventario + compartición local. Primero una app que funciona sin conexión y que gestiona el banco de forma amena; encima, una capa ligera para ofrecer/buscar cerca.
  • Recursos = proyecto personal asistido por IA. Ritmo irregular, sin dependencias externas, pero con la arquitectura preparada para abrir a comunidad y financiación cuando toque.
  • Stack = Flutter/Dart. Un solo código para Android, iOS, escritorio y web, con muy buen soporte offline.

La tesis central del plan: separa radicalmente las dos cosas que estás mezclando — la gestión del inventario (fácil, resuelta, alto valor inmediato) y la red descentralizada de confianza (difícil, arriesgada, incierta). Construye la primera de forma que sea útil aunque la segunda no llegue nunca. Así reduces el riesgo de que la ambición del protocolo entierre el proyecto entero, que es el patrón que mató tu intento anterior en Meteor.

1. Qué problemas resuelve (y cuáles son irreconciliables)

Cuatro problemas, en orden de dificultad creciente:

  1. Inventario personal / de colectivo. Qué tengo, cuánto, dónde, con qué nombre. Este es el problema fácil y de alto valor. Mucha gente lo lleva hoy en libretas o en hojas de cálculo caóticas. Una app amena aquí ya justifica existir.

  2. Qué ofrezco y qué no. Una capa de visibilidad sobre el inventario: por cada cosa, un estado (privado / se comparte / se vende / se pide a cambio). Fácil técnicamente; importante conceptualmente porque es la frontera entre lo privado y lo público.

  3. Compartición local descentralizada. Que otra persona cerca vea lo que ofrezco y me contacte, sin un servidor central que sea punto único de control, censura o multa. Aquí empieza lo difícil.

  4. Red de confianza y reputación. Saber con quién compartir, quién devuelve (el espíritu del "pagaré de semillas" de Plantare), quién es de fiar — de forma descentralizada y resistente a la manipulación. Este es el problema genuinamente no resuelto en el estado del arte, y conviene tratarlo como investigación, no como requisito de lanzamiento.

Tensiones que hay que aceptar, no "resolver"

Estás en lo cierto al intuir contradicciones. Nómbralas para no pelear contra ellas:

  • Descentralización total ↔ buena experiencia de usuario. Cuanto más puro el P2P, más fricción (gestión de claves, disponibilidad, descubrimiento). El punto óptimo casi nunca es el extremo.
  • Resistencia legal ↔ descubrimiento. Para que sea "no multable" a lo Kokopelli, el sistema no puede tener un operador central que "publique un catálogo". Pero para que la gente encuentre semillas, hace falta algún tipo de descubrimiento. Se reconcilian moviendo el descubrimiento al borde (local, entre iguales) en lugar del centro.
  • Reputación ↔ privacidad/seudonimato. Una red de confianza necesita historial; el seudonimato protege a la gente. Web-of-trust (confianza transitiva entre conocidos) es el compromiso clásico.
  • Wallapop como referente ↔ tus valores. Lo que te atrae de Wallapop no es su modelo (centralizado, extractivo), es un efecto: que la gente cierra tratos por fuera y la plataforma solo hace de tablón y de presentación. Ese efecto —"plataforma como presentación, no como intermediario"— sí es replicable de forma descentralizada. El modelo de negocio de Wallapop, no.

2. Estado del arte (lo que ya existe y qué copiar)

No estás solo en esto. Merece la pena no reinventar:

Bancos e intercambio de semillas

  • Red de Semillas "Resembrando e Intercambiando" y las redes locales (Red Andaluza, etc.): tu comunidad natural de usuarios y validadores. Tienen ya reglas sociales de intercambio que deberías codificar en la app (ver §5).
  • Open Source Seed Initiative (OSSI): el "pledge" (compromiso copyleft para semillas). Interesante como modelo de licencia de las variedades que la app puede mostrar como metadato.
  • Seed Library Database (PHP/MySQL, SourceForge) y bases tipo RAMADDA: prior art de esquema de datos de bancos de semillas. Útil para no diseñar el modelo desde cero.

Compartición local descentralizada / marketplaces federados

  • flohmarkt (Codeberg): mercadillo federado de segunda mano sobre ActivityPub. Es casi exactamente tu "Wallapop descentralizado": cada instancia sirve a una comunidad local con coordenadas y radio, y las instancias se conectan entre sí. Es el prior art más relevante para tu capa 3. Estudiarlo a fondo.
  • Karrot (foodsharing): coordinación de grupos locales, código libre. Referencia de UX comunitaria.
  • FEP-0837 (Federated Marketplace): propuesta de estándar para marketplaces en el Fediverso. Si vas por ActivityPub, este es el vocabulario a seguir.

Protocolos de identidad/confianza descentralizada

  • Nostr: identidad = par de claves, mensajes firmados publicados en relays replicables. En 2026 tiene ya sub-protocolos de marketplace (Mostro), reputación de trades como eventos, y web-of-trust (NIP-85 "Trusted Assertions"). Muy alineado con tu filosofía. Existe NDK (Nostr Development Kit) para Dart/Flutter en pub.dev, lo que lo hace realista con tu stack.
  • ActivityPub: federación, no P2P puro. Requiere que alguien hospede instancias (como Mastodon). Más maduro para "comunidades locales", menos "de bolsillo".

La conclusión de §2 alimenta la decisión de protocolo en §4.

¿Existe ya algo como esto? (respuesta directa a tu pregunta)

Buscado explícitamente: no existe una app de gestión + compartición de semillas que sea descentralizada (P2P / federada) y local-first. Lo que hay se reparte en dos mundos que nadie ha unido:

  • Gestión de semillas → todo centralizado y/o web anticuada. Seed Library Database (PHP/MySQL en un servidor), bases institucionales tipo RAMADDA, catálogos de OSSI, y las plataformas grandes de "seed-to-sale" (que en realidad son sobre todo software de cannabis regulado). Todas asumen un servidor central. Ninguna es local-first ni pensada para el bolsillo.
  • Descentralización local → existe, pero para otras cosas. flohmarkt (mercadillo federado), Karrot (grupos locales), Nostr/ActivityPub. La fontanería para "compartir localmente sin centro" ya está inventada y madura — pero nadie la ha aplicado a semillas.

Es decir: tu intuición es correcta. El hueco es real y sigue vacío. Nadie ha cruzado "banco de semillas amable en el móvil" con "red de confianza descentralizada". Eso es a la vez la oportunidad (aportas algo que no existe) y el aviso (si nadie lo ha hecho no es solo por falta de ganas: la Capa 4 es difícil de verdad — por eso el plan la aísla como I+D y no bloquea el lanzamiento con ella).

3. Arquitectura por capas (el corazón del plan)

La idea rectora: capas concéntricas, cada una funcional por sí sola, cada una opt-in. Puedes parar en cualquier capa y tener algo útil.

┌─────────────────────────────────────────────┐
│  Capa 4 — Confianza y reputación (I+D)        │  ← investigación, no bloqueante
│  web-of-trust, historial de devoluciones      │
│  ┌───────────────────────────────────────┐   │
│  │ Capa 3 — Compartición local (federada)  │  ← MVP incluye versión mínima
│  │ descubrimiento por cercanía, contacto   │   │
│  │  ┌─────────────────────────────────┐   │   │
│  │  │ Capa 2 — Oferta                   │  ← qué comparto / qué no
│  │  │ estado por ítem, visibilidad      │   │   │
│  │  │  ┌───────────────────────────┐   │   │   │
│  │  │  │ Capa 1 — Inventario         │  ← NÚCLEO, 100% offline
│  │  │  │ local-first, sin cuenta     │   │   │   │
│  │  │  └───────────────────────────┘   │   │   │
│  │  └─────────────────────────────────┘   │   │
│  └───────────────────────────────────────┘   │
└─────────────────────────────────────────────┘

Capa 1 — Inventario (núcleo local-first)

  • Funciona sin conexión, sin cuenta, sin servidor. Los datos viven en el dispositivo. Esto es un principio, no un detalle: garantiza que la app es útil desde el minuto cero y que nadie puede "apagarla".
  • Datos por ítem: nombre común / nombre propio / nombre académico (opcional), categoría (familia botánica), tipo (semilla o plantel), foto(s), cantidad con una medida sencilla (ver abajo), origen/procedencia, año de cosecha, notas libres, e historial (de dónde vino, a quién se dio — el registro que en papel era el Plantare).
  • Medida sencilla y amena: no pidas gramos con balanza. Ofrece unidades cualitativas ("un sobre", "un puñado", "unas pocas", "muchas") con opción de precisar (nº aproximado de semillas, gramos) solo si la persona quiere. La amenidad viene de no obligar a la precisión.
  • Nombres — el vernáculo manda. El nombre "de trabajo" (el que tú usas: vernáculo, propio, en tu idioma) es lo primario y lo único obligatorio. El nombre científico es metadato opcional y secundario, y tienes toda la razón en que pedir que alguien teclee latín de memoria, sin red y sin ayuda, es raro e inusable. Por eso el nombre académico nunca se escribe a mano en frío: se rellena por autocompletado contra un catálogo empaquetado en la propia app (un subconjunto ligero de nombres de especies hortícolas comunes, del orden de cientos/miles de entradas, cabe de sobra offline y se descarga con la app). Empiezas a escribir "tomate" y te ofrece la vinculación a Solanum lycopersicum si quieres; si no quieres, no pasa nada. Cuando sí hay red (Capa 3), ese catálogo puede enriquecerse/actualizarse, pero el científico nunca es un requisito ni depende de estar conectado. En resumen: el latín es una etiqueta que la app te ofrece, no un campo que te obliga a rellenar.
  • Persistencia: SQLite local (Drift/sqflite en Flutter). Sobre ese SQLite, guardar los datos como estructuras CRDT desde el principio aunque aún no sincronices — así la sincronización futura (entre tus propios dispositivos, y luego P2P) no exige rediseñar el modelo. Librerías Dart ya existentes: crdt, crdt_lf, crdt_sync.
  • Multilingüe desde el día 1: i18n de la interfaz (ya tenías esta intención); y catálogo de nombres comunes por idioma.

Capa 2 — Oferta

  • Cada ítem del inventario tiene un estado de visibilidad: privado · se comparte (gratis) · se pide algo a cambio (semilla equivalente, trabajo, trueque — el modelo Plantare) · se vende localmente.
  • Esta capa es solo marcado local hasta que se active la Capa 3. Sin conexión, sirve como tu propia lista de "qué tengo para dar en el próximo trueque".

Capa 3 — Compartición local (federada / P2P)

  • Objetivo: que alguien cerca vea lo que ofreces y te contacte, con el mínimo de infraestructura central posible.
  • En el MVP, versión mínima realista: publicación de la oferta como eventos firmados que se propagan por relays (modelo Nostr) o por instancias locales (modelo flohmarkt/ActivityPub). Descubrimiento por cercanía aproximada (geohash de baja precisión, nunca ubicación exacta — como en tus mockups, "10 km near you" y el mapa del perfil).
  • Contacto directo: la app presenta; el trato se cierra entre las personas (mensajería cifrada o simplemente un canal de contacto). Este es el "efecto Wallapop" sin el intermediario Wallapop.
  • Identidad = par de claves que la persona controla. Sin email obligatorio, sin registro central.

Capa 4 — Confianza y reputación (I+D, no bloqueante)

  • Web-of-trust: confías en quien confían tus conocidos. Reputación construida sobre afirmaciones firmadas ("intercambié con X y devolvió", "estas semillas germinaron") — exactamente los ratings y comentarios de tu mockup 09_public_profile, pero descentralizados.
  • Historial de devoluciones como digitalización del pagaré Plantare: un compromiso firmado ("recibí X, devolveré antes de fecha Y") que ambas partes guardan.
  • Tratar como investigación abierta. Es el problema no resuelto. No condiciones el lanzamiento a resolverlo; diseña la Capa 3 para que la 4 pueda enchufarse encima.

4. Decisión de protocolo (la parte delicada)

Tu pregunta explícita: ¿blockchain? Respuesta corta: casi con certeza no.

Por qué blockchain no encaja

  • Una blockchain es un libro mayor global y consensuado. Tú no necesitas consenso global sobre "quién tiene qué semilla": necesitas afirmaciones locales entre personas que se conocen. Es el problema opuesto al que la blockchain resuelve bien.
  • Añade coste, complejidad, dependencia de tokens/gas, y una huella (energética, conceptual) que choca con el ethos del proyecto.
  • El registro inmutable y público es malo para tu caso legal: querrías poder olvidar, no un catálogo permanente e inborrable de quién intercambió qué variedad no registrada.

Las dos opciones reales

Nostr ActivityPub (flohmarkt/FEP-0837)
Modelo Claves + relays replicables Instancias federadas (servidores)
Grado de descentralización Muy alto (relays intercambiables, identidad soberana) Medio (dependes de instancias hospedadas)
Encaje con "de bolsillo" / móvil Excelente Requiere que alguien mantenga servidores
Web-of-trust / reputación Nativo emergente (NIP-85) Hay que construirlo
Soporte en Flutter/Dart Sí — NDK en pub.dev Menos maduro en cliente móvil
Resistencia legal (sin operador central) Alta (no hay "editor" del catálogo) Menor (la instancia es un operador identificable)
Madurez del caso "marketplace local" Emergente (Mostro, etc.) Más probada (flohmarkt funciona hoy)

Recomendación: diseña la Capa 3 detrás de una interfaz de transporte abstracta (OfferTransport) y prototipa Nostr primero, por su encaje con móvil, identidad soberana y disponibilidad de NDK en Dart. Deja ActivityPub como segundo backend posible. No te cases con uno en el código; cásate con la abstracción. Esto es lo que te permite equivocarte barato.

Un matiz importante: no hace falta que el protocolo de red esté decidido para empezar. Las capas 1 y 2 no dependen de él. Puedes tener meses de app útil mientras el protocolo de la capa 3 madura en una rama aparte.

5. Codificar las reglas sociales existentes

Un acierto barato y de alto valor: la Red de Semillas ya tiene reglas de qué se puede intercambiar. Codifícalas como ayudas suaves en la app (nunca como policía):

  • La variedad debe haberla cultivado quien la ofrece (al menos un ciclo si viene de otra red; dos ciclos si viene de semilla comprada).
  • No transgénicas, no obtenidas por nuevas técnicas genómicas, libres de propiedad intelectual.
  • El espíritu Plantare: no es venta, es préstamo con compromiso de devolución "similar" (no híbrida, no transgénica, ecológica).

En la app esto se traduce en: campos opcionales de "ciclos cultivados", una etiqueta de licencia de la variedad (p.ej. OSSI-pledged / dominio público / desconocida), y la posibilidad de generar un Plantare digital (el pagaré firmado por ambas partes). Digitalizas literalmente el PDF que ya diseñasteis en 2009.

5-bis. La faceta vírica y descentralizada de Plantare

Esto merece capítulo propio porque es, probablemente, la idea más potente que ya tienes en la mano y aún no has explotado: el Plantare de papel ya es un protocolo descentralizado. No hay que inventarlo, hay que leerlo bien y traducirlo. Descompongamos sus propiedades:

1. Instrumento al portador, sin libro mayor central. Cada Plantare es un objeto físico que guardan las dos partes. No existe registro central: la "base de datos" está repartida en los cajones de todo el mundo. Eso es, literalmente, un ledger distribuido — pero social, no digital. Nadie lo puede apagar ni confiscar de golpe.

2. Partida doble repartida entre dos bolsillos. El diseño tiene dos matrices: "recibo para mí" (me deben / yo debo) y la parte que cortas y entregas. Cada intercambio produce dos registros casados en manos de las dos personas. Es contabilidad de partida doble físicamente partida entre ambas partes: a prueba de manipulación (los dos tienen que coincidir) sin ninguna autoridad que lo valide. Es exactamente el patrón que un sistema criptográfico reproduce con firmas.

3. La reciprocidad obliga a reproducir — anti-monopolio por diseño. La promesa es devolver una cantidad similar (no híbrida, no transgénica, ecológica) antes de una fecha. Para cumplirla tienes que cultivar la semilla, y al cultivarla la multiplicas. El instrumento codifica una regla que hace crecer el procomún en lugar de agotarlo. Es el espejo exacto de la semilla privativa (híbrida, terminator) diseñada para no reproducirse: Plantare está diseñado para forzar la reproducción. Ahí está tu "viralidad" — y es virtuosa, no extractiva.

4. Vírico también en lo memético. El propio artefacto es copyleft (CC-BY-SA) y dice "descarga e imprime más". El instrumento se reproduce sin permiso, igual que las semillas que gobierna. El medio es el mensaje.

Cómo se traduce a la app: dos caras de lo mismo

Cara arquitectura (descentralización):

  • Plantare digital = compromiso bilateral firmado. Las dos partes guardan una copia firmada (las dos matrices del papel, en criptografía). El registro vive en los dos dispositivos, no en un servidor. Es el diseño de papel, tal cual, en forma de par de claves.
  • Intercambio 100% offline, de dispositivo a dispositivo (QR / NFC): dos móviles se firman mutuamente la copia, sin red. Es la forma más descentralizada y, además, donde el tema es legalmente sensible, nada toca un servidor.
  • Puente con el papel: la app imprime un Plantare (continuidad con el objeto físico) y también puede ingerir uno de papel (foto / QR). Papel y digital son el mismo protocolo a distinta fidelidad. El gesto de dar semillas nunca se bloquea por falta de tecnología.
  • Genealogía como DAG distribuido: cada Plantare enlaza padre→hijo (este lote vino de aquel intercambio). Una genealogía de la variedad, en cadena, firmada — como un grafo de commits de git, pero de semillas. Traza el origen sin catálogo central: la "trazabilidad" descentralizada que además es legalmente más segura que un catálogo central (ver §6). La procedencia viaja con la semilla, en el bolsillo de quien la tiene, no en un índice global buscable.

Cara crecimiento (viralidad):

  • La invitación es la transacción. Para entregar semillas con un Plantare digital, la otra persona necesita la app (o un enlace web para contrafirmar). Cada intercambio real recluta. El crecimiento cabalga sobre un acto que la gente ya hace — en cada feria de intercambio, en cada trueque de vecindario. No necesitas embudo de marketing: necesitas la compartición que ya ocurre. Es la versión sana del "growth loop".
  • La obligación de devolución trae a la gente de vuelta: "prometiste devolver semillas antes de marzo" es re-enganche incorporado, cálido y social, no spam.
  • La multiplicación se hace visible: la app puede mostrar la descendencia de un lote ("estos tomates crecen ya en 14 huertas de 3 comarcas"), volviendo tangible la multiplicación anti-monopolio y convirtiendo el procomún abstracto en algo que ves crecer. Ese es tu contador de viralidad — y es, literalmente, semillas reproduciéndose.

Las tensiones de esta faceta (nombrarlas)

  • Viralidad ↔ exposición legal. Una genealogía global y pública podría convertirse en el mismísimo "catálogo" que hizo vulnerable a Kokopelli. Se resuelve manteniendo el DAG local y compartido entre iguales, no publicado globalmente: la procedencia viaja con la semilla, no en un índice central.
  • Viralidad ↔ fricción. Exigir que quien recibe instale una app estorba justo en el momento de regalar. Mitigación: contrafirma web sin instalación / QR que capture el compromiso y permita adoptar la app después. El papel como red de seguridad siempre.
  • Obligación ↔ cultura del regalo. Las redes de semillas son economías del don; un marco de "deuda" con dientes chirría. Mantén el espíritu del Plantare: es una promesa de mantener la semilla en circulación, no un pagaré con intereses. Aquí el lenguaje de la interfaz lo es todo (microcopy).

En una frase: Plantare ya resolvió, en papel y en 2009, el problema de la confianza descentralizada que en §3 (Capa 4) tratábamos como I+D difícil. No lo resolvió del todo —el papel no escala ni teje web-of-trust automática— pero te da el modelo mental correcto y probado socialmente. La app no inventa un protocolo nuevo: digitaliza y amplifica uno que ya funciona.

5-ter. Nombre de la app y pantalla "Acerca de"

Nombre (decidido): Tanemaki (種まき, japonés: "sembrar / esparcir semillas"), con apodo corto "Tane" (種, "semilla") — que es el identificador que usamos en repo y código. Honra la tradición japonesa de ayuda mutua que inspiró el Plantare original, viaja bien en cualquier idioma (no es ni anglo ni latina), y su significado —esparcir semillas— captura literalmente la faceta vírica y descentralizada del proyecto (§5-bis). Alternativas descartadas por colisión o encaje: Tane a secas como nombre público (genérico, dominios cortos en manos de brokers), Plantare (solo funciona en español/latín), Spora (suena fúngico), Semia (demasiado "semiótica").

Identidad digital (decidida):

  • Dominio: tanemaki.app (libre, barato, fuerza HTTPS). Descartados .eco (caro ~70 €/año + Eco Profile obligatorio anual) y los tane.* cortos (cogidos o aparcados para reventa).
  • Repositorio: tane.git (bare en ~/repos/tane.git; apodo corto como identificador técnico).
  • Identificador de paquete Flutter (reverse-DNS): usar un dominio propio y estable. Recomendado org.comunes.tane (aprovechando comunes.org, que ya es tuyo y no cambiará) como applicationId de Android y bundleId de iOS. Alternativa app.tanemaki, pero org.comunes.tane es más sólido a largo plazo (el identificador de paquete no debe cambiar nunca una vez publicado). comunes.org/net/info sirven además para hospedar web, relays comunitarios o el "Eco Profile" que no pagamos, si hiciera falta.

La app debe incluir una pantalla "Acerca de" (About) que explique, en lenguaje para todos los públicos y traducible a todos los idiomas (i18n, como el resto de la interfaz), qué significa el nombre y cuál es la filosofía. Borrador del texto (en español; habrá que hacer la versión en inglés y las traducciones):

Acerca de Tanemaki

Tanemaki (種まき) significa "sembrar" en japonés: el gesto de esparcir semillas para que broten. El nombre es un homenaje a las antiguas tradiciones japonesas de ayuda mutua en torno al arroz —el yui, el trabajo comunitario compartido, y el tanomoshi, los fondos vecinales de reciprocidad— que inspiraron el "Plantare", el pagaré de semillas del que nace esta app.

Tanemaki es una herramienta libre para cuidar y compartir semillas tradicionales. Sirve para llevar, de forma sencilla y amena, el inventario de tu banco de semillas y tu plantel; para decidir qué ofreces y qué no; y para compartirlo con gente cercana sin intermediarios ni control central.

Detrás hay una idea: las semillas tradicionales son un bien común, de toda la humanidad, cultivado y mejorado durante milenios. Frente a su privatización por unas pocas empresas, Tanemaki quiere ponértelo fácil para conservarlas, multiplicarlas y hacerlas circular. Como una semilla, la app está pensada para reproducirse de mano en mano: cada intercambio la propaga.

Por eso Tanemaki es software libre (copyleft), funciona sin conexión y sin cuenta, guarda tus datos en tu dispositivo, y está disponible en muchos idiomas gracias a quien traduce voluntariamente. No hay empresa dueña, no hay publicidad, no se vende tu información.

Cuando das semillas a alguien, puedes acompañarlas de un Plantare: un compromiso —heredero del pagaré original— de devolver, cuando puedas, una cantidad parecida de semilla libre. No es una deuda: es una promesa de mantener la semilla viva y en movimiento.

Tanemaki continúa el camino del Plantare (BAH-Semillero, 2009), de la Red de Semillas "Resembrando e Intercambiando" y de la cultura libre. Las semillas del conocimiento libre ya están plantadas.

Notas de implementación del "Acerca de": incluir versión/enlace al código fuente y a la licencia, crédito a Plantare/BAH-Semillero y Red de Semillas, enlace para traducir, y un botón para imprimir un Plantare en papel (puente digital↔papel, §5-bis). Mantener el texto corto y cálido; el registro es divulgativo, no legal ni técnico.

6. Implicaciones legales

No soy abogado; esto es orientación para que decidas con criterio y, llegado el caso, consultes con alguien especializado (Red de Semillas tiene experiencia y contactos).

Lo esencial del panorama:

  • El caso Kokopelli (Francia): la asociación fue multada (10.000 € en 2007, 23.000 € más en 2008) por vender semillas de variedades no inscritas en el catálogo oficial. El TJUE (asunto C-59/11, 12 julio 2012) confirmó que la normativa europea de catálogo era válida. Lección clave: el problema legal se dispara con la comercialización y con un operador central identificable que "pone en el mercado" variedades no registradas.

  • España: el intercambio entre agricultores de variedades tradicionales cultivadas ecológicamente, con fin de conservación y en cantidades limitadas, está mucho más protegido (Ley 30/2006 de semillas; y la práctica de la Red de Semillas). La venta es donde aparece la fricción normativa.

  • UE, situación en curso (julio 2026): hay una nueva regulación de material de reproducción vegetal (propuesta de julio 2023) en fase de trílogos (Comisión–Parlamento–Consejo), sin texto final cerrado. Las versiones en negociación eximen de registro/certificación a: material de redes y organizaciones de conservación, intercambio en especie entre agricultores, y material destinado a jardinería aficionada. Es una ventana potencialmente favorable, pero no está cerrada y conviene seguirla (Red de Semillas, Ecologistas en Acción e Inf'OGM la cubren).

Traducción a decisiones de diseño (privacy/legal by design):

  1. La app no es un vendedor ni un catálogo. Es una herramienta personal de inventario que además facilita el contacto entre personas. No opera un mercado central. Esta distinción es tu mejor defensa: replica la lógica de por qué Kokopelli fue vulnerable (venta + centralización) y evita ambas.
  2. Prioriza el marco de "compartición/conservación" sobre el de "venta". Que vender sea posible pero no el eje; el eje es el trueque y el préstamo Plantare, que es donde la protección legal es más fuerte.
  3. Minimización de datos: ubicación siempre aproximada; identidad seudónima por defecto; datos en el dispositivo; nada de registro central de "quién ofrece qué variedad prohibida".
  4. Multilingüe y multi-jurisdicción: el estado legal de una práctica varía por país. La app puede mostrar avisos contextuales por región sin bloquear nada (informar, no vigilar).
  5. Licencia de las semillas ≠ licencia del software. Documenta que la app es neutral respecto al contenido; quien intercambia es responsable de cumplir su normativa local.

7. Sostenibilidad en el tiempo

El mayor riesgo de este proyecto no es técnico, es de continuidad. Los proyectos así mueren por agotamiento del mantenedor único, no por malas decisiones de arquitectura. Estrategia en tres frentes:

Técnica (que no dependa de ti para seguir vivo):

  • Local-first significa que la app sigue funcionando aunque no haya nadie manteniéndola ni servidores encendidos. Es la forma más fuerte de sostenibilidad: la utilidad no caduca.
  • Sin infraestructura central que pagar = sin factura mensual que mate el proyecto. Relays de Nostr o instancias son opcionales y compartidos por la comunidad.
  • Código libre (copyleft: AGPL o GPL v3) para que otra gente pueda continuar. Datos en formato abierto y exportable (que nadie quede atrapado).

Comunitaria (aunque hayas elegido empezar en solitario):

  • Aunque el desarrollo inicial sea personal + IA, abre el repositorio desde el principio y ve dejando puertas: README claro, issues etiquetados "good first issue", documento de visión (este documento puede ser su semilla).
  • La Red de Semillas y colectivos agroecológicos son tu comunidad de usuarios y validadores, incluso antes que de desarrolladores. Involúcralos pronto para diseño y prueba, no al final.
  • Traducción como vía de entrada de colaboradores no programadores (encaja con "multilingüe": usa Weblate o similar).

Económica (opcional, para cuando quieras acelerar):

  • Financiación de bien común, no modelo de negocio. Tu proyecto encaja de libro con fondos europeos de tecnología libre: NLnet / NGI Zero (financian P2P, descentralización, privacidad), Prototype Fund, subvenciones de soberanía alimentaria y agroecología. Estos fondos no piden que monetices usuarios.
  • Descarta explícitamente el modelo Wallapop (comisiones, datos, publicidad): es incompatible con el ethos y además reintroduce la centralización que quieres evitar.
  • Si algún día hay costes recurrentes (relays comunitarios), donaciones / cuotas voluntarias de colectivos, nunca cobro por uso.

8. Del código anterior: qué conservar, qué descartar

  • Descartar el intento en Meteor (meteor-old, seedks/): Meteor es cliente-servidor centralizado, justo lo contrario de local-first, y el ecosistema está en declive. No arrastres esa base.
  • Conservar y tratar como oro los mockups (docs/mockups/) — como tú mismo dices, es lo valioso. Ya definen: inicio, menús, búsqueda con tarjetas y precio/trueque, inventario por categorías con miembros del banco, ítem con historial/docs/comentarios, perfil público con mapa y valoraciones, chat. Son un product spec casi completo de las capas 1–3.
  • Conservar los iconos SVG propios (docs/icons.svg, la fuente seedks.ttf) y el logo — identidad visual ya hecha.
  • El nombre Tanemaki (apodo Tane) ya está decidido — ver §5-ter para el razonamiento y las alternativas descartadas. El antiguo nombre de trabajo "seedks" queda solo como nombre heredado de algún asset (p.ej. la fuente seedks.ttf), no como nombre del proyecto.

Nota operativa sobre esta carpeta: está sincronizada con Seafile. Para el desarrollo con git, tu idea de un bare repo en ~/repos es la correcta: evita meter un .git dentro de una carpeta sincronizada por Seafile (conflictos entre los dos sistemas de sincronización). Trabaja el código en un clon fuera de Seafile, con el bare repo como origen. Puedo ayudarte a montarlo.

9. Hoja de ruta por fases

Fase 0 — Fundaciones (semanas 1–3) Montar git (bare repo en ~/repos + clon fuera de Seafile). Proyecto Flutter. Modelo de datos del inventario sobre SQLite (Drift) con estructuras CRDT-ready. i18n desde el primer commit. Portar la identidad visual (iconos, logo). Reescribir estos mockups como pantallas reales de la Capa 1.

Fase 1 — Inventario usable (meses 1–2) → primer hito entregable CRUD de ítems con nombres múltiples, categorías, fotos, medida cualitativa, historial. Búsqueda y filtrado local. Exportar/importar (CSV/JSON). Sincronización entre tus propios dispositivos como primera prueba real de los CRDT. En este punto ya es una app que merece usarse.

Fase 2 — Oferta + Plantare digital (mes 3) Estado de visibilidad por ítem. Generador de "Plantare digital" (pagaré firmado). Reglas sociales de la Red de Semillas como campos y avisos suaves.

Fase 3 — Compartición local, prototipo (meses 4–6) → rama de investigación Interfaz OfferTransport abstracta. Prototipo con Nostr/NDK: identidad por claves, publicar oferta, descubrir por geohash aproximado, contacto. Probar con un grupo pequeño real (un banco de semillas amigo). Evaluar honestamente si la UX es aceptable; si no, iterar o probar el backend ActivityPub.

Fase 4 — Confianza (I+D continua, sin fecha dura) Web-of-trust sobre afirmaciones firmadas; valoraciones y comentarios descentralizados (los del mockup de perfil); historial de devoluciones. Se integra encima de la Capa 3 cuando esté sólida.

Transversal, todo el tiempo: abrir repo, involucrar a la Red de Semillas, documentar visión, preparar (si quieres) una solicitud a NLnet/NGI Zero — que además te daría un plazo y una estructura útiles contra el agotamiento.

10. Próximos pasos concretos que puedo hacer contigo

  1. Montar el esquema git (bare repo + clon fuera de Seafile) — dímelo y te doy los comandos exactos o lo dejo escrito.
  2. Redactar el modelo de datos del inventario (entidades, campos, tipos CRDT) como documento técnico.
  3. Convertir los mockups en un flujo de pantallas Flutter anotado (spec de UI navegable).
  4. Escribir un borrador de solicitud NLnet/NGI Zero aprovechando este documento como base.
  5. Un README de visión en inglés para abrir el repo y atraer comunidad.

Dime por cuál empezamos.

Fuentes