Part of Stem. Sources: the Seed Resources board of 6 and 7 October 2026, and the Stem specification of 8 October 2026. Status is one of answered, leaning, open. "Answered" means the specification takes a position; it does not mean the team has decided.
Resources and nodes
Question | Stem answer | Status | Where |
|---|---|---|---|
Can a resource's state be expressed by named roots or head blobs? | Yes. The head Node blobs of a node, by the fold, give the state target. | answered | |
Do we need generations? | No. Node ids are never reused, and | answered | |
Is there a unified way to know which root dominates? | Yes: drop Node blobs superseded through | answered | |
Is "resource maps to a set of blobs" enough, or must it be more dynamic? | Enough for sync and access; facts and links carry the dynamic view. | leaning | |
How should node ids be derived? | Decided (Eric, 2026-10-08): the id is the CID of the creating Node blob, which carries no | answered | |
Should a migrated node's id be the earliest Ref's CID or the genesis Change's CID? | Stem's position: the Ref, because a Change has no space or placement. | leaning | |
Do conversations produce named roots; are comments resources or triples? | Comments are resources: unnamed nodes in the author's space with | answered | |
Which merge rule applies when two Snapshots of one node are concurrent? | Both are heads; the next Snapshot lists both in | open | |
Are cross-space parents needed? | Stem forbids them: a parent is always in the node's space. Whether a shared folder across two spaces is wanted is open. | open | |
Snapshots versus full history for documents? | Unchanged from the roadmap: open, awaiting the custom CRDT. A Change may already dep on a Snapshot so either outcome fits. | open | |
What about pretty paths? | Derived from names, never identity; resolution order fixed; redirects are a Node target. | answered | |
Does the sidebar hierarchy depend on paths, or is it separate? | It is the placement tree, which is separate from identity and from authority. | answered |
Links
Question | Stem answer | Status | Where |
|---|---|---|---|
Can we express everything with named links plus a weight? | Yes: nine link kinds, each with fixed flags; the flags are the weight. | answered | |
Do we need weights if peers speak the same link types? | No; flags are derived from the kind. | answered | |
What is the ontology of links that we need? | The nine kinds on the Links page; extending the union is how new ones arrive. | leaning | |
Can we express everything as a blob link? | A link targets a blob or a node reference; a deterministic permanode per node is not needed because node ids are stable. | answered | |
Is it useful to have multiple labels for one physical blob? | Yes, later; not in this specification. | leaning | |
Should the dual CID problem (BLAKE2b daemon, SHA-256 clients) be fixed by canonicalising advertised CIDs? | Open; Stem keeps HM24's multihash pre-check and notes the team's codec canonicalisation plan. | open |
Authority and privacy
Question | Stem answer | Status | Where |
|---|---|---|---|
What are the access domains: spaces, groups, group per document? | Readers are computed per node from grants, inheritance and targets; groups are permanodes; no fixed domains. | answered | |
Do comments need their own grants? | No by default: a comment's readers are the target's readers through | leaning | |
How does a bearer audience work over peer sync? | It does not: a bearer cannot authenticate a connection. Bearer grants are honoured on HTTP reads only, where the secret is presented per request. | answered | |
Encryption and the | Reserved. | open | |
How does | Each peer applies its own clock at evaluation; an expired grant stays in the graph so a peer coming online late computes the same live set as everyone else once its clock passes the time. Clock skew between peers can make them disagree briefly. | leaning | |
Should admin reach exclude principals the owner has revoked, to end revocation ping-pong faster? | Open; Stem keeps the Keyline rule. | open | |
What happens to a revoked writer's already-received blobs? | Kept but unapplied: they fall out of the fold and can come back if authority is restored. | answered | |
Should indexed metadata be authoritative and signed, or peer-derived? | Both, kept distinct: every fact carries | answered |
Sync
Question | Stem answer | Status | Where |
|---|---|---|---|
Can set reconciliation be efficient over graphs of links instead of flat sets? | Each scope set is a flat set derived from the graph; reconciliation stays flat. | answered | |
Prolly trees versus flat RBSR per scope? | Open. Stem specifies flat RBSR per scope with per-peer filtering. A Prolly tree per node could replace the maintained scope index later without a wire change if items stay | open | |
How to partition so there are no access gaps? | Filter the scope set by the requester's readers before fingerprinting; no partitions are needed. | answered | |
Could a Prolly root be a resource that a node points to? | Not specified; nothing prevents a kind whose snapshot is an index. | open | |
How can a client query for multiple roots, like an entire space? | A scope with depth | answered | |
Should the "inodes" project land before blob accounting? | Yes; blob access is keyed by node. | answered | |
Sync relations instead of links? | Peers sync blobs; relations (facts, links) are derived locally with provenance. | answered | |
How does a fresh install find a space's authority peers without a gateway? | Open; a signed provider record per space is sketched. | open | |
Should Reconcile become bidirectional so the responder also learns what it lacks? | Open; Offer covers the common case. | open |
Agents
Question | Stem answer | Status | Where |
|---|---|---|---|
How can we model agents and notifications with this? | Agents, sessions and triggers as resources of new kinds; notifications as derived facts in a personal scope. | sketched | |
Could the notification set be a Prolly tree, and who owns it? | The account owns it; a Snapshot resource with audience | leaning |
Raised on other pages
Every question marked "Open:" inline on a Stem page, collected here so that this page stays the single register. Status is open unless the row says otherwise.
Question | Where |
|---|---|
whether an agent's key should be allowed to hold | |
whether notifications derived from public content should be computed by the account's site rather than a dedicated notification server, now that a site is an authority peer with a | |
whether | |
the bound on group nesting depth, and whether a group may be owned by another group | |
whether | |
whether admin reach should exclude principals whose membership was revoked by the owner specifically, to shorten this exchange | |
a provider record keyed by space, signed by an authority peer, so that a fresh install can find a space's site without a gateway | |
whether a sub-space, a child node with its own key, is ever needed; Stem does not define one | |
whether and when the daemon publishes Snapshots of documents to shorten histories (the custom CRDT discussion in the roadmap) | |
whether a kind change should ever re-evaluate existing nodes, or whether a changed descriptor must be a new kind | |
whether | |
whether | |
labels beyond CIDs, above | |
the exact | |
whether migrated path-scoped WRITER grants should be dropped outright (the roadmap's "trashed") rather than kept as | |
whether derived grants and Snapshots should be re-signed by the owner (step 4) and, if so, whether the app does it silently or asks | |
how the two CID hashes for identical bytes (BLAKE2b in the daemon, SHA-256 in the SDK) should be unified when Node heads are compared, since a migrated Ref may name either | |
comments on a migrated document whose path was redirected before migration | |
whether a client should offer to leave a redirect by default on every rename, or only when the old path has known inbound links | |
whether a Node blob should be allowed to name a parent in another space to express "mounted" content, or whether redirects are enough | |
the retention period of the disclosure ledger, and whether public serves are logged at all or only counted | |
whether | |
the exact shape of the encryption layer | |
should a kind be allowed to declare an automatic merge for concurrent Snapshots, and in what language? The core kinds do not need it | |
whether the client should require a writer to acknowledge concurrent placement before publishing a merging Node blob, or merge silently with the lowest-CID rule | |
whether the id should instead be derived so that an account can keep several policies | |
whether derived index records for migrated HM24 blobs should be materialised as real signed blobs by the owner's device once it comes online, so that a Stem-only peer can hold a migrated space without the HM24 originals | |
how a daemon learns about a Kind descriptor it has never seen (a third-party kind) | |
what d2 should do with blobs it fetched for B between coming online and reloading the policy; the lean is to keep them until the next collection pass | |
the retention window and whether a site should refuse to collect anything it ever served |
Do you like what you are reading? Subscribe to receive updates.
Unsubscribe anytime