<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>flove making-of — all questions</title>
    <link>https://flove.org/making-of.html</link>
    <description>Every design question from flove interviews.</description>
    <language>en</language>
    <item>
      <title>The 🙂 top-nav button becomes a red "Custom" button (like the entrance band) — what should it do?</title>
      <link>https://flove.org/making-of.html#apps-index-redesign_q1</link>
      <guid isPermaLink="false">apps-index-redesign_q1</guid>
      <category>apps</category>
      <category>frontend</category>
      <category>ui</category>
      <pubDate>Fri, 19 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Keep the feeling-filter toggle — Renamed Custom, red, still toggles the 5-feeling filter row — mirrors the entrance. Lowest surprise, no behaviour lost.
• Open the Custom sort modal — Opens the CSS-only Custom sort/tune modal instead; then the feeling row has no trigger.
• Static red label only — Just a red chip, no behaviour; the feeling filter becomes unreachable.

★ decided: Keep the feeling-filter toggle · ◇ recommended: Keep the feeling-filter toggle</description>
    </item>
    <item>
      <title>The modal "See docs →" links point to Spanish ids that don't exist in docs — how to fix?</title>
      <link>https://flove.org/making-of.html#apps-index-redesign_q2</link>
      <guid isPermaLink="false">apps-index-redesign_q2</guid>
      <category>apps</category>
      <category>docs</category>
      <category>links</category>
      <pubDate>Fri, 19 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Map to real category sections — Point each app to its existing docs anchor (#metaphysics, #science, #biology, #language, #psycosocial, #economy, #ecosystem). Fixes all links, no docs edits.
• Add per-app anchors in docs — Insert an id per app and deep-link; most precise, much more work for 30+ apps.
• Point all to docs top — Open docs at the top; simplest, least useful.

★ decided: Map to real category sections · ◇ recommended: Map to real category sections</description>
    </item>
    <item>
      <title>Second slide = a screenshot of the actual app landing page. How to produce it?</title>
      <link>https://flove.org/making-of.html#apps-index-redesign_q3</link>
      <guid isPermaLink="false">apps-index-redesign_q3</guid>
      <category>apps</category>
      <category>frontend</category>
      <category>media</category>
      <pubDate>Fri, 19 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Live iframe mini-preview — Scaled, lazy, non-interactive iframe of the app's own page; always current, no binary assets, loads only when the modal opens.
• Real PNG screenshots — Pixel-accurate and light at runtime, but needs a render pass now and 30+ image files to maintain.
• Styled placeholder for now — Keep a 📷 placeholder, wire previews later.

★ decided: Live iframe mini-preview · ◇ recommended: Live iframe mini-preview</description>
    </item>
    <item>
      <title>"Collapse all main categories (expanded by default)" — what exactly should collapse?</title>
      <link>https://flove.org/making-of.html#apps-index-redesign_q4</link>
      <guid isPermaLink="false">apps-index-redesign_q4</guid>
      <category>apps</category>
      <category>frontend</category>
      <category>ui</category>
      <pubDate>Fri, 19 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Grid grouped under category headers — Regroup the 37 tiles into collapsible sections; matches the wording most literally but is the biggest change.
• Nav categories become disclosures — The category buttons row collapses; smaller change.
• Collapse the entrance splash bands — Affects the entrance, not the grid view.

★ decided: Nav categories become disclosures · ◇ recommended: Grid grouped under category headers</description>
    </item>
    <item>
      <title>Which new icon for the collapse toggle?</title>
      <link>https://flove.org/making-of.html#apps-index-redesign_q5</link>
      <guid isPermaLink="false">apps-index-redesign_q5</guid>
      <category>apps</category>
      <category>frontend</category>
      <category>ui</category>
      <pubDate>Fri, 19 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Chevron ▸ / ▾ — Rotating triangle; the standard disclosure affordance — down when open, right when collapsed.
• Plus / minus ＋ / － — Explicit and legible, less subtle.
• Caret ⌄ that flips — Minimal chevron-down that rotates 180° when collapsed.

★ decided: Chevron ▸ / ▾ · ◇ recommended: Chevron ▸ / ▾</description>
    </item>
    <item>
      <title>Public host for provenance / commit links (GIT_BASE public)?</title>
      <link>https://flove.org/making-of.html#talk2web-refine_q1</link>
      <guid isPermaLink="false">talk2web-refine_q1</guid>
      <category>Gitea</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Public Gitea at git.flove.org — Stand up a public Gitea; commit + wiki links resolve for everyone. Most self-hosted-aligned.
• Mirror to GitHub (floveorg) — Push a mirror; link to GitHub commits. Easy reach, less FOSS-pure.
• Keep localhost only — Links work only on your machine; public visitors get no provenance.

★ decided: Public Gitea at git.flove.org · ◇ recommended: Public Gitea at git.flove.org</description>
    </item>
    <item>
      <title>Commit + push making-of on every recording?</title>
      <link>https://flove.org/making-of.html#talk2web-refine_q2</link>
      <guid isPermaLink="false">talk2web-refine_q2</guid>
      <category>Gitea</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Always, automatically — Each recorded interview commits + pushes. Zero drift; matches the current rule.
• On confirmation — Ask before each push. Safer, more friction.
• Manual — You push when you choose.

★ decided: Always, automatically · ◇ recommended: Always, automatically</description>
    </item>
    <item>
      <title>How does 'push' actually post to the commit-wiki (gitea-docsify)?</title>
      <link>https://flove.org/making-of.html#talk2web-refine_q3</link>
      <guid isPermaLink="false">talk2web-refine_q3</guid>
      <category>Gitea</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• docsify-comments via Gitea (Gitalk-style) — Comments land as Gitea issues through a docsify comment plugin; one click, real.
• Gitea API write with a token — Skill writes a wiki page / issue via API. Powerful, needs a stored token.
• Keep copy + open (manual paste) — Current MVP: copy the AI-text, open the page, paste.

★ decided: docsify-comments via Gitea (Gitalk-style) · ◇ recommended: docsify-comments via Gitea (Gitalk-style)</description>
    </item>
    <item>
      <title>DOCS_BASE — where does gitea-docsify actually live?</title>
      <link>https://flove.org/making-of.html#talk2web-refine_q4</link>
      <guid isPermaLink="false">talk2web-refine_q4</guid>
      <category>Gitea</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Gitea on :3000 (wiki render) — Reuse the running Gitea; docsify renders its docs.
• Separate docsify server (own port) — A dedicated docsify instance over the repo files.
• Public docs.flove.org — A published docs host for public deep-links.

★ decided: Gitea on :3000 (wiki render) · ◇ recommended: Gitea on :3000 (wiki render)</description>
    </item>
    <item>
      <title>Shared / public replies — backend?</title>
      <link>https://flove.org/making-of.html#talk2web-refine_q5</link>
      <guid isPermaLink="false">talk2web-refine_q5</guid>
      <category>Backend</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Local only (browser) for now — Keep frontend-first; everyone answers privately. Defer aggregation.
• flovenet P2P aggregation — Replies sync over flovenet; native, bigger build.
• oasis / SSB — Use the oasis add-on feed for shared replies.

★ decided: Local only (browser) for now · ◇ recommended: Local only (browser) for now</description>
    </item>
    <item>
      <title>'debate' target (forums)?</title>
      <link>https://flove.org/making-of.html#talk2web-refine_q6</link>
      <guid isPermaLink="false">talk2web-refine_q6</guid>
      <category>Backend</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Gitea issues as debate threads — Each question debates in a Gitea issue; reuses existing infra.
• A real forum (Discourse-style) — Richer discussion, a separate service to run.
• Defer debate for now — Keep the copy + open placeholder until a forum exists.

★ decided: Gitea issues as debate threads · ◇ recommended: Gitea issues as debate threads</description>
    </item>
    <item>
      <title>The conversation-publishing skill (piece C)?</title>
      <link>https://flove.org/making-of.html#talk2web-refine_q7</link>
      <guid isPermaLink="false">talk2web-refine_q7</guid>
      <category>Backend</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Defer it — Finish talk2web + making-of first; publish whole chats later.
• Build it now — A skill that publishes entire conversations like interviews.
• Fold into talk2web — Make talk2web itself publish full conversations.

★ decided: Defer it · ◇ recommended: Defer it</description>
    </item>
    <item>
      <title>Category tree structure?</title>
      <link>https://flove.org/making-of.html#talk2web-refine_q8</link>
      <guid isPermaLink="false">talk2web-refine_q8</guid>
      <category>Design</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Keep 3-deep groups (talk2web / nety·flovenet) — Conversation → sub-section → category leaf, as now.
• Regroup by phase — Brainstorm / plan / implementation as the top groups.
• Flat list + search — Drop nesting; add a filter box.

★ decided: Keep 3-deep groups (talk2web / nety·flovenet) · ◇ recommended: Keep 3-deep groups (talk2web / nety·flovenet)</description>
    </item>
    <item>
      <title>Default view on load?</title>
      <link>https://flove.org/making-of.html#talk2web-refine_q9</link>
      <guid isPermaLink="false">talk2web-refine_q9</guid>
      <category>Design</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• talk2web open + decisions revealed — Current: the talk2web interview expands with the decided option highlighted.
• All collapsed — Quietest; the visitor opens what they want.
• All open + decided — Everything expanded at once; heavy.

★ decided: talk2web open + decisions revealed · ◇ recommended: talk2web open + decisions revealed</description>
    </item>
    <item>
      <title>Aesthetic direction?</title>
      <link>https://flove.org/making-of.html#talk2web-refine_q10</link>
      <guid isPermaLink="false">talk2web-refine_q10</guid>
      <category>Design</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Keep warm-paper editorial — Fraunces + mono, coral / teal — the current field-journal look.
• Align with flove main palette — Match the home page's identity more tightly.
• Add a dark-mode toggle — Offer both; more CSS to maintain.

★ decided: Keep warm-paper editorial · ◇ recommended: Keep warm-paper editorial</description>
    </item>
    <item>
      <title>Question paginator (currently 20 / page)?</title>
      <link>https://flove.org/making-of.html#talk2web-refine_q11</link>
      <guid isPermaLink="false">talk2web-refine_q11</guid>
      <category>Design</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Keep 20 per page — Balanced for long interviews like nety (67).
• 10 per page — Lighter pages, more clicks.
• Show-all by default — No pagination; long scroll.

★ decided: Keep 20 per page · ◇ recommended: Keep 20 per page</description>
    </item>
    <item>
      <title>Per-question footer (note / see-more / push·debate·save)?</title>
      <link>https://flove.org/making-of.html#talk2web-refine_q12</link>
      <guid isPermaLink="false">talk2web-refine_q12</guid>
      <category>Design</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Keep all of it — Full toolkit on every question.
• Trim to note + save — Less clutter; drop per-question push / debate.
• Move actions to entry-level only — One Copy / Share per interview, not per question.

★ decided: Keep all of it · ◇ recommended: Keep all of it</description>
    </item>
    <item>
      <title>When to offer the form?</title>
      <link>https://flove.org/making-of.html#talk2web-refine_q13</link>
      <guid isPermaLink="false">talk2web-refine_q13</guid>
      <category>Skill</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Offer each time (you opt in) — Current: propose it, you choose. No surprise forms.
• Auto when ~4+ questions — Skip the ask above a threshold.
• Always in brainstorm / plan — Every batch becomes a form.

★ decided: Offer each time (you opt in) · ◇ recommended: Offer each time (you opt in)</description>
    </item>
    <item>
      <title>Context model in the copied prompt?</title>
      <link>https://flove.org/making-of.html#talk2web-refine_q14</link>
      <guid isPermaLink="false">talk2web-refine_q14</guid>
      <category>Skill</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Pointer-links to public wiki-git — Current: links travel, not text. Light, single source of truth.
• Embed full text — Self-contained prompt; heavier, can drift from source.
• Both — Links plus an embedded snapshot.

★ decided: Pointer-links to public wiki-git · ◇ recommended: Pointer-links to public wiki-git</description>
    </item>
    <item>
      <title>Copy-prompt intents to offer? (multi)</title>
      <link>https://flove.org/making-of.html#talk2web-refine_q15</link>
      <guid isPermaLink="false">talk2web-refine_q15</guid>
      <category>Skill</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Find conflicts — Flag tensions / contradictions across picks.
• Summarize — Condense picks into a brief.
• Draft a plan — Turn picks into an implementation plan.
• Critique — Challenge the weakest picks.
• Extract decisions — Emit a clean decision log.

★ decided: Find conflicts · Summarize · Draft a plan · Critique · Extract decisions · ◇ recommended: Find conflicts · Summarize · Draft a plan · Critique · Extract decisions</description>
    </item>
    <item>
      <title>Recording flow ownership?</title>
      <link>https://flove.org/making-of.html#talk2web-refine_q16</link>
      <guid isPermaLink="false">talk2web-refine_q16</guid>
      <category>Skill</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• talk2web records + feeds + commits — Current: the skill appends the entry, regenerates feeds, commits + pushes.
• Manual recording — You add entries by hand.
• A separate 'record' skill — Split recording into its own skill.

★ decided: talk2web records + feeds + commits · ◇ recommended: talk2web records + feeds + commits</description>
    </item>
    <item>
      <title>Implement first?</title>
      <link>https://flove.org/making-of.html#talk2web-refine_q17</link>
      <guid isPermaLink="false">talk2web-refine_q17</guid>
      <category>Plan</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Gitea fully operating (provenance + push) — Make links + push real before anything else.
• making-of design polish — Finalise the page UX first.
• Sharing backend (replies / debate) — Stand up the shared layer first.
• Publishing skill (C) — Start whole-conversation publishing first.

★ decided: Gitea fully operating (provenance + push) · ◇ recommended: Gitea fully operating (provenance + push)</description>
    </item>
    <item>
      <title>Milestone size?</title>
      <link>https://flove.org/making-of.html#talk2web-refine_q18</link>
      <guid isPermaLink="false">talk2web-refine_q18</guid>
      <category>Plan</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• One coherent commit per block (A→E) — Ship each block as a unit; reviewable.
• Tiny incremental commits — Many small steps; the current cadence.
• Big-bang — All at once; risky.

★ decided: One coherent commit per block (A→E) · ◇ recommended: One coherent commit per block (A→E)</description>
    </item>
    <item>
      <title>What do you want to do with the writing-skills workflow?</title>
      <link>https://flove.org/making-of.html#talk2web-design_q1</link>
      <guid isPermaLink="false">talk2web-design_q1</guid>
      <category>Skills</category>
      <category>Process</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Create a new skill — Author a brand-new skill from scratch, starting with a baseline (RED) test.
• Edit an existing skill — Modify or improve a skill you already have.
• Test / verify a skill — Run pressure scenarios against an existing skill.

★ decided: Create a new skill</description>
    </item>
    <item>
      <title>What's the skill about?</title>
      <link>https://flove.org/making-of.html#talk2web-design_q2</link>
      <guid isPermaLink="false">talk2web-design_q2</guid>
      <category>Skills</category>
      <category>Process</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• A flove/frontend pattern — A reusable design/code technique from the flove work.
• A workflow/process rule — A discipline future agents should follow.
• Something else — A different technique or reference.

★ decided: A workflow/process rule</description>
    </item>
    <item>
      <title>When should the form replace asking inline?</title>
      <link>https://flove.org/making-of.html#talk2web-design_q3</link>
      <guid isPermaLink="false">talk2web-design_q3</guid>
      <category>Skills</category>
      <category>UX</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Many questions (~4+) — Use the form whenever there are roughly 4+ questions; ask 1–3 inline.
• Always in brainstorm/plan — Always render the form when there are questions.
• Only when I offer it — I propose the form and you opt in each time.

★ decided: Only when I offer it · ◇ recommended: Many questions (~4+)</description>
    </item>
    <item>
      <title>Where is the generated form saved?</title>
      <link>https://flove.org/making-of.html#talk2web-design_q4</link>
      <guid isPermaLink="false">talk2web-design_q4</guid>
      <category>Skills</category>
      <category>Process</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Alongside the work — Into the relevant project's docs/, then I hand over the path.
• A fixed scratch folder — Always one place regardless of project.
• Current working directory — Wherever we're working, dated filename.

★ decided: Alongside the work · ◇ recommended: Alongside the work</description>
    </item>
    <item>
      <title>Where should we start — decompose A/B/C?</title>
      <link>https://flove.org/making-of.html#talk2web-design_q5</link>
      <guid isPermaLink="false">talk2web-design_q5</guid>
      <category>Process</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Form refinements first (A) — Settle the form; the making-of consumes its output.
• Making-of section first (B) — Design the archive first, then feed it.
• Treat A+B as one spec — Brainstorm them together as one inseparable feature.

★ decided: Form refinements first (A) · ◇ recommended: Form refinements first (A)</description>
    </item>
    <item>
      <title>How should the user tune the copied prompt?</title>
      <link>https://flove.org/making-of.html#talk2web-design_q6</link>
      <guid isPermaLink="false">talk2web-design_q6</guid>
      <category>talk2web</category>
      <category>UX</category>
      <category>Frontend</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Editable textarea (prefilled) — A box prefilled with the default prompt, fully editable, persisted.
• Presets + free add-on — Pick an intent (conflicts/summarize/draft-plan/critique) plus an optional extra line.
• Appendable notes box — Base prompt fixed; user only appends extra instructions.

★ decided: Presets + free add-on · ◇ recommended: Editable textarea (prefilled)</description>
    </item>
    <item>
      <title>Where does the context document come from?</title>
      <link>https://flove.org/making-of.html#talk2web-design_q7</link>
      <guid isPermaLink="false">talk2web-design_q7</guid>
      <category>talk2web</category>
      <category>Architecture</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• I embed it when generating — Bundle the brief at generation time; enables per-question references.
• Filler attaches in-browser — The person filling pastes/uploads a doc; questions can't pre-reference it.
• Both: embedded default + attachable — Embed a default brief AND let the filler attach more.
• Just a pointer/link — Copied prompt carries only a path/URL, lightweight.

★ decided: Both: embedded default + attachable · ◇ recommended: I embed it when generating</description>
    </item>
    <item>
      <title>How should a per-question reference behave?</title>
      <link>https://flove.org/making-of.html#talk2web-design_q8</link>
      <guid isPermaLink="false">talk2web-design_q8</guid>
      <category>talk2web</category>
      <category>UX</category>
      <category>Frontend</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Inline reveal chip — A '↗ brief §B.2' chip; clicking reveals that excerpt; prompt notes '(see §B.2)'.
• Pointer in prompt only — Reference appears only in the copied prompt, no inline reveal.
• Inline reveal + re-inject excerpt — Reveal inline AND duplicate the excerpt into the prompt.

★ decided: Inline reveal chip · ◇ recommended: Inline reveal chip</description>
    </item>
    <item>
      <title>What should the skill be renamed to?</title>
      <link>https://flove.org/making-of.html#talk2web-design_q9</link>
      <guid isPermaLink="false">talk2web-design_q9</guid>
      <category>Naming</category>
      <category>Meta</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• design-interview — Names the artifact: a structured design interview.
• interviewing-for-plans — Gerund, ties to 'interviews you do me for plans'.
• conducting-design-interviews — Fully explicit but long.

★ decided: talk2web · ◇ recommended: design-interview</description>
    </item>
    <item>
      <title>Intent preset set, and setup-block default state?</title>
      <link>https://flove.org/making-of.html#talk2web-design_q10</link>
      <guid isPermaLink="false">talk2web-design_q10</guid>
      <category>talk2web</category>
      <category>Frontend</category>
      <category>UX</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>★ decided: Presets OK (Conflicts · Summarize · Draft-a-plan · Critique); the setup block starts collapsed like every other block.</description>
    </item>
    <item>
      <title>What are we designing?</title>
      <link>https://flove.org/making-of.html#nety-spec_q1</link>
      <guid isPermaLink="false">nety-spec_q1</guid>
      <category>nety-spec</category>
      <category>Brief</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• A flove app/demo — A piece of your flove ecosystem, following its design standards.
• A standalone page — A self-contained page unrelated to flove.
• A single component — One focused UI piece.

★ decided: A flove app/demo</description>
    </item>
    <item>
      <title>Aesthetic direction?</title>
      <link>https://flove.org/making-of.html#nety-spec_q2</link>
      <guid isPermaLink="false">nety-spec_q2</guid>
      <category>nety-spec</category>
      <category>Brief</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Let the assistant choose — Commit to a bold, context-fit direction with reasoning.
• Minimal / refined — Restraint, precision, generous negative space.
• Maximalist / bold — Dense, expressive, heavy motion, grid-breaking.
• Retro / editorial — Magazine, retro-futuristic or art-deco character.

★ decided: Maximalist / bold</description>
    </item>
    <item>
      <title>Scope on nety.html?</title>
      <link>https://flove.org/making-of.html#nety-spec_q3</link>
      <guid isPermaLink="false">nety-spec_q3</guid>
      <category>nety-spec</category>
      <category>Brief</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Bold redesign, same content — Keep all existing content; push the visual language hard.
• Redesign one section — Make just one zone dramatically bolder.
• Add a new section — Keep the page; add a maximalist new section.
• Start fresh — Throw out the layout, build anew.

★ decided: Bold redesign, same content</description>
    </item>
    <item>
      <title>JS budget on nety?</title>
      <link>https://flove.org/making-of.html#nety-spec_q4</link>
      <guid isPermaLink="false">nety-spec_q4</guid>
      <category>nety-spec</category>
      <category>Brief</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• CSS-pure except ONE small inline script — Everything CSS :has()/checkbox driven, except one basic-tier script for the registration form + stars/stage state (live outputs). The agreed stance.
• Fully CSS-pure, zero JS — No scripts at all; outputs are preset/illustrative, can't echo typed input.
• Liberal JS — A full JS app; abandons the CSS-pure ethos.

★ decided: CSS-pure except ONE small inline script</description>
    </item>
    <item>
      <title>Which maximalist direction?</title>
      <link>https://flove.org/making-of.html#nety-spec_q5</link>
      <guid isPermaLink="false">nety-spec_q5</guid>
      <category>nety-spec</category>
      <category>Brief</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Kinetic Mesh — The page IS the network: living constellation of orbiting nodes + link-lines, glowing glass cards, giant NETY.
• Brutalist Terminal — Raw mono, exposed grid, hacker-manifesto energy.
• Editorial Poster — Swiss-magazine: giant diagonal type, asymmetric grid, big numerals.

★ decided: Kinetic Mesh</description>
    </item>
    <item>
      <title>How to frame new features vs what's actually real?</title>
      <link>https://flove.org/making-of.html#nety-spec_q6</link>
      <guid isPermaLink="false">nety-spec_q6</guid>
      <category>nety-spec</category>
      <category>Access</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Honest status badges — Tag each capability live/partial/planned, keeping credibility.
• Aspirational vision — Show the full intended experience, no caveats.
• Vision now, one honesty line — Show the full vision boldly + a single candid line on preview-vs-live. Best of both.

★ decided: Vision now, one honesty line</description>
    </item>
    <item>
      <title>The 'sety' settings page + profily?</title>
      <link>https://flove.org/making-of.html#nety-spec_q7</link>
      <guid isPermaLink="false">nety-spec_q7</guid>
      <category>nety-spec</category>
      <category>Access</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• New top-level sety + polish profily — Create an ecosystem account page + improve profily.
• Use existing puzzy/sety.html — Integrate the existing Puzzy settings page (already on nety's palette), improved.
• Just profily for now — Skip settings this round.

★ decided: Use existing puzzy/sety.html</description>
    </item>
    <item>
      <title>wizy.html / the athen-ia finetuner agents?</title>
      <link>https://flove.org/making-of.html#nety-spec_q8</link>
      <guid isPermaLink="false">nety-spec_q8</guid>
      <category>nety-spec</category>
      <category>Access</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• New wizy.html + surface in sety — Build a new athenea (navy+gold) agents app AND make the agents prominent in sety.
• Only enhance sety's Wizard — No new page; just brand/expand the existing Wizard section.
• New wizy.html only — Build the app; leave sety as-is.

★ decided: New wizy.html + surface in sety</description>
    </item>
    <item>
      <title>Which signals feed a peer's trust score?</title>
      <link>https://flove.org/making-of.html#nety-spec_q9</link>
      <guid isPermaLink="false">nety-spec_q9</guid>
      <category>nety-spec</category>
      <category>Trust</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Linked identities — Verified Telegram/phone/email/biometrics + self-asserted social links.
• Vouches received — Weighted by the voucher's own score (transitive).
• Resources shared — Compute/storage/AI contributed over time.
• Invite-graph position — Branch depth/breadth + your inviter's standing.

★ decided: Linked identities · Vouches received · Resources shared · Invite-graph position</description>
    </item>
    <item>
      <title>Can a trust score go down?</title>
      <link>https://flove.org/making-of.html#nety-spec_q10</link>
      <guid isPermaLink="false">nety-spec_q10</guid>
      <category>nety-spec</category>
      <category>Trust</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Dynamic (can drop) — Inactivity-free, but abuse/slashing + transitive drops can lower it. Living standing.
• Only grows — Permanent once earned; simpler but lets bad/dormant actors keep high trust.
• Grows, but slashable — Accumulates, but specific events can slash it.

★ decided: Dynamic (can drop)</description>
    </item>
    <item>
      <title>One number or multiple facets?</title>
      <link>https://flove.org/making-of.html#nety-spec_q11</link>
      <guid isPermaLink="false">nety-spec_q11</guid>
      <category>nety-spec</category>
      <category>Trust</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Multi-facet — Several sub-scores; different capabilities gate on different facets.
• Single scalar — One blended number; simplest but can't distinguish kinds of standing.
• Scalar + visible breakdown — One headline number, contributing parts shown.

★ decided: Multi-facet</description>
    </item>
    <item>
      <title>How do stars (currency) relate to trust score (standing)?</title>
      <link>https://flove.org/making-of.html#nety-spec_q12</link>
      <guid isPermaLink="false">nety-spec_q12</guid>
      <category>nety-spec</category>
      <category>Trust</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Independent axes — Stars earned/spent; score gates. Share inputs, distinct.
• Stars flow from score — Your standing sets the star MINT-RATE; spending never lowers standing. Tap vs bucket.
• Unified pool — One quantity does both; spending lowers standing until re-earned.

★ decided: Stars flow from score</description>
    </item>
    <item>
      <title>Receiving vs giving trust?</title>
      <link>https://flove.org/making-of.html#nety-spec_q13</link>
      <guid isPermaLink="false">nety-spec_q13</guid>
      <category>nety-spec</category>
      <category>Trust</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Giving is +0 direct — You gain standing only from what others extend to you; no trust-farming. Giving well compounds, giving badly costs.
• Small reward for giving — A tiny bump for participating; more game-able.

★ decided: Giving is +0 direct</description>
    </item>
    <item>
      <title>Invite budget model?</title>
      <link>https://flove.org/making-of.html#nety-spec_q14</link>
      <guid isPermaLink="false">nety-spec_q14</guid>
      <category>nety-spec</category>
      <category>Invites</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Scales with Social facet — Allowance grows with standing; Sybil-resistant.
• Fixed small allotment — Everyone gets the same few; egalitarian but flat.
• Earned per good invite — More invites as your invitees mature.
• Scales + accountability — Scales with standing AND invitees' fates reflect back — invite someone who's slashed, your budget+score drop.

★ decided: Scales + accountability</description>
    </item>
    <item>
      <title>How does abuse become a slash?</title>
      <link>https://flove.org/making-of.html#nety-spec_q15</link>
      <guid isPermaLink="false">nety-spec_q15</guid>
      <category>nety-spec</category>
      <category>Invites</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Weighted peer reports — Reports weighted by reporter's score auto-slash; needs anti-brigading.
• Reports + trusted jurors — A quorum of high-trust jurors confirms; harder to brigade.
• Staked reports — Reporting costs staked stars; false reports burn the stake.
• Defer — just show the slash — Mock only shows 'reported→slashed'; design real adjudication later.

★ decided: Defer — just show the slash</description>
    </item>
    <item>
      <title>Shape of the invite web?</title>
      <link>https://flove.org/making-of.html#nety-spec_q16</link>
      <guid isPermaLink="false">nety-spec_q16</guid>
      <category>nety-spec</category>
      <category>Invites</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Multi-sponsor web (DAG) — A peer can be co-vouched by several; stronger entry.
• Strict tree (one sponsor) — Exactly one inviter each; clean accountability.
• Tree entry, web later — Enter via ONE invite (clean lineage tree), then accumulate vouches that add web edges for scoring without changing your parent.

★ decided: Tree entry, web later</description>
    </item>
    <item>
      <title>Invite code issuance?</title>
      <link>https://flove.org/making-of.html#nety-spec_q17</link>
      <guid isPermaLink="false">nety-spec_q17</guid>
      <category>nety-spec</category>
      <category>Invites</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Single-use only — One code → one person, pre-committed.
• Reusable capped link — One link good for N joins.
• Both (multi-use needs per-registrant validation) — Single-use code OR a capped multi-use link where you approve each registrant before they're in.

★ decided: Both (multi-use needs per-registrant validation)</description>
    </item>
    <item>
      <title>Revocation?</title>
      <link>https://flove.org/making-of.html#nety-spec_q18</link>
      <guid isPermaLink="false">nety-spec_q18</guid>
      <category>nety-spec</category>
      <category>Invites</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Revoke unused only — Refund before use; joined lineage is permanent.
• Revoke + disown — Also sever a joined invitee — costs Social score + leaves a public 'disowned' mark.
• No revocation — Immutable once created.

★ decided: Revoke + disown</description>
    </item>
    <item>
      <title>Invite-graph scoring: depth vs breadth?</title>
      <link>https://flove.org/making-of.html#nety-spec_q19</link>
      <guid isPermaLink="false">nety-spec_q19</guid>
      <category>nety-spec</category>
      <category>Invites</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Favor depth — Deep thriving lineage is the strongest, hardest-to-fake signal.
• Balance both — Wide-and-good scores like deep-and-narrow; steeper decay, higher breadth cap.
• Favor breadth — Reward many good direct invitees; more gameable.

★ decided: Balance both</description>
    </item>
    <item>
      <title>What makes an invitee 'matured' (counts for subtree credit)?</title>
      <link>https://flove.org/making-of.html#nety-spec_q20</link>
      <guid isPermaLink="false">nety-spec_q20</guid>
      <category>nety-spec</category>
      <category>Invites</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Independent verify + outside vouch — ≥ Telegram-verified on their own AND ≥1 vouch from someone OTHER than their inviter — so sponsors can't self-manufacture matured nodes.
• Score threshold + time — Reach a min score sustained for a period; still gameable.
• Contribution-based — Must have actually contributed/published.

★ decided: Independent verify + outside vouch</description>
    </item>
    <item>
      <title>Resisting mutual-vouch rings / collusion?</title>
      <link>https://flove.org/making-of.html#nety-spec_q21</link>
      <guid isPermaLink="false">nety-spec_q21</guid>
      <category>nety-spec</category>
      <category>Invites</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Diversity-weighted vouches — A vouch counts less from your own dense cluster, full from distant independent peers — rings self-cancel.
• Reciprocity discount only — Just down-weight directly mutual A↔B; misses 3+ rings.
• Defer it — Note as a limitation; rely on maturation + slashing for now.

★ decided: Diversity-weighted vouches</description>
    </item>
    <item>
      <title>Slash severity &amp; reach?</title>
      <link>https://flove.org/making-of.html#nety-spec_q22</link>
      <guid isPermaLink="false">nety-spec_q22</guid>
      <category>nety-spec</category>
      <category>Invites</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Graduated + bounded cascade — Severity scales with the offense; cascades to inviter/vouchers but decayed and only to those who didn't disown in time. Proportional.
• Hard reset, no cascade — Zero the facet, contained to the offender; removes accountability pressure.
• Flat penalty + full cascade — Fixed slash propagated undecayed to all ancestors; harsh, collateral-heavy.

★ decided: Graduated + bounded cascade</description>
    </item>
    <item>
      <title>Who signs the invite-lineage edge (builds the public tree)?</title>
      <link>https://flove.org/making-of.html#nety-spec_q23</link>
      <guid isPermaLink="false">nety-spec_q23</guid>
      <category>nety-spec</category>
      <category>Invites</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Co-signed by both — Inviter + invitee both sign — mutual, non-repudiable, hard to forge or deny.
• Inviter publishes — Ties to budget, but invitee hasn't attested their own lineage.
• Invitee publishes — Natural in a feed model, but a parent could be falsely claimed.

★ decided: Co-signed by both</description>
    </item>
    <item>
      <title>Multi-use-link validation expiry?</title>
      <link>https://flove.org/making-of.html#nety-spec_q24</link>
      <guid isPermaLink="false">nety-spec_q24</guid>
      <category>nety-spec</category>
      <category>Identity</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• 72h then auto-lapse — Pending request expires after ~3 days; time to act without strangers hanging.
• 7 days + reminder — Longer window with a nudge.
• No expiry — manual — Sits in your queue until you act.

★ decided: 72h then auto-lapse</description>
    </item>
    <item>
      <title>Inactivity &amp; decay?</title>
      <link>https://flove.org/making-of.html#nety-spec_q25</link>
      <guid isPermaLink="false">nety-spec_q25</guid>
      <category>nety-spec</category>
      <category>Identity</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Slow grace then steady — No decay for ~30 days idle, then gentle decline.
• Gentle continuous — Always decaying slightly; penalizes brief absences.
• Half-life — Each facet decays toward a floor on a fixed half-life.
• Separate Activity stat (not decay) — Earned standing NEVER erodes from idleness; recency is a separate stat instead.

★ decided: Separate Activity stat (not decay)</description>
    </item>
    <item>
      <title>What is the top 'Biometrics' identity rung?</title>
      <link>https://flove.org/making-of.html#nety-spec_q26</link>
      <guid isPermaLink="false">nety-spec_q26</guid>
      <category>nety-spec</category>
      <category>Identity</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Privacy-preserving proof-of-uniqueness — Liveness → non-reversible one-per-person token; raw biometrics never stored. No honeypot, FOSS-aligned.
• Device biometric unlock — WebAuthn-style; proves device control, not one-human-one-account.
• Defer the method — Keep biometrics top conceptually; pin the mechanism later.

★ decided: Privacy-preserving proof-of-uniqueness</description>
    </item>
    <item>
      <title>What is the Activity stat?</title>
      <link>https://flove.org/making-of.html#nety-spec_q27</link>
      <guid isPermaLink="false">nety-spec_q27</guid>
      <category>nety-spec</category>
      <category>Identity</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• A visible presence signal, inside Global — Purely a public liveness indicator; gates nothing, changes no scores. Lives as the presence dimension of the Global facet.
• A scored factor — Activity feeds standing/perks (e.g. mint-rate).
• A separate fifth stat — Its own top-level stat, outside the four facets.

★ decided: A visible presence signal, inside Global</description>
    </item>
    <item>
      <title>Presence model for an offline-first P2P node?</title>
      <link>https://flove.org/making-of.html#nety-spec_q28</link>
      <guid isPermaLink="false">nety-spec_q28</guid>
      <category>nety-spec</category>
      <category>Identity</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Graded LIVE / RECENT / REACHABLE / DARK — LIVE=online now; RECENT=acted lately; REACHABLE=offline but content replicated by peers; DARK=neither. Honest: offline ≠ unreachable.
• Just live heartbeat — Online-now bit; misleading when a dark node's content is still served.
• Last meaningful action — Just a timestamp; ignores reachability.

★ decided: Graded LIVE / RECENT / REACHABLE / DARK</description>
    </item>
    <item>
      <title>What does the permissions layer govern?</title>
      <link>https://flove.org/making-of.html#nety-spec_q29</link>
      <guid isPermaLink="false">nety-spec_q29</guid>
      <category>nety-spec</category>
      <category>Circles</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Content / pages — Who can read your published pages, posts, files.
• Shared resources — Who can draw on the compute/storage/AI you offer.
• Profile data — Field-level visibility of your profily.
• Interaction / social — Who can message you, request to join via you, add you to their MyNet.

★ decided: Content / pages · Shared resources · Profile data · Interaction / social</description>
    </item>
    <item>
      <title>What are permissions granted to?</title>
      <link>https://flove.org/making-of.html#nety-spec_q30</link>
      <guid isPermaLink="false">nety-spec_q30</guid>
      <category>nety-spec</category>
      <category>Circles</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• MyNet + named circles — Your whole MyNet and/or named sub-circles. Most expressive.
• Per-peer only — Individual grant/deny; precise but tedious.
• By trust tier — Grant by network trust level; leans on the score.
• Hybrid: circles + tiers — Circles AND tiers in one rule.

★ decided: MyNet + named circles</description>
    </item>
    <item>
      <title>Default audience for a new peer?</title>
      <link>https://flove.org/making-of.html#nety-spec_q31</link>
      <guid isPermaLink="false">nety-spec_q31</guid>
      <category>nety-spec</category>
      <category>Circles</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Private-first, opt-in to share — Everything starts private; you deliberately widen each area. Safest, FOSS-aligned.
• Sensible per-area defaults — Reasonable defaults per area; friendlier but some things visible early.
• Public-first, opt-in to restrict — Open by default; lock down what you want private.

★ decided: Private-first, opt-in to share</description>
    </item>
    <item>
      <title>Circle model?</title>
      <link>https://flove.org/making-of.html#nety-spec_q32</link>
      <guid isPermaLink="false">nety-spec_q32</guid>
      <category>nety-spec</category>
      <category>Circles</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Flat subsets of MyNet — Each circle a subset; a peer in several; no nesting.
• Nested tiers — Concentric rings close⊆friends⊆MyNet; outer grant includes inner.
• Flat independent tags — Labels with no MyNet relationship; can include non-MyNet peers.
• Nested tiers + independent tags (both) — Tiered rings for graded trust AND flat tag circles for project/context groups, coexisting.

★ decided: Nested tiers + independent tags (both)</description>
    </item>
    <item>
      <title>Which layers do circles span?</title>
      <link>https://flove.org/making-of.html#nety-spec_q33</link>
      <guid isPermaLink="false">nety-spec_q33</guid>
      <category>nety-spec</category>
      <category>Circles</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Both nety + appy, parallel &amp; connectable — nety circles and appy circles are the same circles, running in parallel and easily linked across the bridge.
• Upper (appy) only — Circles live only in the apps layer.
• Lower (nety) only — Circles live only in the infrastructure layer.

★ decided: Both nety + appy, parallel &amp; connectable</description>
    </item>
    <item>
      <title>How visible are your facet scores to others?</title>
      <link>https://flove.org/making-of.html#nety-spec_q34</link>
      <guid isPermaLink="false">nety-spec_q34</guid>
      <category>nety-spec</category>
      <category>Circles</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Owner-controlled per facet — Default private; you reveal each facet (exact or coarse tier) to public/MyNet/circles. The protocol still computes with true scores.
• Public tier badges, exact private — Others see coarse tiers; exact numbers private to you.
• Fully public exact — All four facet values visible to everyone.
• Fully private — Nobody sees scores; only capability outcomes observable.

★ decided: Owner-controlled per facet</description>
    </item>
    <item>
      <title>Free-vs-stars posture (flove is FOSS)?</title>
      <link>https://flove.org/making-of.html#nety-spec_q35</link>
      <guid isPermaLink="false">nety-spec_q35</guid>
      <category>nety-spec</category>
      <category>Economy</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Passwords granted at contributing stages — As you accomplish contribution STAGES you're granted passwords that unlock protected page-sections. Access earned by contributing, not bought.
• Apps free; stars unlock scale/premium — Apps free; stars unlock resource-heavy capabilities only.
• Tiered free core + star-gated apps — Most apps free; some need a star unlock.
• Stars unlock each app — Each app costs stars to open; least FOSS-aligned.

★ decided: Passwords granted at contributing stages</description>
    </item>
    <item>
      <title>Unlock model?</title>
      <link>https://flove.org/making-of.html#nety-spec_q36</link>
      <guid isPermaLink="false">nety-spec_q36</guid>
      <category>nety-spec</category>
      <category>Economy</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• One-time, owned forever — Reach a stage once, keep the access permanently.
• Metered / pay-as-you-go — Spend per use of a heavy capability.
• Subscription — Recurring cost to keep a capability; least aligned.

★ decided: One-time, owned forever</description>
    </item>
    <item>
      <title>What advances you through stages?</title>
      <link>https://flove.org/making-of.html#nety-spec_q37</link>
      <guid isPermaLink="false">nety-spec_q37</guid>
      <category>nety-spec</category>
      <category>Economy</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Contribution, gated by trust floors — Contribution-driven, but sensitive stages (donation-directing, top tier) need a minimum trust floor — no advancing by raw resource-dumping.
• Contribution-only — Pure contribution milestones; clean separation.
• Blended contribution + standing — Every stage needs both contribution and a tier.

★ decided: Contribution, gated by trust floors</description>
    </item>
    <item>
      <title>Donation directing — what can you direct?</title>
      <link>https://flove.org/making-of.html#nety-spec_q38</link>
      <guid isPermaLink="false">nety-spec_q38</guid>
      <category>nety-spec</category>
      <category>Economy</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Both (earmark own + steward pool) — Earmark your own contributions early; steward the shared pool at expert+.
• Steward the shared commons — Allocate the pooled/donated commons; high-trust power.
• Earmark your own — Direct only what you contribute.

★ decided: Both (earmark own + steward pool)</description>
    </item>
    <item>
      <title>Directing — standing policy or per-donation?</title>
      <link>https://flove.org/making-of.html#nety-spec_q39</link>
      <guid isPermaLink="false">nety-spec_q39</guid>
      <category>nety-spec</category>
      <category>Economy</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Standing default + per-donation override — Set a default ('mostly to close'), override on any single donation.
• Standing policy only — One policy until changed; set-and-forget.
• Per-donation only — Direct each donation explicitly; more friction.

★ decided: Standing default + per-donation override</description>
    </item>
    <item>
      <title>In 'only' mode, if the target can't absorb it?</title>
      <link>https://flove.org/making-of.html#nety-spec_q40</link>
      <guid isPermaLink="false">nety-spec_q40</guid>
      <category>nety-spec</category>
      <category>Economy</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Fall back to the shared pool — Surplus flows to the commons rather than sitting idle; softens 'only' but never wastes.
• Hold / queue for the target — Waits until the target can use it; strict.
• Return to donor — Reverts to you to redirect.

★ decided: Fall back to the shared pool</description>
    </item>
    <item>
      <title>Directing transparency?</title>
      <link>https://flove.org/making-of.html#nety-spec_q41</link>
      <guid isPermaLink="false">nety-spec_q41</guid>
      <category>nety-spec</category>
      <category>Economy</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Donor decides — Each donor sets per-donation: public ledger / contributor-visible / private. A steward can't override it.
• Public ledger — All directing visible; max accountability.
• known-visible — Only pool contributors see allocation.
• Private — Allocation not surfaced.

★ decided: Donor decides</description>
    </item>
    <item>
      <title>How does the donation pool fill?</title>
      <link>https://flove.org/making-of.html#nety-spec_q42</link>
      <guid isPermaLink="false">nety-spec_q42</guid>
      <category>nety-spec</category>
      <category>Economy</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Purely voluntary — Only what peers explicitly donate; most free-as-in-freedom, may be thin.
• Voluntary + small auto-tithe — Mostly voluntary + ~2–5% tithe so the pool always exists.
• Surplus / unclaimed flows in — Idle offered resources auto-flow to the pool.
• Voluntary + surplus — Explicit donations + idle surplus, no tithe on used resources.

★ decided: Purely voluntary</description>
    </item>
    <item>
      <title>How does nety standing carry into the apps?</title>
      <link>https://flove.org/making-of.html#nety-spec_q43</link>
      <guid isPermaLink="false">nety-spec_q43</guid>
      <category>nety-spec</category>
      <category>Cross-cutting</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Portable base + per-app overlay — Your four facets/stage/presence port everywhere as the baseline; each app can add its own context reputation on top.
• One global score everywhere — Apps read one standing; consistent but flattens kinds of merit.
• Per-community scoped — Each app weights/holds its own trust; less portable.

★ decided: Portable base + per-app overlay</description>
    </item>
    <item>
      <title>MyWizy autonomy (the finetuner)?</title>
      <link>https://flove.org/making-of.html#nety-spec_q44</link>
      <guid isPermaLink="false">nety-spec_q44</guid>
      <category>nety-spec</category>
      <category>Cross-cutting</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• You set policy, agent optimizes within it — You set goals + hard budgets/privacy; MyWizy optimizes peering/relay/recs within bounds and explains its choices.
• Fully manual, agent only suggests — You set everything; it just recommends.
• Fully autonomous, you set a vibe — Pick a mode; it handles the rest.

★ decided: You set policy, agent optimizes within it</description>
    </item>
    <item>
      <title>Key loss recovery?</title>
      <link>https://flove.org/making-of.html#nety-spec_q45</link>
      <guid isPermaLink="false">nety-spec_q45</guid>
      <category>nety-spec</category>
      <category>Cross-cutting</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Self-backup + social fallback — You hold a backup to rotate yourself; if lost, a quorum of your MyNet/vouchers co-signs to rebind.
• Social recovery only — Always a trusted-quorum rebind; nothing to store, depends on peers.
• Self-custody only — You alone hold a backup; lose it, lose everything.

★ decided: Self-backup + social fallback</description>
    </item>
    <item>
      <title>Standing transfer on recovery?</title>
      <link>https://flove.org/making-of.html#nety-spec_q46</link>
      <guid isPermaLink="false">nety-spec_q46</guid>
      <category>nety-spec</category>
      <category>Cross-cutting</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Carries forward, brief probation — All standing transfers, but a short probation after SOCIAL recovery guards against a hijacked recovery.
• Carries forward fully — New key inherits everything immediately; key-change shown on the tree.
• Lineage yes, scores partial — Identity+lineage survive, some scores re-accrue.

★ decided: Carries forward, brief probation</description>
    </item>
    <item>
      <title>How does the Verify trust section render?</title>
      <link>https://flove.org/making-of.html#nety-spec_q47</link>
      <guid isPermaLink="false">nety-spec_q47</guid>
      <category>nety-spec</category>
      <category>Cross-cutting</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Concentric scope rings — Nested rings Personal(core)→Local→Social→Global; arcs fill by score, Activity pulses on the outer ring. Literally draws 'concentric scope'.
• Stacked meters + boards — Four labeled bars + ladder + stage board; clearest, least designed.
• Orbiting facet constellation — You at center, facet-nodes orbiting; beautiful but busier.

★ decided: Concentric scope rings</description>
    </item>
    <item>
      <title>flovenet apps vs oasis — overall stance?</title>
      <link>https://flove.org/making-of.html#nety-spec_q48</link>
      <guid isPermaLink="false">nety-spec_q48</guid>
      <category>nety-spec</category>
      <category>oasis</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• flovenet INDEPENDENT; oasis as optional add-on — flovenet apps implement everything natively, LEARNING oasis's good patterns; oasis is an opt-in add-on (SSB federation, '42' AI). flovenet works fully without it.
• oasis as the upper layer — Build the apps layer on oasis/SSB directly; a hard dependency.
• Merge into one stack — Fuse flovenet + oasis into a single codebase.

★ decided: flovenet INDEPENDENT; oasis as optional add-on</description>
    </item>
    <item>
      <title>flovenet has ONE score; spec wants four facets — reconcile?</title>
      <link>https://flove.org/making-of.html#nety-spec_q49</link>
      <guid isPermaLink="false">nety-spec_q49</guid>
      <category>nety-spec</category>
      <category>oasis</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Derive four facets as views — Keep the working engine; expose four facets as derived views over inputs it already has. Least churn.
• Refactor reputation_engine into 4 facets — Properly re-model into four stored scores; cleanest, most churn.
• UI-only four facets — Single score under the hood; four facets only in the frontend.

★ decided: Derive four facets as views</description>
    </item>
    <item>
      <title>The invite layer (absent in flovenet) — build where/when?</title>
      <link>https://flove.org/making-of.html#nety-spec_q50</link>
      <guid isPermaLink="false">nety-spec_q50</guid>
      <category>nety-spec</category>
      <category>oasis</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Frontend mock now + adapt oasis pub-invites later — nety page mocks the whole invite web now; real path extends oasis pub-invites with lineage. Native build is a later milestone.
• Start the flovenet invite module now — Begin a real Rust invite layer in parallel.
• Adapt oasis pub-invites — Base it on SSB invites from the start.

★ decided: Frontend mock now + adapt oasis pub-invites later</description>
    </item>
    <item>
      <title>Recovery realism (SSB can't rotate identity)?</title>
      <link>https://flove.org/making-of.html#nety-spec_q51</link>
      <guid isPermaLink="false">nety-spec_q51</guid>
      <category>nety-spec</category>
      <category>oasis</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Accept 'no recovery' for now — Mock recovery in the frontend; real social recovery is an acknowledged hard future milestone, not a blocker.
• Commit to a social-recovery sidechain — Plan a real rotation/recovery layer beside the append-only identity.
• Self-backup only for now — Ship only self-custody backup; defer social recovery.

★ decided: Accept 'no recovery' for now</description>
    </item>
    <item>
      <title>Should one identity span both layers?</title>
      <link>https://flove.org/making-of.html#nety-spec_q52</link>
      <guid isPermaLink="false">nety-spec_q52</guid>
      <category>nety-spec</category>
      <category>Bridge</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• One Ed25519 keypair spans both layers — Your single key is both the flovenet keystore identity AND the (optional) SSB feed. The keypair is the unifying thread.
• Separate keys + signed binding — Distinct keys linked by an attestation; more isolation, more plumbing.
• Bridge at app layer only — Identities separate, associated only in the UI.

★ decided: One Ed25519 keypair spans both layers</description>
    </item>
    <item>
      <title>How does flovenet data reach the upper layer?</title>
      <link>https://flove.org/making-of.html#nety-spec_q53</link>
      <guid isPermaLink="false">nety-spec_q53</guid>
      <category>nety-spec</category>
      <category>Bridge</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• flovenet GraphQL gateway as the bridge — The upper layer reads the portable base (4 facets, stage, presence, resources) from flovenet's existing GraphQL gateway.
• Dedicated SSB↔flovenet service — A translator service maps messages both ways; more decoupled, more work.
• Frontend composes both — The frontend reads each separately; no server unification.

★ decided: flovenet GraphQL gateway as the bridge</description>
    </item>
    <item>
      <title>Where's the authoritative trust/vouch graph?</title>
      <link>https://flove.org/making-of.html#nety-spec_q54</link>
      <guid isPermaLink="false">nety-spec_q54</guid>
      <category>nety-spec</category>
      <category>Bridge</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• flovenet trust_graph (follows mirror it) — Vouches + facet inputs live in flovenet; SSB follows are a social mirror. One source of truth for scoring.
• SSB follows authoritative, flovenet derives — Social graph in SSB; flovenet ingests to score.
• Split: vouches flovenet / follows SSB — Weighted vouches in flovenet, casual follows in SSB.

★ decided: flovenet trust_graph (follows mirror it)</description>
    </item>
    <item>
      <title>Native circle storage / replication?</title>
      <link>https://flove.org/making-of.html#nety-spec_q55</link>
      <guid isPermaLink="false">nety-spec_q55</guid>
      <category>nety-spec</category>
      <category>Native</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• OR-Set CRDT over gossipsub — Membership as a CRDT gossiped over libp2p — reuses flovenet's existing CRDT+gossipsub stack; content encrypted to a group key.
• Dedicated group protocol — A purpose-built group/channel subsystem; cleaner, more to build.
• Reuse social_protocol + storage — Layer circles on existing types; least code, not first-class.

★ decided: OR-Set CRDT over gossipsub</description>
    </item>
    <item>
      <title>Group key when a member is removed?</title>
      <link>https://flove.org/making-of.html#nety-spec_q56</link>
      <guid isPermaLink="false">nety-spec_q56</guid>
      <category>nety-spec</category>
      <category>Native</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Rotate on removal (forward secrecy) — Re-seal a fresh key to remaining members so the removed peer can't read future content.
• Static group key — One key for life; removed members keep it. No forward secrecy.
• Rotate on schedule + on removal — Also epoch-rotate; most secure, most overhead.

★ decided: Rotate on removal (forward secrecy)</description>
    </item>
    <item>
      <title>Encrypted circle posting via the oasis/SSB add-on (7-recps cap)?</title>
      <link>https://flove.org/making-of.html#nety-spec_q57</link>
      <guid isPermaLink="false">nety-spec_q57</guid>
      <category>nety-spec</category>
      <category>Native</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Private groups (box2) per circle — Each circle is an SSB private group with a shared key; scales past the ~7-recipient box1 limit.
• box1 recps everywhere — Classic recps ≤7; breaks for real circles.
• Re-encrypt per member — A copy per recipient; heavy and leaky.

★ decided: Private groups (box2) per circle</description>
    </item>
    <item>
      <title>SSB public posts are irreversible — UI?</title>
      <link>https://flove.org/making-of.html#nety-spec_q58</link>
      <guid isPermaLink="false">nety-spec_q58</guid>
      <category>nety-spec</category>
      <category>Native</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Treat public normally — Public is just another audience choice, no special warning.
• Explicit 'permanent &amp; public' confirm — Going public names the irreversibility; reinforces private-first.
• Public = separate explicit mode — A distinct 'publish to the world' action, separated from private sharing.

★ decided: Treat public normally</description>
    </item>
    <item>
      <title>Lineage tree storage?</title>
      <link>https://flove.org/making-of.html#nety-spec_q59</link>
      <guid isPermaLink="false">nety-spec_q59</guid>
      <category>nety-spec</category>
      <category>Native</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Append-only signed records over gossipsub — Each co-signed edge gossiped + stored; tree reconstructed from edges. Immutable, traceable. (Default — not explicitly chosen.)
• CRDT tree structure — Tree as a CRDT; lineage is immutable history, so append-only fits better.
• Kademlia DHT records — Edges as DHT entries; weaker for full traversal.

★ decided: Append-only signed records over gossipsub</description>
    </item>
    <item>
      <title>Invite-budget over-issuance with no central counter?</title>
      <link>https://flove.org/making-of.html#nety-spec_q60</link>
      <guid isPermaLink="false">nety-spec_q60</guid>
      <category>nety-spec</category>
      <category>Native</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Accept eventual-consistency drift — Don't hard-block; tolerate brief over-issuance under partition, reconcile later by slashing. Fits a P2P network.
• Publicly-derivable allowance + detectable over-issuance — Anyone counts issued vs allowance; excess rejected, over-issuer slashed.
• Invitee checks before accepting — Each joiner verifies the inviter's count first.

★ decided: Accept eventual-consistency drift</description>
    </item>
    <item>
      <title>Names for the five stages (replacing Joined·Contributor·Steward·Patron·Pillar)?</title>
      <link>https://flove.org/making-of.html#nety-spec_q61</link>
      <guid isPermaLink="false">nety-spec_q61</guid>
      <category>nety-spec</category>
      <category>Tiers</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• newbie · known · homie · expert · legend — Marc's chosen stage names, mapping to the mini→super tier ceilings.
• mini · basic · normal · advanced · super — Reuse the tier names as stage names.
• Seed · Sprout · Grove · Forest · Canopy — Organic growth metaphor.

★ decided: newbie · known · homie · expert · legend</description>
    </item>
    <item>
      <title>How do stages relate to the tier/mode you browse in?</title>
      <link>https://flove.org/making-of.html#nety-spec_q62</link>
      <guid isPermaLink="false">nety-spec_q62</guid>
      <category>nety-spec</category>
      <category>Tiers</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Stage = earned ceiling; mode is your choice (optionally activatable) — Your stage unlocks a ceiling of tiers; you freely pick any tier at/below it, new features optional. A legend can browse mini/basic. Earned level ≠ chosen mode.
• Stage hard-locks you to one tier — You're always in the tier your stage dictates; no downshifting.
• Fully independent — Tiers and stages unrelated.

★ decided: Stage = earned ceiling; mode is your choice (optionally activatable)</description>
    </item>
    <item>
      <title>What does the 'super' tier add?</title>
      <link>https://flove.org/making-of.html#nety-spec_q63</link>
      <guid isPermaLink="false">nety-spec_q63</guid>
      <category>nety-spec</category>
      <category>Tiers</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Leave super open for now — Define mini→advanced concretely; super = 'the full stack, TBD'.
• Full integration of all tiers — super = everything woven together, all scopes active.
• Network-wide / steward powers — super adds top-end powers (pool stewardship, governance).

★ decided: Leave super open for now</description>
    </item>
    <item>
      <title>What do nety's hardware tiers add (mini→super)?</title>
      <link>https://flove.org/making-of.html#nety-spec_q64</link>
      <guid isPermaLink="false">nety-spec_q64</guid>
      <category>nety-spec</category>
      <category>Tiers</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Same resource types, more quota — nety is a QUOTA ladder — every tier shares the same resources; higher tiers just raise how much you contribute/draw.
• Scaling capacity &amp; new roles — Each tier adds new hardware capabilities (relay→compute→GPU→orchestration).
• Leave nety tiers open — Spec the hardware ladder later.

★ decided: Same resource types, more quota</description>
    </item>
    <item>
      <title>Do the nety (hardware) and appy (software) ladders advance together or apart?</title>
      <link>https://flove.org/making-of.html#nety-spec_q65</link>
      <guid isPermaLink="false">nety-spec_q65</guid>
      <category>nety-spec</category>
      <category>Tiers</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Independent, both feed your standing — Progress in each domain separately; hardware→Global, software→other facets. Either path raises your stage.
• One linked stage — A single stage advances both domains together.
• Hardware gates software — Climb nety first to unlock the matching appy tier.

★ decided: Independent, both feed your standing</description>
    </item>
    <item>
      <title>Access gating: mini (nety) vs basic (appy)?</title>
      <link>https://flove.org/making-of.html#nety-spec_q66</link>
      <guid isPermaLink="false">nety-spec_q66</guid>
      <category>nety-spec</category>
      <category>Tiers</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• mini open, basic invite-gated — Freely download the client + contribute to nety + get a web miniprofile (no invite); registering into appy (play &amp; store apps) needs an invite.
• Both open — No invite anywhere; fully permissionless.
• Both invite-gated — Even running the nety client needs an invite.

★ decided: mini open, basic invite-gated</description>
    </item>
    <item>
      <title>Can you advance without sharing nety resources?</title>
      <link>https://flove.org/making-of.html#nety-spec_q67</link>
      <guid isPermaLink="false">nety-spec_q67</guid>
      <category>nety-spec</category>
      <category>Tiers</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>• Yes — substitute more authentication/trust — Skip nety contributions but compensate with more Personal/Social/Local (identities, vouches, invites). Facets are substitutable.
• No — contribution is required — You must share resources to advance.

★ decided: Yes — substitute more authentication/trust</description>
    </item>
    <item>
      <title>Two tiered domains</title>
      <link>https://flove.org/making-of.html#nety-spec_q68</link>
      <guid isPermaLink="false">nety-spec_q68</guid>
      <category>nety-spec</category>
      <category>Notes</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>★ decided: Two tiered domains: nety = hardware (compute/storage/AI/network resources — a QUOTA ladder: same resource types, more quota per tier) · appy = data-software (apps/data/profiles — a FEATURE ladder). Each runs mini→basic→normal→advanced→super. The two ladders advance independently and both feed your standing. Profile: profily-mini (open web miniprofile) ↔ profily (full, in appy). Circles exist in both, parallel &amp; connectable.</description>
    </item>
    <item>
      <title>Stages (newbie·known·homie·expert·legend)</title>
      <link>https://flove.org/making-of.html#nety-spec_q69</link>
      <guid isPermaLink="false">nety-spec_q69</guid>
      <category>nety-spec</category>
      <category>Notes</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>★ decided: Stages (newbie·known·homie·expert·legend) gate the TIER CEILING you can use; the tier/mode you browse is your choice (features optionally activatable — a legend can browse mini). Advance by sharing nety hardware OR by substituting more authentication/trust. appy tiers map: mini=nety(resources)·basic=profily+apps(play &amp; store)·normal=sety(data mgmt)·advanced=MyWizy·super=open.</description>
    </item>
    <item>
      <title>Access</title>
      <link>https://flove.org/making-of.html#nety-spec_q70</link>
      <guid isPermaLink="false">nety-spec_q70</guid>
      <category>nety-spec</category>
      <category>Notes</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>★ decided: Access: mini (nety) is open — free client + contribute + web miniprofile, no invite. basic (appy) is invite-gated — registering to play &amp; store apps needs an invite (~3/month per user, vertical web-of-trust bootstrap).</description>
    </item>
    <item>
      <title>Four scoped facets</title>
      <link>https://flove.org/making-of.html#nety-spec_q71</link>
      <guid isPermaLink="false">nety-spec_q71</guid>
      <category>nety-spec</category>
      <category>Notes</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>★ decided: Four scoped facets (Marc's taxonomy): Personal=authentication · Local=invite-net · Social=trusts · Global=contribs. Activity (presence) lives inside Global.</description>
    </item>
    <item>
      <title>Identity rung weights</title>
      <link>https://flove.org/making-of.html#nety-spec_q72</link>
      <guid isPermaLink="false">nety-spec_q72</guid>
      <category>nety-spec</category>
      <category>Notes</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>★ decided: Identity rung weights (low→high): social link (email-only platform) → social link (phone-required platform, e.g. idealista &gt; Instagram) → verified email → verified Telegram ✦ publish gate → verified phone → biometrics. Only Telegram is verified for now; weight = verification rigor.</description>
    </item>
    <item>
      <title>Registration is invite-coded;</title>
      <link>https://flove.org/making-of.html#nety-spec_q73</link>
      <guid isPermaLink="false">nety-spec_q73</guid>
      <category>nety-spec</category>
      <category>Notes</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>★ decided: Registration is invite-coded; publishing a static HTML page needs ≥ Telegram verification.</description>
    </item>
    <item>
      <title>Store integrates</title>
      <link>https://flove.org/making-of.html#nety-spec_q74</link>
      <guid isPermaLink="false">nety-spec_q74</guid>
      <category>nety-spec</category>
      <category>Notes</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>★ decided: Store integrates profily (extended profile) + puzzy/sety (settings) + wizy (agents).</description>
    </item>
    <item>
      <title>MyNet</title>
      <link>https://flove.org/making-of.html#nety-spec_q75</link>
      <guid isPermaLink="false">nety-spec_q75</guid>
      <category>nety-spec</category>
      <category>Notes</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>★ decided: MyNet spans both layers (f2f substrate in nety, custom circles in appy). MyWizy = your athen-ia finetuner (tunes f2f connectivity + apps experience); Wizy = the app.</description>
    </item>
    <item>
      <title>Stages unlock more across both layers</title>
      <link>https://flove.org/making-of.html#nety-spec_q76</link>
      <guid isPermaLink="false">nety-spec_q76</guid>
      <category>nety-spec</category>
      <category>Notes</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>★ decided: Stages unlock more across both layers: further apps (upper) + further resources &amp; donation directing (lower). Donations can target a circle ('to my close ring, mostly or only').</description>
    </item>
    <item>
      <title>Invites stay public/traceable</title>
      <link>https://flove.org/making-of.html#nety-spec_q77</link>
      <guid isPermaLink="false">nety-spec_q77</guid>
      <category>nety-spec</category>
      <category>Notes</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>★ decided: Invites stay public/traceable for flagging, even though facet scores are owner-private.</description>
    </item>
    <item>
      <title>GOVERNING STANCE</title>
      <link>https://flove.org/making-of.html#nety-spec_q78</link>
      <guid isPermaLink="false">nety-spec_q78</guid>
      <category>nety-spec</category>
      <category>Notes</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>★ decided: GOVERNING STANCE: flovenet apps INDEPENDENT — implemented natively, LEARNING oasis's good patterns (private groups, follows-as-mirror, offline-first, private-first, circles). oasis = optional add-on (SSB federation, '42' as a pluggable MyWizy AI engine).</description>
    </item>
    <item>
      <title>Bridge</title>
      <link>https://flove.org/making-of.html#nety-spec_q79</link>
      <guid isPermaLink="false">nety-spec_q79</guid>
      <category>nety-spec</category>
      <category>Notes</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>★ decided: Bridge: one Ed25519 keypair → flovenet (lower) → GraphQL gateway (portable base) → upper layer. 'Circles' is the user-facing name; SSB tribes only an under-the-hood primitive.</description>
    </item>
    <item>
      <title>MyWizy AI</title>
      <link>https://flove.org/making-of.html#nety-spec_q80</link>
      <guid isPermaLink="false">nety-spec_q80</guid>
      <category>nety-spec</category>
      <category>Notes</category>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>★ decided: MyWizy AI: flovenet-native local-first by default; oasis '42' an optional pluggable engine. Deeper inference details = further spec later.</description>
    </item>
  </channel>
</rss>
