<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>flove making-of — Native questions</title>
    <link>https://flove.org/making-of.html</link>
    <description>New Native design questions from flove interviews.</description>
    <language>en</language>
    <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>
  </channel>
</rss>
