aetheridentity 2.0.0__tar.gz

aetheridentity-2.0.0/AUTHORS.md

@@ -0,0 +1,33 @@
+# Authors
+
+## Samir Baladi
+
+**Role:** Author, researcher
+**Affiliation:** Ronin Institute / Rite of Renaissance
+**Research area:** Interdisciplinary AI Research
+**ORCID:** [0009-0003-8903-0029](https://orcid.org/0009-0003-8903-0029)
+**Email:** [gitdeeper@gmail.com](mailto:gitdeeper@gmail.com)
+
+Samir Baladi is the author of the Aether family of preprints, including
+AetherGit, AetherFlow, AetherProof, AetherMesh, AetherGovern, AetherRuntime,
+AetherOrchestrate, and the present candidate, AetherIdentity.
+
+The Aether family investigates functional dimensions of coordinated agentic
+software engineering. Each preprint adopts a falsification-first methodology:
+failure conditions are stated before the candidate is described.
+
+## Versions
+
+- **v0.1.0** — Architectural Hypothesis (original draft)
+- **v1.0.0** — Formal Architecture Proposal (33-page paper)
+- **v2.0.0** — Experimental Reference Implementation (this release)
+
+## How to contribute
+
+**For the paper (v1.0.0):** independent review of F1–F4, literature pointers,
+bibliographic corrections.
+
+**For the implementation (v2.0.0):** bug reports, coverage improvements,
+new tests for the deferred scenarios (S2–S5).
+
+See `CONTRIBUTING.md` for details.

aetheridentity-2.0.0/CHANGELOG.md

@@ -0,0 +1,66 @@
+# Changelog
+
+All notable changes to AetherIdentity are documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
+and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+## [2.0.0] — 2026-11-11
+
+**Experimental Reference Implementation.**
+
+### Added
+
+- Python package `aetheridentity` (8 modules under `src/aetheridentity/`).
+- L1 — Identity (`identity.py`).
+- L2 — Continuity (`continuity.py`).
+- L3 — Reputation (`reputation.py`).
+- L4 — Sybil resistance (`sybil.py`).
+- L5 — Delegation (`delegation.py`).
+- Simulator (`simulator.py`).
+- Abstract Signer with `FakeSigner` and `Ed25519Signer` (`signer.py`).
+- Record types and canonical JSON serialization (`records.py`).
+- 35 tests (93% coverage).
+- S1 — Bootstrap (P2) executed.
+- S6 — Governance overlap (F3) executed.
+- `SPECIFICATION.md`, `INVARIANTS.md`, `TESTS.md`, `ROADMAP_v2.md`.
+- `REPORTS/v2.0.0/` (test report, evaluation report, amendments, phase log, stop log).
+- `RELEASE/RELEASE.md`.
+
+### Changed
+
+- README updated to reflect v2.0.0 (was v0.1.0).
+- Version series fixed: v0.1.0 (hypothesis), v1.0.0 (paper), v2.0.0 (implementation).
+
+### Not implemented
+
+- Network transport, consensus.
+- AetherMesh integration.
+- Fork resolution.
+- Recovery after total key loss.
+- Single-instance enforcement.
+- Byzantine behavior.
+
+### Deferred
+
+- S2, S3, S4, S5 (out of scope for v2.0.0).
+- F1, F2, F4, F5 (not evaluated in v2.0.0).
+- Machine-checked proofs of P1 and P2.
+
+## [1.0.0] — 2026-11-10
+
+**Formal Architecture Proposal.**
+
+- 33-page paper published on Zenodo and Figshare.
+- OSF Preregistration for v2.0.0 evaluation plan.
+- 5 failure conditions (F1–F5), 6 requirements (R1–R6).
+- 4 formal definitions, 2 propositions (proof sketches).
+- 5 identity layers (L1–L5).
+- 9 metrics, 5 baselines, 6 scenarios, 7 threats, 20 open questions.
+
+## [0.1.0] — 2026-11-09
+
+**Architectural Hypothesis (original draft).**
+
+- Initial falsification-first methodology.
+- Draft P1 and P2.

aetheridentity-2.0.0/CITATION.cff

@@ -0,0 +1,62 @@
+cff-version: 1.2.0
+message: "If you use this work, please cite it as below."
+type: software
+title: "AetherIdentity: A Falsification-First Investigation of Decentralized Agent Identity in the Aether Family"
+version: 2.0.0
+identifiers:
+  - type: doi
+    value: 10.5281/zenodo.24102739
+    description: "Zenodo DOI (paper v1.0.0, software v2.0.0)"
+  - type: doi
+    value: 10.6084/m9.figshare.34981891
+    description: "Figshare preprint DOI"
+  - type: doi
+    value: 10.17605/OSF.IO/B6AEN
+    description: "OSF Preregistration DOI"
+doi: 10.5281/zenodo.24102739
+date-released: 2026-11-11
+license: MIT
+license-url: https://opensource.org/licenses/MIT
+url: https://doi.org/10.5281/zenodo.24102739
+repository-code: https://github.com/gitdeeper15/aetheridentity
+abstract: >
+  AetherIdentity is a candidate eighth functional dimension of the Aether
+  family. It investigates whether identity proof, continuity, reputation,
+  Sybil resistance, and delegation in multi-agent software ecosystems
+  constitute a genuine gap not already covered by the seven existing
+  dimensions. v2.0.0 is an experimental reference implementation of the
+  v1.0.0 paper. It implements L1–L5 and a minimal independent simulator.
+  It does not implement network transport, consensus, or AetherMesh
+  integration. No real-world deployment has been evaluated.
+keywords:
+  - AetherIdentity
+  - decentralized identity
+  - self-certifying identifiers
+  - key rotation
+  - reputation
+  - Sybil resistance
+  - delegation
+  - falsification
+  - reference implementation
+  - aether family
+authors:
+  - family-names: Baladi
+    given-names: Samir
+    orcid: https://orcid.org/0009-0003-8903-0029
+    email: gitdeeper@gmail.com
+    affiliation: "Ronin Institute / Rite of Renaissance"
+references:
+  - type: software
+    title: "AetherIdentity v2.0.0: Reference Implementation"
+    authors:
+      - family-names: Baladi
+        given-names: Samir
+    doi: 10.5281/zenodo.24102739
+    year: 2026
+  - type: generic
+    title: "AetherIdentity: A Falsification-First Investigation (Paper v1.0.0)"
+    authors:
+      - family-names: Baladi
+        given-names: Samir
+    doi: 10.5281/zenodo.24102739
+    year: 2026

aetheridentity-2.0.0/INVARIANTS.md

@@ -0,0 +1,396 @@
+# AetherIdentity v2.0.0 — Invariants
+
+**Version:** 2.0.0 (Phase 2)
+**Parent paper:** v1.0.0 (Zenodo 10.5281/zenodo.24102739)
+**Input:** SPECIFICATION.md (Phase 1)
+**Status:** Invariants. No code.
+**Decision record:** ROADMAP_v2.md
+
+---
+
+## 0. Purpose
+
+This document defines the invariants that every run of the reference implementation must satisfy. Each invariant is:
+
+1. Stated in a form that can be checked mechanically.
+2. Mapped to a failure condition (F1–F5) or a proposition (P1–P2).
+3. Accompanied by its failure mode (what a violation would mean).
+
+An invariant that cannot be checked mechanically is either weakened to a checkable form or reported as **not checkable** with a documented reason.
+
+---
+
+## 1. Invariant format
+
+Each invariant has the following fields:
+
+| Field | Meaning |
+|---|---|
+| **ID** | `I1`, `I2`, … |
+| **Statement** | What must hold. |
+| **Check** | How it is checked (function, test, or property). |
+| **Bears on** | F1–F5 or P1–P2. |
+| **Failure mode** | What a violation means. |
+| **Status** | `checkable` / `not checkable` / `deferred`. |
+
+---
+
+## 2. Core invariants (I1–I12)
+
+### I1 — Determinism of queries
+
+**Statement.** For any `S`, any permutation `S'` of `S`, and any query function `q`, `q(S) == q(S')`.
+
+**Check.** Property-based test: generate random `S`, permute, compare outputs bit-for-bit.
+
+**Bears on.** P1.
+
+**Failure mode.** A query function depends on the order of `S`. This would mean the specification's claim that `S` is a set (not a sequence) is false, and P1 cannot hold.
+
+**Status.** `checkable`.
+
+---
+
+### I2 — Identifier determinism
+
+**Statement.** For any two inception records `r1`, `r2` with the same `(alg, pk, λ)`, `id(r1) == id(r2)`.
+
+**Check.** Construct two records with identical inputs; compare identifiers.
+
+**Bears on.** P1.
+
+**Failure mode.** Identifier derivation is not a deterministic function of its inputs. This would contradict Definition 1 and make P1's condition (a) false.
+
+**Status.** `checkable`.
+
+---
+
+### I3 — Continuity chain validity
+
+**Statement.** For any `id` with a continuity chain `C` in `S`, `C` is valid: `r₀` is self-signed, and for each `k ≥ 1`, `H(pk_k) == c_{k-1}`, `h_{k-1}` is correct, and `o_k` verifies under `pk_k`.
+
+**Check.** Recompute the chain from `S`; verify each link.
+
+**Bears on.** P1, F4.
+
+**Failure mode.** A rotation record is accepted without a valid pre-commitment. This would mean the continuity chain does not enforce the offline-key rule.
+
+**Status.** `checkable`.
+
+---
+
+### I4 — Fork visibility
+
+**Statement.** If two valid rotation records share a predecessor and differ in content, `status_of(S, id) == "contested"`.
+
+**Check.** Construct a fork; assert status.
+
+**Bears on.** F4.
+
+**Failure mode.** A fork is silently resolved. This would mean the specification hides the fork-resolution residual.
+
+**Status.** `checkable`.
+
+---
+
+### I5 — Reputation determinism
+
+**Statement.** For any `S`, `reputation_of(S, id)` is computed in exact arithmetic with a fixed iteration count `K` and a canonical ordering, and returns the same vector for every node holding the same `S`.
+
+**Check.** Two independent computations on the same `S`; compare vectors bit-for-bit.
+
+**Bears on.** P1.
+
+**Failure mode.** The reputation vector depends on floating-point arithmetic, iteration count, or ordering. This would contradict P1's condition (c).
+
+**Status.** `checkable`.
+
+---
+
+### I6 — Reputation fixed point
+
+**Statement.** The reputation iteration `t ← (1 − a) · Cᵀ t + a · p` converges to a fixed point within `K` iterations, with error below a stated tolerance.
+
+**Check.** Compute the residual `‖T(t_K) − t_K‖₁`; assert below tolerance.
+
+**Bears on.** P1.
+
+**Failure mode.** The iteration does not converge within `K`. This would mean the exact-arithmetic claim is not satisfied.
+
+**Status.** `checkable`.
+
+---
+
+### I7 — Delegation monotonicity
+
+**Statement.** For any valid delegation chain `d₁ → d₂ → … → dₙ`, `S_n ⊆ S_{n-1} ⊆ … ⊆ S₁` and `e_n ≤ e_{n-1} ≤ … ≤ e₁`.
+
+**Check.** Construct chains with random scopes and expiries; assert monotonicity.
+
+**Bears on.** F4.
+
+**Failure mode.** Scope or expiry can widen along the chain. This would contradict Definition 4.
+
+**Status.** `checkable`.
+
+---
+
+### I8 — Revocation propagation
+
+**Statement.** If a delegation `d_k` in a chain is revoked, then for any action whose causal closure contains the revocation, the action is invalid.
+
+**Check.** Construct a chain, revoke a link, assert invalidity.
+
+**Bears on.** F4.
+
+**Failure mode.** Revocation does not invalidate downstream links. This would contradict Definition 4.
+
+**Status.** `checkable`.
+
+---
+
+### I9 — Sybil cluster weight
+
+**Statement.** For any identity `id` in a Sybil cluster of size `m`, `cluster_weight_of(S, id) == 1.0 / m`.
+
+**Check.** Construct a cluster; assert weight.
+
+**Bears on.** F4.
+
+**Failure mode.** Cluster weight is not deterministic or not `1/m`. This would mean L4 does not down-weight clusters.
+
+**Status.** `checkable`.
+
+---
+
+### I10 — Sybil detection rates reported
+
+**Statement.** For any Sybil scenario, both false-positive rate (on honest operators) and false-negative rate (on injected clusters) are reported.
+
+**Check.** Assert both fields exist and are numeric in `results.json`.
+
+**Bears on.** F4, F5.
+
+**Failure mode.** Only one rate is reported. This would allow a detector that flags everything to score perfectly on detection.
+
+**Status.** `checkable`.
+
+---
+
+### I11 — Signature separation
+
+**Statement.** A signature produced by `FakeSigner` is not accepted by `Ed25519Signer`, and vice versa.
+
+**Check.** Sign with one, verify with the other; assert `False`.
+
+**Bears on.** P1, F2.
+
+**Failure mode.** The two signers are interchangeable. This would mean the cryptographic verification path is not separated from the test path.
+
+**Status.** `checkable`.
+
+---
+
+### I12 — Structural vs. cryptographic verification
+
+**Statement.** For every record, structural validation and signature verification are checked separately, and both results are reported.
+
+**Check.** Assert both fields exist in the test report.
+
+**Bears on.** P1, F2.
+
+**Failure mode.** The two checks are merged. This would allow a structurally valid but cryptographically invalid record to pass.
+
+**Status.** `checkable`.
+
+---
+
+## 3. Failure-condition invariants (F1–F5)
+
+### 3.1 F1 — Non-redundancy
+
+**Claim.** At least one requirement R1–R6 is not met by L1–L5 plus a bounded extension of one existing dimension.
+
+**How it can be falsified.** A test that expresses all R1–R6 as a bounded extension of exactly one Aether dimension.
+
+**Invariant.** If such a test exists and passes, F1 is falsified.
+
+**Status.** `deferred` (requires AetherGovern/AetherMesh simulator; see S6).
+
+---
+
+### 3.2 F2 — Orthogonality to verification
+
+**Claim.** Some identity decisions cannot be encoded as verified claims.
+
+**How it can be falsified.** A test that encodes every identity decision as a verified claim.
+
+**Invariant.** If such a test exists and passes, F2 is falsified.
+
+**Status.** `deferred` (requires AetherProof simulator).
+
+---
+
+### 3.3 F3 — Boundary with governance
+
+**Claim.** Identity is not reducible to governance plus conventional verification.
+
+**How it can be falsified.** In S6, the fraction of L5 decisions re-expressible as AetherGovern decisions is high (threshold fixed in Phase 3).
+
+**Invariant.** If the fraction exceeds the threshold, F3 is falsified.
+
+**Status.** `checkable` (in S6).
+
+---
+
+### 3.4 F4 — Decentralizability
+
+**Claim.** Most identity functions are monotone or deterministic functions of monotone state; four residuals require something outside the replicated state.
+
+**How it can be falsified.** A test that shows a central authority or strong consistency is required for a function that the specification classifies as agreement-free.
+
+**Invariant.** Every function classified as agreement-free must be computable by two nodes holding the same `S` without communication.
+
+**Status.** `checkable`.
+
+---
+
+### 3.5 F5 — Observable benefit
+
+**Claim.** There exists a scenario class in which the best baseline fails and AetherIdentity succeeds.
+
+**How it can be falsified.** For every scenario, some baseline is non-inferior on the primary metrics, or M9 is ever non-zero.
+
+**Invariant.** If F5's decision rule (from OSF preregistration) is satisfied, F5 is falsified.
+
+**Status.** `deferred` (requires all scenarios S1–S6 and all baselines B1–B5).
+
+---
+
+## 4. Proposition invariants (P1–P2)
+
+### 4.1 P1 — Determinism of local identity issuance
+
+**Claim.** Under conditions (a)–(d), admission satisfies A6, and all honest nodes derive the same views once delivery is complete.
+
+**Invariant.** Two nodes with the same `S` derive identical `status_of`, `reputation_of`, `cluster_weight_of`, `continuity_chain_of`, `delegation_chain_of`.
+
+**Status.** `checkable`.
+
+**Failure mode.** A view differs between nodes with the same `S`. This falsifies P1.
+
+---
+
+### 4.2 P2 — Irreducible trust anchor
+
+**Claim.** Any identity protocol that admits on evidence leaves an irreducible trust anchor.
+
+**How it can be falsified.** A simulated network bootstraps without any externally trusted identity.
+
+**Invariant.** If such a bootstrap succeeds, P2 is falsified.
+
+**Status.** `checkable` (in S1, with a documented bootstrap procedure).
+
+---
+
+## 5. Open decisions resolved here
+
+Phase 1 listed seven open decisions (O1–O7). Phase 2 resolves them as follows:
+
+| # | Decision | Resolution |
+|---|---|---|
+| O1 | Fixed iteration count `K` | `K = 100` for exact arithmetic; convergence checked in I6. |
+| O2 | Canonical ordering of identities | Lexicographic by identifier hash. |
+| O3 | Exact arithmetic for reputation | `fractions.Fraction` for the iteration; final vector rounded to 6 decimal places for reporting only. |
+| O4 | Threshold `τ` for Sybil clusters | `τ = 2` for v2.0.0; tested for sensitivity in S5. |
+| O5 | Epoch length for sponsor quotas | `1` logical epoch = `100` admissions; tested for sensitivity in S5. |
+| O6 | Whether recovery is implemented | **No.** Out of scope for v2.0.0; documented as a residual. |
+| O7 | Whether L5 is separable from AetherGovern | Tested in S6; result reported in Phase 6. |
+
+These resolutions are **binding** for Phase 4. Changing them requires an amendment in `REPORTS/v2.0.0/phase_log.md`.
+
+---
+
+## 6. Invariants that are not checkable in v2.0.0
+
+The following are **not checkable** in v2.0.0, and are reported as such in Phase 5:
+
+| Invariant | Reason | Where it would be checkable |
+|---|---|---|
+| Concurrent admission | Out of scope (§2.4 of SPECIFICATION.md) | Future version with concurrency |
+| Causal delivery | Out of scope | Future version with AetherMesh integration |
+| Fork resolution | Out of scope | Future version with an authority model |
+| Recovery after total key loss | Out of scope | Future version with a guardian protocol |
+| Single-instance enforcement | Requires bounded agreement | Future version with consensus |
+| Byzantine behavior | Out of scope | Future version with adversarial model |
+
+These are **not** reported as passing. They are reported as **not testable under v2.0.0**.
+
+---
+
+## 7. Invariant coverage
+
+| Invariant | Bears on | Phase 3 test | Phase 5 status |
+|---|---|---|---|
+| I1 | P1 | `test_permutation_invariance` | — |
+| I2 | P1 | `test_identifier_determinism` | — |
+| I3 | P1, F4 | `test_chain_validity` | — |
+| I4 | F4 | `test_fork_visibility` | — |
+| I5 | P1 | `test_reputation_determinism` | — |
+| I6 | P1 | `test_fixed_point_convergence` | — |
+| I7 | F4 | `test_delegation_monotonicity` | — |
+| I8 | F4 | `test_revocation_propagation` | — |
+| I9 | F4 | `test_cluster_weight` | — |
+| I10 | F4, F5 | `test_detection_rates` | — |
+| I11 | P1, F2 | `test_signer_separation` | — |
+| I12 | P1, F2 | `test_structural_vs_crypto` | — |
+| F1 | F1 | `test_f1_bounded_extension` | deferred |
+| F2 | F2 | `test_f2_verified_claims` | deferred |
+| F3 | F3 | `test_f3_governance_overlap` | checkable (S6) |
+| F4 | F4 | `test_f4_agreement_free` | — |
+| F5 | F5 | `test_f5_decision_rule` | deferred |
+| P1 | P1 | `test_p1_same_s` | — |
+| P2 | P2 | `test_p2_bootstrap` | checkable (S1) |
+
+---
+
+## 8. Next phase
+
+Phase 3 — `TESTS.md`. Each invariant in §7 becomes at least one test with preconditions, postconditions, and expected outcome. The test count is **determined by the invariants**, not assumed in advance.
+
+---
+
+## Appendix A — Invariant summary
+
+| ID | Short name | Status |
+|---|---|---|
+| I1 | Permutation invariance | checkable |
+| I2 | Identifier determinism | checkable |
+| I3 | Chain validity | checkable |
+| I4 | Fork visibility | checkable |
+| I5 | Reputation determinism | checkable |
+| I6 | Fixed-point convergence | checkable |
+| I7 | Delegation monotonicity | checkable |
+| I8 | Revocation propagation | checkable |
+| I9 | Cluster weight | checkable |
+| I10 | Detection rates reported | checkable |
+| I11 | Signer separation | checkable |
+| I12 | Structural vs. crypto | checkable |
+| F1 | Non-redundancy | deferred |
+| F2 | Orthogonality | deferred |
+| F3 | Governance overlap | checkable (S6) |
+| F4 | Agreement-free | checkable |
+| F5 | Decision rule | deferred |
+| P1 | Same-S determinism | checkable |
+| P2 | Bootstrap | checkable (S1) |
+
+## Appendix B — Relationship to v1.0.0 paper
+
+| Paper section | This document |
+|---|---|
+| §3 Definitions | §2 (I2, I3, I5) |
+| §4 Failure conditions | §3 |
+| §5 Requirements | §7 |
+| §6 Architecture | §2, §4 |
+| §8 Evaluation design | §6, §7 |
+| §10 Open questions | §5 (resolves O1–O7) |

aetheridentity-2.0.0/LICENSE

@@ -0,0 +1,29 @@
+MIT License
+
+Copyright (c) 2026 Samir Baladi
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
+
+---
+
+Note on scope:
+
+The MIT license above applies to code (v2.0.0, src/aetheridentity/).
+The documentation, manuscript, and figures are released under CC-BY-4.0:
+https://creativecommons.org/licenses/by/4.0/legalcode

aetheridentity-2.0.0/MANIFEST.in

@@ -0,0 +1,10 @@
+include README.md
+include LICENSE
+include CHANGELOG.md
+include CITATION.cff
+include SPECIFICATION.md
+include INVARIANTS.md
+include TESTS.md
+include ROADMAP_v2.md
+recursive-include docs/figures *.png
+recursive-include paper *.pdf