Minimal spec for initial consensus

[johngriffin]

Aiming to get the spec started with the aspects that I see common to all proposals. This is in effect that a subscription ID will be a bytes32 value and there will be a cancel function and associated event.

[owocki]

i am curious what Kerman thinks of this.

[androolloyd]

I purpose we also adhere to EIP-165 for how we announce additional features for 948 compliant interfaces.

[owocki]

thats a great idea. i didnt know about 165

[owocki]

just added a new ticket for #13

@androolloyd @Kerman can you submit a review here. the EIP proposal changes look okay to me

[owocki]

@kermankohli can you review too

[shibe-dev]

there's a bunch of metadata that's common to all proposals:
address destination; //address of the service provider
uint amount; //amount to be paid every billing/payment interval

would getter functions to address destination/uint amount to force subscriptions to minimally contain these 2 vars be a good idea?

[Kerman]

I think you tagged the wrong @Kerman! (Ive never met anyone with the /first/ name of Kerman before! hi! )

[lknix]

@johngriffin why is bytes32 a preferred choice over uint256 for subscription ID? If you look at EIP-721 (probably a go-to standard to look at, since it's the only one so far that successfully went through the new review process) it uses uint256. Wouldn't it be better to use the same type?

[androolloyd]

bytes32 gives you the flexibility to generate reproducible values for subscription ids from off chain data, one example I would have is that you could reference multiple subscription to a single account or contract through known third party piece of data, in my example an external subscription id

you can generate a unique hash with (ERC948Contract address, recipient address, external_sub_id) and store that rather than having to ensure that people manage the values of on-chain data elsewhere.

A large part about subscription and e-commerce is being able to adapt to the current ecosystem's use cases and tools, WooCommerce, Shopify, Magento, others.

[lknix]

@androolloyd you can still do this with uint256 (by casting bytes32 to uint256, it doesn't cost anything since EVM internally uses 32 byte data, no types). In our case it's way easier to operate with uint256 for internal IDs (which are then used in read/write functions) than to have to deal with bytes32. This is mostly just inconvenience and the strongest point for uint256 is that it would be really nice to use the same type across standards for the same type of data (IDs are pretty much there imo). Wdyt?

[StefanSimec]

What is the purpose of having this as a separate function instead of just a part of a tupple that getSubscription() returns?

[lknix]

I still think it would be a good idea to consider changing this to uint256:

• UUIDs and sha3 hashes are directly convertible to uint256
• non-fungible token standard (721) is using unit256 for IDs, so why wouldn't we follow existing best practices?

[androolloyd]

I'm working on a model where you sign the hash of an input set of data, and provide the signature as a part of the input data set.

function getSubscriptionHash(
        address recipient,
        uint256 value,
        bytes data,
        Enum.Operation operation,
        uint256 safeTxGas,
        uint256 dataGas,
        uint256 gasPrice,
        address gasToken,
        address delegateWallet
    )
    public
    view
    returns (bytes32)
    {
        return keccak256(
            abi.encodePacked(byte(0x19), byte(0), this, recipient, value, data, operation, safeTxGas, dataGas, gasPrice, gasToken, delegateWallet)
        );
    }

returns a hash that is signed by the owner of the contract, and this signature is then stored by the merchant.

[androolloyd]

I refute the notion that because ERC-721 is currently implementing their UUID's as a uint256 that it represents "best practices", it is definitely an accepted approach.

[lknix]

Probably should have used a bit different wording: if everything else is the same, why shouldn't we go with something that's already out there?

[androolloyd]

I believe constructing a hash as a sum of inputs gives a deterministic ID, and that has a higher value than one that is a scalar value.

[kermankohli]

I'm cool with using uint256, don't really see how it's different to using bytes32 since it's just a smaller conversion step unless I'm missing something.

[androolloyd]

uint256 puts the onus of storing the reference to that variable off chain, rather than being able to compute it, that alone is too large of a headache IMO.

[lknix]

@kermankohli yes, it's directly convertible to bytes32 (no additional cost). I was just pointing out to different types for the same thing across standards.

@androolloyd I don't follow. uint256 and bytes32 are interchangeable. Thus if you want to construct hash from a sum of inputs, that's fine - either bytes32 h or uint256(h) (conversion doesn't cost anything). Thinking more about it: having the ability to do arithmetic operations with IDs (uint256) makes more sense than index access (bytes32). I really think your choice of hash constructed IDs shouldn't be part of the standard nor should standard enforce it. There are other ways of how IDs can be constructed and it should be out of the scope of this standard.

Oh, one more thing - at some point using bytes32 instead of uint256 was more expensive (GAS-wise). Not sure if that's still the case, would like to think it got fixed.

[androolloyd]

@lknix ok I better understand your positioning now, to continue on like I am with bytes32 I just need to cast the uint256 in the implementation.

I know that the input gas cost is eventually to be addressed but from what I can reason it hasn't yet been implemented or isn't slated for immediate fixing.

If there is truly no cost of conversion from uint256 to bytes32 vs bytes32/uint256 gas costs, then a uint256 type would be acceptable for our purposes.

[lknix]

@androolloyd yes, that was the rationale - I probably wasn't clear enough since conversions/castings usually aren't as straightforward. Cost of conversion should be 0 but let's make sure that's the case :)