wiki/concepts/looptloop

LOOPtLOOP

wiki/concepts/looptloop/index.md

Rendered from markdown source. Open raw source on GitHub.

LOOPtLOOP

Working definition: a lightweight witness substrate for hash-only private authorization and live provenance loops.

This concept appears across the CICP access rail, WitnessKey, the archived LOOPtLOOP platform companions, and the public looptloop.online surface. It is the ingredient that turns consent, witness, and provenance into an inspectable public surface without exposing private payloads.

The public site makes the operating claim explicit: private authorization can be witnessed by hash, and provenance can be made visible in recorded media. That is the core semantic role here. LOOPtLOOP is not a generic identity system; it is a bounded witness and provenance layer with a narrow public contract.

Machine-Readable Surface

  • llms.txt
  • Public API base: https://api.looptloop.online/v0
  • Public repository: https://github.com/bobrs/LOOPtLOOP
  • Public pages: /, /witnessmark/, /verify/, /provenance/, /provenance/stage/, /provenance/verify/
  • Public license package: /LICENSE, /IPOL.md
  • The homepage embeds a JSON manifest and JSON-LD API metadata for machine consumers

Core Claims

  • Private payload stays private.
  • Witness should verify the hash, consent envelope, timing, and signature-bound receipt.
  • Provenance can be visible without claiming total truth or legal identity.
  • Status must stay explicit and bounded.

Mechanisms

  • Hash private authorization content locally.
  • Send only sha256: payload hashes and consent-envelope metadata for authorization witness flows.
  • Create, accept, reject, and verify authorization offers as explicit state transitions.
  • Use provenance loops and rotating codes to show that a recording participated in live witness.

Implications

  • A public service can witness consent without becoming a data sink.
  • Verification is a bounded act, not a universal claim.
  • The same substrate can support witness receipts, provenance overlays, and consent-aware mechanics.

Dependencies

Open Questions

  • How far should witness receipts extend before they become generalized identity?
  • Which provenance claims belong in the public surface, and which should remain local?
  • What future loop-state mechanics are compatible with the current public contract?
  • How should machine consumers distinguish bounded witness from stronger claims?

Related Artifacts

Related Pages

Notes

  • This is a concept page, not a canon claim.
  • Treat LOOPtLOOP as a prime ingredient when witness, consent, and provenance need a public, machine-readable edge.
  • Keep it distinct from broader identity, billing, or platform claims unless the public contract expands.