Correct TGP documentation and remove legal framing

README.md

@@ -53,11 +53,13 @@ An operator can subscribe to an IPNS name and let TruthGate resolve it on a sche
 
 ### TruthGate Pointer protocol
 
-TruthGate supports the **TruthGate Pointer protocol (TGP)**: a deliberately small convention in which an IPNS identity publishes a tiny `tgp.json` file that points to one current immutable CID.
+TruthGate supports the **TruthGate Pointer protocol (TGP)**: a small structured layer in which an IPNS identity publishes a lightweight control bundle whose `tgp.json` points to the current immutable application CID.
 
-TGP keeps the mutable layer light, makes freshness checks inexpensive, allows the current target to be cached normally, and supports clear unpin-and-garbage-collection workflows when content is removed. It intentionally does not publish a browsable history through the pointer.
+TGP deliberately trades one additional resolution hop for a predictable machine-readable pointer, inexpensive freshness checks, normal immutable caching of the application, a browser-capable `index.html` fallback, and a stable place for future routing behavior. The public IPNS location can guide IPFS-aware browsers, ordinary browsers, and fallback routes without making the full application DAG serve as the control record.
 
-TGP is an operational protocol, not a legal shield. It cannot erase copies retained by third parties, prevent archiving, or make an operator immune from legal obligations. See the [TGP documentation](docs/tgp/index.md) for the specification, rationale, gateway behavior, and legal limitations.
+IPNS can already move to a new CID, and Kubo can already unpin and garbage-collect old content. TGP does not create those capabilities. Its retention benefit is that it gives TruthGate a consistent boundary around which current-only, bounded-history, selected-release, or archival policies can be expressed and automated. Updating a pointer alone does not delete older CIDs or copies retained by other nodes.
+
+See the [TGP documentation](docs/tgp/index.md) for the rationale, wire specification, client resolution, publisher workflow, and gateway behavior.
 
 ### Static-site publishing
 
@@ -135,7 +137,7 @@ The documentation describes the current defaults and their limits without preten
 - TruthGate does not replace IPFS or Kubo.
 - TruthGate is not a blockchain or a new content network.
 - TruthGate does not make third-party copies of a CID disappear.
-- TGP does not provide legal immunity or guaranteed global deletion.
+- TGP does not make old CIDs globally revocable or replace Kubo pin and garbage-collection operations.
 - A mapped HTTPS domain is still an HTTP delivery path; the content remains independently addressable by CID.
 - TruthGate is not intended to expose Kubo's unrestricted local RPC interface directly to anonymous internet users.
 

docs/tgp/faq.md

@@ -2,11 +2,31 @@
 
 ## Why not point IPNS directly at the full site?
 
-You can. TGP is useful when clients and gateways benefit from a tiny, explicit current-pointer document and a narrow mutable contract.
+You can. Direct IPNS is valid and already supports moving the same identity to a new CID.
 
-## Does TGP delete old content?
+TGP adds a small, predictable control bundle for clients, gateways, browser fallback behavior, retention-policy automation, and future routing metadata. It is a trade: one additional content-resolution hop for those capabilities.
 
-No. It supports updating the pointer, unpinning locally, and garbage collecting local blocks. Other nodes may retain copies.
+## Does TGP make old content removable?
+
+Not by itself. Direct IPNS publishers can already update the name, unpin old content, remove retaining references, and let Kubo garbage-collect eligible local blocks.
+
+TGP gives TruthGate a consistent boundary around which those retention operations can be configured and automated. The actual removal work still belongs to Kubo and the publishing implementation.
+
+## Does updating TGP delete old content?
+
+No. Updating the pointer only changes the advertised current target. Old CIDs may remain pinned, referenced, cached, archived, or retained by other nodes.
+
+## Why make retention explicit?
+
+Different applications need different policies:
+
+- retain only the current deployment;
+- keep the last few deployments;
+- preserve selected tagged releases;
+- maintain a separate complete archive;
+- keep operational audit records without publishing a history catalog.
+
+TGP does not force one choice. It provides a stable place for TruthGate to express and enforce the selected lifecycle.
 
 ## Is `tgp` version `1` or `1.1`?
 
@@ -22,20 +42,16 @@ Yes. V1 clients must ignore unknown fields.
 
 ## Can `current` be an HTTP URL?
 
-No. V1 defines a CID or `/ipfs/` path. Allowing arbitrary URLs would create redirect and trust problems.
+No. V1 defines a CID or `/ipfs/` path. Allowing arbitrary URLs would create redirect and trust problems. Browser routing belongs in the optional helper or a future explicitly versioned extension.
 
 ## Is `index.html` required?
 
-No. It is an optional browser helper.
-
-## Is `legal.md` required?
-
-No. It is optional and informational. Its presence must not block resolution.
+No. It is an optional browser helper. Machine clients resolve `tgp.json` directly.
 
 ## Can I keep deployment history?
 
-Yes, but TGP does not define a public history list. Keep audit history outside the pointer.
+Yes. TGP does not define a public history list. Keep history in a separate operator database, Git repository, logging system, or archive.
 
 ## Does it work with IPFS Companion?
 
-A browser redirect to `/ipfs/<cid>` can be handled by an IPFS-aware browser environment or ordinary gateway routing.
+Yes. A browser helper can detect an IPFS-aware environment and navigate to a direct `/ipfs/<current>` destination that Companion or another integration can handle.

docs/tgp/gateway-behavior.md

@@ -8,10 +8,10 @@ For a TGP-backed IPNS host:
 
 1. resolve and validate `tgp.json`;
 2. identify the current target;
-3. serve or redirect to that target;
+3. serve, embed, or redirect to that target according to gateway policy;
 4. use short caching for the pointer;
 5. use normal immutable caching for the target;
-6. expose the optional legal notice;
+6. support a browser fallback when the TGP root provides one;
 7. reject malformed pointers rather than guessing.
 
 ## Current-target restriction
@@ -20,18 +20,27 @@ A gateway MAY restrict the TGP host to the CID advertised by `current`.
 
 This prevents the same host from becoming a general-purpose path to unrelated or previously advertised CIDs.
 
-It does not prevent users from fetching a known old CID through another gateway or node.
+It does not prevent users from fetching a known old CID through another gateway or node, and it does not remove that CID from any repository.
 
 ## Browser fallback
 
-An optional `index.html` can fetch `tgp.json` and redirect.
+An optional `index.html` can fetch `tgp.json` and choose an appropriate destination.
+
+A browser helper may:
+
+- detect an IPFS-aware browser environment;
+- navigate directly to `/ipfs/<current>`;
+- try a configured Web2 destination;
+- use a gateway or redirect document;
+- provide direct recovery links when extensions or blockers interfere.
 
 The fallback should:
 
-- avoid arbitrary URL redirects;
+- avoid arbitrary unvalidated URL redirects;
 - identify stale fallback behavior;
 - preserve subpaths only when deliberately specified;
-- fail clearly when the pointer is invalid.
+- fail clearly when the pointer is invalid;
+- remain optional for machine clients.
 
 ## Caches
 

docs/tgp/index.md

@@ -1,43 +1,58 @@
 # TruthGate Pointer protocol
 
-The **TruthGate Pointer protocol (TGP)** is a small convention for using an IPNS identity to advertise one current immutable IPFS target.
+The **TruthGate Pointer protocol (TGP)** is a small convention for publishing a structured control bundle through an IPNS identity. Its required `tgp.json` file identifies one current immutable IPFS target.
 
-An IPNS root contains a required `tgp.json` file. Clients read the pointer and then load the CID in `current`.
+```text
+IPNS identity
+      │
+      ▼
+TGP control bundle
+├── tgp.json      required machine-readable pointer
+└── index.html    optional browser resolver and fallback
+      │
+      ▼
+current application CID
+```
 
 ```json
 {
   "tgp": 1,
   "ts": "2026-07-25T17:00:00Z",
   "current": "bafy...",
-  "domainName": "example.com",
-  "legal": "/legal.md"
+  "domainName": "example.com"
 }
 ```
 
-## Why it matters
+## Why use an extra hop?
+
+IPNS can already point directly at an application CID. TGP deliberately adds one content-resolution hop to gain a stable, predictable control layer.
+
+That layer supports:
+
+- a tiny document for inexpensive freshness checks;
+- an explicit current application target;
+- normal immutable caching after resolution;
+- a browser-capable fallback location at the IPNS root;
+- consistent behavior for IPFS-aware and ordinary browsers;
+- gateway policies based on a known pointer contract;
+- explicit current-only, bounded-history, selected-release, or archival retention policies;
+- room for future routing and fallback metadata without changing the application DAG.
 
-TGP keeps the mutable object tiny while the application remains immutable and cacheable.
+## Relationship to IPNS and Kubo
 
-It supports:
+TGP does not replace IPNS. IPNS supplies the signed mutable identity, sequence handling, routing, and name resolution.
 
-- inexpensive freshness checks;
-- one current target;
-- simple client resolution;
-- ordinary caching of the immutable CID;
-- unpin and garbage-collection workflows;
-- gateway policies that only serve the advertised target;
-- clear separation between current deployment and off-pointer audit history.
+TGP also does not create deletion or garbage collection. A direct IPNS publisher can already update the name, remove old pins and references, and allow Kubo to garbage-collect eligible local blocks.
 
-## What it does not do
+TGP's retention benefit is organizational: TruthGate receives a consistent boundary around which retention policy and deployment lifecycle can be expressed, automated, monitored, and verified independently from the application content itself.
 
-TGP cannot:
+## Technical limits
 
-- erase blocks held by another node;
-- revoke a CID globally;
-- prevent caches, mirrors, archives, screenshots, or copies;
-- guarantee that deleted content becomes undiscoverable;
-- provide legal immunity;
-- replace legal advice or an operator's compliance obligations.
+- Updating `tgp.json` does not delete an older CID.
+- Removing local content requires handling every pin and reference that retains it.
+- Other nodes, gateways, caches, mirrors, or users may retain copies independently.
+- TGP does not make CIDs globally revocable.
+- The pointer bundle is an additional IPFS object and resolution hop.
 
 ## Documentation
 
@@ -46,8 +61,6 @@ TGP cannot:
 - [Client resolution](client-resolution.md)
 - [Publisher workflow](publisher-workflow.md)
 - [Gateway behavior](gateway-behavior.md)
-- [Legal considerations](legal-considerations.md)
-- [Legal-notice template](legal-notice-template.md)
 - [FAQ](faq.md)
 
 ## Version terminology