Nostr notes by David

lol

2026-01-17T19:54:41Z

In reply to nevent1q…9whw
_________________________

lol

Greed should be those gable on everything sites or Fartcoin.

2026-01-15T00:55:05Z

In reply to nevent1q…0nns
_________________________

Greed should be those gable on everything sites or Fartcoin.

I struggle with that stuff, and all the AI UIs look bland af. ...

2026-01-15T00:52:58Z

In reply to nevent1q…r9c0
_________________________

I struggle with that stuff, and all the AI UIs look bland af.
Yours gives a nice warm feel while looking professional.

I think about this a lot, same is happening to my job, ...

2026-01-15T00:49:42Z

In reply to nevent1q…5t79
_________________________

I think about this a lot, same is happening to my job, programming. The genuinely enjoyable parts of writing code yourself, designing a function interface, all of this gets taken over completely by AI.
Yet on the high level engineering problems, that always have been hard AI is more than useless. Confidently wrong all the time.

I use Claude Code Opus for coding, it's a scary step up from ...

2026-01-15T00:46:05Z

In reply to nevent1q…p5f3
_________________________

I use Claude Code Opus for coding, it's a scary step up from other coding models and Gemini for UI design since it seems to have more taste.

Like the UI Design, good job!

2026-01-15T00:43:25Z

In reply to nevent1q…zh3j
_________________________

Like the UI Design, good job!

Does someone have the link for the @nprofile…zj6n interview she ...

2026-01-15T00:41:52Z

In reply to nevent1q…c32p
_________________________

Does someone have the link for the jack (nprofile…zj6n) interview she mentioned?

Seeing your posts get so relatively few likes on X (and here too) ...

2026-01-15T00:30:32Z

In reply to nevent1q…kzt6
_________________________

Seeing your posts get so relatively few likes on X (and here too) makes me feel better about screaming into the abyss.
This is civilization level news and flying completely under the radar!

Nah you can do voluntary collectivism. Just nobody does it xD

2026-01-15T00:28:00Z

In reply to nevent1q…tnm5
_________________________

Nah you can do voluntary collectivism. Just nobody does it xD

I don't mind collectivism, just don't touch other ...

2026-01-03T16:30:55Z

In reply to nevent1q…qcqh
_________________________

I don't mind collectivism, just don't touch other people's shit. It's called property rights, the source of wealth creation. The Romans already understood this well.

Yeahhhh, this. 😔

2025-12-09T00:56:20Z

In reply to nevent1q…rd8w
_________________________

Yeahhhh, this. 😔

I'm rocking the 3. Dec. '25

2025-12-04T00:46:08Z

In reply to nevent1q…dpl6
_________________________

I'm rocking the 3. Dec. '25

One of my favorite shows.

2025-12-04T00:43:45Z

In reply to nevent1q…jw6j
_________________________

One of my favorite shows.

Controversial: Firefly. Whedon would have fucked it up 100% xD

2025-12-04T00:42:17Z

In reply to nevent1q…vghe
_________________________

Controversial: Firefly. Whedon would have fucked it up 100% xD

My dream was always to go to BC from EU, but after reading that a ...

2025-12-04T00:39:06Z

In reply to nevent1q…qefm
_________________________

My dream was always to go to BC from EU, but after reading that a few weeks ago I put that behind me. Looking at AUS, but really not sure what's the best place to go.

Gotta make Peter x Tucker happen to find out xD

2025-11-27T14:48:52Z

In reply to nevent1q…3r27
_________________________

Gotta make Peter x Tucker happen to find out xD

Not fair, Peter is doing really great over on X these days 😹 ...

2025-11-27T14:23:21Z

In reply to nevent1q…4qv5
_________________________

Not fair, Peter is doing really great over on X these days 😹

I thought it's a picture of a guy giving away free bars, at ...

2025-11-24T17:28:21Z

In reply to nevent1q…59vs
_________________________

I thought it's a picture of a guy giving away free bars, at first xD

We call it raw dogging truth

2025-11-24T11:32:12Z

In reply to nevent1q…qqy4
_________________________

We call it raw dogging truth

Eric awesome as always T 🚀

2025-11-24T00:04:58Z

In reply to nevent1q…7vlj
_________________________

Eric awesome as always
T 🚀

🚨BREAKING RELEASED 🚨 The EU plan to save the German auto ...

2025-11-22T16:22:16Z

🚨BREAKING RELEASED 🚨
The EU plan to save the German auto industry 🇩🇪🇪🇺

Looking myself for more contact with other builders, any advice?

2025-11-22T15:13:34Z

In reply to nevent1q…aunp
_________________________

Looking myself for more contact with other builders, any advice?

I do the same with a candle 🕯️ Staring at the flame then ...

2025-11-22T15:11:53Z

In reply to nevent1q…zkrl
_________________________

I do the same with a candle 🕯️ Staring at the flame then close my eyes and focus on the image fading away and repeat.
It works much better me than focussing on breath.

I'm dogmatically truthful in my private life, but how do ...

2025-11-22T15:08:10Z

In reply to nevent1q…cvqt
_________________________

I'm dogmatically truthful in my private life, but how do would you handle being a freelancer in web dev? Is very overrun and it seems everyone is bullshitting to get jobs. I struggle with that shit 🙈

This can't be true xD

2025-11-22T14:20:24Z

In reply to nevent1q…ewmj
_________________________

This can't be true xD

That's true, it's very easy now to make something that ...

2025-11-22T14:18:20Z

In reply to nevent1q…thqm
_________________________

That's true, it's very easy now to make something that looks functional on the surface. But in my experience to make a real app, not a prototype, experienced dev work is still required.

Everyone that's not sleeping will transfer and the left coins ...

2025-11-22T14:14:56Z

In reply to nevent1q…h28l
_________________________

Everyone that's not sleeping will transfer and the left coins become the biggest prize pool incentive to research quantum, everyone wins.

⚠️ IMPORTANT message for everyone on nostr: Why the fuck ...

2025-11-22T14:13:55Z

In reply to nevent1q…xnas
_________________________

⚠️ IMPORTANT message for everyone on nostr:
Why the fuck would you use Gmail 🤣

Pretty crazy, how does this compare to montly avgs this year?

2025-11-22T14:12:12Z

In reply to nevent1q…9tqj
_________________________

Pretty crazy, how does this compare to montly avgs this year?

I don't understand the quantum FUD. Everyone that is not ...

2025-11-22T14:00:50Z

I don't understand the quantum FUD.
Everyone that is not asleep can move their stack to quantum resistant addresses when the time comes.
All other coins become the biggest prize pool to incentivize quantum research. Everyone wins and the Satoshi coins get redistributed 🎉

Hurts to think that they will solve literally every problem with ...

2025-11-22T13:54:46Z

In reply to nevent1q…lded
_________________________

Hurts to think that they will solve literally every problem with bigger government.

On the other hand it's refreshing to see two guys talking and agreeing. Crazy how the media tries to clipfarm them -.-

People think we are joking when we say LOWER, but it's ...

2025-11-22T13:48:50Z

In reply to nevent1q…ydsy
_________________________

People think we are joking when we say LOWER, but it's genuinely how I feel. Let's go so fucking low that we flush out all the shitcoins out of the system.

Hey guys, been over on X for the past few months, but the crying ...

2025-11-22T13:47:05Z

Hey guys, been over on X for the past few months, but the crying now is too much. Why did I ever look back -.-

Sadly relevant again 🤣😭 #note13xy…u70n

2025-03-03T07:23:07Z

Sadly relevant again 🤣😭

quoting
note13xy…u70n
Shocking interview with President Trump after signing the crypto EO 😂

Hatchstr 🪺 Part 2: Time-locked messages on Bitcoin block ...

2025-02-23T13:52:16Z

Hatchstr 🪺 Part 2: Time-locked messages on Bitcoin block heights.

Naive shot—single server holds a key, drops it at the right height. Too fragile.
How do you decentralize this? I found a cool, simple, mind-bending way: Check it out 📜

fiatjaf (npub180c…h6w6) Derek Ross (npub18am…p424) HODL (npub1rtl…jtfs) jack (npub1sg6…f63m) ODELL (npub1qny…95gx) —hit me with your best shot.

quoting
naddr1qv…a95g

Introduction: The Challenge of Time-Lock Encryption and Clock Servers

When I first set out to build Hatchstr, the idea was simple: create a way to send messages into the future, encrypted and locked to a specific Bitcoin block height. These messages would remain encrypted until the chosen block height was reached, creating a unique way to send a message to the future.

However, as I began working through the details, I quickly ran into some challenges. One key component of this system involves clock servers—decentralized nodes responsible for releasing decryption keys when the specified block height is reached.

Clock Server Setup: The Basics

Initially, I adopted a simple model: each clock server holds a single public-private key pair unique to that server for a specific block height. When a user creates a message, they choose a clock server to trust and encrypt with the specific public key tied to that block height. Then, when the time comes, the clock server releases its private key to decrypt the message.

Positives:

✅ Clean and Efficient Storage: Each clock server only needs to store a single key pair for each block height, making storage lightweight and scalable.

✅ Lazy Key Generation: Keys are generated on-demand, meaning they’re only created when needed. This prevents unnecessary key generation or storage overhead.

✅ Decentralized: The clock servers don’t need to coordinate with each other or store any sensitive data besides their respective private keys, which simplifies the system architecture.

✅ Limited Release Events: Since each clock server only handles keys tied to a specific block height, the number of release events required is minimized, simplifying the key management process.

At first, this seemed like a good approach, but I quickly realized there were critical limitations:

Challenges:

❌ Server Shutdown: Capsules could be scheduled for many years in the future. If a clock server shuts down, all future capsules linked to it are lost.

❌ Server Downtime: If one of the clock servers is unavailable during unlock time, even for a short period, it leads to a delay for the users waiting for unlock.

❌ Premature Release: If a clock server accidentally releases its key too early, it could compromise the message, making it accessible before the intended time.

Though the setup worked for a basic system, I soon realized it couldn’t guarantee the reliability I wanted for a decentralized application.

Tackling the Challenges of Multi-Sig and Secret Sharing

When I first approached the problem of securing time-lock capsules, I initially considered using multi-signature (multi-sig) solutions as a potential approach. The goal was simple: instead of relying on a single clock server to release its key, I could involve multiple servers to sign off on the decryption. This way, if one server failed or misbehaved, the message would still be protected.

However, as I delved deeper into the multi-sig approach, I quickly realized there were a few key issues:

🔒 Communication Overhead: Multi-sig requires servers to communicate and coordinate with each other. This introduces the possibility of new failure points, like network issues or miscommunication.

⚡ Server Synchronization: If one server was out of sync or released its key too early, it could still lead to the message being decrypted prematurely, breaking the system.

🛠 Increased Complexity: Each server would need to store and manage a unique key pair for every message, making the system more complicated and less efficient.

I quickly realized that multi-sig wasn’t the best fit for this kind of setup. Not only did it add unnecessary complexity, but it also conflicted with the decentralization goals I wanted to achieve. So, I started thinking about ways to distribute the secret across the clock servers without introducing all these new complications.

Enter Shamir’s Secret Sharing (SSS)

Shamir's Secret Sharing (SSS) is a cryptographic technique designed to split a secret into multiple parts (called "shares") so that the secret can only be reconstructed when a specific minimum number of shares are combined. This process is based on polynomial interpolation, and it’s a powerful way to distribute secrets securely.

The Basic Concept

In SSS, a secret (like a cryptographic key or message) is divided into n shares, where n is the total number of shares you want to generate. You also specify a threshold, k, which represents the minimum number of shares required to reconstruct the original secret.

n is the total number of shares.

k is the minimum number of shares required to reconstruct the secret (known as the "threshold").

For example, in a 3-out-of-5 scheme, the secret is split into 5 shares, but at least 3 shares are required to reconstruct the secret. If fewer than 3 shares are available, the secret cannot be reconstructed.

Why This is Secure

Shamir’s Secret Sharing is secure because, with fewer than k shares, it is computationally infeasible to learn anything about the secret. The shares themselves don’t reveal any information; it’s only the combination of the right number of shares that allows reconstruction. This makes it resistant to attacks, as even if an attacker gets hold of some shares, they won’t be able to reconstruct the secret unless they have the required minimum number of shares (comparable to 256-bit cryptographic strength).

Applications of Shamir’s Secret Sharing

Shamir’s Secret Sharing is widely used in scenarios where high availability and reliability are needed, but security and privacy are equally important. Examples include: - Key management: Protecting encryption keys by distributing them across multiple parties. - Multi-signature setups: Requiring multiple parties to sign off on a transaction or access a secure system. - Distributed systems: Ensuring that no single party holds a complete secret, and multiple parties must collaborate to unlock it.

By leveraging Shamir's Secret Sharing, you can strike the right balance between redundancy, security, and availability for your system’s sensitive information.

The Problem with Distributing Secret Shares

SSS could give us exactly the properties I was looking for, with the added benefit that users could choose their preferred setup, for example:

1-out-of-5 scheme: Prioritizing the likelihood that the message is decrypted even if only one of the 5 chosen clock servers does its job at unlock time. With the tradeoff that each of the 5 could leak the message early.

3-out-of-5 scheme: A measured approach that allows for 2 servers to stop working and would also keep the capsule private even if 2 clock servers leak their secret early.

So I considered an approach where each clock server would store part of the key. Instead of a single server holding the full key, I would split the key into parts and distribute those parts across multiple servers. When the time arrived, I’d gather the required number of shares to reconstruct the key and decrypt the message.

At first glance, this seemed like a promising approach. But when we look through the implications, a few problems started to emerge:

💥 Overhead: Each clock server would need to store a share of every key for every message. This would quickly become inefficient and result in unnecessary overhead.

🔔 Exploding Reveal Events: Since each clock server would need to release all its shares at a specific time, there would be a massive increase in the number of reveal events, spamming and possibly overloading Nostr relays.

While the idea of distributing the key was very appealing, the practical issues around overhead and complexity made it clear that this wasn’t the final solution. I needed something that would be more efficient, scalable, while still in line with the decentralized model I was aiming for.

Discovering a Hybrid Solution

After testing out various approaches, I realized that the breakthrough wasn’t just about Shamir’s Secret Sharing (SSS)—that part was fairly intuitive. The real insight came when I thought about how to preserve the original clock server design while solving the challenges of failover and early release.

Instead of having the clock servers store the secret or a share of it, I kept the original design: each clock server only holds a public-private key pair tied to a block height, as initially planned. The twist came when I decided to split an ephemeral AES key into shards using Shamir’s Secret Sharing, but instead of directly storing shares at the clock servers, we could encrypted each share with the public key of the clock server.

This approach would allow us to keep the clock server’s role simple: When the time comes, the servers release their private keys, which can then be used to decrypt the encrypted shares of the AES key that were published alongside the original encrypted message. These shares, once decrypted, allow for the reconstruction of the AES key, which in turn decrypts the message.

This solution solved several key issues:

✅ No Coordination Between Servers: Each clock server only holds one key pair for a specific block height and doesn’t need to know about the other servers. This simplifies the system and removes the need for complex server coordination.

✅ Minimal Overhead: The clock servers only store a single key pair per block height, eliminating the need to store individual keys for each message.

✅ Fault Tolerance: If one clock server is offline, the other shares can still reconstruct the AES key and decrypt the message, ensuring reliability.

✅ Client-Side Security: The AES key is generated on the client side and never stored on the clock servers, providing a high level of security.

By combining the simplicity of the clock server model with the power of Shamir’s Secret Sharing, this hybrid solution allows us to securely split an AES key and manage decryption while ensuring the system remains decentralized, resilient, and efficient.

This was the method I had been searching for.

The Process Breakdown

AES Key Generation:

A random AES key is generated on the client side for each message. This key is never stored anywhere, ensuring that it remains secure and only used for encrypting the message.

Shamir’s Secret Sharing:

The AES key is split into (in this example) 3 shares using Shamir’s Secret Sharing. These shares are associated with 3 independent clock servers.

The threshold of 2 out of 3 means that only 2 clock servers needed later to reconstruct the AES key and decrypt the message.

Encrypting with Public Keys:

The secret shares are then encrypted using the public keys of the target block height for each specific clock server. This ensures that the shares are secure until the proper time comes.

Storage:

The encrypted shares together with the AES-encrypted message can be published to Nostr relais or stored on a decentralized platform like IPFS, which provides redundancy and availability.

Clock Servers Release Keys:

When the specified Bitcoin block height is reached, each clock server publishes its private key to Nostr, allowing everyone to decrypt the shares.

The client reconstructs the AES key from the decrypted shares and finally decrypts the original message.

Conclusion: An Elegant Solution to Time-Lock Encryption

Through a series of experiments and iterations, We finally landed on a solution that balances security, scalability, and efficiency. By combining AES encryption with Shamir’s Secret Sharing, We were able to solve the multi-sig failover problem without adding unnecessary complexity. 🔥

An Open Question: Clock Server Incentives 💰

Decentralized systems thrive when participants are motivated to contribute. For Hatchstr, a critical question remains: Why would anyone run a clock server?

One possibility is allowing users to zap (tip) servers for each capsule they help unlock. But this is just a starting point—how do we ensure reliability without centralizing trust?

I’d love to hear your thoughts. How would you design incentives for a decentralized network of clock servers?

This part is crucial, and I’m excited to explore it with the community.

What's Next for Hatchstr?

🧩 Leveraging Nostr: Let's see how we can integrate the Nostr NIP standards and previous protocol developments into our system to enhance communication and data integrity.

🔮 Designing a Web App: We'll explore building a user-friendly web application for creating and managing digital time capsules. Focus will be on enhancing usability, interface design, and user interaction.

🎛️ Building a Clock Server with Elixir: We'll delve into developing a simple clock server using Elixir, capitalizing on its strengths in concurrency and real-time processing to support our time-locking mechanisms.

Stay tuned as we advance both the user experience and the backend infrastructure of Hatchstr together. If you're interested in following along or contributing to the development, feel free to reach out!

Nostr QR
npub16scfufrpsqcukjg7ymu4r40h7j4dwqy4pajgz48e6lmnmz5pljcqh678uh
Thank you for reading and being part of this journey! 🧡

Part 2 on the public journey of developing Hatchstr 🪺: Digital ...

2025-02-20T21:17:21Z

Part 2 on the public journey of developing Hatchstr 🪺: Digital time-capsules on Nostr

I found a really neat way of decentralizing the time locking mechanism: AES the message then SSS the key and time-lock the shares individually 🤯

Read the article, I triedy best to make it very accessible!

If you know anyone that's into cryptography or might be interested in the project please share 🙏

fiatjaf (npub180c…h6w6), Derek Ross (npub18am…p424), HODL (npub1rtl…jtfs), jack (npub1sg6…f63m), ODELL (npub1qny…95gx) would love to hear your thoughts 🧡

quoting
naddr1qq…4qkl

Introduction: The Challenge of Time-Lock Encryption and Clock Servers

When I first set out to build Hatchstr, the idea was simple: create a way to send messages into the future, encrypted and locked to a specific Bitcoin block height. These messages would remain encrypted until the chosen block height was reached, creating a unique way to send a message to the future.

However, as I began working through the details, I quickly ran into some challenges. One key component of this system involves clock servers—decentralized nodes responsible for releasing decryption keys when the specified block height is reached.

Clock Server Setup: The Basics

Initially, I adopted a simple model: each clock server holds a single public-private key pair unique to that server for a specific block height. When a user creates a message, they choose a clock server to trust and encrypt with the specific public key tied to that block height. Then, when the time comes, the clock server releases its private key to decrypt the message.

Positives:

✅ Clean and Efficient Storage: Each clock server only needs to store a single key pair for each block height, making storage lightweight and scalable.

✅ Lazy Key Generation: Keys are generated on-demand, meaning they’re only created when needed. This prevents unnecessary key generation or storage overhead.

✅ Decentralized: The clock servers don’t need to coordinate with each other or store any sensitive data besides their respective private keys, which simplifies the system architecture.

✅ Limited Release Events: Since each clock server only handles keys tied to a specific block height, the number of release events required is minimized, simplifying the key management process.

At first, this seemed like a good approach, but I quickly realized there were critical limitations:

Challenges:

❌ Server Shutdown: Capsules could be scheduled for many years in the future. If a clock server shuts down, all future capsules linked to it are lost.

❌ Server Downtime: If one of the clock servers is unavailable during unlock time, even for a short period, it leads to a delay for the users waiting for unlock.

❌ Premature Release: If a clock server accidentally releases its key too early, it could compromise the message, making it accessible before the intended time.

Though the setup worked for a basic system, I soon realized it couldn’t guarantee the reliability I wanted for a decentralized application.

Tackling the Challenges of Multi-Sig and Secret Sharing

When I first approached the problem of securing time-lock capsules, I initially considered using multi-signature (multi-sig) solutions as a potential approach. The goal was simple: instead of relying on a single clock server to release its key, I could involve multiple servers to sign off on the decryption. This way, if one server failed or misbehaved, the message would still be protected.

However, as I delved deeper into the multi-sig approach, I quickly realized there were a few key issues:

🔒 Communication Overhead: Multi-sig requires servers to communicate and coordinate with each other. This introduces the possibility of new failure points, like network issues or miscommunication.

⚡ Server Synchronization: If one server was out of sync or released its key too early, it could still lead to the message being decrypted prematurely, breaking the system.

🛠 Increased Complexity: Each server would need to store and manage a unique key pair for every message, making the system more complicated and less efficient.

I quickly realized that multi-sig wasn’t the best fit for this kind of setup. Not only did it add unnecessary complexity, but it also conflicted with the decentralization goals I wanted to achieve. So, I started thinking about ways to distribute the secret across the clock servers without introducing all these new complications.

Enter Shamir’s Secret Sharing (SSS)

Shamir's Secret Sharing (SSS) is a cryptographic technique designed to split a secret into multiple parts (called "shares") so that the secret can only be reconstructed when a specific minimum number of shares are combined. This process is based on polynomial interpolation, and it’s a powerful way to distribute secrets securely.

The Basic Concept

In SSS, a secret (like a cryptographic key or message) is divided into n shares, where n is the total number of shares you want to generate. You also specify a threshold, k, which represents the minimum number of shares required to reconstruct the original secret.

n is the total number of shares.

k is the minimum number of shares required to reconstruct the secret (known as the "threshold").

For example, in a 3-out-of-5 scheme, the secret is split into 5 shares, but at least 3 shares are required to reconstruct the secret. If fewer than 3 shares are available, the secret cannot be reconstructed.

Why This is Secure

Shamir’s Secret Sharing is secure because, with fewer than k shares, it is computationally infeasible to learn anything about the secret. The shares themselves don’t reveal any information; it’s only the combination of the right number of shares that allows reconstruction. This makes it resistant to attacks, as even if an attacker gets hold of some shares, they won’t be able to reconstruct the secret unless they have the required minimum number of shares (comparable to 256-bit cryptographic strength).

Applications of Shamir’s Secret Sharing

Shamir’s Secret Sharing is widely used in scenarios where high availability and reliability are needed, but security and privacy are equally important. Examples include: - Key management: Protecting encryption keys by distributing them across multiple parties. - Multi-signature setups: Requiring multiple parties to sign off on a transaction or access a secure system. - Distributed systems: Ensuring that no single party holds a complete secret, and multiple parties must collaborate to unlock it.

By leveraging Shamir's Secret Sharing, you can strike the right balance between redundancy, security, and availability for your system’s sensitive information.

The Problem with Distributing Secret Shares

SSS could give us exactly the properties I was looking for, with the added benefit that users could choose their preferred setup, for example:

1-out-of-5 scheme: Prioritizing the likelihood that the message is decrypted even if only one of the 5 chosen clock servers does its job at unlock time. With the tradeoff that each of the 5 could leak the message early.

3-out-of-5 scheme: A measured approach that allows for 2 servers to stop working and would also keep the capsule private even if 2 clock servers leak their secret early.

So I considered an approach where each clock server would store part of the key. Instead of a single server holding the full key, I would split the key into parts and distribute those parts across multiple servers. When the time arrived, I’d gather the required number of shares to reconstruct the key and decrypt the message.

At first glance, this seemed like a promising approach. But when we look through the implications, a few problems started to emerge:

💥 Overhead: Each clock server would need to store a share of every key for every message. This would quickly become inefficient and result in unnecessary overhead.

🔔 Exploding Reveal Events: Since each clock server would need to release all its shares at a specific time, there would be a massive increase in the number of reveal events, spamming and possibly overloading Nostr relays.

While the idea of distributing the key was very appealing, the practical issues around overhead and complexity made it clear that this wasn’t the final solution. I needed something that would be more efficient, scalable, while still in line with the decentralized model I was aiming for.

Discovering a Hybrid Solution

After testing out various approaches, I realized that the breakthrough wasn’t just about Shamir’s Secret Sharing (SSS)—that part was fairly intuitive. The real insight came when I thought about how to preserve the original clock server design while solving the challenges of failover and early release.

Instead of having the clock servers store the secret or a share of it, I kept the original design: each clock server only holds a public-private key pair tied to a block height, as initially planned. The twist came when I decided to split an ephemeral AES key into shards using Shamir’s Secret Sharing, but instead of directly storing shares at the clock servers, we could encrypted each share with the public key of the clock server.

This approach would allow us to keep the clock server’s role simple: When the time comes, the servers release their private keys, which can then be used to decrypt the encrypted shares of the AES key that were published alongside the original encrypted message. These shares, once decrypted, allow for the reconstruction of the AES key, which in turn decrypts the message.

This solution solved several key issues:

✅ No Coordination Between Servers: Each clock server only holds one key pair for a specific block height and doesn’t need to know about the other servers. This simplifies the system and removes the need for complex server coordination.

✅ Minimal Overhead: The clock servers only store a single key pair per block height, eliminating the need to store individual keys for each message.

✅ Fault Tolerance: If one clock server is offline, the other shares can still reconstruct the AES key and decrypt the message, ensuring reliability.

✅ Client-Side Security: The AES key is generated on the client side and never stored on the clock servers, providing a high level of security.

By combining the simplicity of the clock server model with the power of Shamir’s Secret Sharing, this hybrid solution allows us to securely split an AES key and manage decryption while ensuring the system remains decentralized, resilient, and efficient.

This was the method I had been searching for.

The Process Breakdown

AES Key Generation:

A random AES key is generated on the client side for each message. This key is never stored anywhere, ensuring that it remains secure and only used for encrypting the message.

Shamir’s Secret Sharing:

The AES key is split into (in this example) 3 shares using Shamir’s Secret Sharing. These shares are associated with 3 independent clock servers.

The threshold of 2 out of 3 means that only 2 clock servers needed later to reconstruct the AES key and decrypt the message.

Encrypting with Public Keys:

The secret shares are then encrypted using the public keys of the target block height for each specific clock server. This ensures that the shares are secure until the proper time comes.

Storage:

The encrypted shares together with the AES-encrypted message can be published to Nostr relais or stored on a decentralized platform like IPFS, which provides redundancy and availability.

Clock Servers Release Keys:

When the specified Bitcoin block height is reached, each clock server publishes its private key to Nostr, allowing everyone to decrypt the shares.

The client reconstructs the AES key from the decrypted shares and finally decrypts the original message.

Conclusion: An Elegant Solution to Time-Lock Encryption

Through a series of experiments and iterations, We finally landed on a solution that balances security, scalability, and efficiency. By combining AES encryption with Shamir’s Secret Sharing, We were able to solve the multi-sig failover problem without adding unnecessary complexity. 🔥

An Open Question: Clock Server Incentives 💰

Decentralized systems thrive when participants are motivated to contribute. For Hatchstr, a critical question remains: Why would anyone run a clock server?

One possibility is allowing users to zap (tip) servers for each capsule they help unlock. But this is just a starting point—how do we ensure reliability without centralizing trust?

I’d love to hear your thoughts. How would you design incentives for a decentralized network of clock servers?

This part is crucial, and I’m excited to explore it with the community.

What's Next for Hatchstr?

🧩 Leveraging Nostr: Let's see how we can integrate the Nostr NIP standards and previous protocol developments into our system to enhance communication and data integrity.

🔮 Designing a Web App: We'll explore building a user-friendly web application for creating and managing digital time capsules. Focus will be on enhancing usability, interface design, and user interaction.

🎛️ Building a Clock Server with Elixir: We'll delve into developing a simple clock server using Elixir, capitalizing on its strengths in concurrency and real-time processing to support our time-locking mechanisms.

Stay tuned as we advance both the user experience and the backend infrastructure of Hatchstr together. If you're interested in following along or contributing to the development, feel free to reach out!

Nostr QR
npub16scfufrpsqcukjg7ymu4r40h7j4dwqy4pajgz48e6lmnmz5pljcqh678uh
Thank you for reading and being part of this journey! 🧡

Part 2 on the public journey of developing Hatchstr 🪺: Digital ...

2025-02-20T21:16:34Z

Yap, got those two as well 😂

2025-02-13T17:57:37Z

In reply to nevent1q…g2p4
_________________________

Yap, got those two as well 😂

Same accounts or different names?

2025-02-13T13:16:16Z

In reply to nevent1q…e68m
_________________________

Same accounts or different names?

Anyone else having these accounts that constantly follow and ...

2025-02-13T10:07:44Z

Anyone else having these accounts that constantly follow and unfollow you? Seems like always the same 2-3 🤔👀
#AskNostr

Already a big improvement over X, if it's bots you actually ...

2025-02-13T10:05:12Z

Already a big improvement over X, if it's bots you actually want to see 😂

I think this will be a major point of development for #Nostr : Feed customization and fine tuning. Killer feature ⚡🚀

#GrowNostr

quoting
note1wc7…e8hc
My whole nostr feed is bots reposting stuff from Twitter.

I miss my frens on my feed 👀

Feels like Twitter all over again.
But I also don’t want to unfollow all of these bots yet since they got some value.

Any way to filter these posts to only show up if they hit a specific like number or zaps?

Or only allow certain time interval? My ratio is literally 8 news bots notes to 2 frens notes.

Oh dang, I got too much 😱 I'll sell then 🤣

2025-02-13T10:00:15Z

In reply to nevent1q…cu66
_________________________

Oh dang, I got too much 😱
I'll sell then 🤣

Not really possible, but I would love it to be easier to ...

2025-02-11T13:50:09Z

In reply to nevent1q…quh4
_________________________

Not really possible, but I would love it to be easier to understand and explain to people.

Even if someone is interested at first and asks how it works, their eyes glace over when you try to explain hashing functions, even in the most simple of terms.
It's just so different from everyones every day life 🤷🧡

Nice, sure will! 🧡 I'm still in the planning stages, Part ...

2025-02-11T01:33:44Z

In reply to nevent1q…ljze
_________________________

Nice, sure will! 🧡

I'm still in the planning stages, Part 2 article coming soon 🤘🚀

Hmm still, works with other users for me 🤷 ...

2025-02-11T01:31:23Z

In reply to nevent1q…uep9
_________________________

Hmm still, works with other users for me 🤷

Also become at peace with having problems, everybody has them ...

2025-02-10T20:21:36Z

In reply to nevent1q…pj3s
_________________________

Also become at peace with having problems, everybody has them 🕊️

Thank you so much 🧡 I hope it could be a valuable contribution ...

2025-02-10T19:42:08Z

In reply to nevent1q…9mec
_________________________

Thank you so much 🧡
I hope it could be a valuable contribution that makes sense.
Trying to get some pointers from people, that know the ecosystem well, since I'm new to the space 😅🚀

GM everyone 👋 I had this idea and finally want to start ...

2025-02-10T14:25:27Z

In reply to nevent1q…jnlf
_________________________

GM everyone 👋

I had this idea and finally want to start building on Nostr myself:

🪺 Hatchstr – a decentralized app for digital time-capsules that only unlock at specific Bitcoin block heights.

I wrote an article breaking down the concept, challenges, and how Nostr helps decentralize it.

I’d love everyone's feedback! 🧡

quoting
naddr1qq…uwsa

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 allows users to publish messages to decentralized 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—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 🧡

GM everyone 👋 I had this idea and finally want to start ...

2025-02-10T14:25:18Z

In reply to nevent1q…xukp
_________________________

GM everyone 👋

I had this idea and finally want to start building on Nostr myself:

🪺 Hatchstr – a decentralized app for digital time-capsules that only unlock at specific Bitcoin block heights.

I wrote an article breaking down the concept, challenges, and how Nostr helps decentralize it.

I’d love everyone's feedback! 🧡

quoting
naddr1qq…uwsa

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 allows users to publish messages to decentralized 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—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 🧡

GM everyone 👋 I had this idea and finally want to start ...

2025-02-10T14:24:36Z

In reply to nevent1q…62rw
_________________________

GM everyone 👋

I had this idea and finally want to start building on Nostr myself:

🪺 Hatchstr – a decentralized app for digital time-capsules that only unlock at specific Bitcoin block heights.

I wrote an article breaking down the concept, challenges, and how Nostr helps decentralize it.

I’d love everyone's feedback! 🧡

quoting
naddr1qq…uwsa

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 allows users to publish messages to decentralized 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—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 🧡

GM everyone 👋 I had this idea and finally want to start ...

2025-02-10T14:23:58Z

In reply to nevent1q…8z8m
_________________________

GM everyone 👋

I had this idea and finally want to start building on Nostr myself:

🪺 Hatchstr – a decentralized app for digital time-capsules that only unlock at specific Bitcoin block heights.

I wrote an article breaking down the concept, challenges, and how Nostr helps decentralize it.

I’d love everyone's feedback! 🧡

quoting
naddr1qq…uwsa

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 allows users to publish messages to decentralized 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—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 🧡

GM everyone 👋 I had this idea and finally want to start ...

2025-02-10T14:20:15Z

In reply to nevent1q…xpj4
_________________________

GM everyone 👋

I had this idea and finally want to start building on Nostr myself:

🪺 Hatchstr – a decentralized app for digital time-capsules that only unlock at specific Bitcoin block heights.

I wrote an article breaking down the concept, challenges, and how Nostr helps decentralize it.

I’d love everyone's feedback! 🧡

quoting
naddr1qq…uwsa

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 allows users to publish messages to decentralized 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—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 🧡

That's an interesting idea, how could that work with the ...

2025-02-10T10:27:15Z

In reply to nevent1q…z8mq
_________________________

That's an interesting idea, how could that work with the time-locking encryption? You would have to be able to manually delete the message. I'll see if it's possible 👍

btw, couldn't zap you, it said you don't have lightning ...

2025-02-10T00:01:34Z

In reply to nevent1q…s3nq
_________________________

btw, couldn't zap you, it said you don't have lightning setup 🤷

Hey, no I didn't start yet, just brainstorming, thinking in ...

2025-02-09T23:49:10Z

In reply to nevent1q…s3nq
_________________________

Hey, no I didn't start yet, just brainstorming, thinking in public and getting some feedback on the idea since I'm new to Nostr myself.

I'm planning to split the project into two parts:
-the capsule designing part, including a client web app (probably React SPA)
-and the time-locking encryption part with a repo for documentation and an initial Clock Server implementation (probably Elixir+Phoenix, cause that's what I know best)

Nothing set in stone though, ofc!

If you're interested, I'd love to have a chat and hear what you think about it. 🤝⚡

Getting from 0 to 1 was scary, but also exciting. I'm pumped ...

2025-02-09T19:46:09Z

Getting from 0 to 1 was scary, but also exciting. I'm pumped to start building 🚀🚀

I haven't thought about how lightning and zaps would fit into ...

2025-02-09T19:28:36Z

In reply to nevent1q…hrnn
_________________________

I haven't thought about how lightning and zaps would fit into it
This seems like something to be handled by the lightning protocol itself though ⚡

Hey everyone! As my first deep dive into learning the Nostr ...

2025-02-09T15:36:00Z

Hey everyone!

As my first deep dive into learning the Nostr protocol I’m planning to build something I hope you’ll love:

🪺 Hatchstr – a decentralized app for digital time-capsules that only unlock at specific Bitcoin block heights.

Imagine sending a message to your children, words of wisdom that unlock years later, or a bold Bitcoin price prediction sealed away until the future! 🕰️✨

I wrote an article breaking down the concept, challenges, and how Nostr helps decentralize it. I’d love your feedback! 🧡

quoting naddr1qv…2dep

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 allows users to publish messages to decentralized 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—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 🧡

fiatjaf (npub180c…h6w6) Derek Ross (npub18am…p424) preston (npub1s5y…6q7z) ODELL (npub1qny…95gx) Nostr News Network (npub1art…6l9m) jack (npub1sg6…f63m) walker (npub1cj8…rz4u) and anyone interested in decentralized communication—what do you think? 🤔

#nostr #bitcoin #decentralization #buildinpublic #Hatchstr

Hey, I don't know about this feature on Facebook. Could you ...

2025-02-09T13:41:07Z

In reply to nevent1q…gmfq
_________________________

Hey, I don't know about this feature on Facebook. Could you explain how it works? Are the messages kept secret from everyone?

GM everyone 👋 I had this idea and finally want to start ...

2025-02-09T13:17:05Z

In reply to nevent1q…v8e4
_________________________

GM everyone 👋

I had this idea and finally want to start building on Nostr myself:

🪺 Hatchstr – a decentralized app for digital time-capsules that only unlock at specific Bitcoin block heights.

I wrote an article breaking down the concept, challenges, and how Nostr helps decentralize it.

I’d love everyone's feedback! 🧡

quoting
naddr1qq…uwsa

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 allows users to publish messages to decentralized 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—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 🧡

GM everyone 👋 I had this idea and finally want to start ...

2025-02-09T13:15:51Z

In reply to nevent1q…gceu
_________________________

GM everyone 👋

I had this idea and finally want to start building on Nostr myself:

🪺 Hatchstr – a decentralized app for digital time-capsules that only unlock at specific Bitcoin block heights.

I wrote an article breaking down the concept, challenges, and how Nostr helps decentralize it.

I’d love everyone's feedback! 🧡

quoting
naddr1qq…uwsa

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 allows users to publish messages to decentralized 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—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 🧡

I invite you to read the article, I talk about that problem in ...

2025-02-09T12:01:30Z

In reply to nevent1q…708x
_________________________

I invite you to read the article, I talk about that problem in detail and how we could find a decentralized way to get around this ⚡🧡

Hey everyone! As my first deep dive into learning the Nostr ...

2025-02-09T11:24:10Z

quoting naddr1qv…2dep

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 allows users to publish messages to decentralized 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—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 🧡

fiatjaf (nprofile…wjy3) , jack (nprofile…283f) , HODL (nprofile…hs8c) , walker (nprofile…yza6) , LynAlden (nprofile…u7e3) and anyone interested in decentralized communication—what do you think? 🤔

#nostr #bitcoin #decentralization #buildinpublic #Hatchstr

#naddr1qv…2dep

2025-02-09T00:57:05Z

In reply to nevent1q…qpzw
_________________________

quoting naddr1qv…2dep

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 allows users to publish messages to decentralized 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—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 🧡

🚀 Hey everyone! As my first deep dive into learning the Nostr ...

2025-02-09T00:49:22Z

🚀 Hey everyone!

As my first deep dive into learning the Nostr protocol I’m planning to build something I hope you’ll love:

🪺 Hatchstr – a decentralized app for digital time-capsules that only unlock at specific Bitcoin block heights.

Imagine sending a message to your children, words of wisdom that unlock years later, or a bold Bitcoin price prediction sealed away until the future! 🕰️✨

I wrote an article breaking down the concept, challenges, and how Nostr helps decentralize it. I’d love your feedback! 🧡

🔗 Read here: naddr1qvzqqqr4gupzp4psncjxrqp3edy3ufhe282l0a926uqf2rmys920n4lh8k9grl9sqqxnzden8qcrwdfhxv6nqdfnfz2dep

fiatjaf (nprofile…wjy3) , jack (nprofile…283f) , HODL (nprofile…hs8c) , walker (nprofile…yza6) , LynAlden (nprofile…u7e3) and anyone interested in decentralized communication—what do you think? 🤔

#nostr #bitcoin #decentralization #buildinpublic #Hatchstr

The future will not belong to cowards. I seriously believe this, ...

2025-02-08T16:17:48Z

In reply to nevent1q…lmaa
_________________________

The future will not belong to cowards. I seriously believe this, the mob was following the Woke because they were speaking loudly and didn't censor themselves. Maybe things are turning now, maybe not.

In the end what can they really do?
If you get cancelled there is a whole parallel economy growing that is waiting for people with strong morals and conviction ⚡

The problem is there's too many scams, too much noise. ...

2025-02-06T13:26:51Z

In reply to nevent1q…c4ts
_________________________

The problem is there's too many scams, too much noise. It's too hard for normies to see the real opportunity. It's sad, but tbh the Bitcoin community has always done it's best to educate 🤷

You should put some pictures of houses that exactly cost the ...

2025-02-06T10:31:18Z

In reply to nevent1q…7xez
_________________________

You should put some pictures of houses that exactly cost the median. Would be nice to know 😊

Sounds cool, I might want to try this for my new project. I'm ...

2025-02-06T10:21:07Z

In reply to nevent1q…70ax
_________________________

Sounds cool, I might want to try this for my new project. I'm planning to develop a fun new nostr app in public and trying to create some buzz for my first article ⚡🎉

Mind if I hit you up for some questions once I'm ready? 🙏

Ses they wanted all the letters to touch, but then the S ...

2025-02-06T10:05:21Z

In reply to nevent1q…fk60
_________________________

Ses they wanted all the letters to touch, but then the S doesn't. And the B is only touching in one point. Uhhh it hurts 🤣🤣

MicroStrategy's, sorry Strategyyy's, graphic design ...

2025-02-05T22:25:46Z

MicroStrategy's, sorry Strategyyy's, graphic design prowess is a pointer to how early we are with #Bitcoin 🫣😂

note1c9q8e7l66r8m3wlmsry7etytw930y9yzmuunrwaff4y3exf8peas40uahz

2025-02-04T12:46:22Z

In reply to nevent1q…q9gn
_________________________

note1c9q8e7l66r8m3wlmsry7etytw930y9yzmuunrwaff4y3exf8peas40uahz

Anyone know a timeline on this?

2025-02-04T12:45:25Z

In reply to nevent1q…yuj9
_________________________

Anyone know a timeline on this?

Love the name @npub1s0v…rmq5 🧡

2025-02-04T10:40:06Z

In reply to nevent1q…m9hp
_________________________

Love the name Sovereign Engineering (npub1s0v…rmq5) 🧡

GM welcome to Cypher Elysium 🕊️🧡

2025-02-02T13:36:13Z

In reply to nevent1q…gnyq
_________________________

GM welcome to Cypher Elysium 🕊️🧡

I am using the default relays on @npub12vk…pugg and it's ...

2025-02-01T11:41:50Z

In reply to nevent1q…7gfp
_________________________

I am using the default relays on primal (npub12vk…pugg) and it's working without a hitch, maybe give it a try? gl

Having the state own part of social media apps, what could go ...

2025-02-01T11:26:52Z

In reply to nevent1q…ev6y
_________________________

Having the state own part of social media apps, what could go wrong 👁️👁️😅

I don't think there is a "nostr" to upload to, ...

2025-02-01T11:21:37Z

In reply to nevent1q…kl0q
_________________________

I don't think there is a "nostr" to upload to, depends on your relays and your client 😺

Beautiful heraldic glass art from a cathedral in Lübeck, Germany ...

2025-01-30T15:02:10Z

Beautiful heraldic glass art from a cathedral in Lübeck, Germany 🛡️⚔️
#art #artstr #photography

In your opinion, what is the etiquette for reposting yourself on ...

2025-01-30T11:23:46Z

In reply to nevent1q…w6lk
_________________________

In your opinion, what is the etiquette for reposting yourself on nostr? Because tbh I feel a bit weird about it 🤷

#AskNostr

Probably everybody 😅

2025-01-29T13:08:30Z

In reply to nevent1q…hh7l
_________________________

Probably everybody 😅

Do you really think the sequence will be: 🇸🇻 ➡️ ...

2025-01-29T12:33:16Z

In reply to nevent1q…zs4t
_________________________

Do you really think the sequence will be:
🇸🇻 ➡️ 🇧🇹 ➡️ 🇺🇸

I highly doubt it 😂

"Centralization actually provides a spark to innovation" ...

2025-01-27T14:33:48Z

In reply to nevent1q…c8un
_________________________

"Centralization actually provides a spark to innovation" How do you figure?

Do you mean that the opression forces you to innovate for your freedom?

Feels like saying you should like the bully because he stopped hitting you, which was nice 🙃

Yea this works, but makes a new note with new interactions (likes ...

2025-01-27T14:01:25Z

In reply to nevent1q…p0gm
_________________________

Yea this works, but makes a new note with new interactions (likes etc).
I was looking for smth like a repost but as a reply. I I repost someone the interactions go to the original note.

Probably doesn't exist but would be a cool feature. 🤷

yep 👍

2025-01-27T13:54:47Z

In reply to nevent1q…003m
_________________________

yep 👍

#AskNostr How would you guys respond to a note by linking a note ...

2025-01-27T13:51:06Z

#AskNostr How would you guys respond to a note by linking a note of your own?

Rn I use node id, but I noticed that this does not connect interactions to the original note (which feels wrong imo)

On the other hand using a link to the note works fine with interactions, but probably only with people on the same app and doesn't feel very nostr 😵‍💫

note17rt33u2vkn24e6l5legfvuvl5yk4luedzx96kf485v43cx2nupfs2tpeas

2025-01-27T13:32:20Z

In reply to nevent1q…fugx
_________________________

note17rt33u2vkn24e6l5legfvuvl5yk4luedzx96kf485v43cx2nupfs2tpeas

note17rt33u2vkn24e6l5legfvuvl5yk4luedzx96kf485v43cx2nupfs2tpeas

2025-01-27T13:30:31Z

In reply to nevent1q…4xjd
_________________________

note17rt33u2vkn24e6l5legfvuvl5yk4luedzx96kf485v43cx2nupfs2tpeas

note17rt33u2vkn24e6l5legfvuvl5yk4luedzx96kf485v43cx2nupfs2tpeas

2025-01-27T13:28:37Z

In reply to nevent1q…h9vn
_________________________

note17rt33u2vkn24e6l5legfvuvl5yk4luedzx96kf485v43cx2nupfs2tpeas

Honestly it's beyond belief for me that #MSTR is allowed to ...

2025-01-27T12:25:47Z

Honestly it's beyond belief for me that #MSTR is allowed to scoop up this once in a civilization asset and nobody in the mainstream notices or cares.

Idiocracy 🤦

#Bitcoin

What was the experiment?

2025-01-27T00:57:33Z

In reply to nevent1q…ggtg
_________________________

What was the experiment?

GM 👋 ...

2025-01-26T14:48:15Z

In reply to nevent1q…7wxr
_________________________

GM 👋

note1ngn92aktrx5gdncja30kcvlh8ax6jguyr8d99qnhzggkkapxucgstn09ug

note1ngn92aktrx5gdncja30kcvlh8ax6jguyr8d99qnhzggkkapxucgstn09ug

2025-01-26T13:10:53Z

In reply to nevent1q…572r
_________________________

note1ngn92aktrx5gdncja30kcvlh8ax6jguyr8d99qnhzggkkapxucgstn09ug

Before GM from the US 🫢🤣 https://m.primal.net/OBAl.png

2025-01-26T13:06:20Z

Before GM from the US 🫢🤣

I like to photograph moss, nature is pretty amazing, even in a ...

2025-01-26T12:28:51Z

In reply to nevent1q…xwck
_________________________

I like to photograph moss, nature is pretty amazing, even in a city you can find these treasures 🌿 🍄‍🟫

#photography #nature

Honestly, I thought it would be much much worse, but I'm ...

2025-01-26T12:19:48Z

In reply to nevent1q…4mt3
_________________________

Honestly, I thought it would be much much worse, but I'm probably just connected to the tamest relays 😅🤣

The value of #Bitcoin and #Nostr wouldn't change at all in ...

2025-01-25T23:47:20Z

In reply to nevent1q…3tkk
_________________________

The value of #Bitcoin and #Nostr wouldn't change at all in terms of personal freedom and censorship resistance.

The focus would shift to making bitcoin into a medium of exchange instead of store of value first. (Zaps are a great start there and a real value rn! ⚡)

I wouldn't put my savings into it in that case, of course. We would all be forced again to search for productive assets to outpace inflation 🤷

I want to focus on getting my freelance app development up and ...

2025-01-25T16:14:58Z

In reply to nevent1q…qnt0
_________________________

I want to focus on getting my freelance app development up and running, hopefully building with some cool people and projects in the #Bitcoin , #Nostr space 🥳🚀

#MSTR #Bitcoin #Saylor https://m.primal.net/NzgQ.png

2025-01-25T15:18:13Z

#MSTR #Bitcoin #Saylor

My favourite picture taken just with my phone 😊 ...

2025-01-25T14:39:55Z

My favourite picture taken just with my phone 😊

#photography #photo #artstr #art #nostr