Next round of open source contributions to SN. User subscriptions are on their way, and I’m working on de-duplicating notifications next!

I am going back to continue building my Bitcoin Citadel into the mountains. My goal for this week is another 3-4 levels of sacks.

I'm going to be pushing some changes shortly that I'll explain when I do that.

Otherwise, I have 2 tabconf presentations I have to make/build/whateverthefuck.

I'm working on an application-agnostic email authentication service for nostr (or any other app dependent on client side keypairs).

The goal being that any developer can paste in a snippet to provide email based login without setting up all the requisite services.

Hopefully, this will allow devs to continue designing around key-based flows for sovereign users, while permitting co-dependent users to easily participate in their communities.

Normies struggle with key-based apps, and most default password managers aren't great at handling them either.

Key delegation is another consideration. It's bad to give multiple apps the same top-level key that can't be easily revoked, and remote-signing setups are too much friction if we're to onboard the masses and make decentralized projects sustainable.

Email authentication is a familiar pattern, and is necessary for things like nostr apps to gain traction with the broader population.

Even seasoned systems operators who access critical servers with SSH keys often have copies of those keys stored behind some email-authenticated cloud service.

These may be sad realities but we must be intellectually honest about them as builders.

Say a nostr app generates a keypair for a user (or allows them to import one), a snippet from the service offers the user ability to link that to an email.

The keys (optionally encrypted with a password), combined with a unique application identifier, and the users email are sent by the client-side snippet to the service.

After the user verifies ownership of the email, the keys are stored by the service for later recovery and associated with the unique application identifier.

In a recovery situation, the service redirects the user to the whitelisted domain- where the credentials are safely re-injected back into the client for use.

In this way, a developer only needs to enroll an application ID and SSL domain with the service where the client is hosted. A negligible fee to enroll your domain would prevent abuse and split the cost of the email server.

Are you a developer? User? What do you think, would you leverage this service? Why or why not?

i'm doing the PlebLab's course on Nostr https://www.udemy.com/course/nostrdevs/

pretty cool how easy it is to interact with nostr network, today i'm playing with a bot that answers 'good morning' to anyone ☀️

Trying out lightning for the first time!

Grinding through the last part of a client gig so that I may earn a normie/fiat payment and then shift focus exclusively to a small fleet of software+games have been chipping away at.

Trying out htmx and learning Rust language

Stackins sats

A few weeks ago, I posted some demo tracks for my ternary rhythm music project: https://www.youtube.com/playlist?list=PLyFgc8iiNfYjf3rmuvbsZXF81hIWgnv2L The first and third tracks are mostly original (it's complicated). The second and fourth tracks are based on Voices (Dream Theater) and Close to the Edge (Yes). I've got some more demo tracks to upload (based on Tarkus, YYZ, and Under a Glass Moon). Then, I need to start shopping around for musicians.

A short video for a crypto conference