Most websites earn revenue through ads like Adsense, but more internet-savvy users are using Adblock - and to fight manga website shutdowns, manga/comic creators can utilize Nimiq to view their comics while getting paid in NIM - without piracy happening in-between, through the method mix of steganography and cryptography - these images are just pieces of cryptographics puzzles solved in-browser to assemble an image… which would only be possible by paying NIM to the creator/artist.
6 Likes
Sounds very cool! Would be very curious to hear what your exact approach would be here to combine the confirmed transaction with a key to decrypt the image.
Maybe when each page is purchased it could be encrypted from the server side using the buyer’s public key, that way only the buyer would be able to decrypt it.
1 Like
I would see this as a two part-er.
- User signs in via NIMIQ hub to declare ownership of their account.
- When a page or item is purchased, the site sends a small transaction back to wallet to confirm purchase.
Rather than being reliant on the site to remember what was purchased, their purchase history could be read from their wallet ID (transaction history), assuming they’re able to sign in to their account successfully.
Not sure how well this would work, specifically with difficulty (if any) of gathering transaction history for a wallet. But potentially a step in the right direction?
1 Like
I think the proposal by @rraallvv would work. But it needs a client side solution that can decrypt the page based on the user’s private key in the KeyGuard. AFAIK, we don’t have such a functionality yet. But the user could also generate a private key and store that for the same functionality. Though, I have to say, it sounds like an interesting use case to me! 
@Harley getting TX history is possible. But only for a limited amount of recent TX - if you need more you would have to rely on an API such as the nimiq.watch API to get all transactions - or run your own node. What I don’t yet understand is how you would take those TX and use them to grant access to the pages or decode them. The TXs are public on the blockchain, so anybody could see them and use the key inside of them - so I think client-side won’t work. But if you take the proof (signed message) that somebody owns an address (login) and then recognize the TX as proof for having paid for the content, that sounds like it could work if you do that server-side with a Nimiq node running. And then, only if the signed message is there and the TX history shows that a particular image has been purchased, then it would be returned by the server. Is that what you plan to do?
2 Likes
Sounds more like the latter is what I was going for. Transaction assigned to the user - whether it’s an encrypted key or just a note “R388RIT$ unlocked for user” - no indication of what was purchased, but the server/store itself would have a note of what R388RIT$ unlocks - the only access requirement is signing a message from wallet to validate ownership.
The TX history, may be the bottleneck - but assuming the uptime of nimiq.watch is stable I’m sure that could be an appropriate method to confirm older TXs.
Though that’s only how I would tackle something like this as a low-tier dev haha, I’m sure there is an easier method as rraallvv mentioned.
2 Likes
It also can be done without having to search the history of transactions nor using public key encryption, all you’d have to do is ask the user to sign a message with their private keys, and after verifying the message from your end you can store a cookie on the browser to check whether the user is allowed to view certain pages. The cookie can be create with some arbitrary expiration date so that users don’t have to sign the message every time they open the browser.
1 Like
Yep, that can work to stay logged in. What Ralv is pointing at is that the server needs to keep track of what has been bought associated with a public key, then the owner of the address has to authenticate for your server to release those images associated with the user. This way you don’t have to scan the blockchain. This would work perfectly fine in a centralized solution - which is what your doing, right? Or what’s your motivation to keep the purchases on-chain only?
1 Like
My expanded flowchart
On third user state (I want to read comic):
The web server would have…
- tx id recorded on web server’s database based from what user bought during “I want to buy comic” state.
- recorded of signed tx for particular image
- an assembled image based on signed tx
Nimiq Hub have done…
- scan previous signed txs related to site
- if not, perform a signed tx for a particular comic to lock in purchase
- perform a paying transaction to confirm the signed transaction on step 2.
- scan previous txs, sees the 2 tx’s done 2 steps back. calls web server to assemble image, user sees assembled image…
signed tx matches bought comic ID = syncs the profile and session
Requires in web server:
- an implementation to make Nimiq Hub act familiar with previous transactions matching the ID of the comic, would function as portable backup in case the new website implements the same database with previously scanned transactions by Nimiq Hub
Disadvantages:
- in case of website lost, all funds already paid, if website backs up in new location without someone knowledgable in Nimiq, you’ll pay the same comic again but in ordinary ways
I know this is an old thread but I like the idea and might be willing to do it, but I think it should be a paywall for anything - news sites, comic books, high-quality blogs. It should also be very easy to set up - I’m thinking maybe do it as a proxy in front of the webpage.
To be honest I think encrypting the images is kind of pointless - after all, once the person can view the image, it is fairly easy to take a screenshot or copy it in another manner. What we can do is require a payment from the viewer’s account, and a signed message (like an auth cookie) to prove they are the actual account owner. We can also prevent right-clicking. And in case people take the images and distribute them, I like the idea of using steganography on the image so at least we can see who shared (or “stole”) the content, unless they really know what they are doing.
I would also be inclined to prioritize the subscription-based model common on news sites over a pay-per-item model - but I’d like to hear what others think.
Anyways, I won’t be available to work on this for the next 3 weeks, but I’d like to hear what you think!
2 Likes