ETL to QE, Update 54, Animating rather than Visualizing
Date: 2024-12-27
Yet another blog post complaining about myself being unable to follow through on a plan.
Difference is this time we have media to compile upon itself for force some sort of emotional resonance for habit building.
I have subconsciously created a plan that I have verbally explained to a couple friends of mine that is as such,
I have been down this rabbit hole of planning so many times I already have a catalog of the plans in Dentropy Daemon Listicle plus the following blog posts,
- ETL to QE Update 38, I suck at making decisions and committing to them
- ETL to QE, Update 48, Attempting to Consciously Make a Plan
I have committed the Planning Fallacy more times than I can count, and I blame Not Knowing Myself well enough as the root cause of the problem.
The Daemon is supposed to be A medium to know thyself. But how am I supposed to Know Myself without the medium that enables me to do so.
Intelligence is ones capacity to Decern therefore if I am incapable of identifying what is important I am not as smart as I think I am.
So we have dozens of TODO lists. plans, and backlogs and get just about nothing done day to day.
The issue is the lack of constraints. We have been unable to set proper constraints that I can follow through on, I do in fact need to be babied, a fact my Self Esteem doesn't want to acknowledge.
The simple fact is that CGFS / ddaemon / QE does not have a single most important backlog I can easily find.
Well we do have our Tutorial your way to victory heuristic.
If we had the perfect tutorials and or documentation for RAG, Nostr, Frontend, SQL, Postgres, SQLite, Cypher, Websockets, WebRTC, REST, RabbitMQ, Kafka, NATS, S3, CRDTs, Hamilton DAG, Web Scraping, Smart Contracts Solidity, Encryption, Hashing, P2P, Socks Proxy, STUN server, TURN server, Wireguard, Caddy, kubernetes, docker, TrueNAS, ZFS, BSD, OpenWRT etc. etc. We would be able to go ahead and build something rather than trying to map out what needs to be learned before we can build anything.
Alright we have already made the decision to master Nostr, but we have not fully articulated what that looks like. Where is our root document for Nostr tutorials?
Oh right here
Now we need to interpret out goal of Master Nostr via Tutorials though a value decerning lens.
Where is a list of all the Use Cases of stuff I would want to do with Nostr. A roadmap similar to our Devops Skills, Backend Skills, Robotics Skills, Blockchain Skills, [Troubleshooting Skills], Learning Pathways sections.
So checking out my current Nostr Tutorial with the CLI I see I don't introduce Nostr well enough. Let's create a Nostr Skills document.
But that Nostr Skills document doesn't lead anywhere. Sure you can do some queries on it but that only get's you as far as you did with the Discord Binding, nothing socially tangible.
We pretty much have all the core aspects of Nostr Skills figured out with code examples we ourselves wrote. We are getting consumed by the problem of writing our own Nostr Relays and writing unit tests to use against all Nostr Relays to test for differences among implementations.
That is taking the hard way to our destination. That may be the correct way but we need to be focused on the right problems. The problem is not the optimal SQL schema but the code that deals with processing Websockets. We have been obsessing over the wrong problem via The Streetlight Effect. Well we should have produced the final report that we can publish somewhere.
Who would be interested in a analysis of SQL schemas on Nostr relays?
Nostr Dev's
I should make a list of those.
Paul, on task,
That Survey of Nostr Relay SQL schema's wasn't well scoped enough. What utility does knowing the schema of Nostr Relays have? Just like with Discord Binding in order to do Analytics you need to recompile the Data to a relational form. Which we could write off the top of our head rather than doing all that research.
We need to remember where we want to be,
At which of these stages are we supposed to implement our own Nostr relay?
- Nostr Interface equivalent to Open WebUI
- Data ingestion of all my social media
Well your actual problem here is you have not mapped out the functionality of "Nostr Interface equivalent to Open WebUI".
Does that mean you access a special relay that you perform authentication against that allows you to query your own data? This would involve setting up a special RBAC schema.
Does that mean we have client to server encrypted conversations that reveal some metadata publicly on a public relay relays?
Does that mean we encapsulate archived information from the AI conversations that need to be un-capsulated and stored in a local client to be searched and stuff?
What is better, a custom client that requires a custom relay to get up and running, or a custom client that works with existing relays and requires running a bot.
Alright so we now have the requirement of working with existing Nostr Relays therefore everything needs to operate as a traditional NIP04/NIP17 encryption... And we write another project update to map out how to map conversational graph metadata.
So in summary we visualized the Nostr Dec 2024 Roadmap and have started animating a scene in ETL to QE, Update 55, Nostr AI Chatbot Implementation Details