Hey, all! I thought it’d be a great idea to have a thread to discuss one of the things I’m currently working on. Background information:
The repository is also public if you want to take a look. With that said - Questions? Suggestions? Ideas on what we can build with the new primitives?
Very glad that you have solved the problem and that we can finally have a good solution for a xch name service. I was quite disappointed by the existing solutions and actually never ever used any of them (although I had bought some domain for my name)
Hope this will be more broadly accepted and used throughout the ecosystem.
So CATalog will-act-as / be the root zone ?
CATalog will be its own thing and used for CATs. I considered having a root zone, but the best past forward is probanly to have XCHandles as the ‘root’ and then a way to define subhandles - such as @example:handle1 and @example:handle2 where @example is the ‘base’ handle.
So the protocol is “@” ? There is https://spacesprotocol.org/ which is trying to do something like this but on BTC.
Didn’t know about Spaces - that’s interesting! The difference in usage is that ‘@’ would be used at the beginning of a string to identify the user is referring to a handle, much like ADA Handles uses the ‘$’ prefix.
Another difference is that, at the protocol level, Spaces uses ‘off-chain’ convenants. This means that there are some rules that cannot be enforced on-chain: given a relevant BTC transaction, you cannot just trust it’s valid because it’s confirmed, but rather need to ask an app keeping track of all previous transactions if the given transaction obeys all rules. For XCHandles, all rules are verified on-chain - other dApps can even assert this data using the XCHandles oracle. It’s like Runes vs. CATs - the Chia equivalent can check everything on-chain because, unlike Bitcoin Script, Chialisp is turing-complete.
Interesting! Looks like XCHandles-oracle is/can-be pseudo root zone for chia names.