Handling sales with access properly

[mrsmkl]

Description

Issues that should be thought about

• when we want to use sales with access flow?
• if sales with access flow is used, how many tokens should the buyer buy to get access?
• should we add a mapping to AccessProofCondition (this will require some work because the args to AccessProofCondition are just the babyjub keys)
• another possibility is just to grant access if the user has enough NFTs

Is this PR related with an open issue?

Related to Issue #

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• Follows the code style of this project.
• Tests Cover Changes
• Documentation

[aaitor]

when we want to use sales with access flow?

So the use case here should be: "As a NFT owner I want to sell them to buyers and give access to DTP encrypted contents"
I think this can be expressed via one template (NFTSalesWithAccessTemplate maybe a better name would be NFTSalesWithAccessProofTemplate) as the combination of the following conditions: Lock, Transfer, Escrow, AccessProof

or via 2 DDO services provided by the templates NFTSalesTemplate for doing the NFT purchase and a second one using the template NFTAccessProofTemplate

if sales with access flow is used, how many tokens should the buyer buy to get access?

This needs to be defined by the publisher in the DDO. I think the parameter in the sdk is nftAmount and in the DDO represented by the _numberNfts parameter in the conditions.
So if the user holds >= _numberNfts can get access.

should we add a mapping to AccessProofCondition (this will require some work because the args to AccessProofCondition are just the babyjub keys)

Extract an interface for access conditions (i.e IAccess) that is implemented by AccessCondition and AccessProofCondition would be ideal, but taking into account the babyjub parameters it looks difficult to find a common interface there that is very clean. But if you have a proposal I can take a look at it

another possibility is just to grant access if the user has enough NFTs

Yep, I think this could be achieved via the 2 services/templates scenario. I think it's cleaner/simpler than 1 template with 4 conditions.

[mrsmkl]

when we want to use sales with access flow?

So the use case here should be: "As a NFT owner I want to sell them to buyers and give access to DTP encrypted contents" I think this can be expressed via one template (NFTSalesWithAccessTemplate maybe a better name would be NFTSalesWithAccessProofTemplate) as the combination of the following conditions: Lock, Transfer, Escrow, AccessProof

or via 2 DDO services provided by the templates NFTSalesTemplate for doing the NFT purchase and a second one using the template NFTAccessProofTemplate

The reason why the NFTSalesWithAccessTemplate exists is because it's more secure: otherwise the consumer could buy the NFTs but not get access password.

But I think the simplest approach for now is to just use the NFT Sales template instead...

another possibility is just to grant access if the user has enough NFTs

Yep, I think this could be achieved via the 2 services/templates scenario. I think it's cleaner/simpler than 1 template with 4 conditions.

I meant that the node would let the user download assets the same way as their owners, without necessarily processing the
access agreement.

[dancespiele]

I guess this endpoint will be called by order method that will be implemented in the sdk-dtp right?

[mrsmkl]

I guess at least for now we can use the same end point as normal, basically if there's no access involved it will just be the same thing as normal.

[aaitor]

@mrsmkl , I think the best approach would be to use the same endpoint and identify if it's a "regular or DTP" flow. That way we maximize reusing existing code and the endpoints remains the same

[dancespiele]

@mrsmkl but in case that is a DTP do we need to implement something in sdk-dtp right?