EthereumOpenSubscriptions
Minimal spec for initial consensus
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.
I purpose we also adhere to EIP-165 for how we announce additional features for 948 compliant interfaces.
just added a new ticket for https://github.com/EthereumOpenSubscriptions/standard/issues/13
@androolloyd @kerman can you submit a review here. the EIP proposal changes look okay to me
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?
I think you tagged the wrong @kerman! (Ive never met anyone with the /first/ name of Kerman before! hi! )
@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?
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.
@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?