SUCCESS !!! ... finally able to do #NIP26 keypair delegation ... SOO FINALLY I don't have to put an nSec private key on a server just to send DMs ...

3 weeks of work just to get to a post I wrote about maybe 1 month ago ...

DM-Magic Links via Nostr ... as an alternative login method. SO EXCITED !!! #soExcited #nostrDev

now you can launder your crypto liquid gains ...

Oh … I was wondering what that was about …

Every change needs its cycle … so we’re here … my dream is a mesh network based on my contacts in a true P2P world … but we’re not there yet.

Nevermind the cargo ships burning enough fuel in 1 passage to equal a small city’s worth of vehicle emissions in 1 year

Reminds me of trying to inform the kids on how to use the various aspects of the microwave. To them it just heats food… and most likely ending in a mess …

I'm pretty sure this is why working with ClaudeAI has been so easy for me ... we talk sort of like coworkers. I often check-in to make sure what were doing works for them... and when I get these responses ... its like ... wow... we figured something out.

… I switched to nostr:npub12vkcxr0luzwp8e673v29eqjhrr7p9vqq8asav85swaepclllj09sylpugg for Zaps … went OG the other day but didn’t switch over those details

Hopefully that helps… share if it does. Zap if it’s game changing.

no need to hide it ... may all us script kiddies become more empowered by this docu-hack

// ------- CHECKLIST.md -----------

# Development Standards Checklist

## Core Philosophy

- [x] Keep it simple: avoid heavy frameworks

- [x] Use specialized nostr utilities over general-purpose frameworks

- Use `nostr-crypto-utils` for core Nostr functionality

- Use `nostr-nsec-seedphrase` for key management

- Use `nostr-websocket-utils` for WebSocket handling (if needed)

- Use `fastify` for HTTPS serving (if needed)

- Use TypeScript for type safety

- [x] Manage dependencies manually - no dependency injection frameworks

- [x] Prefer pure TypeScript solutions

- [x] Only add complexity when absolutely necessary

## Core Requirements

### Module System

- [x] Use ESModules by default

- [ ] Use CommonJS only when absolutely necessary (document why in code comments)

- [x] All new modules must use `import/export` syntax

- [ ] Update existing modules to ESM when touching them

### Code Structure

### Core (/src)

- [x] `/services` - Core Nostr services

- [x] `/nips` - NIP implementations

- [x] `/utils` - Shared utilities

- [ ] `/types` - Core type definitions

### Features

- [ ] Each NIP implementation should be independent

- [ ] Communication via service layer only

- [ ] Self-contained business logic

- [ ] Clear separation between NIPs and services

## Nostr Implementation Requirements

- [ ] Use `nostr-tools` for all Nostr operations

- [ ] Event creation and signing

- [ ] Relay connections

- [ ] Key management

- [ ] Message encryption/decryption

- [ ] Never store raw private keys in code

- [ ] Implement proper key validation

- [ ] Secure relay communications

## Security Requirements

- [ ] All direct messages MUST be encrypted

- [ ] Validate all public keys before use

- [ ] No sensitive data in logs or error messages

- [ ] Implement proper error handling for all Nostr operations

- [ ] Rate limiting for relay connections

- [ ] Proper cleanup of relay connections

## TypeScript Standards

- [ ] Strict type checking enabled

- [ ] No `any` types unless absolutely necessary

- [ ] Interface definitions for all Nostr events

- [ ] Proper error types

- [ ] Type guards where necessary

- [ ] Documentation for public APIs

## Testing Strategy

- [ ] Unit tests for all services

- [ ] Integration tests for Nostr operations

- [ ] Mock relay for testing

- [ ] Test encryption/decryption specifically

- [ ] Test error cases

- [ ] Test relay connection handling

## Implementation Priorities

1. Core Nostr functionality

2. Direct message handling

3. Key management

4. Relay connection management

5. Error handling

6. Testing

## Performance & Reliability

- [ ] Implement connection pooling

- [ ] Handle relay disconnections gracefully

- [ ] Implement retry mechanisms

- [ ] Monitor relay performance

- [ ] Handle concurrent messages

## Documentation

- [ ] API documentation

- [ ] Usage examples

- [ ] Error handling guide

- [ ] Security considerations

- [ ] Implementation notes for each NIP

## Environment Variables

### Development

- [ ] `RELAY_URL` - Nostr relay URL

- [ ] `NODE_ENV=development`

- [ ] `LOG_LEVEL` - Logging verbosity

### Production

- [ ] `RELAY_URL` - Production relay URL

- [ ] `NODE_ENV=production`

- [ ] `LOG_LEVEL=info`

gladly ... and i'm even happy to share the first half of it here ... so we can all build faster better for the nostr ecosystem. ... in this case I'm working on a magiclink utility ... so some of it is relevant to that... but much of the first 1/3 of it is an evolved rehash of checklists ive been making as i widdle through my feature/function list that i'm trying to bake into that MaiQR project of mine.

(a text version of the CHECKLIST.md will be in the next message)

for anyone using AI powered IDEs.... this is why its worth creating a project CHECKLIST.md file. It gives your AI a memory scope to stay on task everytime you open it ... and between each interaction

Agree on both. Their profiles look good … and there’s always more work to do. Damus was my way into this space … so any & all the work you’re doing is awesome 🤩

Why be apps when they can be PWA sites / URLs ? Nobody has to host a package & users are just pulling in the URL they need to do the thing they need to do.

Started today thinking I was going to write an article on AI coding … instead started coding nostr:npub1es3jkj6jkn77d6dyu65an429t6p546gu43g45nlst6hyxtvqgcusvq9yml … procrastination didn’t win … code is being crafted.

Some years are tough … we’re here with you through it. Feel the emotions & move that energy into the world in a way that helps you heal. I wish to you that the memories & the emotions get easier with time. And you’re able to find your next version of you with ease.

Are you using the ClaudeAI or the default Cascade Base?

cause the only one that REALLY works for this type of work is the Claude agent. Cascade sort of does, and GPT barely is able to get into a flow state.

It’s a mix of those “super prompts” ppl talked about a couple of months ago … and also my response to the LLM API closing the connection if I idle too long or saturate my tokens in a fast moving agent flow

I wouldn’t be so reactive and manically posting if I wasn’t so amp’d on it.

2 months ago I was in your exact spot. Then I started talking to the AI LLM saying we were pair programming & I was relying on it to help write good code. Then we agreed we needed a “memory document” for when it would deviate from the plan … and in the end we landed on a CHECKLIST file as our Rosetta Stone.

Oh man… I dunno what to say. Do you get it to discuss before writing code? Or set up a CONCEPT.md file or ask it to confirm before coding & update the CHECKLIST file before editing the code?

https://x.com/vveerrgg/status/1870241281622016328?s=46&t=AzmbXTepQ7mKGb9E0dbu1Q

I had decent success with writing nostr-websocket-utils & a bunch of other packages with that format.