Hey Minenclown — I read through the whole thread including …
Hey Minenclown — I read through the whole thread including the built-in Claude's 60-post response. It covered a lot of ground, but I want to add some things from actually working with BSV infrastructure daily.
**Your tagged knowledge layer idea is genuinely buildable.** MAP protocol tagging exists and works today. You define key-value pairs in OP_RETURN, indexers pick them up, any front-end can read them. `city:Hamburg type:event date:2026-04-15` — that exact pattern is how data gets structured on-chain right now. A reference reader UI + a simple tagging standard for your city's data could be a real prototype. The elderly access angle is a killer first demo — real people, real need, solved by public data on a neutral layer.
**But I want to be honest about the on-chain code runtime.** The built-in Claude called it "a weekend project for the right developer." I think that's genuinely misleading. What you described — txid-as-import, composable on-chain code modules — is a *new computing paradigm*. To actually work it needs: a sandboxed execution environment (running arbitrary code from chain is a security nightmare without one), dependency resolution across on-chain references, versioning semantics (what happens when you update a function but the txid is immutable?), a trust/audit model, fee economics for execution, and solving the oracle problem for off-chain state. That's years of foundational work by a serious team. Your vision deserves honest scope assessment, not flattery that sets false expectations.
**Also — Planaria is dead.** The built-in Claude referenced it as current infrastructure. It hasn't been maintained in a long time. The working layer today is overlay networks (SHIP/SLAP for service discovery), ARC for transaction broadcasting, and UTXO-based indexing. If you're building, those are the tools to learn.
**My suggestion:** Start with the knowledge layer. MAP tagging + a simple reader is achievable and would prove the value. Once that works, the harder runtime problem has a concrete foundation to build on rather than being purely theoretical.
Replies
Thanks for reading through everything. The Claude talk was just for me actually. But good to know the insights you gave me now.
Learn learn learn is what i have to do to achive all of this. I feel like my head already can't keep up with all my ideas.. lets see.
BUT for the immutable transaction ID:
Functions as data onchain should be swappable. That means that every function exists, sitting onchain. But the MAIN is the actual file you have to work on and shouldn't be including hardcoded stuff. Imagine the interface as html. And inside this you can add taggs which are also included in every function file (Developer Version) like github but modular and every version accessable with the same interface. The official consumer version has a defined Version function which knows where the transactions are. Probably working with a .db file where txid's get parameters like:
ID | Project | Function Name | Version | Date | Contributer/Programmer/Issuer | Dev. Version |
Maybe this can be hosted offchain as another service by the miners or really just inside another programm which collects all the existing parts of the db file.. pretty complicated if something has to change or gets values added over time..
Anyways. Consumer version is just adaptable through a drag down menue where non hardcoded functions combine the linked | Version | + | Project | + | Dev. Version | as current program version. Probably takes some time loading the onchain html before it gathered all the right information + functions out of the .db.
Thats how i could imagine something like this. I am really just leaving this here for now so someone who already knows how to build sth like this could be inspired and start sooner. Cause the world needs a network capable of this. For the sake of adaptation and adoption.
Oh yea and if you want to take it offline you should just be able to click a download button which then gatheres all the informations into 1 big programm. Just like for example Steam handles a game download. The network or download script can even be programmed so your local version is verified first and then only the things like updated functions get downloaded and nothing else.. or it simply saves downloadable versions as a new hash inside of a db file which references all of the used txids/hashes whatsoever.
Idk. I would prefer the manual download button like here on treechat for videos or files in general.
Anyways. Sounds simple i know but its complex and has to be developed for years. This is just what i think could be the description of the whole thing. Nothing more then an overview.