scheduled note -- 5 min from now

The password internet is broken. Every platform stores credentials. Every breach leaks identities. Cryptographic identity fixes this. #nostr #sovereignty

Just to be clear: I am a Bitcoiner. I am a Christian. I believe in the victorious Gospel. I believe in sovereignty — spiritual, personal, and digital. I make no apologies for this. For me these convictions are not contradictory or extreme. They form a consistent, sane, joyful, and grounded view of reality. If that bothers some people, so be it. I’m not here to please everyone — I’m here to live and build according to what I believe is true.

Private Relay as a Debugging Tool - 3/11/2026 Running a private relay locally has already proven useful for development. Even though the relay currently runs only on my machine, it provides several advantages: • deterministic testing • controlled publishing behavior • whitelisted writers • predictable event storage Unlike public relays — which sometimes fail, timeout, or behave inconsistently — a local relay behaves exactly as expected. For debugging complex publishing flows, this is extremely valuable. Eventually this relay could also be exposed via a reverse proxy as something like: wss://relay.continuum.xyz But for now, running it locally inside Docker is already useful.

Backfilling a Local Relay - 3/11/2026 One experiment I'm considering is **backfilling my local relay**. I currently have roughly: • 700+ articles • 500+ notes If all of those events are republished to the local relay, the relay becomes a **complete local mirror** of my writing history. This would create a few advantages: • faster queries • deterministic storage • easier testing of relay behavior • simpler debugging The relay effectively becomes a **local indexing engine for Nostr events**. The main thing to watch is limits such as `maxLimit = 500` in strfry configuration. But since this limit only affects queries, not stored events, it should not prevent the relay from holding the entire archive. Again, something to test later.

Relay Lists as Persistent Artifacts - 3/11/2026 Another architectural question surfaced today: **where should my relay list live?** Nostr has a built-in solution: kind:10002 — relay list metadata. Because I already publish relay lists, Continuum could simply retrieve the **latest 10002 event** and use that as the canonical relay configuration. This would mean: • relay configuration becomes portable • relay lists become part of identity history • new installations automatically inherit correct relay configuration Instead of storing relays only in local configuration files, they could become **signed identity artifacts**. That is a much more elegant model.

Local Relay Backfill Experiments - 3/11/2026 Today I started thinking more seriously about using my local relay (running strfry in Docker) as a **performance optimization layer**. Right now Continuum can rebuild the archive from: 1. The deterministic archive repo 2. Multiple public relays 3. Local cached data But a **locally running relay** opens another interesting possibility. If I backfill the relay with all of my existing events (700+ articles and 500+ notes), the relay effectively becomes a **local event index**. That means: • startup reads could be faster • queries could be simpler • archive rebuilds might become optional The open question is performance. Is reading from a local relay faster than rebuilding from the archive? The only way to know is to test it. This isn't urgent, but it's an intriguing direction.

The Pattern for Sovereign Micro-Apps - 3/10/2026 Summary: Today reinforced a pattern for building extremely simple sovereign applications for real businesses. One insight from today is that **simple sovereign applications are becoming easier to build**. Earlier today I finished a small application concept for **Kiki’s Kitchen**. The architecture was intentionally minimal: • static HTML • lightweight admin interface • no external database • simple local file storage The entire project was completed in **roughly two hours**. This reinforces a pattern I’m beginning to see: Small sovereign apps can be built quickly when the constraints are clear. Instead of building massive SaaS platforms, we can build **focused tools that run locally and solve a specific problem**. For many small businesses, that is more than enough. #software #sovereignty #local-first #apps

Identity and Trust on the Open Internet - 3/10/2026 Summary: Publishing keys and verifiable identity infrastructure is a step toward restoring trust online. One of the ongoing problems with the modern internet is the collapse of **verifiable identity**. Most systems rely on: • email/password accounts • centralized identity providers • opaque authentication flows Publishing cryptographic keys reverses that model. Instead of trusting a company to verify who someone is, you verify **directly using cryptography**. Nostr uses public keys for identity. PGP allows verification across other channels. When these systems are used together, they create something powerful: **portable digital identity that is not owned by a platform.** #identity #trust #nostr #pgp

Builders Work Quietly - 3/10/2026 Summary: Much of building happens quietly, far from the noise of social media. Today was a reminder that building rarely looks dramatic from the outside. There are long stretches of quiet work: • updating profiles • refining small applications • responding carefully to thoughtful messages • experimenting with patterns None of this looks impressive on social media. But these small steps accumulate. Over time they become the foundation for much larger systems. #builders #reflection

A Positive Signal - 3/10/2026 Summary: A thoughtful signal from a Nostr user prompted a deeper response and several hours of reflection. Today I received a positive signal from a Nostr user. Signals like this matter more than people might realize. Most of the time when you publish online, especially when building something new, you are operating in **relative silence**. You release ideas. You ship code. You publish articles. And often the response is minimal. But occasionally someone thoughtful reaches out and engages. The user's message prompted me to spend time crafting a careful response. I probably spent close to **two hours thinking through and writing that reply**. These moments are encouraging. They remind me that even when progress feels slow, the work **is reaching people who understand what is being built**. #nostr #builders #signals #network

Updating My Nostr Profile and Adding PGP Verification - 3/10/2026 Summary: I spent time updating my Nostr profile and publishing my OpenPGP public key for encrypted communication and verification. Today I spent some time refreshing my Nostr profile. The biggest change was publishing my **OpenPGP public key** and creating a dedicated page for it. This allows people to: • verify messages I sign • encrypt communications to me • confirm that identities I control are legitimate In the Nostr world, identity is tied to the **npub / private key pair**, but PGP still serves an important complementary role. PGP allows: • cross-platform identity verification • signed documents outside Nostr • encrypted email communication Publishing the key fingerprint publicly is also important so people can confirm they are using the correct key. It is a small step, but it strengthens the broader theme I care about: **self-sovereign identity and verifiable communication.** #nostr #pgp #gpg #identity #security

stimmt !

Local Scheduling as a Sovereign Publishing Primitive - 3/9/2026 Summary: Scheduled publishing is a fundamental building block for sovereign publishing systems built on Nostr. Many publishing platforms support scheduled posts. But they do so by storing drafts and keys inside centralized services. Continuum takes a different approach. Events are signed locally first. Then the scheduler simply decides when to publish them. This keeps the important boundary intact: Signing stays local. Publishing can be delayed. That small difference preserves control over keys and identity. #nostr #sovereignty #continuum #publishing

Article Scheduling UI Parity with Notes - 3/9/2026 Summary: The article list view in Continuum now reflects scheduled publishing states similar to notes, improving visibility into upcoming posts. Notes already displayed scheduled publishing clearly. Articles did not. Today I corrected that. Now the article list view understands three states: Unpublished Scheduled Published If an article is scheduled, the interface now shows: Scheduled badge Scheduled publish time Disabled “Publish (Scheduled)” button This keeps the UI consistent across notes and articles and makes it much easier to see what is queued for publication. #continuum #ui #nostr #software

Scheduling Events While Offline - 3/9/2026 Summary: Continuum preserves scheduled publishing events even if the network is offline, ensuring they publish once connectivity is restored. One subtle but important behavior showed up during testing today. If Continuum is offline when a scheduled publish time occurs, the event does **not fail**. It simply remains in the scheduled state. Once the network returns and Continuum restarts, the scheduler detects that the publish time has already passed and immediately publishes the event. This avoids a major class of failure that many scheduling systems have. In other words: Offline does not break the scheduler. It simply delays execution until publishing is possible. For a local-first publishing system, that behavior matters a lot. #continuum #nostr #offlinefirst #softwaredesign

Scheduled Publishing for Articles Now Working - 3/9/2026 Summary: Continuum now supports scheduled publishing for both notes and articles, enabling authors to queue signed events locally and publish them automatically at a future time. Today I confirmed that scheduled publishing works not only for notes but also for long-form articles in Continuum. The workflow now looks like this: 1. Write the article locally 2. Sign the event locally 3. Choose a future publish time 4. Continuum stores the signed event and waits 5. At the scheduled time, the event is automatically published to relays This means authors can queue work ahead of time without giving custody of their keys to a third-party platform. Everything happens locally. Even better, if the machine is offline when the scheduled time passes, the event remains in a scheduled state and publishes automatically once the network is restored and Continuum restarts. This is exactly the kind of behavior a sovereign publishing system should have. #continuum #nostr #publishing #localfirst #sovereignty