Skip to content

ETL to QE, Update 31, The Man that Takes Things off The Table

Date: 2024-03-14

A friend of mine recently introduced me to the phrase, "The Man that Takes Things off The Table" which basically describes how the circumstances around you shape your decisions.

Reflecting on what just happened

I have spent at least 20 hours over the last week working on this version of my Nostr NIP05 Server project. Last night I realized that I have so much tech debt and bad software architectural decisions that it would be better to rewrite the entire application from scratch.

I also realized that I can't explain what I am doing. My goals and requirements are clearly understood by me but literally no one else shares them. I have starting that maybe writing a Heilmeier Catechism for each function may actually be a good idea. We can write the most understandable code base in history.

It sounds like it is time to upgrade my The 4 Step plan for Question Engine document. Each of those steps should be a Heilmeier Catechism rather than a couple point form notes. I should also be articulating the utility of each step. For example what good is a Discord analytics report. We should also try to avoid the The Serac Problem.

Actually Articulating what I am doing

There are a bunch of concepts implicit to The 4 Step plan for Question Engine that I have not taken the opportunity to articulate. For example what is Context Graph File System and what problem does it solve?

Now the next problem is building out The 4 Step plan for Question Engine. I have so many plans I have setup in this ETL to QE project that I have not followed through. What would be needed to change that?

I need an Accountability Buddy. There are a series of people I can contact and build that kind of relationship with.

Now let's create a plan that I will actually show to whomever I get as my accountability buddy,

  1. Implement the PKI for CGFS in RxDB
    1. Alias / Metadata
    2. Internet Identifier / DNS Name
    3. Ethereum Keys
    4. Store PGP keys, Public and Private
    5. Store IPNS keys, Public and Private
    6. Store Nostr / Bitcoin keys, Public and Private
  2. Implement the CID_store for CGFS in RxDB
  3. Implement Nostr event based RBAC for CGFS indexes/collections/tables
  4. Implement NIP05 Internet Identifier index/collection/table using CGFS
  5. Implement DD20 token standard using CGFS and Nostr events
  6. Implement ability to purchase NIP05 Internet Identifier using DD20 token
  7. Implement coupon to DD20 token faucet
  8. Implement Lightning Network to DD20 token faucet using LNBits API

Okay now that's a relatively clear outline, but there is one gaping problem. Nobody besides myself can actually understand what any of that means. Also it is not even explicit enough for myself to implement. For example this thing, Nostr NIP05 Server project, is going to need an API. It can't exactly operate over traditional nostr clients because we need to encode and decode JSON. Well we can have our own nostr relay but then we need to give the server its own Nostr address which is not listed in the instructions above.

Ideally everything should be websockets. So we should not be using a REST API. Also we can just expand the Implement the PKI part to include generating Nostr keys as well.

So how is the PKI supposed to be used, do we link the domain names to their internet identifiers?

Add RSA public key (x.509 Encoded) by b5 · Pull Request #195 · multiformats/multicodec