EIP165 in EIP721

[andrew-fleming]

What is the best path forward regarding the incorporation of EIP165 with EIP721 (and subsequently, in general)? Being that StarkNet handles selectors by using the function name (versus the signature with EVM), how should we best approach implementing EIP165? A big thanks to @dewi-tim for bringing this up and offering the following options to consider.

Should we:

1. Attempt to replicate Solidity version behavior exactly (i.e. include types when computing selector, somehow imitate bytes4, use XOR)
2. Use StarkNet selectors (felts derived from function name only) and use bitwise xor builtins on felts)
3. Use StarkNet selectors and a different operation to compute interfaceID (e.g. multiplication/addition) <- may have different properties to XOR

My initial response leaned towards thinking that using the builtins on felts would be cheaper; however, regular arithmetic to compute the interfaceId may be less costly (if we don't know for certain, could be a good little research project). Or, of course, should we aim towards EVM compatibility? What other implications should be considered?

An important aspect to contemplate as well is @martriay 's comment in ERC20 function naming—namely, the meta of should these standards in Cairo be interoperable with EVM or should they move away from EVM.

What do you guys think?

[frangio]

One option that I think you didn't mention is that we could just copy the inteface identifier constant verbatim, instead of recomputing it in Cairo. If we're going with implementing ERCs to the letter (see the discussion about camel case), I think this is the only option that is coherent with that approach.

[andrew-fleming]

Excellent point!