Doomscroll News 🇺🇸

Tag: cryptography

  • The Problem: Radically Decentralized, Resilient Global Information Delivery

    The Problem: Radically Decentralized, Resilient Global Information Delivery

    You must design a system to deliver news content (text, images, short videos) to 1 billion people globally. Your design must adhere to the following constraints derived from first principles:

    1. Zero Centralized Infrastructure: You cannot use traditional CDNs (Content Delivery Networks) like Cloudflare, Akamai, or AWS CloudFront. There can be no central servers or data centers that represent a single point of failure. The system must be resilient enough to function even if entire continents go offline.
    2. Physics-Limited Latency: The time it takes for a new piece of content to propagate to 95% of the user base must approach the physical limit imposed by the speed of light across global networks, not the limits imposed by server processing queues.
    3. Near-Zero Marginal Cost: The marginal cost of delivering content to one additional user must be as close to zero as possible. This means you cannot have costs that scale linearly with users or bandwidth, which rules out traditional cloud hosting models.
    4. Incentivized Participation: The system must rely on its users’ devices (phones, computers) to store and distribute content. You must devise an incentive structure, grounded in economic or game-theoretic principles, that encourages users to contribute their storage and bandwidth without direct monetary payment.
    5. Verifiable Integrity: Content must be cryptographically signed at its source to be verifiable, preventing censorship or alteration by the participating nodes that are relaying it.

    How would you design the architecture, protocol, and incentive system from the ground up to solve this?

    David Gross

    Follow me at https://x.com/dgapps and https://davidgrossapps.com

  • The Problem: Decentralized, Trustless Last-Mile Logistics

    The Problem: Decentralized, Trustless Last-Mile Logistics

    Companies like DoorDash, Uber Eats, and Amazon Flex have solved the last-mile delivery problem using a centralized, server-based architecture. A central server, owned by the company, is the trusted intermediary that holds all the data: customer orders, restaurant/merchant locations, driver locations, driver reputations, and payment information. It acts as the “brain,” dispatching orders to drivers based on a proprietary algorithm.

    From first principles, design a system that accomplishes the same goal—efficiently matching customers who want items delivered with a fleet of independent drivers—but without a central server or trusted intermediary.

    Your proposed system must solve the following core problems from the ground up:

    1. Discovery: How does a customer’s order request get broadcast to nearby, available drivers without a central server to see everyone’s location? How does a driver “see” available orders?
    2. Selection & Bidding: How is a driver selected for an order? Does the customer choose? Is there a bidding system? How do you prevent a single malicious actor from accepting all orders and never completing them (a Sybil attack)?
    3. Reputation & Trust: Without a central database of star ratings, how is driver reputation established and verified in a decentralized manner? How can a customer trust a driver they’ve never met? How can a driver trust that the customer will pay? Reputation must be resistant to manipulation.
    4. Payment: How are payments processed trustlessly? The customer needs to be sure they won’t be charged until the item is delivered, and the driver needs to be sure they will be paid upon successful delivery. Design a payment-in-escrow mechanism that doesn’t rely on a central company holding the funds. Consider using smart contracts or a similar cryptographic method.
    5. Efficiency & Scalability: Centralized dispatch algorithms are highly optimized. How can a decentralized, peer-to-peer network achieve comparable route and batching efficiency without a god’s-eye view of the entire system? How does your system scale from a single neighborhood to a whole city?

    Your answer should focus on the fundamental architecture, protocols, and incentive structures, not just the user interface of an app.

    David Gross

    Follow me at https://x.com/dgapps and https://davidgrossapps.com

  • Signal Chat’s Group Verification Blind Spot

    Signal Chat’s Group Verification Blind Spot

    Think of verification (V) as a required security check (like that special handshake) between any two members in a secure chat.

    1. One-on-One Chat: Let the chat be just between Alice and Bob. The set is S = {Alice, Bob}. Signal provides the mechanism (Safety Numbers) for Alice to verify Bob (V(Alice, Bob)) and for Bob to verify Alice (V(Bob, Alice)). For full trust, this verification should happen. Signal makes it possible and encourages it for this single pair (Alice, Bob).
    2. Group Chat (Signal’s Current Design): Let the group be the set G = {Alice, Bob, Charlie, … N}. Signal allows Alice to individually verify Bob (V(Alice, Bob)), or Alice to verify Charlie (V(Alice, Charlie)), and so on for any pair, optionally. Crucially: The group chat works even if these verifications haven’t happened. Alice can be in the group and talk to Bob and Charlie without the system forcing her to verify them, and without them having to verify her using the Safety Number check.
    3. Ideal Group Chat (Logical Requirement): Let the group be the set G = {Alice, Bob, Charlie, … N}. For this group G to have the same fundamental identity assurance as a verified chat between just Alice and Bob, the system design should require or enforce that verification V exists between all relevant pairs within the group. This means: For Alice to securely participate, the system should ensure that V(Alice, Bob), V(Alice, Charlie), and V(Alice, Y) for all other members Y in the group G are established (or at least flagged clearly if not). The same should apply to Bob verifying everyone else, Charlie verifying everyone else, and so on. Think of it like needing a “complete graph” of verification: Alice is securely linked to Bob, Alice to Charlie, Bob to Charlie, and so on for every pair.

    The baffling point is: Signal built the tool for Alice to verify Bob (V(Alice, Bob)), but didn’t make establishing these verification links across the entire group (G) a mandatory prerequisite for group operation. It treated security within the group G as a collection of optional one-on-one checks rather than a fundamental, required property of the group itself.

    Originally Posted on 𝕏 on April 19, 2025

    David Gross

    Follow me at https://x.com/dgapps and https://davidgrossapps.com