Is there a discussion in the community / in CIPs for a open human readable alternative for wallet addresses, similar to adahandle or a DNS service, with a good chance for major adoption?
If no: Should I first describe the idea in more detail here in the forum or submit a CIP draft on GitHub directly?
[italic text edited 16:53 GMT to state key goals more precisely]
Things you maybe look for:
https://adahandle.com/
https://www.adadomains.io/
https://forum.cardano.org/t/cip-draft-domain-validation-for-cardano-addresses/106328 (Work in progress of mine)
https://forum.cardano.org/t/how-to-build-partnership-to-introduce-our-community-to-daedalus/107826 (Unstoppable domains seems to want to expand to Cardano.)
@HeptaSean Thanks for your reply.
Maybe I didnât state my goals quite well. Iâm looking for a solution to pursue the following two key goals:
Thatâs why I think a CIP might be the place to start, not an existing solution â except there is already an initiative for an open standard, with good chances to rule them all. Thatâs the point of my question
Okay, then the closest is the third: My attempt at a CIP that specifies how to validate the connection between a Cardano address and a DNS domain.
Got some critique in the CIP review. So, I will do an overhaul in the coming weeks.
EDIT: Actually, they wanted more motivation and use cases in the review. And my motivation was exactly that: I donât want to be dependent on a centralised commercial service like ADA Handle, but want to use my existing domains without more costs than a few transactions and with full control.
Maybe also consider the discussion in the pull request linked at the top. Thatâs where CIPs are discussed more technically.
Okay, âmyâ solution only works if you have a domain to connect to.
I should mention that there is work currently done to connect decentralised identifiers (DIDs) to Cardano wallets somehow.
IOG has announced that that shall come with Lace:
Didnât see any technical documentation up to now. And I donât know if DIDs are really more user-friendly than addresses. 
I was there at the meeting when this particular motivation was presented, and one of the best known developers in the Cardano community responded as if he wished heâd recognised the significance of this idea. So the decentralising quality of this proposal, once some issues like validation and metadata dependency can be addressed, will definitely make an impact:
I feel you are giving me a bit too much credit here. 
I just heard that that would be a more satisfying motivation to go on with it.
But in fact, it was in the motivation the whole time:
Maybe just too humble and too abstract. Will work on it.
Maybe the Lace wallet DID implementation is a technical solution for the given problem (to link a DID to a wallet), like Cardano wallets implement a eUTXO wallet. Maybe the solution has the same usability flaws: while every DID will have an ID, it doesnât necessarily have a user-friendly nickname.
The Lace speculations shouldnât stop us from discussing nickname solutions meanwhile.
Registering nick names in an open, decentralised way is non-trivial.
âMyâ CIP proposal circumvents that by reusing the existing DNS domains.
ADA Handle mints everything under their well-known, centralised policy.
Even if you would attach nick names to DIDs that would have to be done by some kind of centralised issuer of verified credentials that checks that they are not doubled and provides a lookup service.
We could think about a Plutus contract openly accessible by anyone as that central registry. But I also donât see how that could avoid collisions, since it is not really possible for such a contract to check that something is not there. We would have to give it all registered names as datum and that quickly grows too large for the transaction size. âŠ
«requirements engineering» from a business prespective and «implementation design» are different tasks. Our individual task (yours and mine) is to bring up the requirement and to ignite the discussion. With the method of a CIP, the community can then discuss possible implementations.
Regarding the decentralised database:
If a «standard record to represent an alias» is established, this record may be issued as an NFT and placed in the corresponding wallet. Since the blockchain is an open database, anyone may build an index containing all records. Probably it is better if IOHK would build and publish the index and make it accessible over a (distributed) API. â But as mentioned above, this is just an idea to be discussed by the experts in the community.
I think this «alias meccano» is a fundamental building block for the Cardano Blockchain usability, and so itâs tied very much to the Cardano brand. Thatâs why I think IOHK should be the issuer of the smart contract (if thatâs part of the solution) and IOHK should operate the register.
A CIP has to be a solution, has to be the implementation design. A CIP just stating some requirements that can maybe never be fulfilled wonât have any chance.
How would you ensure that no two people/wallets can register the same name? Who would have the right to issue/mint those NFTs?
Centralising at IOG is not one iota better than centralising at ADA Handle in my book. But if it is just an index that anybody else could also build it might be okayish.
Cardano is not owned by IOG and should grow independent of them in the mid-term.
Implementation design: In the final stage, the CIP describes the implementation. But we start on the other end.
Centralising Infrastructure: An integrity check requires the whole open ledger to be verified. Thatâs a basic constraint. But you wonât hold a copy of the whole blockchain for this application, and browse the whole soup to find a nickname. Thatâs why youâll create an index. In fact: anyone can create an index, and anyone can verify if an index is correct.
IOHK or not: As I wrote above, I am sure IOHK is willing to provide the required smart contracts and API services, since nicknames are an essential usability feature. Together with low fees and robust implementations they have strategic brand value.
Double handles: maybe the smart contract prevents creating doublets. If not: What about a timestamp: first come, first serve. Since you must create an index to make the system usable, you may check for doublets as well.
What about if a smart contract applied a hash function to the nickname to produce a blockchain address (ânickname deposit addressâ) and required this address to have no UTxOs. If the address has no UTxOs then the smart contract mints an NFT representing the nickname and deposits some Ada to the ânickname deposit addressâ. Nobody would be able to remove this UTxO at the ânickname deposit addressâ because there is no known payment key for it.
In the last hours, I wrote my idea following the pattern of @HeptaSean:
Nice proposal. I need to think about it more.
However, one thing that I think you should do to improve it is to basically remove everywhere you suggest that IOHK should do something. The community is really trying to become more decentralised and less dependent on IOHK. Where we do need a central authority for something, it should probably be Cardano Foundation or maybe use future Voltaire voting so the entire community gets to decide.
I think you will find that the IOHK company and team members would also be more likely to approve of the CIP, if modified as described, for the same reasons.
Is it possible to have a smart contract attached to the UTxO that can enable spending without requiring the payment key for the address that the UTxO is stored at?
If so, then the UTxO could attach a smart contract that enables the creatorâs own private key to spend the UTxO. This would then enable the creator to spend the UTxO if he didnât want the nickname anymore, or if he wanted to transfer it to someone else.
@Terminada: Nice input, thanks.
You seem to more literate in blockchain implementation aspects than I am.
Is it essential to have all records distributed over the blockchain? At some point, some elements must be centralised. In your example, thereâs only one smart contract. What if this smart contract maintains its own database, which is always accessible for everyone?
AFAIK, an NFT may contain a reference to an asset published on IPFS. And that file may be owned / signed by a smart contract, right?
What do you think about the following setup:
<issuer>, <registrar> and <owner>.<issuer> creates a <catalog> of nickname classes and verification methods and a <smart contract> to register a nickname.<registrar> may register a nickname on behalf of a wallet <owner>. Typically, a <registrar> is an application to create and provide an interface to wallets of an <owner>.<smart contract> is available for every <registrar>. He may register a nickname by providing a simple JSON structure to the smart contract, where entities of the <catalog> are referenced, among others. He avouches to have fulfilled the verification procedures claimed.<smart contract> validates/verifies the content in the <JSON> and notably ensures the uniqeness of the nickname. On success, the nickname is added to the <index>.I think you need to design out the need for an additional database since the blockchain is already a database.
What I am confused about is where @HeptaSean said:
A specific NFT can only be created once. I donât understand why you canât create a function that takes as input the nickname + a minting policy ID to produce a unique output that is the specific NFT. If the NFT already exists then the attempt to create it again will fail.
Isnât it possible to make the ânickname minterâ smart contract own the minting policy so that it is only possible to create the specific NFT representing that nickname through the ânickname minterâ? Also, wonât this allow anyone to apply the same function of nickname + minting policy ID to look up the NFT. People could then use a blockchain explorer to see what address holds a particular NFT and if it exists.
Or maybe the nickname NFTs could all be stored at a particular address - the ânickname addressâ. Then the cardano-cli tool can look up the UTxOs without needing a blockchain explorer. This ânickname addressâ is specified in a CIP and wallets are configured to look there for nickname NFTs. The private key for the ânickname addressâ is controlled by the ânickname minterâ contract and metadata is attached to each UTxO holding a ânickname NFTâ. The metadata is the references the person wants for that nickname and a separate smart contract is also attached to the UTxO which permits the owner to spend it in order to update his metadata.
@HeptaSean would already know all this so I assume there is some error in my logic. He is likely asleep now so we may need to wait a few hours for some education.
I think you need to design out the need for an additional database since the blockchain is already a database.
This was pointed out in the thread: Thatâs because an index to scan all nickname records is key.
That is something that can not be enforced by the Cardano chain.
Without Plutus, it was done by NFT projects promising to only mint one and using policies that are locked at some point in time, so that nobody can mint or burn after that point. But that would not be suitable here, since other names should still be mintable.
With Plutus, you have some more possibilities than just requiring some signatures and before and after slots, but it is still restricted to information given to the contract in UTxOs of the execution transaction.
That is possible, but it still doesnât solve the âonly oneâ problem. The contract would still need the information about all previously minted names and that is too much to be held in the datum of one UTxO, but if it is distributed in many UTxOs the contract cannot verify that all of them were given to it, and it would still be too much data for the size limit of one transaction.
Requiring that an address has no UTxOs is something that a contract cannot do. It only works on UTxOs given to and coming out of a transaction. And it only restricts the spending of UTxOs on its own address (which is the hash of its code, so only known after the fact) or the minting/burning of tokens for its own policy (which is the hash of its code) depending on the type of contract.
A smart contract cannot read external data. A smart contract is just a very small piece of code executed by every single node that verifies the transaction and it just says âYes, this transaction is okay.â or âNo, this transaction is not okay.â.
The off-chain part of a contract could read external resources from IPFS or somewhere else, but it would then have to prove to the on-chain part that that external resource really contained (or did not contain) the information that the off-chain code claims it does.
Otherwise, in a truly decentralised application, anybody could write their own off-chain code and get the contract to do what they want.
If it is not truly decentralised and the on-chain code requires some special permission and we trust the holders to do âthe right thingâ, we could just throw away the âsmart contractâ marketing, be honest, and say that that centralised entity is in control of the thing and their signature is enough.
Hard thing to do for the reasons stated above.
Instances of tokens are not distinguishable. If just the nickname is the asset name, it could not be told who of the holders of two tokens with the same name holds the first.
There could be a rather complicated construction: Encode the timestamp in the asset name and allow minting only by a smart contract that ensures that the timestamp is correct (this is a local property that can be checked by a contract). Then whoever wants to build the index can take the one with the oldest timestamp and ignore all others with the same name.
There, in fact, has been a CIP for off-chain metadata for over a year:
https://github.com/cardano-foundation/CIPs/tree/master/CIP-0026
It does work without any on-chain shenanigans and just honestly keeps the metadata off-chain, but it does not call for a centralised service either. There could be many different services according to that standard â one by IOG, one by ADA Handle, one by me, one by you, âŠ