Skip to content

ETL to QE, Update 47, Tickets are Important

Date: 2024-11-18

The other day I started working on my Nostr Encrypted Convo Tutorial. The goal of the tutorial is to provide people the required javascript functions to develop chatbots on Nostr. Sadly I did not give the problem of, develop a tool to create chatbots on Nostr, enough credit because the task is a lot more complex than I gave it credit for. For example,

  1. Generate nostr key pair
  2. Generate a second nostr key pair
  3. Keep track of both these keys so they don't get deleted accidentally
  4. Publish a nostr event with a list of relays that the user listens to messages on
  5. Get the event with a list relays a user accepts messages on
    1. Extract those relays
  6. Fetch all the messages sent by yourself to another user
  7. Fetch all the messages sent from that user to yourself
  8. Decrypt all these messages
  9. Sort these messages chronologically

So yea we got 9 steps, 10 if we include setting up a relay for testing. But there is even more than that. That set of steps assumes there is already a conversation being had, if you don't already have message's to decode you need to create those messages.

The key problem causing all the bugs in the tutorial I was writing was keeping track of all the keys that were generated.

So what is the best way to manage nostr accounts and feed them into scripts?

  • How to store accounts
    • Mnemonic
    • NSEC
    • Aliases
    • Indexes (Numbers starting from 0)
    • Indexes (Numbers starting form 1)
  • How to store and or access the accounts
    • Environment Variables
    • dotenv file
    • JSON File
    • SQLite file
    • CLI Arguments
  • Where to store and or access the accounts
    • Just send in raw JSON to the application via CLI
    • Anywhere and send in CLI argument to a file path
    • $HOME/.config folder
    • /opt/user/nostr folder
    • /etc/nostr/ folder

I learned that managing application data in a easy accessable way is far more complex than I gave it credit for. Plus checking projects in Awesome Nostr made me realize there is no agreed upon standard in the space either. Plus event if we choose something like JSON or Environment Variables what is the standard for the accounts? Oh and what about accounts we want to send stuff to that we don't have secret lists for.

Now that I think about we could use the NIP02, follow lists, and NIP05, DNS Identities, to help manage accounts but that makes things even more complex.

There also comes the usability problem, do we feed everything into a CLI using flags or do we use the raw functions themselves?

Why don't we have both?

So for task 3, Keep track of both these keys so they don't get deleted accidentally what solution are we going with?

Well how about we articulate what we already built in the CGFSTutorials git repo?

What was built?

We have a script, generateAccounts.js which has the option of taking in the Environment Variable MNEMONIC otherwise it generates a new mnemonic and just prints out a list of all the accounts it does not save them anywhere.

I guess what we should be doing is saving every account, we generate 10, with NPUB and NSEC prefixes followed by their index for example,

  • NPUB0
  • NPUB1
  • NPUB2
  • ...
  • NPUB9

and

  • NSEC0
  • NSEC1
  • NSEC2
  • ...
  • NSEC9

Save these environment variables and we can play with the accounts easily via CLI.

Talking through the problem produced a solution

I just learned a process, like when you run node server.js can not set environment variables in their parent shell. Therefore when you set environment variables in the program such as process.env.MY_VAR='Hello' that never leaves the shell so that when you run the bash commandecho $MY_VAR it will still be undefined.

The solution to this is to run the source command and feed in a series of command strings that that set environment variables as such.


source <(bun AccountsLoad.js)

But when you run bun AccountsLoad.js by itself it just prints a bunch of stuff similar to the following


export MNEMONIC='about anger bacon ....'
export NSEC0='nsec1amr7....'               
export NPUB0='npub1wveu....'               
...

The trick to make the environment variable accessable in all shells is to either add them your shells config file such as,

  1. ~/bashrc
  2. ~/.bash_profile
  3. ~/.zshrc
  4. ~/.profile

You can also set a .env file in the repo and use the dotenv npm package in the scripts to load or overwrite the environment variables in the shell to the ones in the .env file. And we can set these variables using the following command.


bun AccountsLoad.js > .env

Reflection on Tickets

Seems like the issue is not requiring myself to create tickets when I write code for myself. The issue is accurately thinking though and understanding the problems I am trying to solve. That and taking breaks to let my subconscious make sense of things.