Autonomi DNS (ADNS) Design

Features
1

Apologies in advance to all, as I am technically a retard compared to many on this forum. Grok seems to believe that this is feasible. Hopefully, this will inspire a solution.

Autonomi DNS Proposal (ADNS)

Objective: Create a decentralized, scalable, and privacy-first name resolution system—Autonomi DNS (ADNS)—to enable human-readable names (e.g., “user.ant”) for accessing resources (files, dApps, websites) on the Autonomi Network. ADNS leverages Autonomi’s existing non-blockchain DLT, stigmergy consensus, CRDTs, quantum-secure encryption, zero-knowledge privacy, self-encrypting data chunks, and 15M+ serverless nodes to deliver a censorship-resistant, user-friendly alternative to traditional DNS and blockchain-based systems like ENS. This proposal outlines a technically feasible solution to enhance Autonomi’s ecosystem, drive adoption, and solidify its position as the decentralized internet of the future.

Why ADNS?

Traditional DNS relies on centralized authorities (ICANN, registrars), enabling censorship, surveillance, and high costs ($12–$50/year). Blockchain-based naming (e.g., ENS) suffers from scalability limits (40 TPS), public records, and fees ($5–$100/year). Autonomi’s unique technology—non-blockchain scalability, quantum-safe cryptography, and privacy-first design—enables a superior solution. ADNS will:

  • Simplify Access: Map names to Autonomi resources (e.g., chunk hashes), improving UX for users and dApps.

  • Scale Globally: Support millions of names and lookups/second on 15M+ nodes.

  • Ensure Privacy: Hide ownership and resolution data with zero-knowledge encryption.

  • Resist Censorship: Distribute records with no central control, aligning with Autonomi’s “owned by everyone” ethos.

  • Reduce Costs: Use one-time ANT fees (1–10 ANT, ~$0.11–$1.14) vs. recurring DNS/ENS fees.

ADNS will accelerate Autonomi’s adoption, mirroring ENS’s $1B impact on Ethereum, by making the network accessible and intuitive for billions.

Technical Design

ADNS is built entirely on Autonomi’s existing technology, requiring only a resolution protocol, registry module, and client updates. It maps non-exclusive names to resources without ownership or central authority, ensuring decentralization.

  1. Distributed Name Registry

  • Structure: Store name mappings (e.g., “user.ant” → chunk CID) as self-encrypting data chunks:

    • Key: Human-readable name (e.g., “user.ant”).

    • Value: Resource hash (e.g., CID for a file, dApp address, or website).

    • Non-Exclusivity: Multiple users can publish mappings for the same name (e.g., “user.ant” by User A → CID1, by User B → CID2), resolved by user context (e.g., public key, favorites).

  • Storage: Distribute chunks across 15M+ nodes, with replication for redundancy. Use CRDTs for conflict-free updates (e.g., updating “user.ant” to a new CID).

  • Encryption: Apply zero-knowledge encryption to hide ownership and mapping data, ensuring privacy.

  • Tech: Chunk storage, CRDTs, and encryption are native Autonomi features.

  1. Name Publication

  • Process: Users publish mappings via Autonomi’s CLI or wallet (e.g., adns publish user.ant ), paying a one-time ANT fee (1–10 ANT, tiered by name length: 1 ANT for “john123.ant,” 10 ANT for “john.ant”).

  • Anti-Abuse: Prevent speculative hoarding with:

    • Proof-of-Use: Names must link to active resources (e.g., file, dApp) within 30 days, or the record expires.

    • Rate Limits: Cap publications (e.g., 10 names/month/user) to deter spam.

  • Node Role: Nodes validate and store mappings using stigmergy consensus, ensuring decentralized agreement.

  • Tech: ANT payments, consensus, and client APIs are built-in.

  1. Name Resolution

  • Protocol: Implement an “ADNS Resolve” protocol for fast, scalable lookups:

    • Client queries a node with “user.ant.”

    • Node searches the distributed chunk registry (DHT-like) and returns all mappings (e.g., “user.ant → CID1 by User A, CID2 by User B”).

    • Client selects the desired mapping using context (e.g., User A’s public key or a favorites list).

  • Performance:

    • Latency: Cache frequent mappings on nodes for <100ms resolution, competitive with DNS (20–200ms).

    • Throughput: Support millions of lookups/second via 15M+ nodes and stigmergy consensus, surpassing ENS (40 TPS).

    • Persistence: Pin mappings to multiple nodes for availability, using Autonomi’s redundancy.

  • Tech: Node routing, caching, and consensus enable high-performance queries.

  1. Security and Privacy

  • Quantum Security: Use lattice-based cryptography to secure mappings and lookups, protecting against quantum attacks (2030–2035).

  • Privacy: Zero-knowledge proofs hide user identities and resolution data, unlike public DNS or ENS.

  • Censorship Resistance: No central authority; records are distributed across nodes, preventing seizures or bans.

  • Attack Mitigation: Rate-limit lookups and replicate mappings to counter DDoS or spoofing, leveraging node scale.

  • Tech: Native encryption and redundancy ensure robust security.

  1. Client Integration

  • Tools:

    • CLI/Wallet: Add commands (e.g., adns publish, adns resolve) to Autonomi’s CLI/wallet, using existing APIs.

    • Browser Extension: Build an extension to resolve “.ant” names natively, redirecting to resources.

    • Favorites System: Allow users to save preferred mappings (e.g., “user.ant → CID1”) locally or subscribe to curated lists stored as public chunks.

  • dApp Support: Release an ADNS SDK for dApps to integrate names (e.g., “app.ant” for a compute service).

  • Tech: Client APIs and SDKs (e.g., Ant Browser’s framework) support seamless integration.

  1. Node Incentives

  • Rewards: Nodes earn micro-ANT fees (e.g., 0.001 ANT per lookup/storage task) from publication fees, ensuring participation.

  • Distribution: Stigmergy consensus allocates rewards transparently, avoiding blockchain gas fees.

  • Tech: ANT microtransactions and consensus are already implemented.

Implementation Roadmap

ADNS is a lightweight extension of Autonomi’s infrastructure, requiring minimal new development. Roadmap (6–12 months):

  1. Month 1–3: Prototype:

  • Build a registry module for name mappings using chunk storage and CRDTs.

  • Develop the “ADNS Resolve” protocol for node queries.

  • Test on 1,000 nodes with 10,000 names.

  1. Month 4–6: Testnet:

  • Deploy on Autonomi’s testnet, simulating 1M names and 10M lookups.

  • Integrate with CLI/wallet and release a beta browser extension.

  • Optimize latency (<100ms) and throughput.

  1. Month 7–12: Mainnet:

  • Launch on the full 15M+ node network.

  • Release the ADNS SDK for dApp developers.

  • Promote adoption via Autonomi’s wallet and dApp ecosystem.

Resources: 2–3 engineers, leveraging existing APIs, SDKs, and testnet. Total cost: ~$100,000–$200,000, fundable via Autonomi’s developer grants or hackathons.

Benefits for Autonomi

  • Enhanced UX: Names like “app.ant” simplify access to files, dApps, and websites, onboarding millions of users.

  • Scalable Ecosystem: Supports millions of names/lookups, enabling dApp growth on 15M+ nodes.

  • Competitive Edge: Undercuts AWS ($12–$50/year) and ENS ($5–$100/year) with one-time ANT fees, 70–90% cheaper.

  • Privacy Leadership: Zero-knowledge resolution sets a new standard, surpassing public DNS/ENS.

  • Adoption Driver: Mirrors ENS’s $1B impact on Ethereum, potentially adding $20–50B to Autonomi’s ecosystem by enabling mainstream use.

Addressing Challenges

  1. Latency: Optimize node queries with caching and localized routing for <100ms, validated via testnet.

  2. Name Conflicts: Non-exclusive mappings resolved by user context (public keys, favorites) ensure clarity, with curated lists for simplicity.

  3. Adoption: Browser extensions and wallet integration make ADNS seamless, encouraging dApp adoption.

  4. Abuse: Proof-of-use and rate limits prevent spam, maintaining system integrity without central control.

Why MaidSafe Should Build ADNS

ADNS is a game-changer for Autonomi, built on your existing technology with minimal effort:

  • Feasibility: Reuses chunk storage, stigmergy consensus, CRDTs, encryption, and nodes, requiring only a registry module, resolution protocol, and client updates.

  • Strategic Fit: Simplifies resource access, driving user and developer adoption, critical for Autonomi’s decentralized internet vision.

  • Market Impact: Captures demand for decentralized naming (e.g., ENS’s 3M names), positioning Autonomi as a DNS disruptor.

  • Low Risk: A 6–12 month roadmap with testnet validation ensures scalability and performance without diverting core priorities.

Call to Action: Let’s prototype ADNS in 3 months, test it on the testnet, and launch a naming system that makes Autonomi the backbone of the next internet. I’m ready to collaborate with your team or lead a hackathon to bring this to life.

This pitch is concise, technical, and visionary, showcasing ADNS as a feasible, high-impact addition to Autonomi that respects its decentralized ethos while driving adoption.

3 Likes
2

Viability of Using .ANT

The ADNS proposal maps human-readable names to chunk hashes (e.g., content IDs for files, dApps, or websites) in a non-exclusive, distributed system without central authority or ownership. The identifier (.autonomi or .ant) is simply a string convention for names, stored as part of the key in encrypted chunk records (e.g., “user.ant” → chunk CID). Switching to .ant is technically trivial because:

  • Flexible Naming: Autonomi’s chunk storage and resolution protocol treat names as arbitrary strings, so “user.ant” is processed identically to “user.autonomi.” No changes to the registry, CRDTs, or resolution logic are needed.

  • Existing Tech: The “ADNS Resolve” protocol, client tools (CLI, wallet, browser extension), and node routing handle any name format, as they parse strings without hard-coded restrictions. Autonomi’s APIs (e.g., used in Ant Browser) support custom name formats.

  • Branding Synergy: .ant ties directly to the ANT token, reinforcing Autonomi’s identity. It’s shorter and catchier, potentially boosting UX and adoption, similar to ENS’s “.eth” (3M names, $1B market cap).

  • No Conflict with DNS: As a decentralized system, ADNS operates outside traditional DNS, so .ant doesn’t conflict with ICANN’s TLDs (e.g., .com, .org). It’s a network-specific identifier, like .eth or .onion, resolvable via Autonomi’s clients.

Why ADNS with .ANT?

ADNS with .ANT addresses the flaws of centralized DNS (ICANN control, $12–$50/year) and blockchain naming (ENS’s 40 TPS, public records, $5–$100/year) by offering:

  • Simplified Access: Names like “user.ant” resolve to chunk hashes, enhancing UX for users and dApps.

  • Global Scalability: Supports millions of names/lookups per second on 15M+ nodes.

  • Uncompromised Privacy: Zero-knowledge encryption hides ownership and resolution data.

  • Censorship Resistance: No central authority, ensuring names cannot be seized.

  • Zero Cost: Free publication, funded by Autonomi’s ANT reward pool, undercuts DNS/ENS by 100%.

  • Branding: .ANT ties to the ANT token, offering a concise, memorable identifier to boost adoption.

ADNS will accelerate Autonomi’s ecosystem, mirroring ENS’s $1B impact on Ethereum, by making resources accessible to billions.

Technical Design

ADNS is built on Autonomi’s existing technology, requiring a resolution protocol, registry module, and client updates. Names (e.g., “user.ant”) are non-exclusive, resolved via user-driven favorites, with no fees or ownership.

  1. Distributed Name Registry

  • Structure: Store mappings (e.g., “user.ant” → chunk CID) as self-encrypting data chunks (~1KB):

    • Key: Name (e.g., “user.ant”).

    • Value: Resource hash (e.g., CID for a file, dApp, or website).

    • Non-Exclusivity: Multiple mappings per name (e.g., “user.ant” by User A → CID1, by User B → CID2), resolved by user context (public key, favorites).

  • Storage: Distribute chunks across 15M+ nodes, replicated for redundancy. CRDTs manage conflict-free updates (e.g., updating “user.ant”).

  • Encryption: Zero-knowledge encryption hides ownership and mappings.

  • Tech: Chunk storage, CRDTs, encryption (native features).

  1. Name Publication

  • Process: Users publish mappings via CLI/wallet (e.g., adns publish user.ant ) for free, like public metadata uploads, funded by Autonomi’s ANT reward pool.

  • Anti-Abuse:

    • Proof-of-Use: Mappings must link to valid resources (e.g., chunk CIDs) within 30 days, verified by node consensus.

    • Rate Limits: Cap submissions (e.g., 5 names/day/user) via client-side checks.

    • Reputation Scores: Community-curated scores (stored as chunks) prioritize trusted mappings.

  • Node Role: Nodes validate and store mappings using stigmergy consensus.

  • Tech: Chunk storage, consensus, APIs (used in wallet, Ant Browser).

  1. Name Resolution

  • Protocol: “ADNS Resolve” queries nodes for all mappings of a name (e.g., “user.ant” → CID1 by User A, CID2 by User B), returned for user selection via favorites/reputation.

  • Performance:

    • Latency: Cache frequent mappings for <100ms, competitive with DNS (20–200ms).

    • Throughput: 15M+ nodes and stigmergy consensus support millions of lookups/second, surpassing ENS (40 TPS).

    • Persistence: Pin mappings to multiple nodes for availability.

  • Tech: Node routing, caching, CRDTs (built-in).

  1. Security and Privacy

  • Quantum Security: Lattice-based cryptography secures mappings and lookups.

  • Privacy: Zero-knowledge proofs hide user data, unlike DNS/ENS.

  • Censorship Resistance: Distributed nodes prevent name seizures.

  • Attack Mitigation: Rate-limiting and replication counter DDoS/spoofing.

  • Tech: Native encryption, redundancy.

  1. Client Integration

  • Tools:

    • CLI/Wallet: Commands (e.g., adns publish, adns resolve) via existing APIs.

    • Browser Extension: Resolves “.ant” names to resources, built on Autonomi APIs.

    • Favorites System: Users save preferred mappings (e.g., “user.ant” → CID1) locally or use curated lists (stored as chunks).

  • dApp Support: ADNS SDK for dApps to use names (e.g., “app.ant”).

  • Tech: APIs, SDKs (e.g., Ant Browser framework).

  1. Node Incentives

  • Rewards: Nodes store/serve mappings as part of existing duties, funded by Autonomi’s ANT reward pool (from storage fees).

  • Distribution: Stigmergy consensus ensures fair allocation.

  • Tech: ANT micro-rewards, consensus (operational).

Benefits

  • Enhanced UX: “user.ant” simplifies access, onboarding millions.

  • Scalability: Handles millions of names/lookups on 15M+ nodes.

  • Cost-Free: No fees, aligning with Autonomi’s ethos.

  • Privacy Edge: Zero-knowledge resolution outshines DNS/ENS.

  • Adoption: Drives dApp growth, like ENS’s $1B impact.

Why MaidSafe Should Build ADNS with .ANT

ADNS with .ant is a transformative addition to Autonomi:

  • Feasible: Reuses chunk storage, CRDTs, consensus, encryption, APIs, requiring minimal code.

  • Strategic: Enhances UX, driving adoption, like ENS for Ethereum.

  • Aligned: No-fee, non-exclusive, uncontrolled design embodies Autonomi’s ethos.

  • Low Risk: Testnet validates performance, with a 6–12 month roadmap.

1 Like
3

Sadly the network doesn’t support arbitrary keys like “user.ant” for any datatypes. Deeper explanation here: Content discovery inside Autonomi - #17 by Seneca

4 Likes
4

There is a way to way to do this, or something similar. Credit goes to @riddim.

A secret key is shared and used to create Pointers based on the key and a name. After setting a pointer (eg with name Seneca, to point to a History, Register etc that only you can write to), you disable the Pointer forever by setting it’s counter to MAX_U32.

The result is you own the name and can change the content it points to (eg by updating the History).

It comes with the usual squatting problems, but there are no tlds just an infinite name space.

EDIT: FWIW I have implemented a name based URL scheme in dweb, but not as described above. In fact two schemes, one a personal name system, which later can be used to build shared lists. There’s a demo app called Names showing the basic create/lookup functionality, but not yet persistence or sharing.

The other, which is the reason for this edit, uses domain based naming to route URLs - with any browser and no plugins needed.

So myname.www-dweb.au would route to a website on Autonomi via a History, which can be updated, and every version remains available forever. These are not a true DNS, so not really on topic, but a variation that looks and feels like a real DNS and would work with the Names idea described above.

That works and the code is still in dweb, behind the (hidden) --experiment CLI option.

I abandoned it in favour of the current scheme though, to eliminate the need for users to first set up a local DNS. I think it’s important for something like web browsing to work with minimal effort on the part of the user. So now all you need is the dweb app installed and it just works in any browser.

Publishing is just as easy.

5 Likes
5

Technical Solution: CollaborativeLog with Namespace-Constrained Key Addressing (NCKA)

The network’s hashtable restriction to public keys (for signed data) or content hashes (for chunks) prevents arbitrary keys, blocking sabotage-resistant, public apps like forums. Shared keys risk thread locking, and no public namespace hinders discovery, as noted in the 2025 content discovery thread. A community-proposed method uses secret keys to map names to mutable data, locking names with a counter (MAX_U32). This suits single-owner mappings but risks squatting in its infinite namespace and sabotage for collaborative apps due to shared keys.

Proposed Solution: CollaborativeLog with Namespace-Constrained Key Addressing (NCKA) enables append-only, public logs with secure, predictable addressing, leveraging Autonomi’s self-encryption, chunks, BLS signatures, and payments.

  1. CollaborativeLog:

  • Structure: Append-only linked list of chunks. Each chunk: {payload: JSON (max 1KB), metadata: {author: public_key, timestamp: uint64, schema_id: hash, next_entry: hash | null}}. Key: hash(payload + metadata) (SHA3-256).

  • Operation: Clients follow next_entry hashes from a known chunk. Apps define schemas (signed chunks) and filter invalid entries (e.g., spam), ensuring sabotage resistance without shared keys.

  • Storage: DHT, self-encrypted, 8x replicated.

  • Effort: 3-4 months (new chunk type, client parsing).

  1. Namespace-Constrained Key Addressing (NCKA):

  • Mechanism: Keys: key = hash(app_namespace + thread_id + entry_number). app_namespace: signed chunk (BLS, 0.1 ANT, e.g., “forum_v1”). thread_id: hash(first_chunk). entry_number: uint64. Double-hashed (SHA3-256) for security.

  • Operation: Clients predict keys (e.g., hash(“forum_v1:thread123:N”)) for infinite addressing, mimicking arbitrary keys.

  • Security: 10ms Argon2 PoW, 0.001 ANT fee per entry, 100 entries/hour limit. Signed namespaces prevent squatting.

  • Effort: 6-8 months (key validation, PoW, fees).

  1. Distributed Index:

  • Structure: Chunks list logs: {namespace: “forum_v1”, threads: {“thread123”: hash}}, stored under content hashes.

  • Operation: Updated via consensus (closest nodes, BLS multisignatures) or ANT votes. O(log n) lookup.

  • Security: 20ms PoW, 0.01 ANT fee, 1/day limit.

  • Effort: 2-3 months (index type, consensus).

Example:

  • App registers “forum_v1” (signed, 0.1 ANT).

  • Thread: Post 1 at hash(“forum_v1:thread123:1”), {payload: “Hello”}. Post 2 at hash(“forum_v1:thread123:2”). PoW: 10ms, Fee: 0.001 ANT.

  • Index: hash(“forum_v1:index”) lists {thread123: hash(“forum_v1:thread123:1”)}.

  • Clients filter by schema, ignore sabotage.

Benefits:

  • Sabotage Resistance: No shared keys; client-side filtering ensures open logs, unlike counter-based methods.

  • No Squatting: Signed namespaces prevent conflicts, improving on infinite namespaces.

  • Discovery: Indices enable scalable navigation.

  • Feasibility: Uses existing chunks, encryption, and payments (post-TGE 2025). Total effort: 6-12 months, with CollaborativeLog in ~4 months.

6

I don’t see how? A Pointer’s address is a public key, and the Pointer’s signature has to match. I don’t know how to give a Pointer a name. Of course people can upload lists of name->pointer mappings, but then you’re searching a number of predefined lists, not searching the DHT itself (which is what Grok (and also I) would propose).

This is what I propose we make possible in the post I linked to earlier, but in GraphEntry/Pointer/Scratchpad rather than in chunks.

1 Like
7

Technical Solution: GraphEntry with Namespace-Constrained Key Addressing (NCKA)

The network’s hashtable restricts keys to public keys or content hashes, blocking arbitrary keys (e.g., “user.ant”) and enabling sabotage (e.g., thread locking) in public apps, per the 2025 content discovery thread. A community method maps names to mutable data using secret keys and a MAX_U32 counter, but names aren’t DHT-native, requiring external lists, risking squatting, and allowing sabotage via shared keys for collaborative apps.

GraphEntry with Namespace-Constrained Key Addressing (NCKA) enables sabotage-resistant, public logs with DHT-native addressing, using BLS signatures and payments.

  1. GraphEntry: Signed entries: {payload: JSON (1KB), metadata: {author: public_key, timestamp: uint64, schema_id: public_key, next_entry: public_key | null}}. Clients filter invalid entries via schemas (signed GraphEntries), ensuring open logs. Storage: DHT, signed, 8x replicated. Effort: 3-4 months.

  2. NCKA: Keys: derive_public_key(app_namespace + thread_id + entry_number). app_namespace: signed GraphEntry (BLS, 0.1 ANT, e.g., “forum_v1”). thread_id: hash(first_key). Double-hashed (SHA3-256). PoW: 10ms Argon2, 0.001 ANT fee, 100 entries/hour. Signed namespaces prevent squatting. Effort: 6-8 months.

  3. Distributed Index: GraphEntries list logs: {namespace: “forum_v1”, threads: {“thread123”: public_key}}. Consensus updates, 20ms PoW, 0.01 ANT fee. Effort: 2-3 months.

8

To address Seneca’s confusion and preference for signed data types, I’ve adapted the solution from CollaborativeLog (chunk-based) to GraphEntry with NCKA, using signed GraphEntries (addressed by public keys) with predictable, hash-based addressing. This aligns with the Pointers analysis’ goal of name-based mapping, Seneca’s DHT-based addressing vision, and the 2025 post’s need for sabotage-resistant, public apps.

  1. GraphEntry Data Type

  • Purpose: Append-only, signed entries for public logs (e.g., forum threads), preventing sabotage without shared keys.

  • Structure:

    • GraphEntry: {payload: JSON (max 1KB), metadata: {author: public_key, timestamp: uint64, schema_id: public_key, next_entry: public_key | null}}.

    • Signed with author’s BLS key, stored at a public key (BLS-generated).

    • Schema: Defines rules (e.g., {text: string, max_length: 500}), stored as a signed GraphEntry, referenced by schema_id (public key).

    • Linking: next_entry points to the next GraphEntry’s public key, forming an infinite chain. Latest entry has next_entry = null.

  • Operation:

    • Clients query from a known GraphEntry, follow next_entry keys.

    • Apps filter invalid entries (e.g., spam, non-compliant schema) client-side.

  • Storage: DHT, signed, replicated (8 copies), validated for BLS signature.

  • Sabotage Resistance: No shared keys; each entry is independently signed. Clients ignore invalid entries, ensuring open logs.

  • Implementation: 3-4 months (extend GraphEntry spec, update client libraries for chain parsing and schema filtering).

  1. Namespace-Constrained Key Addressing (NCKA)

  • Purpose: Enable predictable, infinite addressing for GraphEntries, mimicking arbitrary keys, aligning with Seneca’s hash(“forum_v1:thread123:N”) vision and Pointers’ name-based mapping.

  • Mechanism:

    • Keys: public_key = derive_public_key(app_namespace + thread_id + entry_number).

      • app_namespace: Registered as a signed GraphEntry (BLS, 0.1 ANT fee, e.g., “forum_v1”, max 32 bytes).

      • thread_id: hash(first_graphentry_public_key) (SHA3-256, 32 bytes).

      • entry_number: uint64 (supports ~2^64 entries).

      • derive_public_key: Generate BLS keypair from hash(app_namespace + thread_id + entry_number) (SHA3-256, double-hashed for security) as a seed, ensuring predictable public keys.

    • Example: GraphEntry 1 at derive_public_key(“forum_v1:thread123:1”), GraphEntry 2 at derive_public_key(“forum_v1:thread123:2”).

    • Clients predict keys (e.g., derive_public_key(“forum_v1:thread123:N+1”)) to append/read, enabling DHT-native addressing.

  • Storage: GraphEntries stored at derived public keys, mapped to DHT address space.

  • Security:

    • PoW: 10ms Argon2 per entry to deter node targeting (brute-forcing keys to overload nodes).

    • Payment: 0.001 ANT fee per entry, using post-TGE payment system (January 2025).

    • Namespace Registration: app_namespace stored as a signed GraphEntry, verified by BLS signature, preventing squatting.

    • Rate Limiting: 100 entries/hour per client, verified by signatures.

  • Mitigating Concerns:

    • Squatting: App-specific, signed namespaces (e.g., “forum_v1” ≠ “social_v1”) avoid conflicts, unlike Pointers’ infinite namespace.

    • Node Targeting: PoW and double-hashing match public key brute-force resistance, as noted in the 2025 post.

    • Sabotage: Independent keys eliminate shared-key risks, unlike Pointers.

  • Implementation: 6-8 months (extend DHT key derivation, implement PoW, fees, rate limits).

  1. Distributed Index

  • Purpose: Enable DHT-native discovery of GraphEntry logs, addressing Seneca’s concern about list-based searching.

  • Structure: GraphEntry: {namespace: “forum_v1”, threads: {“thread123”: public_key}}, stored at a public key (BLS-generated), signed.

  • Operation: Updated via consensus (closest nodes, BLS multisignatures) or ANT-holder votes. Clients query index for O(log n) lookup, then fetch logs via NCKA keys.

  • Security: 20ms PoW, 0.01 ANT fee, 1/day limit per namespace.

  • Implementation: 2-3 months (extend GraphEntry for indexing, add consensus rules).

Example: Forum Thread

  • Setup: “forum_v1” registered as a signed GraphEntry (BLS, 0.1 ANT).

  • Thread:

    • Post 1: GraphEntry at derive_public_key(“forum_v1:thread123:1”), {payload: “Hello”, metadata: {author: pubkey, timestamp: 2025-05-09}}, signed.

    • Post 2: derive_public_key(“forum_v1:thread123:2”).

    • PoW: 10ms, Fee: 0.001 ANT.

    • Clients filter by schema (e.g., text, max 500 chars), ignore sabotage.

  • Discovery: Index GraphEntry at a public key lists {thread123: derive_public_key(“forum_v1:thread123:1”)}, updated via consensus.

  • Security: PoW, fees, signed namespaces prevent abuse.

9

You can simply use the name (or the hash of the name - or the name and your app name) as seed for a deterministic key derivation.

from hashlib import sha256
from py_ecc.bls import G2ProofOfPossession as bls
from typing import Tuple
import hmac

def hkdf_mod_r(seed: bytes) -> int:
    """
    Derives a deterministic integer in the valid BLS private key range using HKDF.
    
    Args:
        seed: Arbitrary-length input seed as bytes.

    Returns:
        An integer in the range [1, r - 1], suitable as a BLS private key.
    """
    r: int = bls.curve_order  # The order of the BLS12-381 curve
    salt: bytes = b"BLS-SALT"
    info: bytes = b"BLS-KEYGEN"

    # Perform HKDF: extract
    prk: bytes = hmac.new(salt, seed, sha256).digest()
    # Expand phase with a fixed info string
    okm: bytes = hmac.new(prk, info + b"\x01", sha256).digest()

    # Convert to integer and mod by curve order
    i: int = int.from_bytes(okm, "big")
    return i % r

def bls_key_from_string_seed(seed_str: str) -> Tuple[int, bytes]:
    """
    Generates a deterministic BLS private/public key pair from a string seed.

    Args:
        seed_str: The input seed as a UTF-8 string.

    Returns:
        A tuple of (private key as int, public key as bytes).
    """
    seed_bytes: bytes = seed_str.encode("utf-8")
    privkey: int = hkdf_mod_r(seed_bytes)
    pubkey: bytes = bls.SkToPk(privkey)
    return privkey, pubkey
4 Likes
10

This reads like an AI answering

Are you using an AI for this?

3 Likes
11

The entire topic was created and assisted by Grok. I can only understand so much and stated as much in the OP. If it makes you feel any better, I am only concerned about a solution and am pleased with the responses so far.

1 Like
12

You and I share a secret key with the world.

You derive a new secret key for your pointer using secret_key.derive_child(“Seneca”) and use that to create a pointer.

To look that up (find the address of your pointer), I do the same secret_key.derive_child(“Seneca”).

And so can anyone else. We just use the same process and the same secret key.

7 Likes
13

And if you simply write an answer for a thread into a graphEntry instead of linking indirectly through a pointer you have the message chain as immutable data @Seneca

Answer-Adress = derived(message-content + message signature)… Or something similar..

Pretty similar to the proposal of project decorum with the Appendable data type initially..

Ofc it’s easy to spam and create entries that don’t make sense… But by introducing some pow (the answer needs to add 1 Binary to the seed until the hash is below xyz you could make spamming more expensive too… )

4 Likes
14

That’s pretty smart! It turns the deterministic key derivation effectively into a hash function. But of course it requires immutability to not allow anyone to change the content, so we don’t have a solution for when mutability is desired.

Honestly, with this trick present I don’t see any reason why not to change all the datatypes (aside from chunks) to work with a hash-based addressing directly. Any downsides to the system are already possible with this method. It’s just an artificial limitation on mutability now?

5 Likes
15

The mutability is in the History which the pointer points to (or a Register, or your own GraphEntry type).

5 Likes
16

Or you point to a pointer that you can then change…

Indirecting the addressed content

4 Likes
17

The problem I see is that we had no discussion around the design of the data types so we don’t know if they intended to prevent this kind of use, or have any concern about free updates to Scratchpads.

So we don’t know if they might suddenly decide to break any of these behaviours. If we knew the basis for restriction of data types we could infer what is and isn’t likely to be changed in future. But for now we are left building on sand.

3 Likes
18

Then you couldn’t add e.g. The pow as custom modification - oh well - ofc you could if the derivation is based on the hash value and not the seed :thinking: which then would just standardise the process a bit

19

Storage cost saving could be an argument. With the current system only a pubkey and signature has to be stored. If it’d be hash-based the network also needs to store the hash.

20

This workaround is not so easy to stop though, unless they’d let the Pointer counter overflow back to zero. But that’d create all sorts of other issues.

3 Likes