Propsoal: Trim the voucher protocol

[Gozala]

Context

Not a long ago I proposed changes to the simplify voucher protocol and to reconcile what is in the spec vs what is implemented #163 I even claimed there was an issue before there was a PR, but turns out there was no issue so I'm creating one retroactively.

Problems

1. Current implementation uses terms that I intentionally tried to avoid in the spec in order to not tie to a specific names, specifically names like account, service and product are not ideal. We are already renaming that think we called account to thing called space and I'm not even sure we've settled on that new name.
2. The thing you obtain boils down to the pair of [did, id] and same did then shows up in voucher/redeem in three different fields with, iss, service. I've made a case that we should just use did and drop the secondary id, I'll elaborate on why below
3. Design of the protocol as described by spec was that: "agent can request voucher" for the "email" address and get a voucher without it been tied to any space (formally account) allowing agent to pass it along or tie to whatever space it wants without having to communicate it ahead of time. Implementation simply ties to the with field that came in request.
   • This may be a reasonable compromise, but we really need to then revisit spec or at least have some justification captured why we've decided to not follow the spec

Proposal overview

I have proposed to identify subscription / plan / product / (you name it) by did:key identifier for following reasons:

1. That way issuer of the delegation can be an owner of it. In other words delegation chain will no longer have to be rooted in our service DID.
   • This makes it into a protocol that others can implement and not a proprietary feature
   • This also means that owner of the specific "subscription" can be change independent of any other "subscriptions"
     • For example if say we setup a nft.storage "subscription" and it's tied to [ourDID, madeupURI] we can not simply transfer ownership to another organization, because it's tied to our DID and corresponding keys. On the other hand if it's independent DID we can transfer private key of it independent of any other "subscription"s or service private keys.
   • If it is a DID it can link to some CID which can host terms of service and other things. Made up URL can not have any such things (although we could technically create a real URL to do it, but then again let's embrace our own name / content addressing primitives, if we can't use them how do we expect others to).
   • By dropping secondary id we remove need for specific names like product and service from the protocol because it's just a resource which is identified via with.
2. I think we should reframe this from "voucher" protocol to more broad "contract" protocol
   (we can come up with different name, please don't get stuck on the name)
   • voucher implies freemium thing, but we have payed plans now and there is no good reason why you should not be able to get "contract" instead that you can add to your account.
   • I should be able to workout a payed "storage contract" and give it to a space I want to support, there is really no reason to tie to my space or to force me into having a space to take my money.
   • contract is better analogy especially with payed plans, because who ever established it can terminate it not whoever owns the space (My employer may be paying for my storage deal, but once I quit they can terminate the contract and new employer can obtain a storage deal instead)
   • we could have multiple concepts like "voucher" and "contract" that are basically the same, but that makes our system even more complex. More to document, educate, maintain etc... I think it is worth refining some of this now as opposed to later, because it would be more pain.
3. Let create a consensus around whether issued voucher (a.k.a contract) is tied to some "space" or not and then update spec and decision accordingly
   • It feels very unproductive to be writing specs sharing for feedback and then having implementation do a different thing without a feedback loop

Counter arguments

This are some counter arguments I've heard in the discussion over video call, I might be misrepresenting something, if so I apologize, but this is my interpretation

1. Using DIDs means we need to figure out how to manage keys and we already have a lot on our plate.
   • I do sympathise with this. Yet I think we can avoid solving the key management problem for now and deal with that later.
2. But then how do I even know which DID is what "plan" ?
   • Ok fare, but then again initially we can simply have little table or spreadsheet.
   • We can even mine DIDs that would be easy to recognize (in fact our test already have DIDs that and with ali, bob and mal.
   • We can actually publish w3 names with bit more details so it's easy
   • we could use query parameters e.g. did:key:zKey?name=free-plan
   • Overall I think it's a lousy reason, what if we see [notOurDID, ourID] don't we have same problem ? In fact it's worth because ourID can deceive us ignoring notOurDID.
3. We can add the contracts stuff and more general stuff later, let's just roll with what's in repo now
   • I do sympathise with this, but there are tradeoffs
     • We end up with more concepts and larger protocol surface, more docs more code to maintain etc...
   • I think this may be a reasonable compromise, but we really should weight tradeoffs even if it means bit more work

[hugomrdias]

Current implementation uses terms that I intentionally tried to avoid in the spec in order to not tie to a specific names, specifically names like account, service and product are not ideal. We are already renaming that think we called account to thing called space and I'm not even sure we've settled on that new name.

I used descriptive names so i was able to understand what i was doing and actually make something work. Remember this is all super complex. We can rename those at any point.

The thing you obtain boils down to the pair of [did, id] and same did then shows up in voucher/redeem in three different fields with, iss, service. I've made a case that we should just use did and drop the secondary id, I'll elaborate on why below

can you give an example please ?

Design of the protocol as described by spec was that: "agent can request voucher" for the "email" address and get a voucher without it been tied to any space (formally account) allowing agent to pass it along or tie to whatever space it wants without having to communicate it ahead of time. Implementation simply ties to the with field that came in request.
This may be a reasonable compromise, but we really need to then revisit spec or at least have some justification captured why we've decided to not follow the spec

We can definitely adjust that, at the time this was the only way to make it work with tests and type checking.

Proposal overview

1. IMO subscriptions are specific to each implementation and should be owned by the implementer either by hard coding it or some other method.

Regarding the nft.storage example my view is that we will transfer the ownership of the space not the subscription, nft.storage DAO will still pay us to store data.

I dont see the business need to allow users to create their own subscriptions plans that web3.storage would support.

What we need to figure out is how users pay for a subscription and get back a subscription receipt that they can apply to a space. We dont need did or keys to do that.

If and when we see that our customers are asking us to enable them to build businesses not only on top our storage system but also our billing system thats when we can think about defining a protocol where customers can create their own subscription and use our billing system to get paid.

2. we can definitely adjust our voucher protocol no issues with that, but again lets first figure out how users get receipts for paid subscriptions and apply those to spaces. This will teach us a lot and we can apply those learning into a new "contract" protocol.

3. It does not need to be tied to a space, its is now just because of technical issues. i will create a PR to fix that asap.