EIP-5114: Soulbound Badges

[MicahZoltu]

@TimDaub

How about renaming tokenUri to e.g. getMultiHash to make it abundantly obvious and required that the Soulbound Badge must be a hash resolvable through IPFS?

I don’t want to constrain to only IPFS, only to content that doesn’t change.

@TimDaub

interesting if we had an EIP that gave recommendations for what are good URIs and what aren’t when used in e.g. smart contracts

EIPs are for standards, not best practices. I agree that such a document should exist, just not as an EIP. I recommend a blog/article or static website that people can link to.

@SamWilsn

I think the requirement that URI’s be censorship resistant and durable is going beyond what can be enforced by a standard. It’s simply too easy for a token viewing dapp to ignore that requirement and support HTTP(S).

@TimDaub

IMO URI guarantee discussion is out of scope of Soulbound tokens.

I argue that guarantees around what can be cached, how aggressively, and what security guarantees there are for the data SHOULD be part of a standard, as it is part of the interface between different actors communicating via this standard. In this case, the standard is asserting that the data can be cached indefinitely, and that the caller can verify the integrity of the data client side. The specifics of how that is achieved are up to individual implementations.

@SamWilsn

If you aren’t standardizing the content of tokenUri and collectionUri, I would argue that those functions shouldn’t be part of your interface at all. If multiple incompatible standards arise for EIP-5114 metadata, and they all use the same tokenUri function, a contract would not be able to implement more than one of them.

I can appreciate the argument here but I’m hesitant to lock in a data format standard in this EIP as one can imagine several competing standards on that front that build off of this EIP, yet I find it useful to give strong guarantees about the immutability of these tokens and make it clear what they are meant to represent.