Friedger
Friedger
> 1. Is it possible and advantageous to generalize the traits to be compatible with semi-fungible tokens (SFT per SIP013), how? I don't see a good solution. A generalized trait...
I like the commission solution we have right now. Maybe we should add recommendations for how to present this on the market places and wallets. Currently, the user might get...
@314159265359879 This more generalized interface would be `(list-in-token ( uint uint ) (response bool uint)) ...` The problem with the commission is that I don't see a standard way of...
The sip should contain a specification about documenting a minified contract, in particular about adding a reference to a fully documented version of the contract. That would imply a standardization...
Instead of storing this data on-chain, a ``` @error-uri "https://..." ``` would be more efficient, and would better support localization.
We had a discussion about `;;` and `;;;` where the latter is used for docs that can be removed before deployment for cheaper costs.
I am all for a reasonable documentation on-chain. How to represent * on chain docs, including docs for doc-gen * off-chain docs, including docs not for doc-gen
Ludo suggested keywords starting with `@` for docs-gen. Combined with `;;;` we could cover all cases.
For upgrade procedure see https://github.com/blockstack/stacks-blockchain/discussions/2685
As the name is just a label for the user's key, I don't think there is any disadvantage when user/user's key can have several names that redirect to the one...