Reorganized files

.#org-inbox.org

@@ -0,0 +1 @@
+user@lilitop.81586:1773860924

inbox/refile-test.org

@@ -1,5 +0,0 @@
-* Justice, peace, and land
-:PROPERTIES:
-:CREATED:  [2024-06-25 Tue 10:39]
-:END:
-I am watching Rome a fourth time perhaps. Caesar is declared imperator in the Senate. He promises justice, peace and land for all Romans. This is the original life, liberty and property. 

org-inbox.org

@@ -8527,7 +8527,8 @@ By building org-agent, you are creating a system where your daily GTD notes, you
 Would you like me to draft the Lisp parser function that reads an .org skill file and translates its #+NAME and #+BEGIN_SRC blocks into callable Lisp functions for the agent's whitelist?
 
 ** Agora
-:PROPERTIES:
+:
+PROPERTIES:
 :CREATED:  [2026-03-19 Thu 18:50]
 :END:
 
@@ -8948,160 +8949,10 @@ 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.
 
-*** Content
-**** Content flags can be reduced if we slightly increase the fields.for each note: every note has a content field and an agreement field. If the agreement is filled then it's a contract. If it's empty then it is a non-contract note. On case of contracts the content field will have the human readable version of the contract.  Similarly with payment. If zero then there is no payment included (there are multiple types of payment: one off, recurring  schedules...)
-:PROPERTIES:
-:CREATED:  [2026-03-20 Fri 08:07]
-:END:
-
-**** We haven't considered events, invites in the context of the primitive
-:PROPERTIES:
-:CREATED:  [2026-03-20 Fri 08:08]
-:END:
-
-
-**** Expand on default profile types and those chosen for v.1
+*** Expand on default profile types and those chosen for v.1
 :PROPERTIES:
 :CREATED:  [2026-03-20 Fri 08:10]
 :END:
-**** Connection contract could include copyright clauses
-:PROPERTIES:
-:CREATED:  [2026-03-20 Fri 08:10]
-:END:
-
-But does it require escrow for future compensation. Should we develop a lean mechanism?
-
-**** 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.
-
-**** 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.
-
-**** 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.
-
-**** 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.
-
-*** 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:
@@ -9128,47 +8979,7 @@ To address the "Weak Rule of Law," we use a tiered system of human judgment:
 ​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.
 
-*** 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:
-
-*** 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.
-
-*** Exchange
-**** Relay economics bootstrapping
+*** Relay economics bootstrapping
 :PROPERTIES:
 :CREATED:  [2026-03-21 Sat 03:05]
 :END:
@@ -9216,7 +9027,7 @@ An NGO in this system doesn't just have a "handbook." It has a Smart Constitutio
 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.
 
-**** Courts
+*** Courts
 :PROPERTIES:
 :CREATED:  [2026-03-21 Sat 03:18]
 :END:
@@ -9273,22 +9084,6 @@ In our system, AI doesn't just "chat"—it has its own DID (Decentralized Identi
 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.
 
-*** 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.
-
 
 ** 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: