This interface/implementation was originally added as a helper, so that "we" (Decent's frontend) could more quickly (in terms of network round trips) identify what version of contract the implementer of this interface is.
The same thing could be done with the implementer's contract's ERC165 interface, but my original (incorrect) assumption was that ERC165 checks would be O(n) complexity (in terms of network requests), while calling version() is O(1). That assumption was incorrect because we can use the multicall contract to bundle all of those supportsInterface checks into a single request.
Another thing I don't love about the IDecentVersion interface is that it adds tight coupling between clients and contracts. In order for the client to properly utilize this version() call, it needs to make an assumption about what functions are available on the contract. Relying on ERC165 just about guarantees that not only the functions we expect to be there are there (because we ask the contract directly if they are there -- that's what ERC165 is), but also we are now using a common pattern for other teams to be able to deploy and use their own versions of these contracts if they so desire, and as long as they implement the interface, our frontend should work. This only requires the other team to understand how ERC165 works, and not need to understand what our custom version schema is.
This interface/implementation was originally added as a helper, so that "we" (Decent's frontend) could more quickly (in terms of network round trips) identify what version of contract the implementer of this interface is.
The same thing could be done with the implementer's contract's ERC165 interface, but my original (incorrect) assumption was that ERC165 checks would be O(n) complexity (in terms of network requests), while calling
version()is O(1). That assumption was incorrect because we can use the multicall contract to bundle all of thosesupportsInterfacechecks into a single request.Another thing I don't love about the
IDecentVersioninterface is that it adds tight coupling between clients and contracts. In order for the client to properly utilize thisversion()call, it needs to make an assumption about what functions are available on the contract. Relying on ERC165 just about guarantees that not only the functions we expect to be there are there (because we ask the contract directly if they are there -- that's what ERC165 is), but also we are now using a common pattern for other teams to be able to deploy and use their own versions of these contracts if they so desire, and as long as they implement the interface, our frontend should work. This only requires the other team to understand how ERC165 works, and not need to understand what our custom version schema is.