To connect this blog back to its source, for the past ~3 years I've been hurling myself into random and often arbitrary experimental directions through DEIT, and for another ~2 years before that in an unbranded mad-scientist capacity. My biggest regret as a dev is that I'm old enough to remember "blogosphere" emerge as an idea, and yet never committed to one myself outside some half-starts that never got stuck to because then I'd be onto the next idea... and the next... and the next... while never thinking to just make a "Brandon Blog" capturing it all, or even a DEIT blog for that matter. Even in my R&D, I've stayed largely wraith and local disk in my explorations, often intending to publish repos that I'd then overthink or want that one extra round of polish before I flipped it public... if you're reading kiddos, don't do that. Fail in public, it's way more fun.

So to that end, here begins my saga of failing in public, diving into an entirely new (to me) direction as a dev with reckless abandon and as little reading as I could get away with. I recently stumbled into gno.land and while to date I've stuck with the EVM, today I finally rip the bandaid off and delve into CosmosSDK world I've kicked the can on for too long with gno.land.

Why?

I won't lie, I found it through a job listing that came through a Discord server that screamed at me solely because it contained "Tinkerer" in the title... "Tinkerer"... "Tinkerer"... I still can't say it right, but I immediately wanted it because it's exactly what I've been doing under the DEIT brand already with no real clear end goal in mind for it. On the masthead of my employer, one of my unofficial titles in my randomized list of titles is "Director of Zany Ideas", so to go from that to professional "Tinkerer" would be my idiot brain's dream progression... "Tinkerer" lol

But the real reason I wanted to explore gno.land is because outside of it smashing Go into a layer1 project (which is already awesome), their proof-of-contributor model is wildly fascinating to me as a tenured student of social capital, while their concept for GNODEs is rooted in nearly the exact same guiding principles/wants of my stealth mode Commonwealth project. In particular, the Social Insurance 2.0 component and its idealized form of a federated model of regionalized DAOs, realizing Murray Bookchin's Communalism implemented as Stafford Beer's viable system model. As I watched this introduction talk I was already on board well before, but this slide on the GNODE construct made me pause and sit slack jawed seeing my own guiding ethos stare back at me so succinctly... I was entirely sold by this point, regardless of any outcomes from the application. This project is going to be wild to watch play out once it's seen more polish/adoption IMO.

Gno.Land: Initial Install & Interations

The process begins the same as most new projects... with missing dependencies & version conflicts! LevelDB and RocksDB seemed to be giving me grief so these were the dependencies I installed to resolve that. This may have been the result of me working from the main branch at this point/not needed, but captured here anyway.

# leveldb
sudo apt-get install libleveldb-dev

# rocksdb
sudo apt-get install -y libsnappy-dev
sudo apt-get install -y zlib1g-dev
sudo apt-get install -y libbz2-dev

Then I check my version with go version. For this, I need 1.19, which for me meant blowing away my existing version and installing 1.19.

sudo rm -rf /usr/bin/go
sudo tar -C /usr/bin -xzf ~/downloads/go1.19.9.linux-amd64.tar.gz
echo "export PATH=$PATH:/usr/bin/go/bin" >> ~/.bashrc

With that done, I can now jump into installing/playing with Gno.Land.

Install & Account Gen

To save myself some grief dealing with unknown unknowns from the main branch, I cloned the chain/test3 branch into my newly made ~/gno directory (which yes, results in ~/gno/gno as the resulting path).

mkdir ~/gno
cd ~/gno
git clone -b chain/test3 https://github.com/gnolang/gno.git

From here, this initial part of the docs lined up fairly well. With my dependencies already installed, I should be able to just run make as it says.

cd ~/gno/gno
make

Now with that done, and a ./build directory as expected I can generate my seed/mnemonic with the gnokey cmd, which will print a randomized seed string.

./build/gnokey generate

Before the next step, I can confirm I have no accounts setup with ./build/gnokey list. Then using the following, add an account using the mnemonic seed I generated previously. For KEYNAME, use whatever identifier you'd like to attach to this wallet seed. For this project, I just called mine local-test.

./build/gnokey add KEYNAME --recover
Enter a passphrase to encrypt your key to disk:
<make a password>
Repeat the passphrase:
<repeat the password>
Enter your bip39 mnemonic
<enter mnemonic generated previously>

Now when I run ./build/gnokey list again I see the following:

0. local-test (local) - addr: g138j0um48nm4ppcz0tr6az4qu3yjwjl3l6ntqdx

First Interactions With Gno.Land

The interaction section of the docs shows how to interact with the testnet but for my purpose I'll want to be pointing to my local node. Use./build/gnoland to spin up the local node (<- spawn in a separate terminal).

It would seem by default Gno uses port 26657 for the local node instead of the 36657 referenced for the testnet. It also makes a clear note about this at the very top of the Getting Started guide, but I of course didn't notice/remember by the time I got here. Fortunately lsof -i -P -n | grep gnoland worked as well in the moment as more careful reading would have at the start.

Referring back to the interaction portion of the docs, I can now query see the following output:

./build/gnokey query auth/accounts/ACCOUNT_ADDR --remote 127.0.0.1:26657
height: 0
data: null

Now that I've confirmed the local node is responding (note from the future: this is not the response you want), I'll ignore it and make sure I can interact with the testnet as well. Head over to the appropriate testnet faucet address(for this branch that would be test3.gno.land/faucet since the suggested gno.land/faucet 404s), and I enter the address of the account I created previously, solve the captcha, submit the form and... watch it break. Ya... it breaks with "faucet failed".

But wait... I see my error. I've queried locally... but not on the testnet? So I run the previous command again, only this time pointed to test3.gno.land:36657 and I see the same response as before:

./build/gnokey query auth/accounts/ACCOUNT_ADDR --remote test3.gno.land:36657
height: 0
data: null

Now repeat the faucet attempt anddd...nope. Still "faucet failed", served by faucet.test3.gno.land/, which if I just visit on its own I get "check captcha request". Weird. I try a few different permutations of the URL like the actually suggested gno.land/faucet again (still 404s) and faucet.gno.land which doesn't resolve. Over to DNSDumpster I go fishing and find nothing super interesting, except that there's also an rpc.test3.gno.land I'll need to circle back to.

At this point I feel stumped... perhaps it's time to switch back to local node only in case this faucet thing isn't on my end/is unfixable... but of course I can't give up that easily! I reach out to a random Twitter post from Nov last year with one of the few mentions of the exact "faucet failed" error I'm seeing in case they come through in classic white knight fashion, and then its off to Google/Reddit/Github in no particular order for clues while I wait/hope this Twitter stranger comes through.

I find Gnoscan and confirm semi-recent transactions exist, and find my second time running into Onbloc's blog. I also from somewhere had this Gnoland.Space faucet open. Unfortunately, Onbloc's post links to the 404'ing Faucet URL, while Gnoland.Space points to the test3.gno.land/faucet address that I started at. I do see from that site that Adena Wallet is going to come into play soon enough though, and with it being Chromium only temporarily leave my home base of Firefox to rule out browser issues to no avail. (note: all of those are available at awesome-gno.

Back to being stumped and assuming the worst... that I have to wait for a third party resolution to fix a potentially broken faucet (still doubtful that's the issue though; note from future: it's drained)... I switch to local-only in defeat (for now...).

Initial Local Interactions

Jumping back to using 127.0.0.1:26657, I run the following 2 commands from the guide to publish the avl and boards packages to my local node.

./build/gnokey maketx addpkg local-test --pkgpath "gno.land/p/demo/avl" --pkgdir "examples/gno.land/p/demo/avl" --deposit 100000000ugnot --gas-fee 1000000ugnot --gas-wanted 2000000 --broadcast true --chainid test3 --remote 127.0.0.1:26657

./build/gnokey maketx addpkg local-test --pkgpath "gno.land/r/demo/boards" --pkgdir "examples/gno.land/r/demo/boards" --deposit 100000000ugnot --gas-fee 1000000ugnot --gas-wanted 300000000 --broadcast true --chainid test3 --remote 127.0.0.1:26657

Or I intend to run them both. The first one asks for my password, I enter it and get back:

unknown address error
--= Error =--
Data: std.UnknownAddressError{abciError:std.abciError{}}
Msg Traces:
    0  /home/sysadmin/gno/gno/cmd/gnokey/gnokeys.go:338 - check transaction failed: log:--= Error =--
Data: std.UnknownAddressError{abciError:std.abciError{}}
Msg Traces:
    0  /home/sysadmin/gno/gno/pkgs/std/errors.go:86 - account g138j0um48nm4ppcz0tr6az4qu3yjwjl3l6ntqdx does not exist

Which is likely because I'm using my generated account instead of the one suggested in the docs, and find something related to how the chain responds to not-previously seen addresses (note: find that again to understand). So I make a new local-doxxed account, and use the suggested mnemonic:

./build/gnokey add local-doxxed --recover
Enter a passphrase to encrypt your key to disk:
<make a password>
Repeat the passphrase:
<repeat the password>
Enter your bip39 mnemonic
source bonus chronic canvas draft south burst lottery vacant surface solve popular case indicate oppose farm nothing bullet exhibit title speed wink action roast

Running the previous maketx command again with the doxxed account, I now get:

unauthorized error
--= Error =--
Data: std.UnauthorizedError{abciError:std.abciError{}}
Msg Traces:
    0  /home/sysadmin/gno/gno/cmd/gnokey/gnokeys.go:338 - check transaction failed: log:--= Error =--
Data: std.UnauthorizedError{abciError:std.abciError{}}
Msg Traces:
    0  /home/sysadmin/gno/gno/pkgs/std/errors.go:70 - signature verification failed; verify correct account sequence and chain-id

Progress!...ish. Fortunately, with some quick digging I came to realize this is an error from Cosmos land, which gave me some hope there's an answer somewhere online. Instead, I ended up diving into gnokeys.go and realized the chainid test3 might need to be changed to dev, and sure enough, the error is now

internal error
--= Error =--
Data: std.InternalError{abciError:std.abciError{}}
Msg Traces:
    0  /home/sysadmin/gno/gno/cmd/gnokey/gnokeys.go:341 - deliver transaction failed: log:recovered: package already exists: gno.land/p/demo/avl

Which is maybe a good error? Trying the updated version of the command for the boards package gives:

invalid gas wanted
--= Error =--
Data: std.InvalidGasWantedError{abciError:std.abciError{}}
Msg Traces:
    0  /home/sysadmin/gno/gno/cmd/gnokey/gnokeys.go:338 - check transaction failed: log:--= Error =--
Data: std.InvalidGasWantedError{abciError:std.abciError{}}
Msg Traces:
    0  /home/sysadmin/gno/gno/pkgs/std/errors.go:102 - invalid gas-wanted; got: 300000000 block-max-gas: 10000000

After some tinkering with the gas values, I seem to get the same "package already exists" error as the avl package, which after checking the examples folder makes sense, since both are present along with some other packages. Final working commands (I think these worked):

./build/gnokey maketx addpkg local-doxxed --pkgpath "gno.land/p/demo/avl" --pkgdir "examples/gno.land/p/demo/avl" --deposit 100000000ugnot --gas-fee 1000000ugnot --gas-wanted 2000000 --broadcast true --chainid dev --remote 127.0.0.1:26657


./build/gnokey maketx addpkg local-doxxed --pkgpath "gno.land/r/demo/boards" --pkgdir "examples/gno.land/r/demo/boards" --deposit 100000000ugnot --gas-fee 1000000ugnot --gas-wanted 10000000 --broadcast true --chainid dev --remote 127.0.0.1:26657

Local Transactions (The Fail/Foundational Learning)

With that wrestling done, largely of my own making, I now trust I have the packages I need and that I can engage with my local node using gnokey. To test that theory, I'll walk through the documentation's steps to create a board, a post, and a comment on my local node.

I copy the testnet tx command to create a board and swap it out for the local variables.

./build/gnokey maketx call KEYNAME --pkgpath "gno.land/r/demo/boards" --func "CreateBoard" --args "BOARDNAME" --gas-fee "1000000ugnot" --gas-wanted "2000000" --broadcast true --chainid dev --remote 127.0.0.1:26657

Run it, and another error:

("unauthorized" <untyped> string)
--= Error =--
Data: "(\"unauthorized\" <untyped> string)"
Msg Traces:
    0  /home/sysadmin/gno/gno/cmd/gnokey/gnokeys.go:341 - deliver transaction failed: log:msg:0,success:false,log:--= Error =--
Data: &errors.errorString{s:"(\"unauthorized\" <untyped> string)"}
Msg Traces:
    0  /home/sysadmin/gno/gno/pkgs/sdk/vm/keeper.go:239 - VM call panic: ("unauthorized" <untyped> string)

Unauthorized... I sanity check by trying again with gibberish for the password but get a separate error (capturing to collect errors):

invalid account password
--= Error =--
Data: keyerror.errWrongPassword{code:2}
Msg Traces:
    0  /home/sysadmin/gno/gno/cmd/gnokey/gnokeys.go:325 - sign tx

So it is indeed something about my account being unauthorized. Digging into the stack trace, first I check line 239 of keeper.go and it's just a recover handler as you'd expect, so I dig into the boards realm for clues. But as I do something stands out in the terminal above my IDE... I notice the stack trace claims the realm I'm on is gno.land, which I then noticed the pkgpath still referencing it. I try omitting a domain thinking maybe this is referring to the actual domain of gno.land, then trylocalhost and with 127.0.0.1, knowing there's no good reason any should work just to sanity check, and then try to take a step back to understand what it is I must not be understanding.

I have a node running... I can see it logging these requests so that's working, and I've restarted it and queried the auth endpoint to sanity check even though I'm near positive that does nothing before trying again to no avail. I return to the docs and realize those "good errors" above likely relate to the above noticed gno.land realm reference found in the stack trace, and that I'll need to resolve them before interacting will work because let's be real... no error is a good error, so of course I do (I think...). At this point, I lay down to clear my head and see if searching for answers from my phone leads anywhere new.

Fortunately, it does. moul's post on installing a local testnet/installing contracts locally. I learn of gnodev, and follow the link to this GNO Example Demo on the Gnoland YT channel I hadn't yet realized existed (I'd already watched any vids on the Ignite channel before starting any of this). I pop open Jae's vid in a new tab to make sure I watch it later, and then dive into the Example Demo Video.

A half-hour later, this all makes far more sense. To anyone still reading this gonzo take on a walkthrough, start with the GNO Example Demo vid. Seriously. (note from future: but also dig into /r/users, which isn't covered in it)

Other than just making me even more excited to play with all of this seeing a lil gnome store get rolled, the Realm=Smart Contract and Package=Library clarification is worth noting, and I see gnokey account addresses follow the bech32 format. I also see I can edit the genesis_balances.txt file... which somehow had not occurred to me when I read it, I just thought y'all be braggin' :P. I'd already seen the faucet realm stashed under gnoland and assumed I'd need to deploy one locally (confirmed this is also the better option in the vid), but I like that hack for now, and it starts to register why I've been banging into walls this whole time... the data-less output I've been seeing from the queries... is not what I want to see. Which had sort of seemed off, but now I can confirm the expected response should look something like:

height:0
data: {
  "BaseAccount":{
    "address":<address>,
    "coins":"10000000000ugnot",
    "public_key":null,
    "account_number":"99",
    "sequence":"0",                
  }
}

The vid also confirms the chainid should indeed be dev (as fumbled into already), and I see when I finally get a valid response from a transaction it should look something like:

OK!
GAS WANTED: <number>
GAS USED: <smaller number>

I also get to see how the built-in website rendering works, which to capture a brief TL:DW, a Render function uses a switch on the split path; if path empty (ie: pointed to the index) it returns the response of renderItems(), and if conforming to an /item/<id> pattern returns either notFoundMessage or the response of item.GetInfo() (in the gnome store example anyway).

With this newfound information and fresh excitement from the gnomes, I bail on this doxxed test account, embiggen my generated account's balance through the genesis_balances file, restart my gnoland node and cross my fingers while I start over with better-informed eyes.

Local Transactions (The Fumbling/Practical Learning)

I jump back to the "working commands" mentioned above, and swap out the account to rule out whatever tomfoolery might be stemming from trying to use that doxxed account. I get the same UnknownAddressErorr that had disuaded me from using this account previously, and query the auth realm with the address added to genesis_balances and get the same null data. I then do the same using the doxxed address, and get back data in the expected format, but notice the coins value isn't a round number, confirming what the guide suggested, that restarting your node doesn't reset state (because it shouldn't), and to reset state as I now want I need to run make reset.

Sure enough both accounts now return the expected format, though the doxxed one is still not a round number, but is higher than before... will ignore/assume something gets deployed from it through the localnet initialization. With a glimmer of hope in my eye, I once again run my transactions to add the avl package using my generated account. The glimmer fades as I once again get the package already exists: gno.land/p/demo/avl error, but now I'm fully determined to resolve it to see the rest of this work once I do. Having watched the gnome store get made I take a quick glance at r/demo/boards and see no .go files, suggesting a precompile is in order. After a quick comb through the Makefile with more insight into what I'm in need of, I see examples.precompile and examples.build, but alas neither gets me further with either the unauthorized or package already exists errors.

I find this issue related to the unauthed error, pointing to r/demo/users. I decide to spin up the web renderer with ./build/website since it should all around give me a better view into my node(note: it does, do this far earlier than here), and thankfully don't run into any fresh surprises here. I do however not see the test1 address represented by a user, and confirm that /r/demo/users/<address> resolves for valid accounts, but not the doxxed one. I also don't see my generated address for more obvious reasons so I dive into the code for this realm to learn more about user registration.

It doesn't take long to see the source of my grief so far... there's a Register function I've yet to see mention of in any docs, while also not seeing it used in that demo video (was the presenter already a user I assume, or is it not necessary for custom realms?). I see the inviter param and out of curiosity want to see it in action so I hack a bit. I swap out the admin address in users.gno for the doxxed address but abort when a sanity check of the website breaks after a reset and restart (note from future: likely the genesis_txs.txt conflicting). I dive more into the gnokeys.go code, seeing how the signAndBroadcast function builds first a keybase, then gets an info object from it that sets a Path param including the associated address in qopts before using the QueryHandler to fetch the account (getting the same state back that is seen when queried from the command line). It then uses that to sign the tx with SignHandler followed by the BroadcastHandler to inform the chain. All very useful information since I'm using the dirty method instead of the method walking through each of those steps... but not helpful for my current headaches.

I leave the inviter arg blank, and with the following get back an error about not sending enough gas with the first, and then get back an extra confusing invalid gas-wanted; got: 200000000 block-max-gas: 10000000 with the second, even after adjusting the gas-fee to match knowing that shouldn't help, getting back the same value of 10000000 (note from the future: /facepalm... could have been done here with --send with ~5 seconds more thought...).

./build/gnokey maketx call local-test --pkgpath "gno.land/r/demo/users" --func "Register" --args "" --args "kanyetest" --args "OG tinkerer; hack the planet!" --gas-fee "10000000ugnot" --gas-wanted "2000000" --broadcast true --chainid dev --remote 127.0.0.1:26657

I ctrl+f for the error and find my way into pkgs/sdk/auth/ante.go to see what I can do about this oddity of conflicting requests. consParams.Block.MaxGas from the response of ctx.ConsensusParams() seems to be where it's set. This leads me over to pkgs/bft/rpc/core/consensus.go followed by pkgs/bft/state/store.go finding the ConsensusParamsInfo struct, leading to the ConsensusParams struct in pkgs/bft/abci/types. Here I find the BlockParams struct which indeed has a MaxGas property. Searching simply for MaxGas lands me far more quickly at where this is set, which is in cmd/gnoland/main.go. I'm sure this could be broken out into a YAML file or something, but for now I'm going to just jack that number to match the required Register gas amount, run another make reset before spinning up a fresh node and hope for the best. It does not work... now it says I'm not sending enough even when I am instead of the max gas being the issue. Abort.

I do take closer note of the red text that flashes when my node spins up this time though and dig in case its causing any grief:

.level 2 .msg Error on catchup replay. Proceeding to start ConsensusState anyway [err Cannot replay height 1. WAL does not contain #ENDHEIGHT for 0 [module consensus]]

This seems to get thrown from pkgs/bft/consensus/state.go, and references a WALFILE which I will for sure want to dig more into, so capturing the example here:

WALFILE=~/.tendermint/data/cs.wal/wal
cp $WALFILE ${WALFILE}.bak # backup the file
go run scripts/wal2json/main.go $WALFILE > wal.json # this will panic, but can be ignored
rm $WALFILE # remove the corrupt file
go run scripts/json2wal/main.go wal.json $WALFILE # rebuild the file without corruption
----

This doesn't actually seem to matter though, given following the source of my actual error to pkgs/bft/consensus/replay.go includes a comment pointing out this is largely just a sanity check.

One method that occurs to me is editing the genesis_txs.txt file with the Register call I want to make, copying the (I presume) known good format.

{"msg":[{"@type":"/vm.m_call","caller":"g1qpymzwx4l4cy6cerdyajp9ksvjsf20rk5y9rtt","send":"2000000000ugnot","pkg_path":"gno.land/r/demo/users","func":"Register","args":["","kanyetest","OG tinkerer; hack the planet!"]}],"fee":{"gas_wanted":"2000000","gas_fee":"1000000ugnot"},"signatures":[{"pub_key":{"@type":"/tm.PubKeySecp256k1","value":"A6yg5/iiktruezVw5vZJwLlGwyrvw8RlqOToTRMWXkE2"},"signature":"GGp+bVL2eEvKecPqgcULSABYOSnSMnJzfIsR8ZIRER1GGX/fOiCReX4WKMrGLVROJVfbLQkDRwvhS4TLHlSoSQ=="}],"memo":""}

This would require first signing a transaction, which can be done with gnokey but then as I went to do that I realize that a tx requiring a payment will work a little different, and isn't just expecting gas values be tweaked. This really should have probably been obvious sooner since it's no different in EVM land and payable functions/txs. After some digging I update my command to the following:

./build/gnokey maketx call local-test --pkgpath "gno.land/r/demo/users" --func "Register" --args "" --args "kanyetest" --args "OG tinkerer; hack the planet!" --gas-fee "10000000ugnot" --gas-wanted "2000000" --send "200000000ugnot" --broadcast true --chainid dev --remote 127.0.0.1:26657

And voila! I get back:

OK!
GAS WANTED: 2000000
GAS USED:   1327073

My first successful gno.land transaction. Spinning up the website renderer I can now confirm kanyetest is among the users. I'm not sure I've ever been so happy to see my old friend.

This feels like it's now wrapping up Phase 1: Operation Reckless Abandon, with enough new information about this system grifted along the way (<- this is legit my process for new stacks... not just failing per se, but failing with purpose lol). Let Phase 2: Operation Informed Tinkering commence in order to get onto the real fun of Phase 3: Operation Haxx.

Local Transactions (The Success/Learned Application)

From here, it's all easy mode. With a user registered, I can now walk through the board interactions from the Getting Started doc all easily-peasily.

First I go to create the board. Worth noting it seems the BOARDNAME needs to match your username. The following command provides the subsequent response:

./build/gnokey maketx call local-test --pkgpath "gno.land/r/demo/boards" --func "CreateBoard" --args "kanyetest" --gas-fee "1000000ugnot" --gas-wanted "10000000" --broadcast true --chainid dev --remote 127.0.0.1:26657

(2 gno.land/r/demo/boards.BoardID)
OK!
GAS WANTED: 10000000
GAS USED:   2306720

Now I read the board. The following command provides the subsequent response:

./build/gnokey query "vm/qeval" --data "gno.land/r/demo/boards
GetBoardIDFromName(\"kanyetest\")" --remote 127.0.0.1:26657

height: 0
data: (2 gno.land/r/demo/boards.BoardID)
(true bool)

I spin up the website to confirm the board exists at ID 2 before continuing (there's 2 boards, so I trust that's the case).

I now create my post, getting back the following:

./build/gnokey maketx call local-test --pkgpath "gno.land/r/demo/boards" --func "CreateThread" --args 2 --args "Hello gno.land" --args\#file "./examples/gno.land/r/demo/boards/example_post.md" --gas-fee 1000000ugnot --gas-wanted 2000000 --broadcast true --chainid dev --remote 127.0.0.1:26657

OK!
GAS WANTED: 2000000
GAS USED:   906684

Which renders in the browser, but can also be queried with:

./build/gnokey query "vm/qrender" --data "gno.land/r/demo/boards
kanyetest/1" --remote 127.0.0.1:26657

Now let's have kanyetest reply to himself... the following works as well:

./build/gnokey maketx call local-test --pkgpath "gno.land/r/demo/boards" --func "CreateReply" --args "2" --args "1" --args "1" --args "Neat post!" --gas-fee 1000000ugnot --gas-wanted 2000000 --broadcast true --chainid dev --remote 127.0.0.1:26657

(2 gno.land/r/demo/boards.PostID)
OK!
GAS WANTED: 2000000
GAS USED:   962201

Wrap-Up, Post-Mortem & Incoming Followup Walkthrough

This "walkthrough" won't be for everyone, but captured a real experience fumbling through understanding gno.land from 0 prior experience working with the Cosmos universe. Through the fumbling I got to comb through the system more than was likely necessary, but I understand it better now than I did when I started. Mission accomplished!

To quickly summarize the order is: clone, make, gen account, update genesis_balances.txt with account + funds, spin up node, register account at r/users, then move onto the interactions with the boards a la Getting Started guide. Keep in mind this has all been against the local node so far. I'll need to track down the thread I'd found about how first encounters with the chain work I think, since the Register function won't work on test3 until I have some $GNOT to register with, but I suspect the faucet is failing because the address is unknown to the chain as evidenced by the data:null response when querying the account. That said this thread I ran into well beyond bailing on the faucet may suggest the faucet is indeed drained on test3 and a trip to the Discord may be in order (note from future: it is indeed drained).

Given the meandering and verbose nature of this post, and how long it's already run, I'll aim to digest a proper walkthrough from it, providing some of the context I was lacking as I dove face first into the unknown, and providing a catalog of some of the expected response formats and errors I experienced along the way. I regret nothing! I am however quite happy to be through the environment setup phase and onto the best part of any new stack... tinkering!

And with that, I'm off to play with my 4 year old who said she has a "hypofesses" and wants to do an experiment (the Ada Twist show is fantastic, thanks Obama!); my mini-me tinkering padawan :P