ARC-0053 Decentralized, Self-declared, & Verifiable Tokens, Collections, & Metadata

[kylebeee]

Proposal for standardization of project / business self-declaration

[emg110]

Great idea! Although I 100% agree on proposed subject, about the ARC content and standard recommendations I have some questions:
1- Based on which global coverage or living standard this ARC is structured and proposed? Which living standard properties, declarations, versioning and formatting comply to and follow (Compliance and integration question)?

2- By which standard interfaces, gateways, or services in the real world this proposed ARC will be supported transparently without conversion, or interpretation (Usability and interoperability question)?

[kylebeee]

Hey!

1. This is a new ARC, I'm not aware of any previously established conventions for our ecosystem to share this kind of information. As stated in the motivation section for the ARC, we created it because there are a number of custom & centralized ways businesses we're doing simple parts of this. We saw an opportunity to create some decent standards that are relevant to almost every project or business that mints a token or NFTs. So we will definitely have to work to garner adoption with this standard. One of the ways we plan on doing that is introducing an open source app that formats these details & will upload to IPFS via a simple web form.

2. As far as adoption goes for using this information; projects & businesses would be free to utilize it as they see fit. Whats important to us is that the source information is trustworthy & clear in its purpose and i think this establishes that well.

[emg110]

Once again, great intentions, cause and initiative! But I did not get my answer because proposing standards IMHO should not be based on personal or organizational requirements or opinions when they are proposed for a larger scope community or in Algorand's case, global adoption!
What I meant was how this ARC guarantees interoperability and integration with already commonly used global living standards? Not expecting it to be globally adopted (I know this ARC is a new initiative)!

[kylebeee]

What I meant was how this ARC guarantees interoperability and integration with already commonly used global living standards?

What "already commonly used global living standards" are you referring to here?

[emg110]

Actually the response is exactly what I was hoping to hear from ARC proposer! I humbly think you need to have an answer for that question since you are proposing this ARC!
Here are just some contextual (no direct relation to this subject but influential and on-topic examples) examples! In all these, you can find recommendations, structures, metadata or property names, and such, even including business declarations! What I meant was if you have a compliance strategy in this proposed ARC with such standards so that it does not lead to Algorand isolation and getting bubbled down with standards and rules that only make sense domestically!

• Schema.org: [Organization][LocalBusiness] [Corporation]...
• vCard and jCard
• Legal Entity Identifier (LEI)
• ISO/IEC 6523
• ISO 20022
• GS1's Global Data Dictionary (GDD)

[pbennett]

@emg110
This is predominately about projects self-describing their NFT collections. Each marketplace has to hand-define the collections at the moment and as I understand it, quite a mess. Letting creators provide a way to define these themselves in an easily discoverable way seems a win.

[emg110]

Although I 100% agree with your comment @pbennett , I cannot understand what it has to do with my question and your bold disagreement with that! And As I said and need no re-assertion, I adore and agree with idea and was just asking if there are other standards being studied or complied to while proposing this one! Not disagree with it!
Anyways, I got my answer! All good !

[kylebeee]

Those examples give me a much more tangible idea of what you we're thinking. As @pbennett said; this is primarily about collection declaration or minted assets and their grouping. I think those standards you're referencing take this in a bit of a different direction. There are escape hatches for extra information if someone were inclined to include those kinds of data. Perhaps in the future they could be brought into the fold if there was support & a clear desire for it.

That's really the reason this became an ARC. I think NFDs can work excellently for adding all kinds of data in a declarative and verifiable way. The main purpose starting out is sharing collections, tokens and basic information like the team & an FAQ. I have no doubt it will grow and i see this changing and being extended quite a bit. You have to start somewhere. If we were going off and creating our own custom standards that overlap with Schema.org and the others in their purpose i would agree it would have to be addressed and justified up front but thats not the case here.

[pbennett]

I think the title of 'project / business self-declaration' was a bit misleading and is probably part of emg's confusion.
Changing the title might make it more clear what the real intention is here ?

[SudoWeezy]

This one has a broader approach than #122.
It is worth gathering the community around an ARC meeting in the coming weeks to discuss this PR.

[kylebeee]

@SudoWeezy I had seen #122 prior to doing this, one big difference in my eyes is that you can verify collections against multiple wallets on the NFD and many creators will separate collections by wallet just to keep things clean.

@pbennett I agree it should be renamed, not exactly sure how to phrase it given this ARCs broadness.

[SilentRhetoric]

As much as I like and support NFD, private entities do not belong in community standards.

I support the proposal, and, as an aside, I also think it might make sense to have a separate ARC for projects/businesses to declare info (unrelated to NFT collections).

[kylebeee]

Thanks for the feedback @SilentRhetoric, i realize people would like these standards to be completely agnostic but decided to push forward with it for a few reasons.

1. There is at the moment no other existing way to verify multiple wallets via smart contracts ( and readable state ) that i am aware of.

2. I thought this might be okay considering that in addition to being low cost they are also entirely in the control of the end user once they are minted.

3. We held a space discussing the ARC a bit ago and were given the okay as long as the ARC clarifies that it exists for NFDs specifically.

I am all for this being agnostic but an important aspect is this verifiability & I don't see someone creating parallel functionality to make this agnostic altruistically.

I want things to be as decentralized as they possibly can be and agree a private issuer for this identity-extension ARC is not ideal. With that being said I have a lot of faith in the NFD team and know they are working towards more decentralization for the NFD contracts daily.

I don't want to bar ourselves from creating useful things or supporting people & projects working to build on Algorand out of strict adherence to only moving forward when things are perfect.

[SudoWeezy]

What is more important than being platform agnostic (We always name IPFS, for example) is that we don't want a project from the ecosystem to have any advantages with a standard.

[joe-p]

I like the idea of not tying standards to specific projects. Making a generic contract that contains mapping of addresses to IPFS CIDs and only permitting that address to update it would be pretty straightforward.

[joe-p]

Just had a call with @kylebeee to discuss a bit more about why NFD was chosen to be included in the standard as it currently stand. The main thing NFDs offer that isn't available elsewhere is the ability to prove ownership of multiple accounts. If NFDs was not used and it was simply adding addresses to the JSON that indicated associated addresses, a project owner could add a wallet to the project that does not actually want to be added.

I still like the idea of a more general standard and will explore what the effort of having an agnostic standard that supports this sort of address verification next week. I think there is also an opportunity to modularize the efforts here. Perhaps one standard for general linking of metadata to addresses, one standard for multi-address verification, and then ARC53 and other future can leverage those standards.

[kylebeee]

Great speaking with you @joe-p excited to see what comes out of this

[dolphinkitty]

Definitely agree that its critical that ARCs should be platform agnostic!!!
Providing a structural advantage to a specific platform will disincentivize development by other projects within related areas. When developers start associating Algorand with insider advantage, we risk decreasing future developer adoption which would negatively impact the whole ecosystem.

[kylebeee]

Im happy to switch this to an agnostic standard with NFDs being the first to support the standard

[heartberg]

We are working on a fairly ambitious platform that among other things, enables Algorand projects to mint NFTs, associate these with a Collection and with the parent project.

We were considering ARC-0019 as a viable solution for this, because:

• Information can remain mutable if needed (wallets, collection name, etc)
• It is a decentralized source of truth
  We also have a mechanism to restrict which wallets can be associated with a project / collection. To avoid scam collections adding arbitrary influencer wallets to their metadata.

Our proposed platform does not directly compete with NFD as it doesn’t involve domains, but it does compete in certain use cases. Therefor it would not be in our interests to send users from our platform to the NFD platform. Our whole purpose is to enable projects to consolidate their utilities and assets in one platform.

If this proposed ARC is focused on solving the core problem, then we are all for it, but as it is described, it seems to be more focused on increasing NFD adoption.
Even the demo link provided in the description immediately confronts the user with a big ‘Get domain’ button -https://akita.community/
No ARC should force a project to buy a proprietary product from a specific project like NFD.

[kylebeee]

Hi @heartberg, its not intended to spread adoption of NFDs. Its just that it was the only current multi-wallet verification system on mainnet. The core purpose of this is to trustlessly enable sharing collection and other metadata.

Im happy to go forward with it as an agnostic standard, the whole point of it being living was for it to change as new methodologies & use-cases arrive that meet that multi-wallet verification requirement.

[joe-p]

After talking with @pbennett I think accepting this ARC mostly as is and keep it as living is the best path forward.

In an ideal world, NFDomains would have ABI interfaces that are published in an ARC and this standard would reference those interfaces, much like ENS. NFDomains, however, has been a project in the ecosystem for a long time and as such their contracts are fairly complex and don't leverage the ABI due to technical limitations that have historically (and some currently) exist with the AVM and ABI tooling. We could technically document the contracts as they work right now, but this would be a lot of work with not a ton of payoff.

I think this means we should have this ARC exist explicitly referencing NFDomains, but with the ackowledgment that in the future the functionality used will be documented as interfaces rather than explicitly requiring usage of NFDomains.

Change I would recommend to @kylebeee before merging, assuming everyone is on-board with making this a living standard:

• Remove NFDomains from the ARC name
• Add a section that documents the fact that this ARC will eventually include interfaces (with NFDomains being the primarily implementation of those interfaces)

[dolphinkitty]

I am not onboard with this ARC at all!
Referencing NFD in the ARC is detrimental to competition, and short sighted.

You have now heard from at least two voices in this thread that disagree with this proposal and who have stated they are working on projects that in part or full compete with NFD. You have also heard of an alternative more platform agnostic solution in ARC-0030.

Its really simple, we are working on an NFT project that will require a source of truth for collections. We do not want to send our users to NFD. We do not want our users to not use our service because they have to pay our fees and pay NFD fees. They can skip our service and just use NFD. End of our business.

Someone in this thread proposes making NFD the first implementation of this ARC, and you changed that to the ‘Primary’ implementation. Primary can be read to mean the ‘main’ implementation not the first implementation. I get the feeling that people have ulterior motives here to help structurally aid NFD’s business.

NFTs and tokens are the bedrock of any blockchain, having the ultimate source of truth for these point towards a single private business for which you need to buy their product is anticompetitive and ridiculous to even suggest.

Let’s build an ecosystem that is an equal playing field and not support one business over the other.
We should remove all mentions of NFD from this ARC, and ideally, we take another look at ARC-0030 instead :)

[SilentRhetoric]

Just to be clear, ARC-0012 is something entirely different than this. Perhaps there is another ARC you have in mind as an alternative?

[kylebeee]

Hey @cmd-cat i think you're a bit confused.

• We're removing mention of NFDs and moving forward with this as a living standard, which means as other services that support this come online they can be included

• the single source of truth for this info is not at all under the control or influence of NFDs, once the contract is minted the owner has complete control.

If you have an alternative on mainnet right now please say so and i will amend the arc to include both options. Also arc 0012 appears to be a vault ARC so unsure of how thats related here.

[joe-p]

Now that I think about it I think there is an opportunity to make a more general ARC for attaching metadata to an address. Simply have a contract that maps an address to a IPFS CAR. Within that CAR, there can be a file arc53.json that uses the JSON format described here and leverages NFDomains for the multi-address verification feature.

[heartberg]

I agree with @cmd-cat in terms of removing any mentioning of NFD from the ARC.
ARC12 doesn't look suiting to this matter at all.

The problem with ARC19 is that the data is stored on IPFS, which is not accessible by contracts and need an extra step for fetching the metadata.

@joe-p 's comment is good. Using a contract for storing the data and not IPFS would open up possibilities for contracts reading that metadata. Also storing it there via IPFS CARs is a good idea, loosing the contract reading feature though.

I would love to see this ARC to be standardized without any NFDs in mind. If you can have NFDs for verifying multi-addresses that's fine, but that could be another ARC, building on top of a standardized way for verifying Collection data etc.

[dolphinkitty]

@kylebeee When you say: “We’re removing mention of NFDs”, that means ANY mention right, not just removing the name from the title, but completely removing mention of NFD as a primary or initial or other implementation?

Just to cap this off, see this tweet:
https://twitter.com/NFDomains/status/1707818517167214958
NFD is promoting the Akita project; krby.algothen is building the Akita project; and retweeting the NFD tweet; and is also the author of this ARC proposal. There is likely coordination between the author of this proposal and NFD, and at the least a conflict of interest, which should have been a red flag to begin with. More generally we need to be really careful or forbid mention of proprietary products in ARCs, otherwise we risk disadvantaging competitors and sending the wrong message to developers about the openness of the Algorand platform.

We need generalized and open standards in Algorand, especially when it concerns the ultimate source of truth for “Tokens, (NFT) Collections, & Metadata” - pretty important stuff!

[kylebeee]

@cmd-cat I know the NFD team but am not affiliated in any capacity. Just a fan of the contracts capabilities.

I'll remove mention of NFD in the title. I don't see an issue with listing the providers that are capable of supporting this ARC which for right now is just NFDs.

I understand your concern, if your product/business builds the capabilities to support multi-wallet verification (which is crucial), I'll be happy to help push it as an official provider for this asap.

[SilentRhetoric]

Rather than including who can support the standard in the standard, it would be more appropriate to add this information to one of the ARC compatibility matrices, such as: https://arc.algorand.foundation/nfts.

[kylebeee]

Happy to do that instead, is that updated often?

Main concern is just that this needs to be easy to adopt and not listing providers forces the user/business to kinda put the pieces together themselves in some ways

[dolphinkitty]

It seems that my concerns were legitimate, when you said: "We're removing mention of NFDs and moving forward with this", you were in fact just intending to remove NFD from the title, but still include NFD in the standard in some capacity. Sneaky.

ARCs are 'standards', they are not a list of your favorite providers. Once you include NFD in the standard, its likely to remain the primary or only name on the list. There is no guaranty that it will be updated in a timely way or done in a way that does not continue to emphasize NFD. I do not trust your intentions on this matter, due to your clear conflict of interests, your lack of candor in this thread, and the unusual amount of effort you are spending to promote NFD, while multiple people have disagreed with you.

You say that your main concern is the need for this to be easy to adopt. Engineers are smart, they can work out how best to implement this standard, if it is adopted. Your main concern should be whether this ARC distorts competition in the identity space, and whether it requires users to buy a propriety product to conform to the standard.

We need open, platform agnostic standards, not ones designed to explicitly benefit NFD.

[dolphinkitty]

Another thing to add to this discussion: In addition to the airdrop that NFD performed, that promoted NFTs created by the author of this proposal, @kylebeee's NFD account shows that he currently owns 39 NF domains, has sold an additional 14 domains, and has 15 for sale right now (each for 10,000 Algo). And who know how many domains he has in other accounts.

Additionally, kylebeee runs a “domain club”, selling NF domains with over 50 holders:
https://twitter.com/kylebeeeee/status/1706377180476031049

It is crystal clear that @kylebeee is not looking out for the interests of developers as he claims, he is a domainer guy fighting hard to manipulate the ARC process to increase adoption of his preferred TLD, which benefits him personally.

Back in January, Exa_market held a poll to add support for another token – related to this, there was a very divisive discourse between the Akita army and other NFT community members. We really need to push back hard against these people who aggressively try to steer our ecosystem to serve their own interests above those of the whole Algofam!

[kylebeee]

@cmd-cat very clear you're trying to project quite a bit here.

I've only ever been open and honest about my motivations & reasoning with this ARC.

The ARC has already been changed to be agnostic, there is no mention of or requirement to use NFDs now.

Frankly the way you've been attempting to attack me is childish & unprofessional. I wish you luck with whatever product you're building and will be happy to help in terms of it supporting this ARC but i'd greatly appreciate if you communicated in good faith and stopped attempting to smear my intentions.

[dolphinkitty]

@kylebeee The only reason that you have finally removed the mention of NFD and agreed to make this ARC platform agnostic is due to the totality of massage opposing you. You continued to resist this throughout this thread, and therefor more information needed to be brought to bear, especially exposing your conflict of interests. Its not childish, its just unfortunate that you were so committed to NFD even after multiple people raised concerns and some specifically mentioned how this ARC could potentially impact their future business. Algorand is not mature yet, it's blossoming right now and we cannot entrench private platforms and then build services on top of them, while at the same time stifling other emerging businesses. With open standards, more decentralized methods to verify collection metadata will emerge and then we can see what resonates in the market.

[kylebeee]

XGOV-156 is fulfilled & makes this standard much easier to adopt for both ecosystem builders & projects that need to share this information with those platforms.

Watcher
Is a block watcher & API server for the ARC53 standard, it indexes the data it finds on-chain that follows the ARC as well as updates it.

Client
is a web app that makes it easy for projects to create their ARC53 JSON file for them to upload to IPFS & attach to their provider contract.

You can use the client app here