Hacker News Reader

Comment by gavinballard | Hacker News Reader

That second formulation is how I thought of it in the first place.

You could get around the link-sharing problem for those that wanted to avoid it by offering single-use URLs, and provide Gumroad either with a way of generating a new single-use URL for your resource, or a way to pull a new URL from your site. Both of these methods would require some degree of control over the resource, however (you wouldn't be able to do this for content hosted by third parties).

For those who aren't fussed about security, you could offer it as a really easy way to optionally pay for content - eg a rapid "Donate" method.

View on HN

We used something like this for our content at Naughty America.

For each page request we'd generate a link to the file on BitGravity with a timestamp, expiration, and filename, and a hash generated from those concatenated with the requesting IP and a secret key. On BitGravity's end, they'd re-hash everything, and if it matched up they'd serve out the file.

To address the first problem, you should offer a passive solution and not require the user to set up anything special in the way of single-use URLs. In fact, I assumed the issue of payers sharing the end-link was such an obvious problem that the service would have already addressed this and had it built-in by default (but of course, MVP/first-release, I understand).

The way I'd see it working is, I give Gumroad a link I want users to pay for, and Gumroad charges each user, serving up the content, but never sharing with them the link that I gave Gumroad. You could do this by fetching the content on the back end, and serving it up through Gumroad's own single-use URL.

Sure, that would make sense for content that could be so served (for example, the pencil icon used as the example here) - but not all content is like that. What about content you want people to interact with (a blog post on your site, a special beta registration form)? You also take on all the problems of becoming a content distributor rather than a link distributor.

I agree with everything you said. If this were my project, these are all problems I'd be thinking about and trying to address. Looks like you're on the right path ;-)

I'm thinking about them hard. :)

and I would add that the content distributor problem is also a good one to solve (with your solution). May even be more profitable... a lot of people want to sell stuff, not link.

Interesting, I didn't think about the implications of "donate."

Kind of tangentially, I wonder if there's value in letting a user select a charity to donate all of their sales to (no pressure on the user, just an option)?

Reply on news.ycombinator.com