Skip to content

RFC-0001: Scopes & visibility — who may see a memory (format 1.2 proposal) #11

Open

Description

@Krivoblotsky

Summary

The format says where a memory belongs (contextID → context records, nested via parentID) and how sensitive it is (sensitivity), but not yet who may see it — a channel, one person, or a group. Vendor visibility settings survive a round-trip only as opaque ext/metadata: lossless, but not meaningful to a receiver, so a cross-vendor import can silently widen the audience of a private memory. This is the one layer of the format that still has no shared meaning (it is also the layer Stan Tyan's portability checklist grades hardest).

Proposal (short form — full text in the RFC document)

An optional visibility object — { "level": private | group | shared | public, "principals": ["user:…", "group:…", "channel:…"] } — on context records (scope defaults) and on individual records (overrides). Principals are opaque labels, not accounts: the format never resolves them; a receiver maps what it can and treats the rest default-deny. Most-restrictive-wins on merge; receivers MUST preserve it verbatim and SHOULD honor it. Minor bump to format 1.2.0; every field optional, so 1.0/1.1 bundles stay valid.

RFC document: Spec/rfcs/0001-scopes-and-visibility.md (PR linked below).

What we'd like input on

  1. Principal identifiers — opaque prefixed strings (user:, group:, channel:, space:, agent:) vs. recommending W3C DIDs for the user type.
  2. The default for bundles that carry no visibility at all: unspecified → receiver applies its own default, and MUST NOT widen beyond private-to-importer without consent (proposed) vs. private.
  3. Whether shared should require a scope principal (channel:/space:), or may be bare.
  4. Prerequisite: foreign-field carriage (ext) today exists only on episode; for visibility on other kinds to survive 1.0/1.1 readers losslessly, ext must extend to every record kind (candidate RFC-0002). Objections?

Process

Comment period until 2026-10-05, then decision by lazy consensus per GOVERNANCE. Accepted → implemented in both reference SDKs with a shared fixture before format 1.2.0 is stamped.

Activity

  1. added
    enhancementNew feature or request
    rfcRequest for Comments — a proposed change to the format/spec, open for discussion
    on Sep 14, 2026
  2. Krivoblotsky commented on Sep 14, 2026

    @Krivoblotsky
    ContributorAuthor

    RFC text: #12 (Python repo) · MacPaw/portable-memory-swift#13 (Swift repo — same bytes). Read the rendered document at Spec/rfcs/0001-scopes-and-visibility.md on the rfc/scopes-visibility branch until the PRs merge.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestrfcRequest for Comments — a proposed change to the format/spec, open for discussion

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions