Namespaced Keyset Names

[emilypi]

[sirlensalot]

This is a won't fix for now, as keysets have stopped being as central to pact usage with governance and generalized guards.

[sirlensalot]

Re-opening for further discussion

[michaeldoron59]

My intuition tells me that namespaces should not be global, but importable, similar to python in some way. I see something like this as the safe and clean solution: from import marmalade and then the contract will be able to use marmalade.ledger. Alternatively, you can make a contract to be the owner of the namespaces management (like with a module-guard or something) and this way it can also be like I said before, something like that: (import (ns-manager.get-namespace principal ns)) and this will make the contract to know the namespace. In this ns-manager module, the Kadena team can make a bool of verified, which can make things a bit more exclusive for the projects that had a verification process, and this verification process could become also distributed at some point...

[emilypi]

Thanks for the comment @michaeldoron59! I'm unsure of what this has to do with namespacing keysets as much as it seems to be about imports.

from import marmalade and then the contract will be able to use marmalade.ledger.

Pact already has a module import system and a way of "importing" things under a namespace using the namespace native. Namespaces, when defined, already take an administrative and a user guard as a requirement for their definition. When one enters into a namespace via the namespace native, the user guard is validated to make sure a valid operator is contributing the code.

[emilypi]

@michaeldoron59

My intuition tells me that namespaces should not be global, but importable, similar to python in some way.

While this is already the case with module (one need only issue the use command with its extended import syntax), for namespaces, one need only references <namespace>.<module> while importing in order to resolve imports at a particular namespace.

That said, extending the syntax to include namespace-level grouped and even qualified imports, would be a nice feature. However, it does present a logistical problem: how do we reference all constructs under a namespace and make them available to the user? This is a rather costly problem: it requires grouping on namespace references (namely, one must either fork the current pact db system and add a namespace field instead of just a module name that can be resolved, or create a separate table the manages the grouping at startup), or doing a gigantic select and parsing module and keyset names on demand. Both of these are a massive undertaking.

[michaeldoron59]

@emilypi , Thanks for you responses!

I'm not sure why I wrote this line as I wrote it,

from import marmalade

What I meant to write was more close to this: from principal import namespace And as you wrote, it can definitely be a massive logistical problem.. mm,, I got an idea that may figure it out, storing a table of these rows: <key:hash(principal,namespace_name), namespace reference, guard (which will be initialized to the principal)> Then you get a pretty simple table that makes anyone be able to create their own namespace, making the namespaces decentralized, yet safe to use in all chains (similarly to the principal accounts). however, those namespaces will have to lean on principal.. maybe it can be added as a second version of namespaces, and this way you won't have to change pact from the core, it can be a new feature, something like principal-namespace..