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

Timezone Handling for Scheduled Publishing (Current State) - 3/9/2026 Summary: Continuum currently displays scheduled publishing times using a fixed timezone while future improvements will allow timezone configuration per identity. While testing scheduled publishing today, I noticed that scheduled times are currently displayed using a fixed timezone. Right now the API converts scheduled timestamps using a hard-coded timezone setting. This works fine for development and testing, but it is not the long-term plan. Continuum identities already store configuration data locally, and timezone settings can eventually be pulled directly from the active identity configuration. That would allow each identity to display scheduled publish times relative to its own local context. For now the behavior is simple and predictable, which is good enough while the scheduling system itself is being validated. #continuum #scheduler #nostr #software

Toward a Personal Relay 3/8/2026 The relay configuration used locally today could eventually run on an always-on machine and become a permanent personal relay endpoint. For now it serves as a development relay while the architecture continues to evolve. #nostr #relays

Title: Local Relay for Development - 3/8/2026 The Docker relay currently runs locally and is useful for testing relay interactions and inspecting events. Events written to it remain local unless they are also published to external relays. #nostr #development

Improved publish_event Logic - 3/8/2026 Updated the relay manager logic so publishing is considered successful if at least one relay accepts the event. This better reflects how Nostr publishing works in practice. #nostr #relay-manager

Relay Pubkey Whitelisting Enabled - 3/8/2026 Configured the relay with pubkey whitelisting so that only approved identities can publish events. This keeps the relay clean and prevents unwanted writes while testing. #nostr #relays #security

Local Relay Running in Docker - 3/8/2026 Successfully started a Nostr relay locally inside Docker. The relay currently runs only on my development machine and is not yet exposed publicly. Even so, it provides a useful environment for debugging, testing relay behavior, and validating publishing logic. #nostr #relays #docker

Sabbath Reflection: Rest and Building - 3/7/2026 Summary: Considering the relationship between rest, calling, and building meaningful systems. --- The Sabbath is traditionally understood as a day of rest. But rest does not always mean inactivity. Sometimes rest means stepping away from obligation and moving toward calling. Today I continued building Continuum. And yet the work felt calm, focused, and almost restorative. Perhaps the difference is not activity versus inactivity. Perhaps the difference is obligation versus alignment. When the work aligns with purpose, the experience changes. It becomes something closer to rest than labor. #sabbath #calling #reflection

Sabbath Reflection: Writing Without Permission - 3/7/2026 Summary: Local-first tools allow creators to write without waiting for platforms or networks. One of the things I appreciate about Continuum is that writing does not require permission. There is no server that must be reachable. No platform that must approve the post. No account system that must authenticate you. You can simply write. If the network is available, the event can be published. If it is not, the event can wait. But the act of writing itself is never blocked. That small design choice restores something that the modern internet slowly took away: independence. And that independence feels particularly appropriate to reflect on today. #sabbath #sovereignty #writing

Sabbath Reflection: Quiet Progress - 3/7/2026 Summary: A reminder that meaningful progress often happens quietly and without external recognition. --- There are days when building something new feels loud. Announcements, releases, conversations. And then there are days like today. Quiet days. Today I spent most of the time refining small behaviors in the system. Disabling publish buttons when the network is offline. Ensuring notes behave correctly. Improving the overall experience. None of this will likely make headlines. But software is not built from headlines. It is built from hundreds of small, careful decisions. Quiet progress still counts as progress. #sabbath #reflection #building #persistence

Sabbath Reflection: Offline First - 3/7/20206 Summary: Observing how building offline capabilities in Continuum reinforces the philosophy of local-first computing. --- One of the things I worked on today was strengthening Continuum’s offline behavior. When the system detects that the network is unavailable, it now communicates that clearly to the user. Certain actions—like publishing events or deleting notes from relays—are disabled while offline. Other actions remain available. Writing remains available. Scheduling remains available. Signing remains available. Only the parts that truly require the network are restricted. This is what local-first software is supposed to feel like. The machine in front of you remains fully capable even when the outside world disappears. It is surprising how rare that philosophy has become. Today’s small changes brought Continuum closer to that vision. #sabbath #continuum #offline-first #nostr

Sabbath Reflections: Work That Does Not Feel Like Work - 3/7/2026 Summary: A reflection on the strange gift of building something meaningful on the Sabbath without feeling burdened by it. --- Today I worked. But it did not feel like work. There is a difference between labor that drains you and labor that feels aligned with purpose. Today was the latter. The hours passed quietly, almost unnoticed, as I continued implementing offline capabilities inside Continuum. In particular, the notes system is now very close to being fully functional even when the network is unavailable. Notes can still be written, signed, scheduled, and managed locally. Publishing may wait until connectivity returns, but the act of writing itself does not depend on the network. This feels important. Most software assumes the network is always present. But real life is not like that. Planes lose connection. WiFi drops. Relays go offline. And yet writing should continue uninterrupted. In a small way, building software that respects this reality feels like honoring the rhythm of life itself. And today, oddly enough, that work felt like rest. #sabbath #reflection #work #calling #continuum

This is a test

Example screenshot of an event (kind:1) that was signed but then published later https://is.gd/wawt2Z (this note itself will be published 2 minutes from the time it was signed)

Builders often work in silence -3/6/2026 --- Summary: Many of the most important infrastructure projects are built quietly for years before gaining widespread recognition. --- There is an unusual rhythm to infrastructure work. For long periods, it feels like nothing is happening. A small group of builders works quietly. Progress is slow. Adoption appears minimal. Most people are unaware the system even exists. Then gradually, something shifts. Developers begin experimenting with the tool. Early adopters begin using it for real work. The architecture proves reliable. Eventually, the system crosses a threshold where it becomes difficult to ignore. Many foundational technologies followed this path. Git was initially used by a small group of developers before becoming the dominant version control system. Bitcoin existed for years before gaining global attention. Even the early internet protocols developed quietly before becoming essential infrastructure. Infrastructure rarely spreads through marketing. It spreads through usefulness. Builders who focus on architecture rather than hype often work in relative silence for long periods. But if the foundation is strong, the work compounds. Over time, quiet systems can become indispensable. Not because they demanded attention. Because they continued working. --- #builders #infrastructure #craft

The internet never solved identity - 3/6/2026 --- Summary: The internet solved communication and distribution but left identity fragmented across countless platforms. --- The internet solved some remarkably complex problems. Packet routing across global networks. Distributed communication between millions of machines. Instant data transmission across continents. But one problem remained strangely unsolved. Identity. Instead of a unified identity layer, the internet evolved into thousands of separate account systems. Every platform requires a new login. Every service maintains its own user database. Every application manages its own authentication flow. The result is fragmentation. Users manage dozens or even hundreds of accounts. Password resets, email confirmations, and login failures have become routine parts of online life. Cryptographic identity offers a simpler approach. Instead of accounts issued by platforms, users generate keypairs. Applications verify signatures rather than managing identity databases. This approach reduces fragmentation dramatically. One key can authenticate across many services. One identity can move across many applications. Protocols like Nostr demonstrate how this model might work at scale. Rather than solving identity through centralized systems, they solve it through cryptography. The identity belongs to the user. Applications simply recognize it. --- #identity #internet #nostr

Keys are the foundation of sovereignty - 3/6/2026 --- Summary: Digital sovereignty begins with controlling your cryptographic keys rather than relying on platform-managed accounts. --- When people talk about digital sovereignty, the conversation often becomes abstract. But the concept itself is very concrete. It begins with keys. If you control your keys, you control your identity. If someone else controls them, they control your access. Traditional platforms rarely allow users to control their own identity infrastructure. Instead, they issue accounts and manage authentication internally. Users log in with email addresses and passwords. The platform becomes the authority. Cryptographic identity flips this model. Instead of the platform creating the identity, the user generates a keypair. The public key becomes the identifier. The private key becomes the authority. This small shift changes the power structure of the system. Platforms no longer issue identities. They verify signatures. Nostr demonstrates this model clearly. Users generate keys locally. Events are signed locally. Relays simply transmit the signed messages. Applications interpret those messages in different ways, but the identity remains independent of any single service. This independence is what makes digital sovereignty possible. The key does not belong to the platform. It belongs to the individual. And that changes everything about how identity works online. --- #sovereignty #identity #keys

Software should fail gracefully -3/6/2026 Summary: Systems designed for resilience assume parts of the network will fail. Local-first architecture ensures work can continue regardless. Many modern applications assume the network is always available. That assumption works most of the time. Until it doesn't. Outages happen. APIs break. Services disappear. Platforms change policies or simply shut down. When an application depends entirely on remote infrastructure, these failures can stop work immediately. Local-first systems approach this problem differently. Instead of assuming the network will always work, they assume it will sometimes fail. The system is designed to continue functioning regardless. Data is stored locally. Applications run locally. Network synchronization becomes an enhancement rather than a dependency. This philosophy mirrors how resilient physical infrastructure is designed. Electrical grids include redundancy. Road networks offer multiple routes. Distributed systems replicate data across multiple locations. Resilience is not achieved by eliminating failure. It is achieved by designing systems that continue working when failure occurs. Local-first software applies this principle to personal computing. If the network disappears, the work continues. If a relay goes offline, the content still exists elsewhere. If a platform disappears, the identity remains intact. Graceful failure is one of the most underrated qualities in software architecture. But historically, it is one of the qualities that separates durable systems from fragile ones. --- #resilience #architecture #local-first

The architecture is the product - 3/6/2026 Summary: In durable systems, architecture matters more than features. The structure of the system determines what it can become. A common mistake in software is thinking that features define the product. In reality, architecture defines the product. Features are temporary. They change, evolve, and sometimes disappear entirely. Architecture, however, shapes what the system can become over time. If the architecture is fragile, no amount of features can save it. But if the architecture is strong, the system can evolve almost indefinitely. This is why many durable technologies appear deceptively simple at first. Git did not launch with dozens of polished features. SSH did not attempt to solve every networking problem. Bitcoin did not attempt to replicate the entire financial system. Each focused on a clear architectural foundation. Once that foundation existed, the ecosystem grew around it. This perspective is useful when evaluating new software. Instead of asking: “What features does this system have?” A better question is: “What architecture does this system enable?” Architecture determines: • how identities are managed • how data moves through the system • who ultimately controls the environment Local-first systems and cryptographic identity models are interesting not because of their current features, but because of the architectural possibilities they create. Once identity becomes portable and data becomes local-first, an entire new class of applications becomes possible. The architecture changes first. Everything else follows. #architecture #infrastructure #systems

Continuum now supports scheduled publishing for notes. Articles coming next. This means you can write locally, queue posts, and let them publish automatically — without giving custody of your keys to any platform.