Feature Request - Unlockable key/URL/content about hicetnunc

[andrevenancio]

I'm not in favour of injecting an array of people who bought that NFT.

What I think we can do is:
Inject creator, viewer and "isOwner" and "objktid" it's up to you to check whatever u need to against one of the API's in the allow list.

I'm thinking of doing something similar soon. So I'll push for this feature but I don't want to inject more the the basic into the iframe. As for the rest of the conversation, about extra content, it should be external. U can create a website that people login using their wallet. U can check that user wallet is against your objkt and see if that user purchased the objkt and if they did you can provide more content.

[neverhood311]

@andrevenancio I was thinking of something more like what Han is doing with his CryptoCubes project on Rarible. I wanted to do something similar. I'm planning on minting a .gif, but when someone buys it, the buyer (and only the buyer) gets access to a secret URL to a Google Drive folder where additional content is stored. So everyone can see the .gif, but only the current owner can has access to the source files, or a higher-resolution version of the .gif, or information about a private event.

[veqtor]

This is not really possible RN, at least not in a decentralized way with how Tezos wallets work.
In theory, in the future, you could send this URL encrypted with the buyers public key, only letting them decode it.
But there's no functionality that lets only the person who owns an NFT view something, that would be DRM and that requires a level of programmable hardware access which Google, Intel, AMD and Apple are refusing to release (since they make billions selling blackbox-DRM software like widevine & fairplay to customers like Netflix, HBO, Spotify, etc)

[neverhood311]

I've found a workaround for now. If a buyer wants the bonus content, I require them to register their wallet with tzkt.io and to include their Twitter handle on their tzkt profile. Then, they have to DM me with that Twitter handle. If everything looks good, I feel comfortable that I'm talking to the right person.

…

On Wed, Apr 7, 2021, 1:04 PM Tarwin Stroh-Spijer ***@***.***> wrote: Again, this is a problem of privacy on blockchains in general. The other thing you could do was set up a secondary service which a user can log in to using their TEZ wallet, which would confirm purhcase of specific OBJKTs and send users details to registered seller? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#59 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABDGYATMCNJI7P2VV7YAT73THSUDXANCNFSM4Y3ZXKLA> .

[andrevenancio]

We had something very similar happening yesterday where @Quasimondo donated a Saviour of the Realm token to a developer working on the API.

Maybe there should be a wallet controlled by @crzypatchwork whose sole purpose is to upload and mint unique NFT (donated voluntarily by the artists on the platform) and they should be assigned to whoever achieved either a bug fix or a feature.

[dansan566]

@veqtor Did you have a look at the Ticket functionality within Tezos? IMO it would be possible.
https://medium.com/tqtezos/tickets-on-tezos-part-1-a7cad8cc71cd#:~:text=At%20its%20core%2C%20a%20ticket,respect%20to%20a%20Tezos%20address.&text=Tickets%20can%20be%20controlled%20with,and%20some%20natural%20number%20amount.

[veqtor]

@veqtor Did you have a look at the Ticket functionality within Tezos? IMO it would be possible.
https://medium.com/tqtezos/tickets-on-tezos-part-1-a7cad8cc71cd#:~:text=At%20its%20core%2C%20a%20ticket,respect%20to%20a%20Tezos%20address.&text=Tickets%20can%20be%20controlled%20with,and%20some%20natural%20number%20amount.

Hmm, tickets aren't possible to use for this, tickets are a way to move assets around outside of a contract context, not the way to unlock something. You need to understand, we don't want to become gatekeepers sitting on a honeypot of private keys to locked NFT content, I know some sites do this but honestly I find it quite dishonest for them to do it without having created a decentralized DRM tbh since it goes against the principle of decentralization.
When/if someone figures out how to do this the correct way on web3, it's going to be a big deal!

[tarwin]

@neverhood311 I think this is a "problem" with blockchains in general. Everything is public, because it's on the blockchain. To do this you'd need a few things:

a) a way for users to sign up to the site, and have a profile connected to an email address
b) a server that sends links to "hidden" files to these users once they have collected something

I'm guessing both of these kind of go against the ideals of Hic Et Nunc?

[neverhood311]

I'm guessing both of these kind of go against the ideals of Hic Et Nunc?

@tarwin Yeah, I think you're probably right.

I'm thinking the best workaround might be to require the buyer to register their tzkt account with some contact information and send a DM.

[JarrodWoodard]

I have a very large content creator that wants to escape Ethereum for their NFT's but also wants this feature or at least the capacity to confirm someone bought/owns the content which then gives them a redirect to a page of the creators choice for a private 'thank you' or something like that.

[tarwin]

I'd suggest you have something in the comment saying "hey message me once you've bought" or similar.
Example: https://www.hicetnunc.xyz/objkt/18577

[JarrodWoodard]

How would one verify that they did make the purchase?

[tarwin]

Good question. Contacting the buying back and asking them to send a very specific amount of TEZ from the same wallet to you ie "Please send 0.035236 TEZ to Wallet XXXX to confirm". That could work. But it's really a bit of a mess I'd agree.

[tarwin]

Again, this is a problem of privacy on blockchains in general. The other thing you could do was set up a secondary service which a user can log in to using their TEZ wallet, which would confirm purhcase of specific OBJKTs and send users details to registered seller?

[EMES77]

I'm coming back to this with an idea. At least for HTML OBJKTs. If you could provide a POST Array of the collector IDs to the iFrame it would be possible to test the viewer ID agsinst that array and show different content inside the HTML.

[tarwin]

Right now the OBKJT is given an owner and creator address as GET parameters. If we simply added the objktId (simple) then the OBJKT could look up info such as owners etc etc from external APIs.

The only downside to this is that in the future it could break if a) the API changes or b) the API goes dead.

[tarwin]

Another idea. If you wanted actual unlockable content you could make an external service that you need to log in to using your wallet (I think this is possible)? It could be a paid service. Then you mint, along with info on how to get the premium, and upload content to this secondary service.

[EMES77]

Right now the OBKJT is given an owner and creator address as GET parameters. If we simply added the objktId (simple) then the OBJKT could look up info such as owners etc etc from external APIs.

The only downside to this is that in the future it could break if a) the API changes or b) the API goes dead.

I think with a sandboxed iframe it wouldn't be possible to access an external API.

[tarwin]

If you look at the code on site there are specific domains that ARE accessible including those for Tezos API.

[EMES77]

What I think we can do is:
Inject creator, viewer and "isOwner" and "objktid" it's up to you to check whatever u need to against one of the API's in the allow list.

That would be amazing! Even better than having to do it inside the iFrame! Thanks Andre

[skenaja]

Just noting here that the lockable content is still accessible to all by spoofing the iframe parameters (and might also be easily discernible from the objkt's source code), so the data would only obfuscated by the options mentioned above.

[EMES77]

Just noting here that the lockable content is still accessible to all by spoofing the iframe parameters (and might also be easily discernible from the objkt's source code), so the data would only obfuscated by the options mentioned above.

Most of the content is downloadable from IPFS anyway. Searching the code brings certainly a different user experience then intended by the artist. For me that would be enough. Who's able to hack it shall have it ;-)

[skenaja]

Who's able to hack it shall have it ;-)

That's fair enough, but there is demand from some users looking for a stronger DRM/key escrow solution.