[Proposal] Realm path & address

[anarcher]

Description

In the realm path ($zone.land/{p,r}/$namespace/$dir[/$subdir]) , $namespace is a meaningful string, a kind of domain.
IMHO, The domain scheme has the advantage of being human-readable, but it also creates a number of ambiguities.
Just as you can run a server with an IP without a domain, how about make the address available in the contract (gno.module?) like an IP on the internet?

import "gno.land/r/g1jg8mtutu9khhfwc4nxmuhcpftf0pajdhfvsqf5/$dir"
import "gno.land/r/foo/$dir"

// gno.mod
replace gno.land/r/bar => g1jg8mtutu9khhfwc4nxmuhcpftf0pajdhfvsqf5

And what about the approach of using it by replace in gno.mod, or if you want to use it publicly, register it in gno.land/r/users, like you would a domain registration?

[moul]

Thank you.

Please, rename $user to $namespace, which can represent individuals or organizations. Note that this feature is Gno.land-specific and may not be available on other GnoVM chains.

I'm also in favor of supporting a unique address or hash for packages in addition to the human-readable path. Can you explain why you think it could create ambiguities?

Currently, the address is derived from the path, but I suggest switching to a content-based hash.

Related with #694

[anarcher]

Please, rename $user to $namespace, which can represent individuals or organizations.

👍

Can you explain why you think it could create ambiguities?

Best of all, We can deploy contracts without permission. (Coordination-free?)
My impression from #384 is that meaningful naming always requires some sort of management or consensus (to prevent spamming, etc.) If we can import paths based on contract addresses, the contract itself will be free of this constraint. But public contracts or libraries (std,system,etc) need validation and consensus. So these packages need a public name.
And we can also support some sort of symlink/upgrade by mapping, remapping the contract address to a $namespace (just like we can support rolling upgrades in load balancers by linking to a specific domain).

[moul]

Do you agree that we're discussing limitations and constraints rather than ambiguities? Ini, your proposal may offer more options but could also create ambiguity. Please let me know if I'm missing something.

Coordinated package publishing, as defined in #384, may only apply to gno.land. Other chains may require varying levels of permissioning or follow a permissionless model.

I support making raw addresses more accessible for gno mod in #694, but believe we should prioritize human-readability as the default option. Using raw addresses directly should be an exception for rare cases only. My inspiration is GitHub, where specific commit hashes are rarely shared by default.

I believe all options are interesting, and we should seek more input from others if possible.

[anarcher]

Do you agree that we're discussing limitations and constraints rather than ambiguities? Ini, your proposal may offer more options but could also create ambiguity. Please let me know if I'm missing something.

Agree to a point. :-) It's just another idea. I admit that there is a problem with not knowing what is in the raw address. (like can't tell what server it is just by looking at the IP).

[grepsuzette]

Suppose my realm depends on gno.land/foo/exchange_rate, and that realm is updated, should my realm now depend on the new version (automatically)?

I don't think so, even if we have trusted DAOs.
Because no responsible realm owner will want to put his users at risk.

An entrepreneur is liable for all its users.

Because of that, an idea like that proprosed by @anarcher is going to be necessary.
However there are other solutions too:

Something like gno.land/foo/exchange_rate@v2. It's not really elegant however. I don't like it.

Or using gno.land/foo/exchange_rate, with the implication the dependencies for a realm are manageable right from a panel, either by the owner, a group, commitee, or a DAO. But in that case you know, it would be an update for my realm. The realms dependent on my realm would need to update. It's probably what I would find the most elegant, but we are not there yet.

[moul]

I recommend that both of you read #694, which also addresses this issue.

Should we merge the two issues or focus this one on the pros and cons of displaying non-human-friendly immutable contract names in the UX?

[grepsuzette]

Ok seen #694. Of course I also support having gno.land/r/manfred/pkg@hash.

Should we merge the two issues or focus this one on the pros and cons of displaying non-human-friendly immutable contract names in the UX?

If no one disagrees of having it like github like you said (having hashes, but where hashes are rarely used), the question then is simply when is the hash accessed. I suppose:

• realm visitors may click on some Realm details button (to visualize the hash, and the dependencies used and their hashes, and the history and what not).
• but their browser would just show the path name without hash.

If again there's agreement on this, then I think we can just use #694 to discuss the more difficult points about updating dependencies. So it depends on what @anarcher thinks about gno.land/r/manfred/pkg@hash or if he sees another thing to discuss.