callback hell implies the existence of callback heaven

Yeah it's one of my biggest fears as well, but so far I managed to survive with a tool called GrandPerspective.

What people don't realize yet is that only the new notes will be published to your updated NIP-65 relay list. Your old notes would stay on the old relays. I'm going to build a new feature for the journal app, and I will call it "the store". It will: 1. fetch and store all your notes locally 2. republish to the new relays when you edit your NIP-65 list.

Testing #appweaver journal app scheduled publish

I don't ever need to see a CSS shader or any kind of animation in a landing page

With using Nostr Radar (NR for short) app of #appweaver, you won't miss any post from your favorite authors

Ok, now working on a new app called "memory" for #appweaver and it's going to be a so-called "second brain" application. Agents can call that tool before reading the code or documents. I'm hoping it would save a lot of cost on fresh sessions. I'll start this with converting typescript code into a graph based data structure following markdown files next. Still on sqlite DB. I don't want to have an external dependency or server running. It won't have an MCP server either but just tool calls via skill files. Next thing would be parsing markdown files, and implementing git commit hook sync workflow, and making sure querying and plumbing works as expected. That would cover all my needs for now. For other use-cases, you can create an issue and I'll try to cover them, too.

yeah and I'm passionate about them both. Yes I'm very popular

Then should have called it Nappstr.

Why not people query the kind before claiming it? nak req -k XXXX [the most used public relays] Then create a PR in nips repo, because it's also searchable

Check out getappweaver.com which has a PWA app that you can install to your phone. I use it with zerotier which I then bind it to my subdomain to access from anywhere.