267 lines
27 KiB
Markdown
267 lines
27 KiB
Markdown
# Seedks — 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
|
||
|
||
Seedks 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](http://plantare.ourproject.org/) 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.
|
||
|
||
---
|
||
|
||
## 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 **"seedks"** ya lo elegiste (frente a seedbank, seeks, etc.). Mantenerlo.
|
||
|
||
**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
|
||
|
||
- Plantare (pagaré de semillas): http://plantare.ourproject.org/ — © BAH-Semillero, CC-BY-SA 3.0
|
||
- "Las semillas del conocimiento libre", Vicente J. Ruiz Jurado, *Diagonal* nº15, 2005 (incluido en la carpeta)
|
||
- Caso Kokopelli: [Wikipedia](https://en.wikipedia.org/wiki/Association_Kokopelli) · [TJUE C-59/11 (curia)](https://curia.europa.eu/jcms/jcms/P_89305/) · [organic-market.info](https://organic-market.info/news/Heavy_fine_imposed_on_organic_seed_association_in_France.html)
|
||
- Nueva regulación UE de material de reproducción vegetal (estado 2026): [Comisión Europea](https://food.ec.europa.eu/plants/plant-reproductive-material/legislation/future-eu-rules-plant-and-forest-reproductive-material_en) · [Legislative Train (marzo 2026)](https://www.europarl.europa.eu/legislative-train/carriage/revision-of-legislation-on-seeds-plant-and-forest-reproductive-material/report) · [Bio Eco Actual (marzo 2026)](https://www.bioecoactual.com/en/2026/03/31/the-upcoming-eu-seed-law-and-its-implication-for-agrobiodiversity/) · [Inf'OGM](https://infogm.org/en/agricultural-biodiversity-at-risk-with-new-seed-regulation/)
|
||
- Legalidad del intercambio en España: [Red de Semillas — situación legal](https://www.redsemillas.info/situacion-%E2%80%9Clegal%E2%80%9D-de-las-variedades-locales-desde-la-produccion-venta-e-intercambio-reflexiones-de-la-red-de-semillas-%E2%80%9Cresembrando-e-intercambiando%E2%80%9D/) · [Ley 30/2006 (BOE)](https://www.boe.es/buscar/doc.php?id=BOE-A-2006-13555) · [Ecologistas en Acción](https://www.ecologistasenaccion.org/27105/trabas-para-las-variedades-locales-de-semillas/)
|
||
- Prior art de compartición federada: [flohmarkt](https://codeberg.org/flohmarkt/flohmarkt) · [FEP-0837 Federated Marketplace](https://socialhub.activitypub.rocks/t/fep-0837-federated-marketplace/3501) · [Karrot](https://karrot.world/)
|
||
- Nostr y web-of-trust: [nostr.org](https://nostr.org/) · [NDK para Dart/Flutter](https://pub.dev/packages/ndk) · [Nostr Compass (2026)](https://nostrcompass.org/en/newsletters/2026-03-25-newsletter/)
|
||
- CRDT en Dart: [crdt_lf](https://pub.dev/packages/crdt_lf) · [crdt_sync](https://pub.dev/packages/crdt_sync)
|
||
- Open Source Seed Initiative: [osseeds.org](https://osseeds.org/)
|