capture project athela
This commit is contained in:
987
org-inbox.org
987
org-inbox.org
@@ -8470,7 +8470,6 @@ Scraping for Sol: Use the Scraper Skill to monitor urban planning and LVT news,
|
|||||||
:CREATED: [2026-03-20 Fri 08:19]
|
:CREATED: [2026-03-20 Fri 08:19]
|
||||||
:END:
|
:END:
|
||||||
|
|
||||||
|
|
||||||
Building the local power once the logic is stable.
|
Building the local power once the logic is stable.
|
||||||
Server Rack Assembly: Build the 4080/4040 aluminum skeleton.
|
Server Rack Assembly: Build the 4080/4040 aluminum skeleton.
|
||||||
Local AI Capability: Install the RTX 6000 Pros. Move from remote APIs to local inference using Ollama/vLLM (DeepSeek-R1 / Qwen3-Coder).
|
Local AI Capability: Install the RTX 6000 Pros. Move from remote APIs to local inference using Ollama/vLLM (DeepSeek-R1 / Qwen3-Coder).
|
||||||
@@ -8621,6 +8620,992 @@ What do you think?
|
|||||||
|
|
||||||
But does it require escrow for future compensation. Should we develop a lean mechanism?
|
But does it require escrow for future compensation. Should we develop a lean mechanism?
|
||||||
|
|
||||||
|
*** Difference between natural persona and legal persona
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-03-21 Sat 02:54]
|
||||||
|
:END:
|
||||||
|
|
||||||
|
1. Natural Person: The "Dictator with Safety Nets"
|
||||||
|
For a human, the design goal is Ultimate Sovereignty. You are the "Root." Even if you have "Recovery Friends," they should have no power over you unless you are incapacitated.
|
||||||
|
The Logic: The Master Key holds a Priority Weight.
|
||||||
|
The Rotation Rule: The user’s primary key has a weight of 100. The "Recovery Friends" group has a collective weight of 100, but they can only be activated after a Time-Lock (e.g., 7 days of inactivity).
|
||||||
|
Non-Consensual Removal: Because the user holds the "100-weight" key, they can sign a "Rotation Event" at any time that simply deletes the Friends' public keys from the identity log. Since your weight is sufficient to meet the threshold alone, the system doesn't ask the friends for permission. You effectively "fire" your recovery team instantly.
|
||||||
|
2. Legal Entity: The "Protected Quorum"
|
||||||
|
For an LLC or NGO, the goal is Mutual Defense. You want to prevent a "hostile takeover" where one founder kicks out the others.
|
||||||
|
The Logic: All shareholder keys have Equal Weight (e.g., 3 shareholders, weight of 33 each).
|
||||||
|
The Rotation Rule (The Governance Gate): The threshold to post might be 2-of-3 (Simple Majority), but the threshold to change the board is set to 3-of-3 (Unanimity) or 75% (Super-majority).
|
||||||
|
Consent Requirement: If Shareholder A wants to remove Shareholder B, they need Shareholder B to sign the removal order (unlikely) or meet the super-majority threshold.
|
||||||
|
Veto Rights: You can designate a specific "Founder Key" that has Veto Power. This key must be among the signers for any rotation event to be valid, making that person impossible to remove without their own signature.
|
||||||
|
3. The "Legal Override": The Break-Glass Mechanism
|
||||||
|
To handle situations like a death, a lost key, or a court order, we use a Designated Guardian Delegate.
|
||||||
|
How it works: At inception, the identity includes a "Public Key" belonging to a Neutral Third Party (like a decentralized notary or a legal escrow service).
|
||||||
|
The Constraint: This key is "dormant." It has a weight of 0 for daily operations.
|
||||||
|
The Trigger: However, the identity’s code includes a rule: "If a certified Legal Attestation (signed by the local Court's Public Key) is presented, the Escrow Key's weight jumps to 100 for a single Rotation Event."
|
||||||
|
The Empowerment: This allows the law to intervene technically—not by "hacking" the account, but by using a pre-authorized, transparent back door that was agreed upon when the identity was created.
|
||||||
|
|
||||||
|
To prevent an escrow service or a "legal override" key from becoming a back door for surveillance or theft, we must implement a non-custodial, time-locked transparency architecture.
|
||||||
|
In this design, the escrow agent doesn't "hold" your identity; they hold a Permission to Propose a change. Here is the technical breakdown of how we ensure the agent cannot act without the owner (or the public) knowing and having a chance to stop it.
|
||||||
|
1. The "Observer-First" Transparency Log
|
||||||
|
Every identity in this network maintains a Key Event Log (KEL). This is a public, append-only ledger (similar to Certificate Transparency used for website security).
|
||||||
|
The Rule: Any change to the master key—including a legal override—must be published to this log before it becomes technically valid.
|
||||||
|
The Benefit: It is impossible for an escrow agent to "quietly" take over an account. The moment they attempt to use their key, every device the user owns (and any "watchdog" services they hire) receives an automated alert: "Warning: Escrow Key X has initiated a rotation event."
|
||||||
|
2. The "Veto Window" (Time-Locking)
|
||||||
|
We introduce a mandatory Delay Period for any rotation event initiated by a key that is not the "Primary" owner key.
|
||||||
|
Operational Flow: When the legal escrow initiates a recovery, the system enters a 72-hour Pending State.
|
||||||
|
The Owner's Veto: If the owner still has their primary key (e.g., the lawyer is acting maliciously), the owner can sign a "Veto & Revoke" message. Because the Owner Key has a higher priority in the identity's logic, their signature instantly kills the pending rotation and can even strip the escrow agent of their future recovery rights.
|
||||||
|
The "Dead Man's Switch": If the owner is truly incapacitated (the reason for recovery), they won't sign a veto, and after 72 hours, the escrow's change becomes "Final" in the log.
|
||||||
|
3. Multi-Party (M-of-N) Escrow
|
||||||
|
To prevent a single corrupt lawyer or government official from hijacking an identity, we use Threshold Escrow.
|
||||||
|
Technical Spec: Instead of one Escrow Key, you define a Recovery Council.
|
||||||
|
Example: To override an identity, you require signatures from 2-of-3 designated entities (e.g., a Notary, a Law Firm, and a Decentralized Oracle).
|
||||||
|
The Benefit: No single entity has the power to act alone. They would have to collude, which significantly raises the cost and risk of the attack.
|
||||||
|
4. Governance Logic: Personal vs. Corporate
|
||||||
|
You raised an excellent point about shareholders vs. parents. We handle this via Inception Policies defined at the moment the identity is created.
|
||||||
|
For the Natural Person (The "Sovereign" Policy)
|
||||||
|
Rule: The Primary Key has Absolute Priority.
|
||||||
|
Mechanism: The identity logic states: "Any rotation signed by Key A (User) is effective immediately. Any rotation signed by the Escrow Group requires a 72-hour delay and can be cancelled by Key A." This ensures the user is never "locked out" by their own safety net.
|
||||||
|
For the Legal Entity (The "Stakeholder" Policy)
|
||||||
|
Rule: Quorum Consensus is required for all state changes.
|
||||||
|
Mechanism: The logic states: "A rotation requires signatures from 3-of-4 shareholders. No single key can veto the others."
|
||||||
|
Protection: This prevents a CEO from "firing" the board and taking the company identity for themselves. The "consent" is baked into the math of the threshold. If a shareholder needs to be removed for legal reasons, it requires the quorum (or the legal override) to meet the pre-defined 75% threshold.
|
||||||
|
|
||||||
|
The Ultimate Fail-Safe: "Pre-Rotation"
|
||||||
|
One final technical detail: In the KERI protocol, we use Pre-rotation. When you create your current key, you also publish a hash of your next key. Even if a quantum computer breaks your current key tomorrow, the attacker can't "guess" your next key because you’ve already committed to it. This provides "forward security" that even a legal override can't easily bypass unless they follow the established protocol.
|
||||||
|
|
||||||
|
*** Delegated authoring permission
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-03-21 Sat 03:01]
|
||||||
|
:END:
|
||||||
|
|
||||||
|
Moving to the Data Layer: The "Multi-Sig" Social Feed
|
||||||
|
Now that we have a secure, governed Identity (with built-in banking via Lightning), how does this "Legal Person" actually interact with a social network without giving any one person too much power?
|
||||||
|
The "Company Post" Problem
|
||||||
|
Currently, if an LLC wants to tweet, they give a social media manager the password. That manager can go rogue and delete the account or post something offensive.
|
||||||
|
Our Solution: Cryptographic Delegated Signatures.
|
||||||
|
The Master Identity: The LLC identity (the DID) is the "Owner" of the social account.
|
||||||
|
The Delegation: The Board uses their multi-sig master key to sign a Delegation Certificate. This certificate says: "Employee X is allowed to post to our Social Persona for the next 30 days, but only if the post is under 280 characters."
|
||||||
|
The Signature: When Employee X posts, the social network sees two things:
|
||||||
|
Employee X’s personal signature.
|
||||||
|
The LLC’s delegation certificate.
|
||||||
|
The Result: The post appears as "Verified: [LLC Name]." If Employee X is fired, the board simply signs a Revocation to the identity log. The social network instantly stops accepting signatures from that employee's key.
|
||||||
|
4. Ownership of the Data "Silo"
|
||||||
|
In this model, the LLC's data (posts, customer lists, internal chats) doesn't live on a company server; it lives in a multi-sig PDS (Personal Data Server).
|
||||||
|
Non-Custodial Data: The data is encrypted. To read the LLC's private files, you need a key that is also derived from the master identity.
|
||||||
|
Access Control: You can grant "Read-Only" access to an auditor or "Read/Write" access to a manager. Because the access is tied to their DID, not a password, you can track exactly who accessed what data and when.
|
||||||
|
The "Exit" Strategy: If the LLC decides to move from one social network (Client A) to another (Client B), they don't have to "download" their data. They simply point Client B to their PDS. Because the LLC holds the master keys, Client A cannot stop them or "delete" their history.
|
||||||
|
|
||||||
|
*** Relays
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-03-21 Sat 03:04]
|
||||||
|
:END:
|
||||||
|
|
||||||
|
1. Who Runs the Relays?
|
||||||
|
Unlike centralized social media where one company runs all the servers, a decentralized ecosystem has three types of operators:
|
||||||
|
The "Backbone" Providers (Big Tech/NGOs): Large organizations (like Bluesky Social PBC or the "Free Our Feeds" collective) run "Global Relays." They ingest everything on the network to provide a "Google-like" search experience for the whole platform.
|
||||||
|
The "Neighborhood" Operators (NGOs & Communities): An NGO, a professional guild, or a town council might run a relay specifically for its members. They don't index the whole world; they only index the people their community cares about.
|
||||||
|
The "Specialists" (Commercial Startups): Companies like Primal or River run relays to power their own apps. They cover the costs because they want their specific mobile app to be the fastest and most feature-rich on the market.
|
||||||
|
2. How Do They Cover the Costs?
|
||||||
|
Running a relay is expensive—it requires high bandwidth and massive NVMe storage. To avoid the "Surveillance Capitalism" trap (selling your data), these operators use four alternative revenue models:
|
||||||
|
A. The "Anti-Spam" Entrance Fee
|
||||||
|
In the Nostr protocol, many high-quality relays require a one-time or monthly payment (often $1–$5) paid via Bitcoin Lightning.
|
||||||
|
Why it works: It’s too expensive for a bot-farm to pay $2 to 1,000 different relays, but it’s cheap for a human. This fee covers the hardware costs and keeps the feed "clean."
|
||||||
|
B. The "Boutique" Model (Freemium)
|
||||||
|
A relay might be free to "Read" (anyone can see the posts) but requires a subscription to "Write" (post your data there).
|
||||||
|
Example: A "Professional Photography" relay might charge $10/year. In exchange, they guarantee your high-res photos are always online and indexed in high quality for recruiters.
|
||||||
|
C. Institutional "Public Good" Funding
|
||||||
|
Governments and NGOs (like the European Union) are beginning to realize that running social media infrastructure is as vital as building roads.
|
||||||
|
The Model: They run "Public Interest Relays" funded by taxes or grants to ensure citizens have a place to communicate that is not controlled by a foreign corporation.
|
||||||
|
D. The "Zaps" & Micro-tips
|
||||||
|
Because we've integrated Lightning Keys into your Identity Persona (as we discussed earlier), users can "Zap" (tip) a relay operator instantly.
|
||||||
|
The Incentive: If a relay provides an amazing "No-AI" feed or a "Sports-Only" search index, users can send 10 cents here and there. At scale, thousands of micro-tips can sustain the server costs.
|
||||||
|
3. Resilience: Global Firehose vs. Fragmented Relays
|
||||||
|
One of the cleverest parts of this design is that Relays are replaceable.
|
||||||
|
If a Relay goes greedy: If a relay starts charging too much or censoring people, you simply tell your PDS to stop sending data to that relay and start sending it to a competitor.
|
||||||
|
The "Firehose" protection: Unlike Facebook, where if their server dies, your data dies—in this model, your data is "Multi-homed." You can push your posts to 5 different relays simultaneously. If 4 of them go bankrupt, the 5th one still has your entire history, and your followers can still find you.
|
||||||
|
|
||||||
|
*** Relay economics bootstrapping
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-03-21 Sat 03:05]
|
||||||
|
:END:
|
||||||
|
|
||||||
|
Yes, they absolutely can, and in the early stages of a decentralized network, this is actually a significant risk. We call these "Honeypot Relays."
|
||||||
|
Because a relay is just a server that sees your traffic, it is technically possible for an operator to offer a "free" service while secretly harvesting your metadata to sell to advertisers or analytics firms.
|
||||||
|
1. The "Metadata Harvesting" Trap
|
||||||
|
Even if your messages are encrypted, a relay sees a wealth of information that is highly valuable for "Surveillance Capitalism":
|
||||||
|
IP Addresses: They know exactly where you are and what device you're using.
|
||||||
|
Social Graph: They see who you talk to, how often, and who is in your inner circle.
|
||||||
|
Activity Patterns: They know when you wake up, when you’re most active, and what topics (tags) you interact with most.
|
||||||
|
Unencrypted Content: Unless you use end-to-end encryption (E2EE) for every single post, the relay can read your public posts and "read-only" data to build an interest profile on you.
|
||||||
|
2. Why "Decentralized Surveillance" is Weaker
|
||||||
|
While a relay can act like a mini-Facebook, it is fundamentally less powerful for three reasons:
|
||||||
|
No Walled Garden: On Facebook, if you leave, you lose your friends and your history. In this model, if you find out a relay is selling your data, you simply uncheck a box in your settings. You move to a new relay, and your followers find you instantly because your identity (DID) hasn't changed.
|
||||||
|
Fragmented Data: Most users connect to multiple relays simultaneously (e.g., one for home, one for work, one global). No single relay has the "whole picture" of your life unless you only ever use that one relay.
|
||||||
|
The "Tor" Option: Advanced users and LLCs can run their PDS through a VPN or Tor. This makes it impossible for the relay to see your true IP address, stripping away the most valuable piece of surveillance data.
|
||||||
|
3. The "Bootstrap Phase" Economics
|
||||||
|
Early in the network’s life, "Surveillance Relays" might be the only ones that are free and fast. This creates a "Bootstrap Trap":
|
||||||
|
The Lure: A big tech company might launch a massive, free, high-speed relay to capture the early market.
|
||||||
|
The Defense: As the network grows, "Privacy-First" relays (funded by the NGO dues or micro-tips we discussed) will emerge.
|
||||||
|
The Switch: Because your data is portable, the moment a better, more ethical relay exists, the entire community can migrate in a single day. In the old world, a migration takes a decade; in the decentralized world, it takes a click.
|
||||||
|
4. How an LLC or NGO Protects Itself
|
||||||
|
If you are running an organization, you shouldn't trust a "free" public relay for sensitive operations. Instead, you use a Tiered Relay Strategy:
|
||||||
|
Internal Relay: Your NGO runs its own private relay for internal board communications. This relay is "dark" to the public and collects zero data.
|
||||||
|
Public Gateway: You use the big "Surveillance" relays only for public PR and marketing posts. You treat these relays like "billboards"—you expect people to look at them, but you don't do your private business there.
|
||||||
|
|
||||||
|
*** Backups
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-03-21 Sat 03:07]
|
||||||
|
:END:
|
||||||
|
|
||||||
|
Backing Up at Trusted Friends (Social Redundancy)
|
||||||
|
To ensure you can regenerate your history even if your PDS is destroyed, we use a technique called Peer-to-Peer Social Caching.
|
||||||
|
A. The Gossip Protocol (Natural Caching)
|
||||||
|
In protocols like Secure Scuttlebutt (SSB) or Nostr, your "Social Graph" (the people who follow you) acts as your backup.
|
||||||
|
When you post, your data is pushed to your friends' devices.
|
||||||
|
Their apps "cache" your last 1,000 posts so they can show them to you offline.
|
||||||
|
The "Phoenix" Effect: If your server dies, your new PDS can "shout" to your friends' devices: "I am the owner of DID:123. Please send me everything you have signed by my key." Your history literally flows back to you from the people who care about you.
|
||||||
|
B. Encrypted Peer-Backups (The "Friend-Box")
|
||||||
|
For a more formal backup, you can use tools like Syncthing or BorgBackup between PDSs.
|
||||||
|
The Logic: You and three friends agree to "swap" 10GB of encrypted space.
|
||||||
|
The Result: Your PDS automatically sends an encrypted, compressed "State Snapshot" to your friends' servers every night. If your house burns down, you go to your friend, download the 10GB blob, and your entire digital life is restored.
|
||||||
|
3. Regenerating the Social Graph
|
||||||
|
The "Social Graph" (who you follow and who follows you) is actually just a list of DIDs. In this architecture, this list is part of your Identity Log.
|
||||||
|
The Proof: Every time you follow someone, you create a "Follow Event" signed by your Master Key.
|
||||||
|
The Log: This event is stored in your PDS, but also mirrored on the Relays and in your friends' caches.
|
||||||
|
The Rebuild: When you start a new PDS, the software scans the network for any "Follow Events" signed by your key. It mathematically reconstructs your list of 500 friends without you having to remember a single username.
|
||||||
|
4. Recovering the Master Key (Social Key Recovery)
|
||||||
|
If you lose the phone that holds your Master Key, the data backup is useless because you can't decrypt it. This is where Shamir’s Secret Sharing comes in.
|
||||||
|
The Tech: Your Master Key is mathematically split into 5 "Shards."
|
||||||
|
The Distribution: you give one shard to your brother, one to your best friend, one to your lawyer, etc.
|
||||||
|
The Recovery: To "regenerate" your key, you only need 3 out of 5 friends to click "Authorize" on their apps. Once the shards meet, your Master Key is reborn on your new device, and you can begin pulling your data back from your friends' PDSs.
|
||||||
|
|
||||||
|
*** Social mirroring
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-03-21 Sat 03:11]
|
||||||
|
:END:
|
||||||
|
|
||||||
|
1. The "Secure Scuttlebutt" (SSB) Pattern
|
||||||
|
The most established version of this is the Scuttlebutt protocol. In SSB, there are no central servers.
|
||||||
|
Following = Replicating: When you "follow" an NGO or a creator, your device automatically downloads their entire feed history and stores it on your local disk.
|
||||||
|
The Gossip Protocol: When your device connects to the internet (or even just to a friend’s phone via Wi-Fi), it "gossips" with other peers. If they have new posts from the NGO that you don't have yet, your phone pulls them. If you have posts they don't have, you push them.
|
||||||
|
The Result: The NGO’s content is mirrored on every single follower's device. To "delete" that NGO from the internet, you would have to physically destroy every single follower's phone.
|
||||||
|
2. High-Bandwidth: The "Follower-as-CDN" Model
|
||||||
|
For audio and video, you can’t store the entire history on every phone (it would take up too much space). Instead, we use BitTorrent-style "Seeding".
|
||||||
|
The "Pinning" Donation: A follower can click a button that says "Support this NGO with 5GB of storage." Their PDS (Personal Data Server) or app then "pins" the most recent videos from that NGO.
|
||||||
|
WebRTC Peering: When a new user tries to watch a video, the app doesn't go to the NGO's server. It looks for "Seeds" (other followers who are currently online). The video is streamed P2P from the followers' devices to the new viewer.
|
||||||
|
Scaling with Popularity: This creates a perfect economic loop: The more viral a video goes, the more people are watching it, and therefore the more "Seeds" there are to serve it. The "cost" of going viral becomes $0 for the creator because the fans provide the bandwidth.
|
||||||
|
3. "In-Kind" vs. "Monetary" Support
|
||||||
|
This transforms the relationship between an organization (like an LLC or NGO) and its community:
|
||||||
|
The "Poor but Loyal" Follower: Someone who can’t afford a $10/month subscription can instead "donate" their fiber-optic upload speed and 20GB of hard drive space.
|
||||||
|
Resilience against De-platforming: If a government blocks the NGO’s main website, the NGO simply tells its followers: "Turn on P2P mirroring." The content continues to circulate through the "Swarm," moving through the "cracks" of the internet via followers' devices.
|
||||||
|
|
||||||
|
*** Pay per view
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-03-21 Sat 03:14]
|
||||||
|
:END:
|
||||||
|
|
||||||
|
1. The "Encrypted Swarm" Logic
|
||||||
|
If you want to charge for a video, you cannot send the raw file into the P2P swarm. If you did, the first "seeder" would simply share the unencrypted version for free.
|
||||||
|
The Locked Box: The creator encrypts the video with a unique Symmetric Key.
|
||||||
|
The Distribution: This encrypted "Blob" is what followers replicate. They are hosting and seeding a file they cannot see. They are essentially a "Blind CDN" (Content Delivery Network).
|
||||||
|
The Key Market: To watch the video, the viewer needs the decryption key. This key is sold by the creator (or their PDS) via a Lightning Invoice.
|
||||||
|
2. The LSAT Protocol (The Smart Ticket)
|
||||||
|
To automate this for a software engineer, we use LSATs (Lightning Service Authentication Tokens).
|
||||||
|
How it works: When a user clicks "Play," the app sees it’s a "Paid Blob."
|
||||||
|
The 402 Challenge: The PDS sends back an HTTP 402 (Payment Required) error containing a Lightning Invoice and a "Macaroon" (a digital ticket).
|
||||||
|
The Unlock: Once the user pays the 100 sats (about $0.05), they get a Preimage (proof of payment). They send this back to the PDS, which then releases the Decryption Key.
|
||||||
|
The Result: The video decodes and plays instantly. The user’s device might have downloaded the data from a friend’s PDS (the swarm), but the permission to see it was bought from the creator.
|
||||||
|
3. Incentivizing the Seeders (Paid Seeding)
|
||||||
|
One of the most innovative features we can add is "Seeder Micro-Rewards." If a follower provides the bandwidth that allows a creator to go viral, the creator can choose to share the revenue with them.
|
||||||
|
The Split Payment: When the 100 sats are paid, the Lightning Network can "route" the payment such that:
|
||||||
|
90 sats go to the Creator.
|
||||||
|
5 sats go to the Relay (for indexing).
|
||||||
|
5 sats go to the Seeder (the follower who actually provided the data bits).
|
||||||
|
The Economic Shift: "Following" an NGO now becomes a way to earn a tiny amount of Bitcoin while supporting their mission. The better the content you seed, the more "tips" your server collects for providing the bandwidth.
|
||||||
|
|
||||||
|
|
||||||
|
*** Contacts
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-03-21 Sat 03:16]
|
||||||
|
:END:
|
||||||
|
|
||||||
|
Technical Specifications: Sovereign Contract & Arbitration Layer (SCAL)
|
||||||
|
Objective: To enable personas to execute binding Ricardian contracts (Human + Machine readable) with multi-tiered, decentralized dispute resolution.
|
||||||
|
1. The Ricardian Contract Module
|
||||||
|
A contract in this system is not a PDF; it is a Cryptographic Object composed of:
|
||||||
|
Natural Language (The Markdown): The human-readable terms (e.g., "Person A delivers 100 bricks to Person B by Friday").
|
||||||
|
Machine Logic (The JSON-LD): The executable parameters (e.g., due_date: 2026-01-16, price_sats: 50000, arbitrator_did: did:key:xyz).
|
||||||
|
The Merkle Link: Both parts are hashed together. If you change a comma in the text, the digital contract breaks. This ensures the "Code" and the "Law" are the same thing.
|
||||||
|
2. Payment & Escrow: The "HODL Invoice"
|
||||||
|
For service delivery, we use Lightning HODL Invoices. This is a trustless escrow that doesn't require a middleman to hold the money.
|
||||||
|
Commitment: The Buyer "pays" the invoice. The money leaves their wallet but is locked in the network.
|
||||||
|
The Proof: The Seller sees the money is locked and delivers the goods.
|
||||||
|
Settlement: Once the Buyer confirms receipt, they release the Preimage (the key), and the money instantly moves to the Seller.
|
||||||
|
Dispute: If there is a problem, the funds stay locked until an Arbitrator provides the key to either the Buyer (Refund) or Seller (Payout).
|
||||||
|
3. Multi-Level Arbitration (The "Circles" Model)
|
||||||
|
To address the "Weak Rule of Law," we use a tiered system of human judgment:
|
||||||
|
4. Enforcement: Social vs. Financial
|
||||||
|
In a weak rule-of-law environment, we use two "sticks" to ensure the contract is followed:
|
||||||
|
Financial Collateral: Both parties can be required to lock "Safety Deposits" in a 2-of-3 multisig before the contract begins.
|
||||||
|
Reputation Slashing (Social Enforcement): If a persona loses an arbitration and refuses to comply, their DID is "Flagged" across the entire network. Because their identity is persistent, they can't just delete their account. Their "Credit Score" in the community drops to zero, and they can no longer find work or trade.
|
||||||
|
|
||||||
|
|
||||||
|
*** Courts
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-03-21 Sat 03:18]
|
||||||
|
:END:
|
||||||
|
|
||||||
|
1. The Multi-Level "Court" Hierarchy
|
||||||
|
We mirror the traditional legal system but replace "jurisdiction by geography" with "jurisdiction by reputation and stake."
|
||||||
|
|
||||||
|
2. The Mechanics of an Appeal
|
||||||
|
In this system, an "Appeal" isn't a request to a boss; it's a Cryptographic Escalation:
|
||||||
|
Level 1 Ruling: The "Local Elder" rules. If both parties accept, the HODL invoice settles.
|
||||||
|
The Trigger: If one party disagrees, they pay an "Appeal Fee" (to prevent spam). This fee funds the next level of jurors.
|
||||||
|
The Escalation: The contract logic automatically "unlocks" the case for Level 2 (The Guild). The data (evidence, previous ruling) is pushed to the new panel.
|
||||||
|
Finality: Level 3 is the "Final Court of Appeal." Once the Global Jury rules, the cryptographic keys are released, and the smart contract executes the payment automatically—no human can stop it.
|
||||||
|
|
||||||
|
3. Why this works in "Weak States"
|
||||||
|
In a country where the police won't help you collect a debt, this system provides Self-Executing Justice:
|
||||||
|
The "Escrow Stick": The money is already gone from the buyer's wallet (locked in Lightning).
|
||||||
|
The "Reputation Stick": In a decentralized society, your DID is your livelihood. Losing your "Trust Score" is a digital death sentence for your business
|
||||||
|
|
||||||
|
*** Governance
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-03-21 Sat 03:23]
|
||||||
|
:END:
|
||||||
|
|
||||||
|
1. The Governance "Stack"
|
||||||
|
Governance in this system operates at three distinct scales, mirroring the human organization patterns we've built:
|
||||||
|
Micro-Governance (The Persona/Household): Decisions made by a single seed holder or a small family multi-sig (e.g., "Who can spend from the grocery Lightning wallet?").
|
||||||
|
Meso-Governance (The NGO/LLC/Circle): Decisions made by a defined group using Weighted Voting (e.g., "Should our NGO hire this contractor?").
|
||||||
|
Macro-Governance (The Protocol/Network): Decisions that affect everyone (e.g., "Should we upgrade the PDS data schema to version 2.0?").
|
||||||
|
2. Voting Mechanisms
|
||||||
|
Traditional "One-token, One-vote" often leads to plutocracy (the rich rule). To build a healthy social network, the engineer must implement more nuanced math:
|
||||||
|
Quadratic Voting: The cost of a vote increases by the square of the votes cast (cost = votes^2). This prevents a single whale from drowning out 1,000 small voices. It prioritizes the intensity of preference across the community.
|
||||||
|
Conviction Voting: Voters don't just "click a button." They "stake" their preference over time. The longer you hold your vote on a proposal, the more weight it gains. This rewards long-term thinkers and prevents "flash-mob" takeovers of community policy.
|
||||||
|
Liquid Democracy: You can delegate your "Moderation Vote" to a friend you trust. If that friend stops being trustworthy, you instantly pull your delegation back.
|
||||||
|
3. The "Constitution as Code" (Executable Policies)
|
||||||
|
An NGO in this system doesn't just have a "handbook." It has a Smart Constitution stored on its PDS.
|
||||||
|
Policy Triggers: If a vote passes to "Change the Arbitration Fee," the system doesn't wait for a human to update the website. The Contract Module (from our previous spec) automatically updates the fee parameter across all the NGO's active contracts.
|
||||||
|
The "Veto" Safety: High-impact changes (like moving the Treasury) can have a Time-Lock. The vote passes, but execution is delayed by 7 days. This gives the community a "Cooling-Off Period" to trigger a counter-vote if they suspect foul play.
|
||||||
|
|
||||||
|
*** The algorithm
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-03-21 Sat 03:25]
|
||||||
|
:END:
|
||||||
|
|
||||||
|
To a software engineer, the Algorithm Layer is the "Information Router." In traditional social media, the algorithm is a secret "Black Box" that sits between you and your friends, deciding what you see to maximize ad revenue.
|
||||||
|
In our design, we move the algorithm out of the server and into a Marketplace of Feed Generators. This allows users to "hire and fire" the logic that sorts their attention.
|
||||||
|
1. The "Feed Generator" Architecture
|
||||||
|
Instead of one giant "For You" algorithm, we use a pluggable API.
|
||||||
|
The "Skeleton" Request: When you open your app, it doesn't ask the server for "The Feed." It sends a request to a Feed Generator (which can be run by anyone—an NGO, a scientist, or a group of friends).
|
||||||
|
The Response: The Generator doesn't send the actual posts (it doesn't have your data). It sends a "Skeleton"—a list of IDs (CIDs) of posts it thinks you'll like.
|
||||||
|
Hydration: Your app then takes that list of IDs and "hydrates" them by pulling the content directly from your friends' PDSs or Relays.
|
||||||
|
2. The Algorithm Marketplace
|
||||||
|
Because the API is open, different organizations can compete to provide the best "curation" services:
|
||||||
|
|
||||||
|
*** User journey
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-03-21 Sat 03:28]
|
||||||
|
:END:
|
||||||
|
|
||||||
|
Phase 1: Onboarding (The Birth of the Persona)
|
||||||
|
Download & Seed: The user downloads the app. The first thing it does is generate a Seed Phrase (the Master Key).
|
||||||
|
Persona Creation: The user doesn't create a "Username." They create two Personas: "Work" and "Social." Behind the scenes, the app derives two different DIDs from the same Master Key.
|
||||||
|
The Founder Connection: For a minor, the parent scans a QR code to "Co-sign" the identity, setting up the Succession Logic we discussed.
|
||||||
|
PDS Selection: The user is asked: "Where would you like to store your data?" They select a Community PDS run by a local NGO they trust.
|
||||||
|
Phase 2: Consumption & "Seeding" (The Data Economy)
|
||||||
|
Choosing a Lens: The user goes to the "Marketplace" and selects the "Scientific Signal" Algorithm. Their feed instantly rearranges to show verified research.
|
||||||
|
Micro-Earning: The user watches a video. A toggle in their settings is on: "Support this creator by seeding." While they watch, their phone serves bits of the video to 3 other nearby users via WebRTC.
|
||||||
|
The Reward: Because they provided bandwidth, the creator’s PDS sends a "Thank You" of 5 sats ($0.002) directly to the user’s Lightning wallet. It’s small, but it covers the cost of their PDS hosting for the month.
|
||||||
|
Phase 3: The Civil Contract (Digital Law)
|
||||||
|
The Deal: User A wants to buy a custom chair from User B.
|
||||||
|
The Contract: They click "Create Contract." They select a Markdown Template for "Handmade Goods."
|
||||||
|
Arbitration Choice: They both agree to use the "Carpenters' Guild" as the Level 2 Arbitrator.
|
||||||
|
The Lock: User A pays the invoice. The funds move into a HODL Escrow. User B sees the "Funds Locked" status and starts building.
|
||||||
|
The Delivery: User B delivers the chair. User A scans a QR code on the chair, which releases the Preimage, instantly paying User B.
|
||||||
|
|
||||||
|
*** Comms
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-03-21 Sat 03:35]
|
||||||
|
:END:
|
||||||
|
|
||||||
|
1. Asynchronous Communication (Correspondence & Messaging)
|
||||||
|
We use the DIDComm (Decentralized Identifier Communication) protocol. This is a transport-agnostic standard for secure, private communication.
|
||||||
|
The Mailbox (PDS as Proxy): Because your phone isn't always online, your PDS acts as an encrypted "Post Office."
|
||||||
|
Sending: You encrypt a message using the recipient's Persona Public Key (found in their DID Document).
|
||||||
|
Routing: The message is sent to the Service Endpoint listed in their DID (their PDS).
|
||||||
|
Storage: The PDS stores the encrypted "envelope." It cannot read it.
|
||||||
|
Pickup: When the recipient's phone wakes up, it fetches the envelope, decrypts it locally, and deletes the copy from the PDS.
|
||||||
|
Contextual Isolation: Because you have multiple Personas, the "Work" Persona and "Dating" Persona have separate message queues. A message sent to your "Work DID" never touches the inbox of your "Dating DID."
|
||||||
|
2. Synchronous Communication (Live Voice & Video)
|
||||||
|
For real-time calls, we use WebRTC, but with a decentralized twist for the Signaling phase.
|
||||||
|
Decentralized Signaling: Usually, WebRTC requires a central server to help two phones "find" each other. In our system, the DIDComm channel we just described handles the handshake.
|
||||||
|
Persona A sends a "Call Request" via DIDComm to Persona B's PDS.
|
||||||
|
Persona B's phone receives the request and sends back its IP/ICE candidates (the "digital map" to find the phone).
|
||||||
|
Peer-to-Peer Tunnel: Once the handshake is done, the voice/video data flows directly between the two devices. No server—not even the PDS—sees the call data.
|
||||||
|
3. Encryption Standards: Beyond "Just E2EE"
|
||||||
|
To a developer, "End-to-End Encryption" is the baseline. We need Perfect Forward Secrecy (PFS) and Post-Compromise Security.
|
||||||
|
Double Ratchet Algorithm (Signal Protocol): Every single message uses a new, derived key. If a hacker somehow steals one key, they can't use it to read past messages or future ones.
|
||||||
|
Metadata Masking: We use Tor-style Onion Routing between PDSs when possible. This hides the "Traffic Pattern," making it impossible for a network observer to see that Persona A is talking to Persona B.
|
||||||
|
|
||||||
|
*** Physical to digital assets
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-03-21 Sat 03:36]
|
||||||
|
:END:
|
||||||
|
|
||||||
|
1. Digital Twins & Tokenization
|
||||||
|
In our system, a physical asset (a car, a house, a shipment of bricks) is represented by a Digital Twin.
|
||||||
|
The Digital Passport: This is a Verifiable Credential (VC) issued by a trusted entity (a manufacturer, a community inspector, or a professional guild) to one of your Personas.
|
||||||
|
Tokenization: For high-value assets, the Persona can "mint" an NFT-like token on their PDS or a sidechain. This token represents the "Legal Title."
|
||||||
|
Fractionalization: An NGO can tokenize a community building, allowing 1,000 members to own 0.1% each. Their voting power in the Governance (GEM) layer is then tied to these tokens.
|
||||||
|
2. Physical Collateral in Civil Contracts
|
||||||
|
How do you use a physical asset to secure a loan or a contract in a "weak state"?
|
||||||
|
The Pledge: You link the Digital Twin (the token) to a Civil Contract.
|
||||||
|
The Lock: The smart contract logic "freezes" the token. You still have the physical object, but you cannot sell or transfer the digital title until the contract is fulfilled.
|
||||||
|
The "IoT Stick" (Optional): For high-stakes assets (like a tractor or factory machine), an IoT sensor can be bound to the contract. If the Arbitration (HDR) rules that you defaulted on your payment, the contract can send a signal to the machine's "Smart Lock" to disable it until the debt is settled.
|
||||||
|
|
||||||
|
*** Executive summary
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-03-21 Sat 03:38]
|
||||||
|
:END:
|
||||||
|
|
||||||
|
Project Goal: To replace extractive, centralized social platforms with a decentralized "Social Operating System" that provides Identity, Justice, and Commerce for sovereign individuals and communities.
|
||||||
|
The Problem
|
||||||
|
Current social networks are built on "Digital Feudalism," where platforms own user data, control visibility via secret algorithms, and provide no legal protection for users in regions with weak state institutions.
|
||||||
|
The Solution: Aletheia
|
||||||
|
Aletheia is a modular protocol stack that returns power to the edges:
|
||||||
|
Sovereign Identity: Users manage multiple "Personas" from a single seed, preventing surveillance and "context collapse."
|
||||||
|
Mutual-Aid Infrastructure: Data is hosted by "Social Clouds"—communities backing up each other’s encrypted data, ensuring unbannable history.
|
||||||
|
Self-Executing Law: Integrated civil contracts with tiered, human-led arbitration allow for global trade without relying on local corrupt courts.
|
||||||
|
The Attention Marketplace: Users choose their own "Algorithm Filters," turning the "Feed" into a tool for empowerment rather than addiction.
|
||||||
|
A Circular Economy: Built-in Bitcoin micro-payments reward users for seeding data, creating a self-sustaining network where "following" is an act of investment.
|
||||||
|
Immediate Roadmap
|
||||||
|
MVP Release: Basic PDS hosting with Persona-based messaging (DIDComm).
|
||||||
|
Commerce Beta: Integration of Lightning HODL invoices for simple peer-to-peer services.
|
||||||
|
Justice Rollout: Launch of the first "Professional Guilds" to provide arbitration services.
|
||||||
|
Tokenized Assets: Enabling the bridging of physical inventory into the contract layer.
|
||||||
|
|
||||||
|
*** Unified content and feed
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-03-21 Sat 03:39]
|
||||||
|
:END:
|
||||||
|
|
||||||
|
1. Unified Content Schema
|
||||||
|
Instead of having different databases for different types of content, we use a universal Event Object. The app looks at the "Type" field and adjusts the interface accordingly.
|
||||||
|
If Type = "ShortVideo": The UI enables the "TikTok-style" vertical scroll and auto-play.
|
||||||
|
If Type = "AudioStream": The UI switches to a "Podcast" player with 1.5x speed and background play.
|
||||||
|
If Type = "MarketplaceListing": The UI adds a "Buy Now" button linked to a HODL Invoice.
|
||||||
|
2. The "Single Feed" with Multiple Lenses
|
||||||
|
Imagine your data is a single pile of bricks. One app (the "Instagram Lens") looks for bricks that contain high-resolution photos. Another app (the "Etsy Lens") looks for bricks that contain price tags and shipping info.
|
||||||
|
The Content is Fluid: You could post a 10-minute video.
|
||||||
|
One user sees it in their "YouTube View" (with comments and related videos).
|
||||||
|
Another user sees it in their "Educational View" (where the algorithm has filtered it alongside academic papers).
|
||||||
|
A third user sees just the audio in their "Podcast View" while driving.
|
||||||
|
|
||||||
|
*** Hardware wallet
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-03-21 Sat 03:42]
|
||||||
|
:END:
|
||||||
|
|
||||||
|
1. The Key Device (The Sovereign Root)
|
||||||
|
You use a dedicated, offline device (a hardware wallet or an air-gapped laptop) to generate the Master Seed.
|
||||||
|
Hardened Derivation: On this offline device, you derive your Personas using Hardened Paths (e.g., m/9000'/0', m/9000'/1').
|
||||||
|
The Firewall: Because you use Hardened derivation, even if a phone is stolen and a Persona Private Key is extracted, the thief cannot "climb up" the tree to find the Master Seed or even discover that other Personas exist.
|
||||||
|
2. The Provisioning Workflow (Air-Gapped Transfer)
|
||||||
|
To get a Persona onto your phone without the Master Seed:
|
||||||
|
On the Key Device: You generate the Extended Private Key (xpriv) for only the specific Persona (e.g., Persona #2).
|
||||||
|
The Transfer: You display this Persona xpriv as a QR code or save it to an encrypted microSD.
|
||||||
|
On the Phone: You scan/import that specific Persona key.
|
||||||
|
Result: Your phone now has the power to act as Persona #2 (sign messages, spend sats, enter contracts), but it has zero knowledge of your Master Seed or your other Personas.
|
||||||
|
|
||||||
|
3. The Security "Trade-off"
|
||||||
|
The Phone's Private Keys: Yes, the phone holds the private keys for the active Persona. This is necessary because the phone needs to sign "Live" events (sending a message, liking a post, paying for a coffee).
|
||||||
|
The "Kill Switch": If the phone is stolen, you go to your Key Device (the Master) and issue a Key Rotation Event. Because the Master is the "Parent," it has the cryptographic authority to tell the network: "Persona #2's old key is now void; here is the new public key for Persona #2." * The Result: The thief holds a useless key, and you regain control of your identity using a new phone.
|
||||||
|
|
||||||
|
Final Project Component: The "Vault" Device
|
||||||
|
For a software engineer, this means building a small Companion App or a Web-USB tool specifically for the "Key Device" that handles:
|
||||||
|
Master Seed Generation.
|
||||||
|
Persona "Export" (QR/File).
|
||||||
|
Emergency Recovery/Rotation.
|
||||||
|
|
||||||
|
*** Phone theft
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-03-21 Sat 03:45]
|
||||||
|
:END:
|
||||||
|
|
||||||
|
To address the scenario of a stolen phone and ensure the thief is "locked out" of historical data, we need to implement a strategy called Cryptographic Rotation with Content Re-keying.
|
||||||
|
When a phone is stolen, the thief has the Persona Private Key for that specific device. Even if you "rotate" to a new key, the old encrypted files on the PDS can still be opened by that stolen key unless we take further action.
|
||||||
|
1. The Solution: Envelope Encryption (Data-at-Rest)
|
||||||
|
To make re-encryption efficient, a software engineer should use Envelope Encryption. Instead of encrypting a large video file directly with your Persona Key, you do the following:
|
||||||
|
The Content Key (DEK): Each file is encrypted with a random, unique symmetric key (the Data Encryption Key).
|
||||||
|
The Wrapped Key (KEK): This small DEK is then encrypted (wrapped) with your Persona Public Key.
|
||||||
|
The Storage: The PDS stores the [Encrypted File] + [Wrapped DEK].
|
||||||
|
In the Event of Theft:
|
||||||
|
Rotation: You use your Key Device (The Master) to generate a new Persona Key and publish a "Rotation Event" to the network.
|
||||||
|
Re-Wrapping: Your PDS (or your new phone) doesn't need to re-download and re-encrypt the massive video file. It only needs to:
|
||||||
|
Decrypt the tiny Wrapped DEK using your old key (or a recovery key).
|
||||||
|
Re-encrypt that same DEK with your New Persona Public Key.
|
||||||
|
Purge: The PDS deletes the old "Wrapped DEK."
|
||||||
|
Result: The thief has the old private key, but the PDS no longer provides the "envelope" that the key can open. The massive encrypted file remains on the server, but it is now cryptographically invisible to the thief
|
||||||
|
|
||||||
|
2. The "Vault" Device Guide (For the Engineer)
|
||||||
|
The "Vault" is a dedicated application for an offline/hardware device that manages the Master Seed.
|
||||||
|
Functional Requirements for the Vault Tool:
|
||||||
|
Seed Generation: Must use a high-entropy hardware RNG to generate the BIP-39 mnemonic.
|
||||||
|
Persona Derivation: Must implement a hardened derivation logic where the user can "Export Persona #N."
|
||||||
|
Key Rotation Signer: This is the most important feature. If a phone is lost, the Vault device creates a DID Update Transaction. This is a cryptographically signed message that says: "I am the Master Seed; I hereby revoke Persona Key A and authorize Persona Key B."
|
||||||
|
Recovery Seed Export: The Vault should allow exporting a "Recovery Key"—a special key used specifically for the "Re-Wrapping" process mentioned above.
|
||||||
|
|
||||||
|
*** Recovery
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-03-21 Sat 03:50]
|
||||||
|
:END:
|
||||||
|
|
||||||
|
In our worst-case scenario simulation, the "Key Device" (the air-gapped Master Seed holder) is physically lost or destroyed. Since the Master Seed never touched your phone or any other online device, we are at a critical juncture: The root of your identity tree is gone.
|
||||||
|
To prevent a total loss of your digital life, the software engineer must implement Social Recovery and Threshold Cryptography during the initial setup phase.
|
||||||
|
1. The Recovery Simulation: "The Broken Root"
|
||||||
|
Without a pre-planned recovery strategy, losing the Master Seed means you can never rotate your Persona keys again. If your phone is then stolen, you are permanently locked out. To solve this, we use Shamir’s Secret Sharing (SSS).
|
||||||
|
The Split: When you first generated your Master Seed on the Vault device, it was cryptographically split into 5 "Shares."
|
||||||
|
The Distribution: You distributed these shares to 5 trusted "Guardians" (this could be 5 close friends, or 3 friends + 1 safe deposit box + 1 lawyer).
|
||||||
|
The Threshold: You set a "3-of-5" threshold. No single guardian can see your seed, and even if two of them conspire, they still have zero information.
|
||||||
|
2. The Restoration Workflow
|
||||||
|
The Trigger: You realize your Vault device is destroyed.
|
||||||
|
The Gathering: You contact your guardians. Using their own "Aletheia" apps, they sign a Recovery Fragment.
|
||||||
|
The Reconstruction: You buy a brand new "Key Device." You scan the 3 fragments from your guardians. The new device performs the Lagrange Interpolation math to rebuild your original Master Seed.
|
||||||
|
Full Recovery: Your identity tree is restored. You can now issue a new rotation event to secure your existing Personas.
|
||||||
|
|
||||||
|
*** Web gateway
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-03-21 Sat 03:52]
|
||||||
|
:END:
|
||||||
|
|
||||||
|
To make decentralized, P2P content accessible to people on the "Open Web" (traditional browsers like Chrome or Safari without special plugins), we must bridge the gap between Content-Addressed Data and Location-Addressed URLs.
|
||||||
|
We do this using a Gateway Architecture. Think of a gateway as a "translator" that sits on the edge of the decentralized network and talks HTTP to the rest of the world.
|
||||||
|
1. The HTTP Gateway (The Bridge)
|
||||||
|
In our system, every PDS (Personal Data Server) or a dedicated "Public Relay" can act as a web gateway.
|
||||||
|
The URL Mapping: A piece of content identified by its hash (CID) like bafy...123 can be viewed by anyone at a URL like:
|
||||||
|
https://aletheia-gateway.org/ipfs/bafy...123
|
||||||
|
The Translation: When a browser hits that link, the Gateway:
|
||||||
|
Fetches the data from the P2P swarm (using the protocols we designed).
|
||||||
|
Verifies the cryptographic signature against the creator's Persona DID.
|
||||||
|
Wraps the content in standard HTML/CSS so it looks like a normal webpage.
|
||||||
|
2. Human-Readable Handles (DNS & ENS)
|
||||||
|
Most people won't share a long hash (CID). To make it "web-friendly," we use DNSLink or .limo style routing.
|
||||||
|
Personal Handles: A user can point their own domain (e.g., alice.com) to their Persona.
|
||||||
|
Automatic Resolution: When someone visits alice.com, the Gateway sees a DNS record that says: "Go find content hash XYZ on the Aletheia network."
|
||||||
|
Web3 Domains: For those using .eth or .p2p names, we use gateways like Eth.limo. You simply type yourname.eth.limo into a standard browser, and the gateway does the heavy lifting of resolving the blockchain record and serving the P2P data.
|
||||||
|
3. Social Mirroring for Search Engines (SEO)
|
||||||
|
To ensure your content shows up on Google, we use Aggregators/Indexers.
|
||||||
|
The Firehose: Relays emit a "Firehose" of every public post.
|
||||||
|
SEO Rendering: A specialized "App View" (like a web-frontend) consumes this firehose and generates static, crawlable pages. This allows Google's bots to index the decentralized content just like a traditional blog or news site.
|
||||||
|
|
||||||
|
*** AI integration
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-03-21 Sat 03:53]
|
||||||
|
:END:
|
||||||
|
|
||||||
|
Integrating AI into the "Sovereign Stack" transforms it from a static database into an active, intelligent ecosystem. In this architecture, AI isn't a central "God-eye" controlling you; it is a Personal Assistant or a Community Curator that you own and direct.
|
||||||
|
1. The Decentralized AI Architecture
|
||||||
|
To keep AI sovereign, we distribute the three pillars of machine learning: Compute, Data, and Models.
|
||||||
|
Local Inference (On-Device): Your phone or PDS runs small, optimized models (like Llama-3-8B or Mistral) for privacy-sensitive tasks.
|
||||||
|
Decentralized Compute Swarms: For heavy tasks (like generating 4K video or training a guild-wide model), the network taps into the spare GPU power of the community. Nodes that provide "Compute" are rewarded with sats, creating a P2P AI Marketplace.
|
||||||
|
Privacy-Preserving Training: Using Federated Learning, an NGO can train a custom algorithm on its members' data without ever seeing that data. The members' devices compute "updates," which are then combined into a new model version.
|
||||||
|
2. AI Personas as "Digital Agents"
|
||||||
|
In our system, AI doesn't just "chat"—it has its own DID (Decentralized Identifier).
|
||||||
|
Delegated Authority: You can spawn an "AI Agent Persona" from your Master Seed. You delegate specific rights to it: "You are authorized to spend 1,000 sats/month to buy research papers and summarize them for me."
|
||||||
|
Verifiable Origins: Because every AI post is signed by its Agent-DID, you can instantly distinguish between "Human-Signed" and "AI-Signed" content in your feed.
|
||||||
|
|
||||||
|
*** Static websites
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-03-21 Sat 03:55]
|
||||||
|
:END:
|
||||||
|
|
||||||
|
Because we’ve already built the "Gateway" and "Identity" layers, publishing a website becomes a native feature of the network rather than a separate hosting service.
|
||||||
|
1. How a Persona "Hosts" a Website
|
||||||
|
To a software engineer, publishing a website in this system follows the same logic as a "Post," but with a different metadata type.
|
||||||
|
The Content Bundle: You use a Static Site Generator (SSG) like Hugo, Jekyll, or Next.js to build your site.
|
||||||
|
The CID Root: You upload the folder to your PDS. The network generates a single Content Identifier (CID) for the root folder.
|
||||||
|
The Persona Link: Your Persona signs a "Publish Event" that links your DID to that CID.
|
||||||
|
Example: did:key:persona1 -> bafy...root_hash.
|
||||||
|
2. Accessing the Website
|
||||||
|
Because the "Open Web" doesn't speak P2P naturally, we use the Gateway architecture we designed earlier to serve the site to standard browsers.
|
||||||
|
|
||||||
|
3. Why this is better than "Standard" Hosting
|
||||||
|
Unstoppable Content: Since the site is P2P, if your PDS goes down, any other node (or a "Pinning Service") that has cached your CID can continue to serve your website.
|
||||||
|
Zero-Configuration SSL: Gateways handle the HTTPS certificates automatically for any domain linked to a Persona.
|
||||||
|
Built-in Monetization: You can combine this with the Commerce Layer. You could host a "Static" site where certain pages are only "unwrapped" and served if the user’s browser provides a Lightning Preimage (proof of payment).
|
||||||
|
The "Aletheia" Portfolio Use Case
|
||||||
|
A freelance photographer can now:
|
||||||
|
Generate a portfolio using a static site generator.
|
||||||
|
Publish it to the network via their "Professional Persona."
|
||||||
|
Link it to a civil contract for hiring.
|
||||||
|
All from one interface.
|
||||||
|
|
||||||
|
*** Naming
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-03-21 Sat 03:57]
|
||||||
|
:END:
|
||||||
|
|
||||||
|
In a decentralized system without a central naming authority, the best way to handle "usernames" is to use Subdomains provided by your PDS (Personal Data Server) or a Community Hub.
|
||||||
|
This follows the AT Protocol (Bluesky) model, where your identity is a permanent cryptographic string (the DID), but your handle is a human-readable domain name.
|
||||||
|
1. The Subdomain Model (The "Default" Handle)
|
||||||
|
If you don't have yourname.com, your PDS provider (e.g., the NGO or community hub hosting your data) grants you a subdomain of their own address.
|
||||||
|
Logic: username.provider.org
|
||||||
|
Example: If you join the "Aletheia Global" hub, your handle would be alice.aletheia.social.
|
||||||
|
Technical Link: The hub's DNS contains a TXT record at _atproto.alice.aletheia.social that points to your unique DID (did:key:xyz...).
|
||||||
|
2. Multi-Persona Naming
|
||||||
|
Since you have multiple Personas (Legal, Social, Professional), you need a way to refer to them specifically. The software engineer should implement a Persona-Suffix convention.
|
||||||
|
|
||||||
|
Format Example
|
||||||
|
Primary/Legal name.provider.org john.aletheia.social
|
||||||
|
Professional name-pro.provider.org john-pro.aletheia.social
|
||||||
|
Anonymous/Alt alias.provider.org night-owl.aletheia.social
|
||||||
|
|
||||||
|
3. Web3 Naming Services (ENS)
|
||||||
|
If you want a username that isn't tied to a specific PDS provider, you can use a Decentralized Naming Service like ENS (Ethereum Name Service).
|
||||||
|
How it works: You register yourname.eth. You can then create Unlimited Subnames for free (e.g., work.yourname.eth, social.yourname.eth).
|
||||||
|
Portability: If you move your data from one PDS to another, your .eth name stays with you. You just update the "Content Hash" record on the blockchain to point to your new PDS.
|
||||||
|
|
||||||
|
*** Name search
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-03-21 Sat 04:00]
|
||||||
|
:END:
|
||||||
|
|
||||||
|
In a truly decentralized network, Global Search isn't a single website (like Google); it is a Service Layer that you choose to subscribe to.
|
||||||
|
Because there is no central database, search requires "Aggregators" or "Relays" to watch the public firehose of data and index it for everyone else. Here is how your engineer would implement this across your different username types (subdomains, custom domains, and .eth).
|
||||||
|
1. The Indexer "Firehose"
|
||||||
|
All public posts, profile updates, and username registrations are broadcast as Signed Events.
|
||||||
|
The Indexer's Job: A search provider (which could be an NGO or a commercial entity) runs a massive database that "listens" to the network. It catalogs every Handle <-> DID mapping it sees.
|
||||||
|
Multi-Format Support: When you search for "@alice," the indexer looks across:
|
||||||
|
Subdomains: alice.aletheia.social
|
||||||
|
Custom Domains: alice.com
|
||||||
|
Web3 Names: alice.eth
|
||||||
|
2. Verified Search Results
|
||||||
|
Because we use DIDs, the search engine can guarantee the results are authentic.
|
||||||
|
The Problem: In a decentralized world, anyone can claim to be "Alice."
|
||||||
|
The Solution: The Search UI shows a "Verified" checkmark only if the handle (e.g., alice.com) has a valid cryptographic back-link to the DID. If someone tries to squat on a username without owning the domain, the search engine flags them as "Unverified."
|
||||||
|
|
||||||
|
3. "Privacy-First" Search
|
||||||
|
Since our network supports Private Personas, search must be opt-in:
|
||||||
|
Public Personas: (e.g., your "Work" persona) are indexed and searchable by anyone.
|
||||||
|
Private Personas: (e.g., your "Anonymous" persona) are hidden from global indexers. To find a private persona, someone must have your exact DID or be invited via a private DIDComm message.
|
||||||
|
|
||||||
|
*** Technical Specifications: Sovereign Identity & Data Protocol (SIDP)
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-03-21 Sat 03:09]
|
||||||
|
:END:
|
||||||
|
|
||||||
|
Objective: To build a decentralized social infrastructure that decouples identity, data, and finance from platform operators, enabling user-led governance and mutual-aid hosting.
|
||||||
|
1. Identity Architecture (The Root)
|
||||||
|
The system shall utilize a Hierarchical Sovereign Identity (HSI) model based on the W3C DID (Decentralized Identifier) standard.
|
||||||
|
Master Root (Level 0): A BIP-32/44 Seed Phrase or Master Key.
|
||||||
|
Natural Person: Controlled via Priority Weights (Owner = 100).
|
||||||
|
Legal Person (LLC/NGO): Controlled via M-of-N Thresholds (Quorum consensus).
|
||||||
|
Derivation Paths (Personas & Profiles):
|
||||||
|
Personas (Level 1): Cryptographically separated identities (e.g., m/purpose'/persona_index'/).
|
||||||
|
Profiles (Level 2): Context-specific metadata (Social, Professional, Dating) tied to a Persona.
|
||||||
|
Functional Keys (Level 3):
|
||||||
|
Bitcoin/Lightning: BIP-44/84/1017 paths for on-chain and LN Node IDs.
|
||||||
|
Encryption: PGP/NACL keys for End-to-End Encryption (E2EE).
|
||||||
|
Authentication: SSH/WebAuthn keys.
|
||||||
|
2. Governance & Lifecycle Management
|
||||||
|
The identity must remain persistent regardless of key rotations, managed via KERI (Key Event Receipt Infrastructure).
|
||||||
|
Key Event Log (KEL): An append-only, verifiable history of all key rotations and membership changes.
|
||||||
|
Founder/Parent Logic:
|
||||||
|
Genesis: Identities can be initialized by "Founders" (Parents for minors, Board for LLCs) using a threshold signature.
|
||||||
|
Succession: Automated or manual transfer of control (e.g., 2-of-3 Parent/Child moves to 1-of-1 Adult).
|
||||||
|
Legal Override & Escrow:
|
||||||
|
Implementation of Time-Locked Recovery.
|
||||||
|
Veto Window: A mandatory 72-hour delay on recovery events, allowing the primary owner to invalidate unauthorized rotations.
|
||||||
|
3. Data Layer: Personal Data Servers (PDS)
|
||||||
|
Data must be portable, content-addressed, and decoupled from the application UI.
|
||||||
|
PDS Architecture: Multi-tenant-ready Dockerized environments.
|
||||||
|
Storage: * Metadata/Social Graph: JSON-LD signed events (Nostr/ActivityPub hybrid).
|
||||||
|
Blobs (Video/Audio): Content-addressable hashes (IPFS/S3) with WebRTC-based P2P mirroring for high-bandwidth delivery.
|
||||||
|
Mutual-Aid Hosting (Social Cloud):
|
||||||
|
Encrypted Peer-Backups: Automated, encrypted state snapshots synced between trusted "Friend PDSs."
|
||||||
|
History Regeneration: Automated reconstruction of the social graph by querying Relays for all events signed by the Master DID.
|
||||||
|
4. Infrastructure & Scaling
|
||||||
|
Relays: High-availability indexers that ingest the PDS "Firehose."
|
||||||
|
Economic Model: Support for NIP-05/Lightning payments for relay access fees to prevent spam/surveillance incentives.
|
||||||
|
Relay Resilience: Multi-homed posting (Client pushes to N relays simultaneously).
|
||||||
|
Metadata Protection: PDS-to-Relay transport layer should support VPN/Tor tunneling to obfuscate IP addresses.
|
||||||
|
|
||||||
|
5. P2P Replication & Social Seeding
|
||||||
|
The system must support altruistic data mirroring to ensure high availability and censorship resistance.
|
||||||
|
Mirroring Policy (Follower-Side):
|
||||||
|
Apps must include a "Seeding" toggle.
|
||||||
|
Users can designate a Storage Quota (e.g., "Seed up to 1GB for my Top 5 followed profiles").
|
||||||
|
Content Addressing (CID): * All data (posts, images, video) must be hashed using IPFS-style CIDs. This ensures that even if a follower provides a replica, the receiver can verify it was signed by the original Master Key and hasn't been tampered with.
|
||||||
|
Gossip Dissemination: * Implementation of Epidemic Broadcast Trees (EBT) or Nostr-style relay discovery to let followers know when a "Pinned" profile has published new content.
|
||||||
|
Bandwidth Delegation (WebRTC): * For high-bandwidth "Blobs" (Video), the client should utilize a P2P streaming library (like WebTorrent or HLS over WebRTC). This allows the "Swarm" of active viewers to serve as a distributed Content Delivery Network (CDN).
|
||||||
|
|
||||||
|
6. The "Identity-Data" Linkage
|
||||||
|
Verification: The replica is only valid if the follower can provide the Proof of Provenance (the signature of the Persona that created the data).
|
||||||
|
Privacy: Followers replicate Public Data by default. Private/Encrypted Data can be replicated as "Encrypted Blobs"—followers host the data but cannot see the contents, providing a "Blind Backup" service for the creator.
|
||||||
|
|
||||||
|
7. Content Monetization & LSAT Integration
|
||||||
|
The system shall implement a Pay-per-Access model using the LSAT (Lightning Service Authentication Token) standard.
|
||||||
|
Encryption at Rest: * All premium content must be encrypted using AES-256 (or equivalent) before being published to the PDS/Relay.
|
||||||
|
The encrypted blob is identified by a unique CID (Content Identifier).
|
||||||
|
The LSAT Workflow:
|
||||||
|
Request: Client requests a CID.
|
||||||
|
Challenge: Server issues an LSAT Macaroon + Lightning Invoice.
|
||||||
|
Payment: Client pays via LN and receives a Preimage.
|
||||||
|
Redemption: Client submits {Macaroon + Preimage} to the Key-server/PDS.
|
||||||
|
Key Release: Server returns the symmetric decryption key.
|
||||||
|
Incentivized Swarms (Seeder Rewards):
|
||||||
|
Proof of Delivery: Seeders can provide "signed receipts" of bits delivered to a peer.
|
||||||
|
Attestation: The creator's PDS can include a Split Invoice logic where the viewer's payment is distributed among the top N seeders identified in the metadata.
|
||||||
|
|
||||||
|
8. The "Key-Server" Module
|
||||||
|
The PDS must include a Key-Management Module that handles the automated sale and distribution of decryption keys.
|
||||||
|
Privacy Note: The Key-server must be separate from the Data-server so that the entity holding the "keys" is not necessarily the same entity hosting the "blobs."
|
||||||
|
|
||||||
|
9. Ricardian Contract Schema
|
||||||
|
The PDS must support a standard ContractEvent type:
|
||||||
|
Participants: Array of DIDs (Buyer, Seller, Arbitrator).
|
||||||
|
Legal_Text_CID: IPFS hash of the human-readable terms.
|
||||||
|
Condition_Logic: Boolean triggers for payment release (e.g., "Require 2-of-3 signatures to settle").
|
||||||
|
Arbitration_Clause: Defines the Escalation_Path (Circle -> Guild -> Jury).
|
||||||
|
10. Multi-Sig / HODL Management
|
||||||
|
Escrow Service: The client app must interface with the PDS to manage Lightning HODL Invoices.
|
||||||
|
Timeout Logic: Contracts must include a CLTV-expiry (CheckLockTimeVerify). If the arbitrator doesn't rule within 30 days, the funds are automatically returned to the Buyer to prevent "Forever-Locks."
|
||||||
|
11. Proof-of-Delivery (Oracles)
|
||||||
|
Physical Goods: Support for "Scanning a QR code" on delivery, which automatically releases the payment.
|
||||||
|
Digital Goods: Support for Zero-Knowledge Proofs (ZKP) where the payment is released automatically once the file hash is verified as correct.
|
||||||
|
|
||||||
|
|
||||||
|
12. Hierarchical Dispute Resolution (HDR) Protocol
|
||||||
|
The system shall implement a tiered arbitration framework to settle ContractEvents.
|
||||||
|
|
||||||
|
|
||||||
|
Web of Trust (WoT) Integration:
|
||||||
|
Arbitrators at Level 1 are selected based on Transitive Trust (e.g., "Find a person trusted by both parties within 3 degrees of separation").
|
||||||
|
The UI must show an "Elder Badge" for accounts that have successfully resolved >50 disputes with a high "Fairness Score."
|
||||||
|
|
||||||
|
|
||||||
|
Escalation path logic
|
||||||
|
|
||||||
|
{
|
||||||
|
"arbitration_policy": {
|
||||||
|
"tier_1": { "type": "social_circle", "quorum": 1, "fee": "0" },
|
||||||
|
"tier_2": { "type": "expert_guild", "quorum": 3, "fee": "5000_sats" },
|
||||||
|
"tier_3": { "type": "global_jury", "quorum": "sqrt(n)", "fee": "25000_sats" }
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
|
||||||
|
Reputation Slashing (Social Collateral):
|
||||||
|
Each DID shall have a public "Justice Ledger" attached to its profile.
|
||||||
|
If a user refuses to follow a final (Tier 3) ruling, the system issues a "Negative Attestation." * This attestation is mirrored across all Relays. Other apps will see this "Red Flag" and automatically block that user from entering into future high-value contracts.
|
||||||
|
|
||||||
|
13. Ricardian Evidence Vault
|
||||||
|
Evidence Submission: Parties upload encrypted "Evidence Blobs" to their PDS.
|
||||||
|
Selective Disclosure: Using Zero-Knowledge Proofs (ZKPs) or Shared Keys, the parties grant the current level of arbitrators temporary read-access to the evidence without making it public.
|
||||||
|
Audit Trail: Every ruling, appeal, and evidence hash is stored in the Key Event Log (KEL) for that contract, creating a verifiable record of the "trial."
|
||||||
|
|
||||||
|
14. Governance Executable Module (GEM)
|
||||||
|
The PDS must support a GovernanceEngine that processes ProposalEvents.
|
||||||
|
Proposal Schema:
|
||||||
|
Proposer_DID: The identity initiating the change.
|
||||||
|
Action_Payload: The specific code/parameter change to be executed (e.g., Update_Fee_Schedule).
|
||||||
|
Voting_Logic: Defined algorithm (Simple Majority, Quadratic, Conviction).
|
||||||
|
Quorum_Threshold: Minimum DID participation required for validity.
|
||||||
|
Reputation-Weighted Voting:
|
||||||
|
Integrates with the HDR (Judicial) layer.
|
||||||
|
DIDs with higher "Fairness Scores" or longer "Network Tenure" may be granted higher voting weights in specific "Expert" categories (e.g., Technical Upgrades).
|
||||||
|
15. The Community Treasury (Multi-Sig Vault)
|
||||||
|
Wallet Integration: Governance logic must be able to trigger Lightning/On-chain multisig transactions.
|
||||||
|
Automated Payroll: Support for "Streaming Payments" (e.g., X sats per block) that are automatically paused if a "Stop Work" governance vote reaches a threshold.
|
||||||
|
16. Moderation & "The Algorithm" (Social Governance)
|
||||||
|
Community Filters: Communities can vote on "Global Blocklists". If 70% of an NGO's members flag a specific DID as a "Spam Bot," that DID is automatically hidden from all members' feeds.
|
||||||
|
Curated Feeds: A community can vote to "Pin" certain content creators to a shared "Featured" feed, creating a decentralized editorial board.
|
||||||
|
|
||||||
|
17. Pluggable Feed Generation (PFG) API
|
||||||
|
The system must support an Open Feed Protocol where the Client App is decoupled from the Sorting Logic.
|
||||||
|
Feed Discovery:
|
||||||
|
Algorithms are identified by their own DID (Decentralized Identifier).
|
||||||
|
Users "Subscribe" to an algorithm by adding its DID to their PDS metadata.
|
||||||
|
The getFeedSkeleton Workflow:
|
||||||
|
Request: Client → AppView (proxied to Feed Generator DID).
|
||||||
|
Auth: Request is signed by the User's Persona key (to allow for personalized results).
|
||||||
|
Return: A JSON list of post_CIDs and reason metadata (e.g., "Reason: Your friend liked this").
|
||||||
|
Display: The Client hydrates the CIDs from the local cache or Relay.
|
||||||
|
Algorithm Privacy: * Support for Private Feed Generators. An NGO can run a feed that is only accessible to DIDs on their "Member List," preventing outsiders from seeing internal community highlights.
|
||||||
|
18. Decentralized Moderation (Labelers)
|
||||||
|
Moderation is treated as "Competitive Labeling" rather than "Censorship."
|
||||||
|
Labeler DIDs: Independent services that "tag" content (e.g., "Spam," "Graphic," "High-Quality").
|
||||||
|
Client-Side Filtering: The user's app pulls these labels and applies the user's personal policy (e.g., "Hide anything labeled 'Graphic' by the NGO 'SafetyFirst'").
|
||||||
|
Stackable Moderation: Users can subscribe to multiple labelers simultaneously (e.g., a "Fact Checker" labeler + a "Church Group" labeler).
|
||||||
|
|
||||||
|
19. UX/UI Requirements (The "Abstraction" Layer)
|
||||||
|
The engineer must ensure that the complexity of DIDs and CIDs is hidden behind a familiar interface.
|
||||||
|
Key Management: The app must use Biometric Unlock (FaceID/Fingerprint) to sign transactions. The user should never see a raw private key during daily use.
|
||||||
|
Status Indicators: * "Seeding Now": A subtle icon showing the user is currently providing P2P bandwidth.
|
||||||
|
"Protected by [NGO Name]": Verification of which PDS/Relay is currently handling their data.
|
||||||
|
20. The "Action-Trigger" API
|
||||||
|
The app must handle Asynchronous Events for the Judicial and Governance layers.
|
||||||
|
|
||||||
|
Notification scheme
|
||||||
|
|
||||||
|
|
||||||
|
.{
|
||||||
|
"event_type": "CONTRACT_DISPUTE_INITIATED",
|
||||||
|
"action_required": "SUBMIT_EVIDENCE",
|
||||||
|
"deadline": "2026-01-20T12:00:00Z",
|
||||||
|
"current_tier": 1
|
||||||
|
}
|
||||||
|
|
||||||
|
Auto-Execution: The PDS must be capable of "listening" for finalized Jury results and automatically releasing keys/funds without the user being online.
|
||||||
|
|
||||||
|
18. Persona Derivation Path
|
||||||
|
The software must implement a standard derivation path to ensure interoperability between different wallet apps.
|
||||||
|
Path: m/purpose' / persona_index' / profile_index / key_type
|
||||||
|
Hardened Personas: The persona_index MUST be hardened to prevent correlation attacks.
|
||||||
|
19. Cross-Persona Interaction (The "Bridge")
|
||||||
|
The system shall allow a user to "Attest" that two personas belong to the same human without revealing the master seed.
|
||||||
|
Use Case: Your "Pseudonymous Developer" persona can prove it has the "Verified Citizen" badge from your "Legal Persona" via a Zero-Knowledge Proof (ZKP). You prove you are a citizen without revealing which citizen you are.
|
||||||
|
20. Profile Metadata (JSON-LD)
|
||||||
|
Profiles are non-cryptographic "wrappers" around the Persona's DID.
|
||||||
|
|
||||||
|
{
|
||||||
|
"context": "https://www.w3.org/ns/did/v1",
|
||||||
|
"id": "did:key:persona_1_id",
|
||||||
|
"profiles": [
|
||||||
|
{
|
||||||
|
"type": "Professional",
|
||||||
|
"data": { "title": "Lead Architect", "skills": ["Solidity", "Rust"] }
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"type": "Commerce",
|
||||||
|
"data": { "currency": "BTC", "shipping_region": "EU" }
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
|
|
||||||
|
21. Secure Communication Module (SCM)
|
||||||
|
The system shall implement the DIDComm v2 specification for all non-public interactions.
|
||||||
|
Message Format: JWM (JSON Web Messages) wrapped in a JWE (JSON Web Encryption) envelope.
|
||||||
|
Encryption Suite: X25519 for key agreement, AES-256-GCM for content encryption.
|
||||||
|
Asynchronous Forwarding: PDS must support the Forward message type, acting as an encrypted relay for offline delivery.
|
||||||
|
22. Real-Time Adjudication (VoIP/Video)
|
||||||
|
Signaling: Handshakes for WebRTC MUST be conducted over an authenticated DIDComm channel.
|
||||||
|
Relay (TURN): If a direct P2P connection fails (due to strict firewalls), the system shall utilize Community TURN Servers where the traffic is encrypted with the same keys used for the call, ensuring the relay is "blind."
|
||||||
|
23. Physical-to-Digital Asset Bridging (The "Vault")
|
||||||
|
NFC/QR Binding: The app must support "Binding" a physical object to a Digital Persona.
|
||||||
|
Verifiable Credentials (VC): When a user buys a physical asset (like the chair in our journey), the Seller issues a Verifiable Credential to the Buyer's Persona. This VC is the "Digital Deed."
|
||||||
|
Hardware Security: High-value keys (the Master Seed) should be stored in the device's Secure Enclave or a hardware wallet, never in the app's general memory.
|
||||||
|
|
||||||
|
24. Physical Asset Linking (PAL) Protocol
|
||||||
|
The system must support the mapping of physical objects to DIDs using Tamper-Evident Identifiers.
|
||||||
|
Hardware Binding: Use of NFC tags or specialized QR codes that, when scanned, provide a Proof of Authenticity signed by the original issuer's DID.
|
||||||
|
Digital Deeds (VCs): Asset ownership must be stored as a W3C Verifiable Credential within the user's Persona-specific data vault.
|
||||||
|
25. The Hardware Security Module (HSM)
|
||||||
|
To protect these assets, the "Master Seed" must be treated with bank-grade security.
|
||||||
|
Cold Storage Integration: The app must allow "Deep Cold" Personas where the keys never touch an internet-connected device (e.g., using a hardware wallet like Ledger or Keystone).
|
||||||
|
Multi-Sig Assets: High-value community assets (like a shared warehouse) should require a 3-of-5 signature from different community members to be moved or used as collateral.
|
||||||
|
26. Final System Map for the Engineer
|
||||||
|
|
||||||
|
Component Function Technology
|
||||||
|
Persona Tree Identity & Privacy BIP-32/44 + DID
|
||||||
|
PDS Data Sovereignty Docker + IPFS/NoSQL
|
||||||
|
DIDComm Private Communication JWE + Double Ratchet
|
||||||
|
HODL Invoices Financial Escrow Lightning Network
|
||||||
|
Digital Twins Physical Assets Verifiable Credentials
|
||||||
|
HDR Engine Justice/Courts Ricardian Smart Contracts
|
||||||
|
GEM Engine Community Rules Quadratic
|
||||||
|
|
||||||
|
27. Universal Event Schema (UES)
|
||||||
|
The PDS must support a polymorphic event structure based on ActivityStreams 2.0.
|
||||||
|
|
||||||
|
{
|
||||||
|
"id": "did:key:abc#event_123",
|
||||||
|
"actor": "did:key:persona_legal",
|
||||||
|
"type": "Create",
|
||||||
|
"object": {
|
||||||
|
"type": "Video",
|
||||||
|
"mimeType": "video/mp4",
|
||||||
|
"url": "cid:bafy...",
|
||||||
|
"metadata": {
|
||||||
|
"aspectRatio": "9:16",
|
||||||
|
"duration": 60,
|
||||||
|
"price": "500_sats"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
"signature": "..."
|
||||||
|
}
|
||||||
|
|
||||||
|
|
||||||
|
28. "View" Discovery & Rendering
|
||||||
|
MIME-Type Dispatcher: The client app must include a rendering engine that dispatches the UI based on the object.type and metadata.
|
||||||
|
Metadata Extensions: Apps can define "Custom Namespaces" for specific services (e.g., an Etsy-like view looks for an ext:ecommerce namespace to handle inventory and shipping).
|
||||||
|
|
||||||
|
29. Decoupled Key Provisioning
|
||||||
|
The app shall support Subkey Injection rather than requiring a Master Seed.
|
||||||
|
Persona Import: The client must allow importing a standalone xpriv or privKey for a specific derivation index.
|
||||||
|
Key Scoping: The app must restrict its operations to the scope of the imported key. It shall not attempt to derive "sibling" personas.
|
||||||
|
Multi-Device Sync: Users can "Invite" a second device (like a tablet) by sharing a Persona-level subkey, ensuring the Master Seed stays in a physical safe.
|
||||||
|
30. Watch-Only Master (Optional)
|
||||||
|
Master XPUB: The phone can optionally store the Master Public Key (xpub).
|
||||||
|
Function: This allows the phone to see all Personas and their balances/activities for monitoring, but it lacks the private keys to authorize any actions. This is the "Auditor View."
|
||||||
|
|
||||||
|
31. Mandatory Envelope Encryption
|
||||||
|
All data marked as "Private" or "Paid" must utilize the Envelope Encryption pattern.
|
||||||
|
Cipher: AES-256-GCM for Content; X25519 for Key Wrapping.
|
||||||
|
Metadata: The Wrapped DEK must be stored in a separate KeyHeader object, indexed by the Persona DID.
|
||||||
|
32. Automated Re-Keying Service
|
||||||
|
The PDS shall include a background worker that triggers upon a KEY_ROTATION_EVENT.
|
||||||
|
Action: Iterate through all KeyHeader objects belonging to the revoked DID.
|
||||||
|
Migration: Re-encrypt headers using the new KeyWrappingKey.
|
||||||
|
Security: The PDS must never see the raw Master Seed. Re-keying is performed by the User's New Device (which has the old and new Persona keys) or via a Proxy Re-Encryption (PRE) scheme if the user wants the PDS to do it without seeing the content.
|
||||||
|
|
||||||
|
33. Shamir’s Secret Sharing (SSS) Integration
|
||||||
|
The Vault device software must support the SLIP-0039 standard (the industry standard for Shamir backups).
|
||||||
|
Thresholding: Mandatory "M-of-N" setup during master seed creation.
|
||||||
|
Share Verification: Guardians must be able to verify their share is still valid without revealing the secret (using a VSS - Verifiable Secret Sharing scheme).
|
||||||
|
34. The "Dead Man's Switch" (Protocol Level)
|
||||||
|
To prevent assets from being "lost forever" if you disappear, the engineer shall implement a Time-Locked Recovery.
|
||||||
|
The Watcher: A smart contract or a "Guardian Persona" monitors your activity.
|
||||||
|
The Trigger: If your Master DID has zero "Key Activity" for 12 months, a pre-designated Inheritance Key is authorized to initiate a recovery.
|
||||||
|
The Safety: You receive a "Warning Notification" every month leading up to the trigger. A single "Heartbeat" signature from your phone resets the 12-month clock.
|
||||||
|
|
||||||
|
35. Public Gateway API
|
||||||
|
The PDS/Relay shall implement a Public HTTP Resolver.
|
||||||
|
Pathing: Support for /ipfs/{cid} and /at/{did}/{collection}/{rkey}.
|
||||||
|
CORS Policy: Must allow cross-origin requests to enable decentralized apps (dApps) to fetch media directly from any PDS.
|
||||||
|
MIME-Type Sniffing: The gateway must correctly serve headers (e.g., Content-Type: video/mp4) based on the UES (Universal Event Schema) metadata.
|
||||||
|
36. DNSLink & Well-Known Support
|
||||||
|
/.well-known/atproto-did: The PDS must serve the user's DID at this endpoint to allow standard domain names to be verified as identities.
|
||||||
|
Automatic SSL: The gateway should automatically provision Let's Encrypt certificates for any mapped custom domains.
|
||||||
|
|
||||||
|
37. AI Agent Personas (AAP)
|
||||||
|
The system shall treat AI Agents as first-class citizens with their own DIDs.
|
||||||
|
Parent-Child Linking: AI Agent DIDs must include a controller field pointing to the Human Persona that owns them.
|
||||||
|
Restricted Capabilities: The app must allow "Capabilities-based Security," where an agent is cryptographically barred from signing Civil Contracts or moving assets unless a multi-sig threshold with the human is met.
|
||||||
|
38. Plug-and-Play Inference (Ollama/Local Integration)
|
||||||
|
The PDS shall include a standard Inference Proxy API.
|
||||||
|
Workflow: When the user selects a "Smart Filter," the PDS routes the data through a local Ollama instance or a community-run vLLM node.
|
||||||
|
Prompt Transparency: The "System Prompt" for every algorithm must be public and verifiable. If an NGO claims their algorithm is "unbiased," the community can inspect the actual weights and prompt instructions.
|
||||||
|
39. Distributed Reputation Oracles
|
||||||
|
AI can be used as a Tier 0 Arbitrator.
|
||||||
|
The "Sanity Check": Before a human enters the HDR (Judicial) process, a local AI analyzes the evidence and provides a "Likely Outcome" report.
|
||||||
|
Automated Labeling: AI agents can act as "Labelers" (as described in v1.6), tagging millions of posts for quality, spam, or sentiment, which users can then choose to "Listen to" or ignore.
|
||||||
|
|
||||||
|
40. Static Asset Resolver (SAR)
|
||||||
|
The PDS must include a module that can interpret a directory CID as a web root.
|
||||||
|
Index Resolution: If a request hits a folder CID without a filename, the PDS must automatically serve index.html.
|
||||||
|
Relative Pathing: All assets (images, scripts) must be referenced using Relative URLs to ensure the site functions correctly regardless of which gateway or local node is serving it.
|
||||||
|
|
||||||
|
41. Automated Deployment Pipeline
|
||||||
|
Git Integration: The Vault or a CLI tool should support "Push-to-Publish." When the engineer pushes code to a repo, a GitHub Action (or local script) builds the site, signs the result with the Persona key, and updates the PDS.
|
||||||
|
Versioning: Every "Publish Event" is recorded in the Persona's signed history. This allows for Instant Rollbacks—to revert the website, the Persona simply signs a new event pointing to a previous CID.
|
||||||
|
|
||||||
|
42. Handle Resolution Protocol
|
||||||
|
The system shall support two methods for resolving a handle (e.g., alice.aletheia.social) to a DID.
|
||||||
|
Method A: DNS TXT: The client queries the DNS for a record at _atproto.alice.aletheia.social.
|
||||||
|
Method B: HTTPS Well-Known: The client fetches https://alice.aletheia.social/.well-known/atproto-did.
|
||||||
|
Validation: To prevent "spoofing," the DID document returned by the PDS must contain a back-link to the handle.
|
||||||
|
43. Automated Subdomain Issuance
|
||||||
|
The PDS software must include a "Registrar Service."
|
||||||
|
Request: User signs up with a desired username.
|
||||||
|
Availability Check: PDS checks its internal database.
|
||||||
|
Creation: If available, the PDS automatically updates its Virtual Host configuration and internal DNS to route traffic for newuser.pds-domain.com.
|
||||||
|
|
||||||
|
44. The Aggregator API (Search Provider)
|
||||||
|
The system must support a SearchService endpoint that the Client App can query.
|
||||||
|
Query Format: GET /xrpc/org.aletheia.search.query?q=keyword
|
||||||
|
Response Schema: Returns a list of DIDs + Handles + Profile_Snaps.
|
||||||
|
Ranking Transparency: The provider must publish its Ranking Logic (e.g., "We prioritize accounts with 3+ Web-of-Trust endorsements").
|
||||||
|
45. Cross-Namespace Resolution
|
||||||
|
The Search Indexer must implement a "Resolver Bridge":
|
||||||
|
Handle Lookup: If a search matches a .eth name, the indexer queries the ENS Smart Contract on Ethereum to find the associated DID.
|
||||||
|
DNS Lookup: If it matches a .com, it checks the _atproto DNS record.
|
||||||
|
Local Index: If it matches a PDS subdomain, it checks its local cache of the PDS "User Directory."
|
||||||
|
|
||||||
|
**** Master Architecture Document: Project Aletheia
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-03-21 Sat 04:05]
|
||||||
|
:END:
|
||||||
|
|
||||||
|
Version: 1.0 (January 2026)
|
||||||
|
Status: Design Baseline
|
||||||
|
Concept: A Sovereign Social Operating System (S-SOS)
|
||||||
|
1. System Philosophy & Objectives
|
||||||
|
Aletheia is designed to solve "Digital Feudalism" by decoupling Identity, Data, and Logic from central platforms.
|
||||||
|
Sovereignty: Users own their keys (DIDs) and data (PDS).
|
||||||
|
Privacy: Multi-persona architecture prevents context collapse and mass surveillance.
|
||||||
|
Commerce: Built-in Lightning Network payments for services and data seeding.
|
||||||
|
Justice: Cryptographic civil law contracts with decentralized arbitration.
|
||||||
|
2. Core Architectural Pillars
|
||||||
|
2.1 Identity: Hierarchical Multi-Persona Model
|
||||||
|
The Root: A Master Seed (BIP-39) kept offline on a "Vault Device."
|
||||||
|
Personas: Hardened child keys (BIP-44) derived from the root. Each Persona is a distinct DID (did:key or did:plc).
|
||||||
|
Profiles: Contextual metadata views (Social, Work, Dating) signed by a Persona.
|
||||||
|
Security: If a phone is stolen, the Vault Device issues a Key Rotation Event to revoke the compromised Persona key without exposing the Master Seed.
|
||||||
|
2.2 Data: Personal Data Servers (PDS) & Relays
|
||||||
|
PDS: A user’s personal "Social Cloud." It stores signed events (posts, likes) and encrypted blobs (media).
|
||||||
|
Relays (The Firehose): Aggregators that crawl PDS nodes to create a global, searchable stream of public data.
|
||||||
|
Mirroring: Community nodes provide encrypted backups for one another, ensuring data remains unbannable and resilient.
|
||||||
|
2.3 Economy: The Lightning Layer
|
||||||
|
Incentivized Seeding: Users earn micro-sats for providing P2P bandwidth (WebRTC) for media delivery.
|
||||||
|
Pay-to-View: Creators can wrap content in HODL Invoices, requiring a payment preimage to unlock the decryption key.
|
||||||
|
Direct Support: Integrated tipping and subscription logic at the protocol level.
|
||||||
|
2.4 Justice: Sovereign Contract & Arbitration (SCAL)
|
||||||
|
Ricardian Contracts: Human-readable terms hashed with machine-executable logic.
|
||||||
|
Multi-Level Arbitration:
|
||||||
|
Tier 1: Social Circle (Web of Trust).
|
||||||
|
Tier 2: Professional Guilds (Verified Experts).
|
||||||
|
Tier 3: Global Jury (Staked Random Crowds).
|
||||||
|
Enforcement: Cryptographic escrow (HODL) and reputation "slashing" attestations.
|
||||||
|
3. Communication & Privacy
|
||||||
|
Messaging (Asynchronous): DIDComm v2 for secure, metadata-masked routing between Personas.
|
||||||
|
Calls (Synchronous): WebRTC with decentralized signaling via DIDComm.
|
||||||
|
Encryption: Envelope Encryption for all private data. Content is encrypted with a Data Key (DEK), which is wrapped by the Persona Public Key. This allows for instant re-keying if a device is stolen.
|
||||||
|
4. Discovery & AI
|
||||||
|
Pluggable Algorithms: Users subscribe to "Feed Generators" (DIDs). The algorithm provides a "Skeleton" of CIDs; the client app hydrates the content.
|
||||||
|
AI Agents: AI has its own DID, controlled by a human. It can perform tasks (summarization, moderation) using authorized sub-wallets.
|
||||||
|
Open Web Bridge: Public gateways translate P2P CIDs into standard HTTP URLs, making content searchable by Google and accessible via standard browsers.
|
||||||
|
5. Technical Implementation Stack (The "Engineer's Toolbox")
|
||||||
|
|
||||||
|
Layer Recommended Technology
|
||||||
|
Identity W3C DIDs, BIP-39/44, SLIP-0039 (Shamir)
|
||||||
|
Networking AT Protocol (Scaffolding), Libp2p
|
||||||
|
Communication DIDComm v2, WebRTC
|
||||||
|
Payments Lightning Network (LND/CLN), HODL Invoices
|
||||||
|
Database SQLite (Local), NoSQL/IPFS (PDS Storage)
|
||||||
|
AI/Logic Local Inference (Ollama), vLLM
|
||||||
|
|
||||||
|
6. Disaster Recovery: The "Broken Root" Protocol
|
||||||
|
In the event of a lost Master Seed, Aletheia utilizes Social Recovery:
|
||||||
|
Shamir Secret Sharing (SSS): Master Seed is split into a 3-of-5 threshold during setup.
|
||||||
|
Guardians: Trusted DIDs (friends/lawyers) hold fragments.
|
||||||
|
Reconstruction: Fragments are combined on a new Vault Device to rebuild the root and regain authority over all Personas.
|
||||||
|
|
||||||
|
**** Growth
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-03-21 Sat 04:10]
|
||||||
|
:END:
|
||||||
|
|
||||||
|
Scaling a decentralized network requires shifting from "Hand-holding" to "Protocol Incentives."
|
||||||
|
Order 1: The First 1,000 (The "Founders")
|
||||||
|
Target: Technical enthusiasts, privacy advocates, and niche professional guilds (e.g., decentralized AI devs).
|
||||||
|
Tactics: Manual onboarding. We seed the first Arbitration Guilds.
|
||||||
|
Success Metric: First successful civil contract signed and settled via HODL invoice.
|
||||||
|
Order 2: The 10,000 (The "Communities")
|
||||||
|
Target: Small NGOs, local trade groups, and content creator "Swarms."
|
||||||
|
Tactics: Launch the Community PDS templates. Enable "One-Click Hub" setup so a leader can host their entire group.
|
||||||
|
Success Metric: The emergence of "Community Algorithms"—feeds curated by these 10k users that provide unique value.
|
||||||
|
Order 3: The 100,000 (The "Marketplace")
|
||||||
|
Target: Freelancers, gig workers, and "Etsy-style" digital sellers in regions with weak rule of law.
|
||||||
|
Tactics: Focus on Mobile UX. The app must feel "normal." Introduce Automated Key Rotation so non-tech users don't fear losing their phones.
|
||||||
|
Success Metric: $1M+ in peer-to-peer transaction volume via SCAL contracts.
|
||||||
|
Order 4: The 1M+ (The "Ecosystem")
|
||||||
|
Target: The general public.
|
||||||
|
Tactics: The Algorithm Marketplace becomes the draw. People join because "The Scientific Lens" or "The Family Lens" on Agora provides a better mental health experience than the addictive AI of centralized apps.
|
||||||
|
Success Metric: Total P2P bandwidth (Seeding) exceeds the capacity of a mid-sized centralized CDN.
|
||||||
|
|
||||||
** Are our meetings and discussions being summarized in the dailies? There are some gems there that really should make their way to the daily then to atomic notes eventually
|
** Are our meetings and discussions being summarized in the dailies? There are some gems there that really should make their way to the daily then to atomic notes eventually
|
||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
:CREATED: [2026-03-20 Fri 08:13]
|
:CREATED: [2026-03-20 Fri 08:13]
|
||||||
|
|||||||
Reference in New Issue
Block a user