Typecasting a string to Guard via Pact code

[Jad-KMC]

Currently, there is no way to create a single-key guard via pact code. (read-keyset) is required, limiting the ease-of-use for creating new accounts. This limits marmalade transfer-create to only accounts that already exist on the coin contract unless Javascript is used. The same issue exists for transfer-create of new coins

I suggest we create a new function called string-to-guard.

Example for something I would use directly with marmalade:

(let (
           (account-name "k:23455679…")
       )
       (marmalade.ledger.transfer-create token-id account (string-to-guard account-name) amount)
)

where (string-to-guard) would remove k: and check the length of account-name, and cast into a :guard typing

Alternatively, something like create-single-key-guard would be useful

(let ((account-name "k:123456abcdef..."))
  (create-account account-name (create-single-key-guard account-name)))

[emilypi]

Just to clarify, this really only refers to principal account protocols, which are the only valid things that could be considered for translation into a guard value. Of these, because of the compression inherent in the one-way hashes used to denote the strings, it's impossible to "create" a guard from anything but k: or r: account protocols. In this sense, it's more createkeysetlike-guard that you're looking for, which is to say, an easy way to construct a guard for a single keyset or keyset reference protocol.

In the case of r: or keyset reference protocols, you have this already: it's called keyset-ref-guard. In the case of k:, the policy of the language is to never construct keysets - rather, to only ever treat them as code blobs that can be queried, but never modified. However, because this policy was created before the notion of "principal" protocols entered the language, this is something that can perhaps be eased, since you do in fact have a universality to them that makes them equivalent to a keyset.

[sirlensalot]

My hesitation is that I think the focus on k: is a bit overstated. Today in crypto single-key custody dominates but IMO that's a problem not a benefit, so having a lot of tooling around single-key custody has the danger of perpetuating the single-key mindset and associated problems of lost funds etc.

Indeed, it's accidental that k: is a two-way principal, as obviously ETH and BTC do not have this for their addresses.

Finally, it is an intentional feature of Pact that keyset-based accounts are not createable in code, as this inevitably leads to developers checking in keys to source code. Pact eliminates this by design.

I would like to hear of a concrete use case that requires synthesizing a new keyset autonomously, because if it's not autonomous, you have access to the message data payload.