aset-network-python-sqlite

Non-normative Internet-capable reference implementation extension for the ASET Network Extension. It extends by composition the exact published aset-python-sqlite v0.1.0 reference implementation; it does not fork or reimplement Seed resolution semantics.

• NORMATIVE=false
• PRODUCTION_READY=false
• Profile: ASET-NETWORK-PYTHON-SQLITE-HTTPS-REFERENCE-V1
• Extension relation: ADDITIVE_IMPLEMENTATION_EXTENSION
• Base implementation: aset-python-sqlite v0.1.0
• Network target: ASET-NETWORK-EXTENSION@0.1.0-alpha.2
• Seed target: ASET-SEED-COMPATIBILITY-STANDARD@seed-0.3.0-alpha.3
• Transport profile: ASET-NETWORK-PYSQL-HTTPS-ED25519-V1
• Implementation precedence: none

Layering

NORMATIVE                              NON-NORMATIVE REFERENCE

ASET Seed ---------------------------> aset-python-sqlite
   |                                        |
   | extended by                            | extended by composition
   v                                        v
ASET Network Extension -------------> aset-network-python-sqlite

aset-network-python-sqlite imports the exact base implementation and delegates every target-local Seed cycle to DurableSeedRuntime. Network-specific code may create Seed requests, submit a local resolution and observe the result, but it may not replace Seed ALLOW/BLOCK semantics.

Exact upstream bindings

The release profile pins three independently verifiable upstream identities:

ASET Seed
  seed-0.3.0-alpha.3
  commit 633c130187b2a2bb42f24cfd66662d475de385d2
  canon sha256:c5d48a418466ea7a60fccb7161adbd5ad568174bbc9a28fc03fd7e6e77955d31

aset-python-sqlite
  v0.1.0
  commit daee6da46636ce4996cf1b880d1adbb6b36e1996
  tree   3ba234337d1c220df349d1c90e34928fcc3d785a

ASET Network Extension
  v0.1.0-alpha.2
  commit e15c88e060e1b2c129e97a003fdc5385e1b63a71
  tree   a0cef84d783c9edbaf10083356495955db1d7beb
  canon  sha256:64d718812cea7768f21b288fc525298516d9150ecd790016ffb6513bfe68c1c1

The Network binding also pins the mechanically proved canon-refinement evidence (3 recorded obligations) and Network-to-Seed refinement evidence (261 recorded obligations). Those counts are release evidence, not universal semantic constants.

Strict verification

A releasable candidate must pass the same style of assurance used by aset-python-sqlite, extended for the second normative layer and the real network surface:

exact Seed Conformance Kit
        +
exact published aset-python-sqlite source + wheel
        +
exact Network Extension release snapshot
        |
        v
cross-binding verification
        |
        +--> base aset-python-sqlite complete profile gate
        +--> Network 18/18 external conformance
        +--> implementation tests + traceability + manifest
        +--> deterministic source archive build
        +--> wheel build + black-box audit
        +--> real two-container HTTPS/Ed25519 gate
        v
NETWORK_PYSQL_PROFILE_GATE=PASS

The release gate refuses a different Seed standard, base release, Network canon, formal relation, Network proof evidence, or database binding.

Real network semantics

One Docker container represents one sovereign Context. Every container has its own local Network SQLite database and its own directory of target-local aset-python-sqlite databases. There is no federation-wide SQL database.

The transport profile uses HTTPS/TLS plus an Ed25519 signature over the canonical message. Peers are explicit ContextID -> URL + public key bindings. Inbox message IDs are persistent replay keys and failed sends remain in a durable local outbox.

The semantic flow is deliberately fail-closed:

source export
  -> signed HTTPS delivery
  -> target OBSERVE_IMPORT = UNKNOWN/BLOCKED
  -> target-local aset-python-sqlite Seed cycle
  -> local ALLOW or BLOCK
  -> Network ACCEPT/ALLOW or DENY/BLOCKED

Remote delivery never transfers Authority and never produces local ALLOW by itself. Even after a local ACCEPT/ALLOW, this reference implementation returns effect_executed=false.

Two-node demo

Generate ephemeral demo TLS/signing material and start two Contexts:

python tools/generate_demo_material.py
docker compose -f examples/two-node/compose.yml up --build

For an automated end-to-end verification of the real TLS path:

python tools/docker_two_node_gate.py

The implementation intentionally does not claim ASET-NETWORK-LIVENESS-V1; retry is durable but explicit, and target-local resolution remains a local decision.

Guided web demonstrator

A separate non-normative UI can drive the same real two-Context deployment without importing the reference implementation packages or mounting either Context database/private key:

python tools/generate_demo_material.py
docker compose -f examples/demonstrator/compose.yml up --build

Open http://localhost:8080. The demonstrator exercises four guided paths through the real HTTPS APIs: local ALLOW -> ACCEPT, local BLOCK -> DENY, exact-message replay, and forged/tampered transport rejection. Its machine-readable boundary is examples/demonstrator/DEMONSTRATOR_PROFILE.json: normative=false, authority=false, canonical_state=false, conformance_oracle=false, and private_key_access=false.