@ David
2025-02-09 00:16:55
## 1. What if You Could Send a Message into the Future?
Imagine leaving **a message for your future self**, a loved one, or even an entire community—one that no one, not even you, can unlock until a specific moment in time. Picture leaving **a message for your children**, a note of wisdom or love that remains hidden until they're old enough to appreciate it, all timed by Bitcoin's block height. You might also make **a bold prediction** about the future price of Bitcoin, sealing it away until the blockchain reaches a certain block height.
This is the idea behind *Hatchstr*, a decentralized app for time-locked messages that only unlock at predetermined Bitcoin block heights—no central authority required.
### Why Build This?
I want to dive into the Nostr protocol not just by reading documentation, but by actually building something that embodies its core principles: **censorship resistance**, **user ownership**, and **decentralization**. Hatchstr is both an experiment and a contribution to the Nostr ecosystem—a way to test the limits of permissionless communication while learning and engaging with the community.
## 2. The Vision: How Hatchstr Would Work for Users
At its core, Hatchstr lets users create time capsules—encrypted messages that only become readable after a specified Bitcoin block height. Here’s what that looks like:
* You design a capsule with text and images using Hatchstr’s web app.
* You pick an unlock time (e.g., 1000 blocks from now).
* The message is encrypted, locked away, and published as a Nostr event.
* At the chosen time, the decryption key is revealed, allowing the recipient to finally access the message.
#### Potential Use Cases
* **Personal Messages**: Send birthday wishes that unlock at midnight, time-delayed love letters, or notes to your future self.
* **Timed Learning**: Lock educational content to unlock when students reach key learning stages or ages.
* **Creative Storytelling**: Release serialized fiction, riddles, or treasure hunt clues that unlock over time.
* **Community & Events**: Time-gate announcements for Nostr-based communities or scheduled voting mechanisms.
### 3. The Centralized Trap: Why Build on Nostr
When thinking about how to implement this, we could go the obvious, easy route:
* Store messages on a centralized server.
* Release them when the time is right.
* Let users download their messages.
Simple, right? **But is it the right approach? Let's break it down.**
### Why This Fails
* **Single Point of Failure**: If my server goes down, all messages are unavailable.
* **Privacy Risks**: Users would need to trust me not to access their messages.
* **Ownership & Longevity**: What happens if I lose interest? The system dies with me.
A centralized model defeats the purpose of time-locking messages. Users shouldn’t have to trust a third party. We need decentralization.
## 4. Nostr to the Rescue: How Decentralization Can Help
Instead of a single server holding messages hostage, [Nostr](https://nostr.how/en/what-is-nostr) allows users to publish messages to [decentralized relays](https://nostr.how/en/relays). Here are the key differences:
* **Nostr IDs = Self-Owned Identities**: Your public key is your identity, not tied to any company.
* **Relays = Decentralized Bulletin Boards**: Anyone can run one, ensuring redundancy and censorship resistance.
* **Messages = Signed Events:** Cryptographically signed by the sender or encrypted for only the recipient.
### How Nostr Reduces Centralization
In this version of Hatchstr, capsules are still stored in a centralized manner at first until they 'hatch'. However, once the Bitcoin block height condition is met:
* **Capsule Publication**: The system publishes the capsule events to Nostr relays, making the messages available for decryption by the intended recipients.
This approach, while not eliminating the central server, allows for:
* **Third-Party Clients**: Developers can now create clients that interact with Hatchstr capsules on Nostr, enhancing the system's openness and potentially leading to a richer ecosystem around time-locked messages.
* **Decentralized Access**: Even though the initial storage is centralized, the access to the messages becomes decentralized once published to Nostr, reducing the dependency on a single point for message retrieval.
We have some improvements, **but I am sure we can do better!**
## 5. The Path to Decentralized Timekeeping
### The Timeless Nature of Encryption
Encrypted messages exist outside time—once locked, they remain secure indefinitely. Modern cryptography (like AES-256) doesn’t "expire" or weaken unless decrypted (excluding brute force attacks). This creates a paradox: How do you bind something timeless to a specific moment in the physical world?
#### The Time-Lock Puzzle Dilemma
Cryptographers have proposed [time-lock puzzles](https://iacr.org/archive/crypto2019/116940354/116940354.pdf)—encryption that requires sustained computation to unlock, theoretically forcing a minimum wait time. But these face critical hurdles:
* ##### **Hardware Uncertainty**
Solving time depends on an attacker’s computational power. A nation-state could crack in hours what takes years for a regular user.
* ##### **No Real-World Alignment**
Puzzles can’t guarantee unlocks align with calendar dates or real-world events ("unlock on my child’s 18th birthday").
* ##### **Energy Waste**
Requires continuous computation, making it environmentally impractical for longer time locking.
#### Bitcoin as a Decentralized Clock
This is where Bitcoin’s blockchain shines. Its difficulty-adjusted proof-of-work acts as a trustless metronome:
* ##### **Predictable Rhythm**
Despite hash rate fluctuations, the 10-minute block target (via difficulty adjustments) creates a consistent approximation of real-world time.
* ##### **Immutable History**
Block height 1,000,000 will always correspond to the same point in Bitcoin’s timeline, regardless of future changes in mining power
#### **Splitting the Problem**
Hatchstr can bridge timeless encryption and blockchain timing by separating concerns:
##### **1. Capsules** – The time-locked message itself:
* Design independent of the time-locking mechanism.
* Encrypted client-side.
* Content stored anywhere the user wants (IPFS, personal servers, etc.).
* Completely owned by the user—not Hatchstr.
##### **2. Clock Servers** – Independent, lightweight timing nodes that:
* Only publish decryption keys when the target Bitcoin block height is reached.
* Users can choose which Clock Server to trust.
* Anyone can run their own Clock Server.
* Multiple servers can coordinate to prevent a single point of failure.
**This means Hatchstr itself doesn’t store anything—users are fully in control.**
## 6. What Comes Next
This project is just beginning—a blueprint with open questions and untested assumptions. In the next two articles, I’ll explore how to turn this concept into something tangible. First, how we might design playful time capsules that can be displayed faithfully by multiple clients, balancing creativity with decentralization. Then, the messy realities of clock servers: why federating them matters, how to incentivize reliability, and borrow Bitcoin’s rhythm without centralizing control. We will dive into setting up a simple clock server to get things started.
I’m still learning Nostr’s ecosystem, and this project is as much about sharing my education as anything else. If any part of this concept makes you think “yes, but…” or “what if…”, I’d genuinely love to hear it. Find me on Nostr – no expertise required, just an interest in sending messages to the future. :
```
npub16scfufrpsqcukjg7ymu4r40h7j4dwqy4pajgz48e6lmnmz5pljcqh678uh
```
Thank you for reading 🧡