Metadata-Version: 2.4
Name: tibet-continuityd
Version: 0.6.1
Summary: Continuity daemon and sealed handoff tool — watch, sniff, verify, triage, reseal, police, and send continuity-bearing TBZ objects across local and cross-host lanes.
Author-email: Jasper van de Meent <info@humotica.com>, Root AI <root_idd@humotica.nl>, Codex <codex@humotica.nl>
License: MIT
Project-URL: Homepage, https://humotica.com
Project-URL: Spec, https://github.com/Humotica/tibet-continuityd/blob/main/SPEC.md
Keywords: tibet,continuity,daemon,audit,trust,inotify,libmagic,icc,tbz,ssm,phantom,distributed-continuity-os,humotica
Classifier: Development Status :: 4 - Beta
Classifier: Intended Audience :: System Administrators
Classifier: Intended Audience :: Information Technology
Classifier: License :: OSI Approved :: MIT License
Classifier: Operating System :: POSIX :: Linux
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: Python :: 3.10
Classifier: Programming Language :: Python :: 3.11
Classifier: Programming Language :: Python :: 3.12
Classifier: Programming Language :: Python :: 3.13
Classifier: Topic :: Security :: Cryptography
Classifier: Topic :: System :: Monitoring
Classifier: Topic :: System :: Logging
Requires-Python: >=3.10
Description-Content-Type: text/markdown
Provides-Extra: verify
Requires-Dist: tibet-drop>=0.1.0; extra == "verify"
Provides-Extra: phantom
Requires-Dist: tibet-phantom[icc]>=0.2.1; extra == "phantom"
Provides-Extra: mux
Requires-Dist: tibet-mux>=1.0.1; extra == "mux"
Provides-Extra: full
Requires-Dist: tibet-drop>=0.1.0; extra == "full"
Requires-Dist: tibet-phantom[icc]>=0.2.1; extra == "full"
Requires-Dist: cryptography>=41.0; extra == "full"
Requires-Dist: cbor2>=5.4; extra == "full"

# tibet-continuityd

> **Continuous integrity daemon and sealed handoff tool for continuity-native systems.**

`tibet-continuityd` is the resident trust and continuity guardian of the
TIBET stack.

It watches an inbox, sniffs what arrived, classifies trust and mismatch,
optionally verifies and forks sealed objects, reseals trusted forward
state, emits audit records, and can now also **send** and **ack**
sealed envelopes across hosts.

In short:

- **daemon**
  - watch, sniff, verify, classify, triage, seal, police
- **CLI**
  - pack, send, and acknowledge sealed continuity objects across hosts
- **discipline**
  - name is hint, content is truth, arrival is event

## Why it exists

Modern agentic and stateful systems fail when they silently trust:

- filenames
- resumed state
- imported sessions
- unpacked blobs
- unexpected arrivals
- stale or disguised handoff material

`tibet-continuityd` exists to put a resident gate in front of those
arrivals.

It turns:

- file arrival
- cross-host handoff
- resumed state
- imported continuity material

into something that can be:

- sniffed
- verified
- classified
- quarantined
- triaged
- resealed
- audited

## Core model

```
Arrival → Sniff → Classify → Verify/Fork → Trust → Seal → Police
```

The daemon treats every arrival as a meaningful event.

It does **not** assume:

- extension is truthful
- resumed state is safe
- transport success implies continuity legitimacy

## Design axiom

> **Name is hint. Content is truth. Arrival is event.**

## What it does today

### Daemon behavior

- watches inbox lanes for arrivals
- recognizes TBZ/ICC-style sealed bundles via magic bytes
- detects disguised payloads and extension/content mismatch
- classifies arrivals into trust/triage/quarantine/reject paths
- emits audit JSONL suitable for machine analysis and operator review
- supports:
  - `passive`
  - `active`
  - `strict`
  modes
- supports:
  - coalescing
  - verify-fork
  - trust-kernel handoff
  - reseal/outbox
  - police scan for unpacked drift
  - backpressure monitoring

### CLI behavior

The `tcd` CLI now supports:

- `tcd run`
  - run the daemon
- `tcd send FILE --to HOST:PATH`
  - seal and send over `scp`
- `tcd send FILE --to jis:org:service@host`
  - convention-based identity-bound routing
- `tcd send FILE --transport http --to http://host:port`
  - sealed HTTP inbox delivery to a peer listener
- `tcd send FILE --transport http --to jis:org:service@host`
  - JIS-style destination resolution directly into an HTTP inbox URL
- `tcd ack REF --to TARGET`
  - sealed receipt/acknowledgement envelope for a prior object

This means `tibet-continuityd` is no longer only a passive inbox daemon.

It is also becoming the first practical **post-email sealed handoff
primitive** in the stack.

## Current feature surface

### Watch

- inbox watcher on Linux
- arrival detection
- lane-local event flow

### Sniff

- TBZ magic-byte detection
- sealed bundle recognition independent of extension
- detection of:
  - executable
  - PDF
  - JSON text
  - empty payloads
  - disguised vendor-style names

### Classify

- `trusted-candidate`
- `triage-disguised`
- `reseal-candidate`
- `quarantine`
- `reject`

### Verify / Fork

- optional cryptographic verify path
- forward-only continuation discipline
- trusted fork semantics for admitted sealed material

### Trust / Seal

- optional trust-kernel integration
- reseal to outbox
- forward continuity discipline instead of silent mutation

### Police

- periodic scan for unpacked or policy-breaking material
- age-based alerting for lingering unsafe state

### Backpressure

- queue pressure observation
- low/high watermark monitoring
- intended as part of larger lane health discipline

### Send

- pack local file or directory as sealed envelope
- preserve semantic surface fields
- deliver through:
  - `scp`
  - `http`
- optionally resolve JIS-style destinations before delivery
- optionally sign the HTTP request itself
- target peer daemon processes arrival through the same watcher/sniff
  pipeline as local files

### ACK

- create a small sealed receipt object referencing a prior bundle name or
  short ID
- default to a low-priority/background semantic surface
- deliver over the same transport paths as `send`
- make roundtrip proof and receipt flow continuity-native instead of
  out-of-band

## Install

```bash
pip install tibet-continuityd
```

Optional stacks:

```bash
pip install "tibet-continuityd[verify]"
pip install "tibet-continuityd[phantom]"
pip install "tibet-continuityd[full]"
```

## Quick start — local daemon

```bash
TIBET_CONTINUITYD_INBOX=/tmp/tibet/inbox \
TIBET_CONTINUITYD_QUARANTINE=/tmp/tibet/quarantine \
TIBET_CONTINUITYD_TRIAGE=/tmp/tibet/triage \
TIBET_CONTINUITYD_AUDIT=/tmp/tibet/continuityd-audit.jsonl \
tcd run
```

Drop a TBZ-prefixed file into the inbox:

```bash
printf 'TBZ\x01\x00\x00\x00' > /tmp/tibet/inbox/sample.claude.tza
```

The daemon will emit an arrival and sniff decision.

## Quick start — send over SCP

```bash
tcd send hello.txt \
  --to root@target-host:/var/lib/tibet/inbox \
  --surface-context first-real-cross-host-push \
  --surface-profile claude \
  --surface-priority normal
```

What happens:

1. local file is packed as a sealed `.tza` envelope
2. Ed25519 signing is applied through the TIBET drop toolchain
3. `scp` delivers the bundle to the peer inbox
4. peer `continuityd` sees the arrival and runs the normal intake flow

## Quick start — send over HTTP

Start the peer daemon with an HTTP inbox listener:

```bash
TIBET_CONTINUITYD_INBOX=/tmp/tibet/inbox \
TIBET_CONTINUITYD_AUDIT=/tmp/tibet/audit.jsonl \
TIBET_CONTINUITYD_HTTP_PORT=8443 \
tcd run
```

Then send:

```bash
tcd send hello.txt \
  --transport http \
  --to http://target-host:8443 \
  --surface-context http-proof \
  --surface-profile claude \
  --surface-priority normal
```

Flow:

1. pack sealed envelope
2. HTTP `POST /inbox/<filename>`
3. peer HTTP inbox writes to the daemon inbox
4. inotify watcher sees the new object
5. sniff/classify path runs normally

Note:

- the HTTP inbox listener is transport-friendly, but in this release the
  HTTP layer itself is not the trust source
- the sealed bundle remains the integrity-bearing object

When enabled, HTTP delivery can also carry:

- a signed transport auth header
- a sender DID claim header
- optional AINS-based public key pin verification on the receiving side

## Quick start — identity-style target

Convention-based target form:

```bash
tcd send hello.txt --to jis:humotica:continuityd@p520
```

Current behavior:

- resolves to default SSH user + default inbox path by convention
- can optionally consult the AINS resolve API
- is a stepping stone toward richer identity-bound routing

HTTP-aware identity target:

```bash
tcd send hello.txt \
  --transport http \
  --to jis:humotica:continuityd@192.168.4.76
```

Current behavior:

- resolves the JIS-style destination into an HTTP inbox URL
- keeps the sealed object format unchanged
- can attach a signed HTTP auth header
- can attach a sender DID claim header
- degrades gracefully if no AINS record exists

## Quick start — ACK / roundtrip receipt

```bash
tcd ack "2026-05-11.v058-roundtrip.claude.normal.tza" \
  --transport http \
  --to http://target-host:8443 \
  --note "delivered from laptop, ack from laptop"
```

What happens:

1. a small ACK payload is created locally
2. it is packed as a sealed `.tza` envelope
3. an `ack-of-<shortid>` semantic surface is produced
4. it is delivered through the same transport layer as `send`
5. peer `continuityd` receives it as a normal arrival event

This makes the receipt itself a continuity-bearing object.

## Modes

### `passive`

- observe
- classify
- audit
- advise

### `active`

- verify/fork/seal behavior enabled where configured
- operational continuity handling

### `strict`

- stronger policy expectations
- suited for sealed-only or higher-trust lanes

## Disposition table

| Intake class | Trigger | Disposition |
|---|---|---|
| `sealed-tbz` | TBZ magic + recognized surface | `trusted-candidate` |
| `sealed-tbz-no-ext` | TBZ magic, no/unknown extension | `trusted-candidate` |
| `disguised` | vendor-like name, no TBZ magic | `triage-disguised` |
| `json-text` | raw JSON state in sealed-oriented lane | `reseal-candidate` |
| `executable` | ELF / PE / executable signature | `quarantine` |
| `pdf` | PDF magic | `reject` |
| `unknown` | everything else | `quarantine` |
| `empty` | zero-byte file | `reject` |

## Proven proofs so far

### Portable evaluation

The external evaluation kit proves:

- preflight passes on fresh hosts
- conformance vectors classify correctly
- mini-pipeline runs end-to-end

### Dual-node host simulation

The dual-node lab proves:

- node A to node B handoff shape
- `sniff → verify-fork → seal` on both sides
- same stage/disposition pattern despite reseal

### Real cross-host SCP handoff

Proven:

- real host A packs and sends
- real host B receives and sniffs
- sealed bundle survives host boundary
- older peer daemon versions still recognize the container by magic bytes

### Real HTTP transport handoff

Proven:

- `tcd send --transport http --to http://host:port`
- peer HTTP inbox listener receives the bytes
- writes them into the inbox
- daemon watcher processes the arrival normally

This is the first practical proof that sealed continuity objects can be
carried through a simple HTTP ingress without changing the continuity
discipline.

### Identity-bound HTTP handoff

Proven:

- `tcd send --transport http --to jis:...`
- JIS-style destination resolution to HTTP inbox URL
- signed transport request
- DID sender claim header
- graceful AINS no-record fallback
- normal daemon arrival discipline after ingress

This shows that identity-bound transport can already happen without
depending on a future mux lane.

### ACK roundtrip primitive

Proven:

- `tcd ack <bundle-name> --to <target>`
- sealed ACK envelope generation
- delivery over the same transport carriers as `send`
- receipt itself becomes a continuity-bearing arrival event

## Operational paths

The package now has three practical deployment/use surfaces:

- **package runtime**
  - `tcd run`
- **cross-host push**
  - `tcd send`
- **cross-host receipt**
  - `tcd ack`
- **reference deployment kit**
  - portable eval
  - systemd appliance
  - dual-node lab

Reference deployment kit:

- [`reference-deployment/README.md`](reference-deployment/README.md)

## FHS and first-run note

Production defaults are FHS-oriented:

- `/var/lib/tibet/...`
- `/var/log/tibet/...`

For laptop or peer-eval use, set user-writable env vars explicitly.

That split is intentional:

- production appliance defaults
- local/peer override paths

## Why this is different from plain file transfer

`scp`, HTTP, or future mux transport are not the core innovation by
themselves.

The important thing is that what moves is a:

- sealed
- signed
- continuity-bearing
- sniffable
- classifiable
- triageable

object.

Transport is replaceable.

Continuity discipline is the point.

This now also applies to receipts:

- an ACK is not just a side message
- it is also a sealed continuity object
- which can be sniffed, classified, audited, and handled like any other
  arrival

## Related stack pieces

- `tibet-drop`
  - pack/verify/seal primitives
- `tibet-phantom`
  - resumable state and ICC bridge
- `tibet-mux`
  - future unified transport lane
- `tibet-overlay`
  - identity-oriented routing substrate
- `tibet-triage`
  - human-visible escalation surface

## Project direction

Near-term direction includes:

- richer identity-bound routing via AINS/JIS
- mux-backed transport as an alternative carrier
- stronger mirrored surface checking
- safer first-run ergonomics for non-root hosts
- deeper causal record integration

## License

MIT — Humotica + Root AI + Codex (2026)
