Fix naming (Seedks->Tanemaki) in PLAN; reconcile data-model with core/domain boundary (Plantare->Pledge, Movement->LedgerEntry notes); fix quantity_label type nit; note social layer as one indivisible block in VISION; add seedks.ttf asset
This commit is contained in:
parent
8286d1fec8
commit
e4ccffe168
5 changed files with 14 additions and 8 deletions
|
|
@ -4,6 +4,8 @@
|
|||
|
||||
> Status: draft for discussion. Nothing here is frozen; it is the starting point for the first Drift schema (`schemaVersion = 1`).
|
||||
|
||||
> **Core/domain split.** This model is presented *flat* for readability. Which of these tables live in the generic engine (`commons_core`) vs. the seeds domain (`app_seeds`) is decided in [core-domain-boundary.md](core-domain-boundary.md). In short: `Variety`, `Lot`, `Movement`, `Species` and the seed-specific fields are **domain**; `Offer`, `Party`, `SeedBank`→`Group`, trust, identity and the signed-return promise are **core**. Two entities below are the seeds view of a generalized core concept — see the notes on `Movement` (§2.4) and `Plantare` (§2.7).
|
||||
|
||||
## 0. Design constraints (why the model looks like this)
|
||||
|
||||
- **Local-first & offline.** The whole model lives in local SQLite. No server is required. Online only enriches.
|
||||
|
|
@ -86,11 +88,13 @@ Quantity is deliberately *rough and human*, not precise. But the informal vocabu
|
|||
- **Plant-form natural units:** a **cob** (mazorca, maize), a **flower head** (cabezuela, sunflower), a **pod** (vaina, legumes), an **ear/spike** (espiga, cereals), a **fruit's worth** (tomato, pepper, squash), a **bulb**, a **tuber**, a **seed head**, a **bunch**.
|
||||
- **Precise (optional):** grams or seed count (`quantity_precise` + `quantity_unit`).
|
||||
|
||||
Modelling: store `quantity_kind` (a stable enum key like `pod`, `cob`, `head`, `packet`, `handful`, `grams`, `count`) + an optional numeric `quantity_label`/`quantity_precise`. The **display label is localized** from the key, so "pod"→"vaina"/"beina"… Units are *labels for a rough amount*, generally **not convertible** between each other or to grams — and that's fine. Suggestion logic (e.g. Poaceae → ear/cob, Fabaceae → pod, Helianthus → flower head) lives in the catalog mapping, not hardcoded, so it stays extensible and translatable. **To think through further:** the full starter list per family, and whether users can add their own unit keys (probably yes, as free `quantity_label` text when no key fits).
|
||||
Modelling: store `quantity_kind` (a stable enum key like `pod`, `cob`, `head`, `packet`, `handful`, `grams`, `count`) + an optional numeric `quantity_precise` (and a free-text `quantity_label` for a rough amount when no key fits). The **display label is localized** from the key, so "pod"→"vaina"/"beina"… Units are *labels for a rough amount*, generally **not convertible** between each other or to grams — and that's fine. Suggestion logic (e.g. Poaceae → ear/cob, Fabaceae → pod, Helianthus → flower head) lives in the catalog mapping, not hardcoded, so it stays extensible and translatable. **To think through further:** the full starter list per family, and whether users can add their own unit keys (probably yes, as free `quantity_label` text when no key fits).
|
||||
|
||||
### 2.4 `Movement` — the append-only event log
|
||||
Immutable events on a `Lot`. Entries/exits are just types. This *is* the history tab and the provenance chain.
|
||||
|
||||
> The append-only *mechanic* is the generic `LedgerEntry` of `commons_core` (see [core-domain-boundary.md](core-domain-boundary.md) §2, §4.3); `Movement` is its seeds-domain shape. At v0 it lives whole in `app_seeds` (per that doc's §8 conservative start); it may be split later.
|
||||
|
||||
| Column | Type | Notes |
|
||||
|---|---|---|
|
||||
| `id` | UUID | |
|
||||
|
|
@ -119,6 +123,8 @@ Immutable events on a `Lot`. Entries/exits are just types. This *is* the history
|
|||
### 2.7 `Plantare` — the signed seed-IOU (§5-bis)
|
||||
The digital version of the paper Plantare. Bilateral, signed, held by both parties.
|
||||
|
||||
> `Plantare` is the seeds-domain name for the generic `Pledge` (return promise) of `commons_core` — see [core-domain-boundary.md](core-domain-boundary.md) §2, §5. The generalization uses `Pledge.return_kind = similar` for seeds (return *something alike*) vs. `same_item` for a lent tool. The columns below map onto that core entity.
|
||||
|
||||
| Column | Type | Notes |
|
||||
|---|---|---|
|
||||
| `id` | UUID | |
|
||||
|
|
|
|||
|
|
@ -78,11 +78,11 @@ Empezar por los niveles **1 y 2** (precio en Ğ1 + enlace a la cartera): casi gr
|
|||
- **WoT propia pero compatible con Duniter** (no dependiente, no independiente-desde-cero): mismo primitivo de identidad + mismo modelo de certificación + import unidireccional de la WoT de Ğ1.
|
||||
- **Una sola clave para todo**, tipo Duniter-v2/Substrate (perfil, ofertas, mensajes, certificaciones, Ğ1). Sin claves por función. Clave seudónima distinta = solo opción avanzada para publicar algo sensible.
|
||||
|
||||
**Consecuencia honesta (a mirar):** una sola clave Duniter/Substrate **debilita el encaje de Nostr** como transporte — la identidad de Nostr *es* su clave secp256k1, y no es la nuestra. O bien Nostr queda como transporte "tonto" con nuestro propio sobre firmado (perdiendo el ecosistema NIP), o bien conviene **apoyar ofertas/mensajería en el ecosistema Duniter** (datapods/indexadores firmados con la misma clave) o en un transporte **agnóstico a la clave**. Se replantea en la ronda social (no bloquea la Fase 1). → [open-decisions.md](open-decisions.md) D7.
|
||||
**Resuelto — "una sola clave" *y* Nostr, vía derivación:** los datapods de Duniter **no están en servicio**, así que para el transporte (Nostr) sí necesitamos una clave **secp256k1**. La solución que mantiene "una sola identidad": la secp256k1 se **deriva determinísticamente** de la semilla raíz Ğ1 (como las carteras multi-cadena derivan claves de varias curvas de una misma mnemónica; precedente: Cesium deriva sus claves de cifrado de la de firma). El usuario respalda **una sola cosa** (el QR de la semilla Ğ1); la secp256k1 se regenera cuando hace falta. Así **Nostr vuelve a ser transporte viable** (NIP-99/17/85) sin gestionar dos claves ni depender de infraestructura muerta. La derivación es **unidireccional**: desde la secp256k1 pública no se puede llegar a la identidad Ğ1 (aunque el uso simultáneo podría correlacionarse — para eso queda la clave seudónima aparte del peor caso).
|
||||
|
||||
## A decidir (pendiente)
|
||||
|
||||
- **Transporte de la capa social** dado "una sola clave Duniter": ¿datapod/indexador estilo Duniter, transporte agnóstico, o Nostr como mero relay? (Revisar; sustituye la inclinación previa "Nostr primero".)
|
||||
- **Transporte de la capa social:** Nostr vuelve a ser viable (secp256k1 **derivada** de la semilla Ğ1). Confirmar Nostr para ofertas/mensajería/WoT y su madurez. (Datapods de Duniter descartados: no están en servicio.)
|
||||
- Ruta/dominio de derivación de la secp256k1 desde la semilla raíz (que sea estándar y unidireccional).
|
||||
- ¿Nivel 3 (import de la WoT de Ğ1) entra en la primera ronda de la capa social o en una posterior?
|
||||
- ¿`sr25519` o `ed25519` (lo que use Duniter v2) para la clave única?
|
||||
- Formato de certificación propio, mapeable al modelo Duniter.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue