search

gnolang / gno

Gno: An interpreted, stack-based Go virtual machine to build succinct and composable apps + Gno.land: a blockchain for timeless code and fair open-source.
https://gno.land/
Other
880 stars 364 forks source link

[OPS] Wishlist - Feature ideas #2102

Open albttx opened 4 months ago

albttx commented 4 months ago

Description

Hello, after couple discussions with @zivkovicmilos and @thehowl about some ideas of features, they told me i should create a ticket to discuss about it. This is a general ticket, if some feature makes debate, let's open smaller ticket to discuss about them.

1️⃣ $HOME/.gno

In cosmos-sdk, there is a feature i find cool is the client.toml file. This file contains informations about the chain, like node (endpoint), chain-id, all client configurations to discuss with a blockchain.

Since in Gno philosophie, we want the gnoland-data folder to be only containing the chain data. it would be non-sense to put the client.toml file there.

My suggestions would be to to create a $HOME/gno folder where we could put a clients.toml (notice the S), to be able to have "context" (like in S3 clients), were we could replace commands like:

gnokey query -remote="http://rpc.staging.gno.land:36657" "bank/balances/g1qhuef2450xh7g7na8s865nreu2xw8j84kgkvt5"

By having 

#clients.toml
[default]
chain_id="dev"
remote="http://localhost:26657"

[staging]
chain_id="staging"
remote="http://rpc.staging.gno.land:36657"

[portal-loop]
chain_id="portal-loop"
remote="http://rpc.gno.land:26657"

So the command would be 

gnokey query --ctx staging "bank/balances/g1qhuef2450xh7g7na8s865nreu2xw8j84kgkvt5"

2️⃣ Put back default genesis.json file inside of the gnoland-data folder

I understand the feature and the benefit of having the genesis.json file outside of the folder but i don't believe it should be outside by default.

It's so much simpler in multiple way... the other day i had issue because i was removing gnoland-data folder for having a new chain, and got errors because i forgot the genesis.json file.

3️⃣ gnoland init

There is already a LOT of PRs and public discussions about it, and i just want to find a solutions for this.

I understand @moul positions about UNIX style and avoid sugar syntax of tasks, but the default behavior is to do a simple init and after a start, and i don't believe really useful all the genesis init + secrets init + config init.

So here is some proposals that maybe could fit ?

Like migrating everything under init and having something like:

or by default and have the "lazy flags" for smaller cases like:

4️⃣ --data-dir into --home, remove --config-path

gnoland want to be simple. the CLI have different system which aren't logical.

with gnoland start i can set --data-dir, but i can't set a different --config-path, (which wouldn't make sense)

So in gnoland config init, i propose to update --config-path into --data-dir that will be {{ data_dir }}/config by default

moul commented 3 months ago

1️⃣ $HOME/.gno

About ~/gno, I believe we need to envision a future where we have multiple Gnovm chains while maintaining a unified language and a primary chain. In practice, I don't think we can say that ~/gno is solely for gno.land, but rather for the broader "Gnovm ecosystem" or just for the Gno language.

Having a client.toml file could make sense, but it should be specific to each zone or contain all the zones in one file.

I'm not fond of the idea of having to manage such configuration files manually or even from a CLI. Instead, I think we should focus more on hostnames/zones and auto-configuration, like go get DOMAIN/PATH works not because it's hardcoded, but because it follows a standard (HTML headers). We can do gno.land/r/zones. The only exception I can see is for local development, where you may want to override something. Even in this case, I'd prefer to find idiomatic patterns around localhost.

Maybe the question is: when you launch albert.land; would you prefer having ~/albert and using albertkey, and having the ~/gno for gno (the language/dev binary, not the gno.land binary)? If so, then I propose having ~/gno not for the chain, but just for the language, and then having ~/gnoland for the chain.

2️⃣ Put back default genesis.json file inside of the gnoland-data folder

No opinion.

3️⃣ gnoland init

I provided more details in a previous comment. The summary is that I anticipate 3 main cases for people who run the gnoland binary:

I can't find any evidence that your suggested unified gnoland init is better than the current solutions in any of the 3 cases mentioned. Is it? Is there a fourth case that I've missed?

4️⃣ --data-dir into --home, remove --config-path

No opinion.

albttx commented 3 months ago

Thanks for replying @moul

1️⃣ $HOME/.gno

Since it's gno, it's for zone, and it's by chain-id, so it could manage all zones in 1 file.

I believe in the future having gnokey with context albert.mainnet would be great :)

This is a feature request, we can work on it later :)

BONUS: we could mention the $GNOROOT for each zone, the gnoland-data folder ... :)

3️⃣ gnoland init

Right now, it is not possible to start a node with only

gnoland config init
gnoland genesis init
gnoland secret init

It's lacking the gno.land/{r,p}/... in the genesis file.

So the only solutions is to gnoland start --lazy, wait a moment and ctrl+C, then setup... (IIRC, @zivkovicmilos is working on this fix ?) Nonetheless, once fixed, it will be 3 or 4 commands to init + 1 to start... I understand the fine grain, but it's just more complexe...

I don't understand the purpose of --lazy. IMHO devs will use gno dev or a simple docker-compose.yml that we could provide to start a dev node. But if it's decided, i'm not against. (Maybe rename to gnoland dev to stay consistent with gno dev ?)

IMHO, as a zone architect and full node runner, i would mostly use a gnoland init + gnoland config set ... (multiple times) + cp my_priv_validator_key.json -> gnoland start.

I don't see any world were i need to do only gnoland secrets init or gnoland config init without the rest of the commands.

I'm thinking as a new user, he will get the gnoland binary and run gnoland --help, and won't see an init. Could be complexe to understand.