Technical Paper for Contributors

Technical summary for contributors

This document presents a technical implementation proposal for Internet 5.0 for review by engineers, operating-system maintainers, browser developers, security researchers, cryptographers, Linux communities, Android/Windows teams and RFC contributors.

Internet 5.0 is not an attempt to replace the TCP/IP stack. It is an incremental architecture, initially in user space for the MVP, designed to integrate secure sessions, cryptographic identity, censorship-resistant name resolution, multiple locators, plural reputation, anti-phishing protection and ethical governance without backdoors.

The proposal is divided into three technical blocks: I5SL, I5NS and I5TRUST.

1. Engineering objective

The engineering objective is to create a session and resolution layer allowing an application to request communication by identity and policy, rather than depending exclusively on a domain, DNS, IP, single route or single provider.

Application
  ↓
secure_session(identity_or_name, policy, content_type)
  ↓
I5NS Resolver → I5ID + locators + reputation
  ↓
I5SL Route/Session Manager
  ↓
TLS/QUIC/HTTPS/IPFS/onion/relay/cache
  ↓
content verified by signature or hash

The project should start as a library, local daemon and browser extension. Native operating-system integration should come later, after validation of architecture, security, UX, performance and governance.

2. Technical blocks

3. Non-goals

• do not modify operating-system kernels in the MVP;
• do not replace IP, TCP, UDP, TLS, QUIC or DNS;
• do not create a mandatory blockchain;
• do not create a global naming authority;
• do not require civil identity or KYC for reading public content;
• do not promise absolute impossibility of blocking;
• do not defend generic disregard for court orders;
• do not create a network without accountability for crimes or fraud.

The initial focus is interoperability, auditability and progressive adoption.

4. Threat model

The architecture assumes adversaries capable of blocking DNS, IPs, ports, protocols, app stores or domains; tampering with resolution responses; classifying traffic by metadata; degrading routes; pressuring registrars, providers, data centers, operators and platforms; issuing broad blocking orders; exploiting confusing names for phishing; capturing reputation lists; or forcing downgrade to less secure routes.

The architecture does not promise protection against physical cable cuts, national power shutdowns, arrest of operators, total device control, criminal prohibition of privacy tools or complete isolation of national networks.

5. Cryptographic identity

The I5ID is an identifier derived from a public key. It does not represent mandatory civil identity. It represents cryptographic control.

i5id:ed25519:z6Mkp...

The client should verify whether a record, content item, locator, revocation or update was signed by the corresponding key.

• I5ID should be self-issued;
• reading public content should not require a persistent reader I5ID;
• publishers may use public, pseudonymous or organizational identities;
• ephemeral identities should be possible for sensitive sessions;
• reputation should follow the key and history, not only the human-readable name.

6. I5NS Record

The I5NS Record is the signed object linking human-readable name, cryptographic identity and locators.

{
  "type": "I5NS-Record",
  "version": "0.1",
  "name": "internet5.i5",
  "canonical_id": "i5id:ed25519:z6MkpExamplePublicKey",
  "created_at": "2026-05-27T00:00:00Z",
  "valid_until": "2027-05-27T00:00:00Z",
  "sequence": 42,
  "locators": [
    {
      "scheme": "https",
      "uri": "https://alexfernando.com/internet5.0/",
      "priority": 10,
      "transport_policy": ["tls13", "ech-preferred"]
    },
    {
      "scheme": "ipfs",
      "uri": "ipfs://bafyExampleHash",
      "priority": 30
    },
    {
      "scheme": "onion",
      "uri": "http://exampleonionaddress.onion/",
      "priority": 40
    }
  ],
  "policies": {
    "downgrade_protection": true,
    "mirroring_allowed": true,
    "reader_identity_required": false,
    "no_backdoor_commitment": true
  },
  "recovery_policy": {
    "type": "m-of-n",
    "required_signatures": 2,
    "recovery_keys": [
      "i5id:ed25519:z6RecoveryKey1",
      "i5id:ed25519:z6RecoveryKey2",
      "i5id:ed25519:z6RecoveryKey3"
    ]
  },
  "signature": {
    "alg": "ed25519",
    "key": "i5id:ed25519:z6MkpExamplePublicKey",
    "value": "base64url-signature"
  }
}

The sequence field mitigates replay of old records. valid_until forces renewal. The m-of-n policy reduces permanent loss risk when the primary key is lost.

7. I5NS resolution

The I5NS resolver should consult multiple sources and never depend on a single sovereign server: local cache, .well-known file, DNS TXT, DoH, DoT, ODoH, IPFS, transparency logs, configurable trust lists, independent mirrors and user-pinned records.

resolve_i5_name(name, context):
    records = collect_from_multiple_sources(name)
    valid = []

    for record in records:
        if not verify_signature(record):
            continue
        if is_expired(record):
            mark(record, "expired")
            continue
        if is_replayed(record):
            mark(record, "replay-risk")
            continue
        valid.append(record)

    reputation = query_i5trust(valid)
    ranked = rank_records(valid, reputation, context)
    return ranked

8. I5SL session establishment

The conceptual API may be:

secure_session(identity_or_name, policy, content_type)

Example policy:

{
  "privacy": "high",
  "require_integrity": true,
  "allow_mirrors": true,
  "allow_onion": true,
  "allow_ipfs": true,
  "fail_closed_on_downgrade": true
}

1. resolve name through I5NS;
2. validate signature and identity;
3. rank locators;
4. evaluate privacy policy;
5. try secure direct route;
6. use ECH/DoH/DoT/ODoH when available;
7. try signed mirror, IPFS, onion, relay or cache;
8. verify content integrity;
9. return session or explainable error.

9. Locator ranking

The session manager should rank locators by integrity, privacy, latency, availability, censorship risk, user preference, publisher policy, success history, reputation warnings, content sensitivity and jurisdiction.

if policy.privacy == "high":
    prefer privacy-preserving locators

if policy.require_integrity:
    reject content without valid signature/hash

if censorship_risk == "high":
    avoid single direct route

if locator.reputation == "phishing":
    block or require explicit confirmation

10. Operating-system integration

10.1. User-space MVP

• libi5sl — session library;
• i5nsd — local daemon/resolver;
• i5trustd — reputation/list verifier;
• i5ctl — command-line tool;
• i5-record-tool — record generator and validator;
• browser extension demo.

10.2. Linux

On Linux, the recommended initial path is a user daemon with local socket, optional integration with NSS, NetworkManager, browsers and CLI tools. eBPF, Netfilter or kernel modules should be avoided for the MVP.

10.3. Windows

On Windows, the initial path is a user-space library and local service. Later integration could explore Windows Filtering Platform, but that should not be an initial requirement.

10.4. Android

On Android, the MVP can start with a per-application SDK, local service integrated into participating apps or a VpnService prototype. The mature target would be integration with the system resolver, per-app network policy and native secure-session API.

10.5. Browsers

Browsers are the most strategic initial adoption point: .i5 resolution, I5ID verification, phishing warnings, homograph detection, fallback to locators and trust panel.

11. I5TRUST: anti-phishing and plural reputation

I5TRUST is not a central list. It is a model for plural, signed, auditable, contestable and protocol-optional lists.

• Trust List;
• Warning List;
• Fraud List;
• Phishing List;
• Compromised Key List;
• Dispute List;
• Brand Impersonation List;
• High-Risk Identity List.

A warning should contain issuer, target, affected name, reason, evidence, severity, date, expiration, appeal channel and signature. The protocol should not globally erase an identity.

12. Name speculation, logs, security, privacy and performance

I5NS should reduce speculative occupation of human-readable names. Reputation follows identity, not only the string; name transfer does not automatically transfer trust; unused names may receive low reputation; proof of control and public history increase trust; conflicts should be displayed rather than erased by a single authority.

Transparency logs should not be sovereign registrars. They only prove events: name claims, locator updates, mirror revocations, m-of-n recovery, disputes and warnings.

Security mitigations include sequence numbers, short validity, mandatory signatures, content hashes, m-of-n recovery, plural lists, local cache, multiple-source queries, transparency logs, homograph warnings, optional pinning, strict-mode fail-closed behavior and code audits.

Privacy requirements include no persistent reader identity, private name queries, local cache, possible batched queries, ODoH or equivalent support, non-logging transparency infrastructure, periodic reputation-list downloads and minimal telemetry.

Performance should rely on local cache, prefetch, periodic list download, parallel queries, locator ranking, asynchronous reputation checks, offline pinned records and progressive fallback.

13. Recommended MVP and test vectors

Required test vectors should cover valid record, invalid signature, expired record, replayed record, old sequence, revoked key, disputed name, malicious locator, Unicode homograph, phishing warning, valid trust list, expired trust list, valid 2-of-3 recovery and invalid 1-of-3 recovery.

14. Open questions for contributors

1. Should canonical format be JSON, CBOR, COSE, JOSE or another format?
2. Is Ed25519 sufficient for the initial draft?
3. What post-quantum transition strategy should be anticipated?
4. How to prevent centralization of transparency logs?
5. How to prevent Sybil attacks in reputation lists?
6. How to classify disputed names without central authority?
7. How to balance anti-phishing warnings with the risk of private censorship?
8. How to perform private resolution without excessive latency?
9. How to integrate with browsers without depending on extensions?
10. How to create an operating-system API without breaking compatibility?
11. How to define fail-open and fail-closed policies?
12. How to protect users in countries where privacy tools are criminalized?
13. How to implement Android support without permanent dependence on VpnService?
14. How to implement Windows support without requiring a kernel driver in the MVP?
15. How to implement Linux support without fragmenting across distributions?
16. How to prevent reputation lists from becoming outsourced censorship?

15. Technical conclusion

Internet 5.0 should be understood as a transition architecture. It does not replace the current Internet, does not promise absolute invulnerability, does not create a lawless network, does not require global civil identity and does not depend on a single registrar.

secure session layer;
key-based naming system;
multiple signed locators;
distributed resolution;
plural reputation;
anti-phishing warnings;
decentralized recovery;
downgrade protection;
resolution privacy;
accountability at the edges;
absence of backdoors.

The correct question for technical review is: is it possible to create an open, incremental and auditable layer that increases availability, privacy, authenticity and censorship resistance without creating a new central point of control?

Internet 5.0 answers: yes, provided the architecture starts decentralized, preserves strong encryption, separates civil identity from cryptographic identity, uses plural reputation, keeps accountability at the edges and evolves through progressive implementation.