Over this past weekend I had the idea to build a sort of link shortener but with a payment system built-in. There have been many times in the past where I wanted to share a link - on Twitter or just through IM with a few friends - but did not want to go through the overhead of setting up a whole store.
So I built Gumroad. I coded/designed from 12PM -> 11PM on Saturday and 8AM -> 11PM on Sunday. There are still tons of features missing (I'm working on AJAX file uploading next!) but I think it's reached that - buzzword alert! - MVP stage where I want to see if anyone's actually going to use the darn thing (I'm thinking about taking a 30% cut).
Stripe reps have stated repeatedly that whatever their fee structure looks like right now, it's not representative of what it will look like when they come out of beta.
The only thing that I've seen that was commented on, but not objected to, is that it's 'similar to' PayPal fee structures. But even that's up to being refuted.
I love the idea! This makes it really easy to sell scripts (e.g. your own jQuery plugins or whatever) for $5 where it would normally be too much work to set up some payment processing.
The 30% cut is way too high though. Especially for higher priced links - I wouldn't want to sell my $99 game engine[1] through your service. I think something like "5%, but at least $0.30" would make more sense. But maybe having such "highly" priced links wasn't your intention in the first place?
> Bitcoins [...] _could_ become as universal as PayPal is today
Putting aside numerous other issues, bitcoin.org states "The total eventual circulation will be 21 million bitcoins".
[EDIT: DanI-S pointed out that bitcoins can already be subdivided. So this was switched from "there are too few bitcoins to support even American e-commerce" to "bitcoins are not valuable enough to support even American e-commerce". The number of fractional bitcoins is still an issue, but less immediately.]
At the current ~$0.70 / bitcoin, this means that every American will be able to have ~$0.05 in his or her electronic wallet, once all bitcoins are generated. Assuming that the rest of the world does not participate at all and that bitcoins are evenly distributed.
Sure, you could imagine an instant dollar-to-bitcoin-to-dollar conversion at the point of payment. Or you could imagine a bitcoin2.org that generates more coins. Or you could hope for a massive surge in the value of the bitcoin.
I'd put my money on Paypal sticking around, though.
The obvious hole in your chain of reasoning is that "$0.70/bitcoin" would obviously change when every American attempted to fill his wallet with bitcoins.
I'd put my money on paypal sticking around, but I'd also expect the volume on the Bitcoin/USD markets to increase as the value climbs (presumably from rate of new bitcoins from mining declining). I think we could see services using fractional bitcoins behind the scenes and USD (or euros) end to end.
I bet you could make some money facilitating lower fee transactions backed by bitcoins.
Bitcoins probably won't take off (cf the failures of all the other alternative digital currencies so far), but the whole number of bitcoins is no more a roadblock than the limited number of ounces of gold in the world was to getting everyone using gold as currency. The problems basically lie elsewhere.
[EDIT: the text below is correct, but a bit too snarky. My apologies.
Also, the site owner could just trust the client to actually run his/her bitcoin-generating code for a couple of hours and send any generated coins - this should earn him/her ~$0.20/hour, rounded down because lots of people have crufty computers. Still not feasible, and generating bitcoins will only get harder in the future, but not as bad as I suggest below.]
Sure, if you're willing to leave your browser consuming 100% CPU for a couple of weeks. And if you're willing to pay the entire resulting 50 bitcoins (~$40-45) you generated (at the cost of ~$60 in electricty, I'd guess)[1], or trust the site to return you the rest. In either case, you'd need to trust the site code to tell you that it's generated a coin, instead of silently sending it back to the server and continuing to run.
At least, that's my understanding of how bitcoins work.
[1] Only GPU-based generation is currently profitable, and there's no way NaCl can be given full access to the GPU - GPUs typically have DMA access, so being able to run arbitrary code on them is more or less equivalent to kernel-level access. In theory, you could verify the GPU code - but that's an enormous job, and there are lots of GPUs that you'd need to check for security holes. And security was not design criterion #1 for these devices, I'd guess.
Something like DirectX/OpenGL access makes sense, but running crypto algorithms through OpenGL (instead of CUDA or the like) is probably infeasible.
I like that idea. It seems like microgeneration is a feature Bitcoin is currently suffering from a lack of. As competition increases, generation seems to be more and more centralized. A low-traffic way to generate small amounts of Bitcoin in a peer-to-peer network would be a great addition to a future Bitcoin protocol.
This doesn't seem like a good match. With different hardware and prices of electricity out there it would be hard to make the system fair for everyone. Also, although minting coins is an important feature of Bitcoin, it seems there's a certain amount of miners needed to offset threat of fraudulent transactions; going significantly above that amount is just wasting planet's resources.
I can't imagine bitcoins in their current implementation gaining traction as a form of payment with 'regular folks'. I mean the whole idea is complicated enough that even I as a technically minded person have trouble fully understanding how it works.
Plus it's not clear to me that there are enough bitcoins to go around. Some comments below point out the fact that bitcoins can be divided down to multiple decimal places. That's great and all but I can't imagine a 'regular person' being comfortable with the idea that they currently posses .00152 bitcoins. I doubt most people think of a penny as .01 dollars, because fractions are confusing. Plus even if that .00152 bitcoins is enough to buy a car, it still just seems like a minuscule amount.
I don't mean to be a huge downer. I think bitcoins are an interesting idea, but if you want to sell things now a more traditional payment method would probably make sense.
And it has to be a completely separate account. They basically force you to either pay way too much or violate their terms by having two separate accounts. :/
You definitely don't want to use PayPal for a service like this, unless you want to lose all your un-swept earnings when they catch on.
PayPal's TOS specifically prohibit running a payment gateway or aggregation service, ie collecting payments on behalf of many sellers and then re-distributing the proceeds.
A service like this would almost certainly draw their attention, since one could be selling warez, pr0n, stolen credit card numbers, or any number of other naughty files through this service...
Someone else posted a tale of woe within the last month about their "experience marketplace" getting impounded by PayPal, ostensibly for the same reason.
<<The solution was first announced last October when the company said that the upcoming feature would offer "a competitive fee structure for micropayments, with pricing at 5 percent plus 5 cents for purchases under $12.">>
No, that's definitely a good point. I'm going to switch to a .30c + x% (tiered) model - aim to make at least $70-80 of that $99 if you use Gumroad.
I'm also thinking hard about "Preferred" accounts. Basically, you send an email to sahil@slavingia.com in the next 24 hours, whenever I do your balance at the end of the month you get as much as I can give without losing money on the transaction. ;)
I disagree. Take a bare minimum of 15%. That seems to be about what's competitive for non-merchant-account payment systems. You'll need to keep margins up.
Exactly. And keep in mind, you're competing against someone setting up their own web store. If I didn't use your service, I probably wouldn't go through all of the trouble of setting something up. In that scenario, I make $0. If you charge 30%, and I price my stuff at $10.00, I make $7 per transaction, which is $7 more than I would have made without your service.
1) How soon until the money reaches PayPal?
2) There are no assurances that the CC data is safe. It looks to be sent over HTTPS, but you're assumed to be trusted.
Wow - that's fast feedback! On a separate side-note would you be interested in early access to apps for similar sort of reviews / blog postings, or is that inappropriate to ask?
That's not inappropriate to ask at all. It's a fun hobby. Look through my site and you'll see I've done this a long time and have some big wins that launched first with me.
Cool idea! One quick thing: I would change the
"(Minus our cut)"
wording to something a little more friendly. Maybe transaction fee or something along those lines.
I would include a sample URL or two on the homepage - I was confused as to how I would get people to buy/what the sales page would look like - but thanks for clarifying with the attached URL.
Suggestion: you should now build a second app which generates a stream of single-use urls that are invalidated as soon as they are accessed, and which proxy through to an original base url. Then hook the two apps together and profit.
Love the idea! I'd also love a thumbnail/pic for each link, though. Something that might give them a little more evidence of what they're getting into.
Honestly, I'm not sure - hence them not being listed - but I think I'm going to go with 30%. And then for people making >$x a month dropping that in tiers. Thoughts?
30% commission is for when you are selling people's stuff for them. Unless you have a huge audience who can't wait to buy random stuff on the internet (like Apple does), 30% is outrageous. If Paypal started charging 30% commissions on money transfers people would drop it like a hot potato.
My recommendation is to establish the %age markup based on file sizes, since that would be the basis for infrastructure costs such as storage and bandwidth.
30% is definitely high. I understand 30% has become a buzzword these days, but in reality it cuts a lot into merchants' margins. You may want to research on current digital goods market sites such as e-junkie, payloadz etc. Most seem to have a combination of monthly pricing and a "low" per transaction fee. Monthly fee certainly going to be a barrier for casual merchants.
Yeah - I'd rather try my luck at Kickstarter and pay their 5% fee and PayPal's 2.7%.
You'd have to write up some very specific usage scenarios that make that cut viable.
Apple's cut makes sense so far that you get some tangible advantages in terms of such things as exposure. You'll have to explain people what they get for the 30% cut.
Right now, I'm unconvinced that you get 30%'s worth. But, on another note, it's probably always better to start at a high price and dial it down than to launch a product and increase the prices over time. People will be crying bait and switch - justifiably.
Or eJunkie - it lacks the (apparent) simplicity for but for $5 a month you can make an unlimited number of sales for up to 10 digital items and then you've got PayPal/processor fees on top of that.
PayPal's micropayments pricing is 5 cents plus 5% per transaction so this combination can be a big money saver.
We created a service for a niche market that was mostly using eJunkie at the time (lowest cost, word of mouth travels fast among groups of sellers) and we had to compete with them on price and features.
great idea, but if your site is getting traction, you'll have to face tons of imitators -- after all, you already said that this is a weekend project. They are going to undercut you like crazy if you are doing 30%. So might as well make it as enticing as possible, maybe just 3% overhead (or even 1%).
"But I make a profit of three and a quarter cents an egg by selling them for four and a quarter cents an egg to the people in Malta I buy them from for seven cents an egg.
Of course, I don't make the profit. The syndicate makes the profit. And everybody has a share."
If the payment fails, will you still redirect to the link?
If you only redirected based on successful payments, you could use this as a simpler paypal for charging clients on your site using unique gumroaded links.
Seriously? I'm not sure I could take anyone seriously that tried to sell me a link of "value." Why not just share the link for free like people have been doing since the beginning of time?
Don't get me wrong. You did a great job getting this rolled out over a weekend and it looks nice. I must need some enlightening because I really don't get it.
I think there are some links that do have value. For example, if I wanted to release a new web app to my Twitter followers but wanted some sort of barrier (without having to set it all up myself) - I would use Gumroad.
If I had a bunch of files laying around my FTP that I never sold and would like to sell off for $5 a pop without the overhead of creating a store - I would use Gumroad.
Imagine you have a Fireworks iPhone mockup template.
Instead of setting up a store somewhere to list your ONE item, you put the template up on your website and link to it through gumroad.
Then, you give out the Gumroad link on Twitter: "Need a sweet Fireworks iPhone UI template? Buy it for a buck: gumroad.url"
Your twatting friends click it, give you a dollar, get redirected to your website. They download the template, you get a dollar - all in like 2 minutes while your oatmeal was cooking.
For many of the things that people might want to do, a "patronage" model isn't so bad either: the creator demands $1000 for the work behind the link; people can leave an e-mail address and pay anything from $1 to the full remaining price, and will be notified as soon as the work is available.
I think this has tons of value, almost like a mini-kickstarter without the need to advertise for a kick for communities of people (forums, etc) who want new features or some kind of quick bit of work done.
Disable direct links and proxy the content, that way you can create unique URIs for every buyer. Then you can do all sorts of things like add a watermark on the content page containing the credit card number of the buyer or just add expiration time to the links. That'll limit sharing somewhat, although I don't think it's a huge problem.
More likely usage scenario: pornography. Niche pornography.
(Hmmm, you may need to give some thought to legal questions raised when you're suddenly making money by selling every possible type of pornography into every jurisdiction of the world.)
What's being sold isn't the "link" but ability to access what it points to - an image, a blog post, etc. I think it's a great idea with oodles of potential - a link-based mini-paywall :).
As with many ideas I see floated and mvp'd on HN, I'm jealous. Great idea, good execution. I'd agree with others that the 30% is too high. 5-10% would be acceptable.
If anyone buys the access to a a non-unique-link (ie: http://mybook.com/book.pdf), and then shares the redirected URL to a third person, this third person could load the link without paying, right?
Yup. For now, there is no security built into the link once you get through that payment wall. I'm thinking about how to do that without hurting UX - though it's low on the priority list anyways.
If you potentially host the files/keep track of static/unique URLs on your site, you could keep track of who is the first owner to ensure that no future users also claim to be the owner and resend the file/link as their own.
This doesn't take into account all cases but a good chunk to start with.
Nice - how about this as a feature: # of downloads allowed. This would allow people to sell just 1 copy or set up something like a groupon-esque clone. First 50 people get 50% off. Then after 50 people say you're too late. Just an idea.
I really like this idea, especially for art. It solves the "what if someone just passes the final link around" problem because if you're getting 1 of 25 copies of something you're less likely to go out of your way to reduce the rarity of the item you bought.
I'd like to think that this has lower overhead than eBay. Nothing is there to stop you for now - I think this is more for casual use than building an entire business on top of. Yes, I'm thinking about adding in a preview option with cluttering up the experience.
Come on, if you want to see the icon/graphic/design/whatever before you pay for it obviously the seller can show you a smaller/low-res/watermarked/whatevered version.
The second question has been answered.
This is a completely different model than ebay.
These are really bad questions. I'm not putting you down - its no big deal, but just a little critical thought should answer these for you.
> If you want to see the icon/graphic/design/whatever before you pay for it obviously...
But that's the whole point. There's nothing that allows a seller to do this at the mo.
> The second question has been answered.
Sure, after my post. The answer to which seems to be "there isn't". So a valid question.
> This is a completely different model to ebay.
Perhaps from the platform's perspective, not from the sellers. The motivation is to enable someone to quickly put up an item for sale. I can pretty damn quickly put up a single item for sale on ebay too.
> Perhaps from the platform's perspective, not from the sellers. The motivation is to enable someone to quickly put up an item for sale. I can pretty damn quickly put up a single item for sale on ebay too.
You are completely wrong. The model is entirely different from the seller's perspective. See the author's original comment. I've included it below.
>How does this work for art though? I mean you want to see the icon/graphic/design/whatever before you pay for it.
This is also answered by the original comment.
"There have been many times in the past where I wanted to share a link - on Twitter or just through IM with a few friends - but did not want to go through the overhead of setting up a whole store."
The seller will be sharing a link with a person who they have a seller/buyer relationship with. The product in question is the last step in a process that the seller has complete control over.
> "There have been many times in the past where I wanted to share a link - on Twitter or just through IM with a few friends - but did not want to go through the overhead of setting up a whole store."
Right - and putting something up for sale on ebay and sending people the link is different... how?
Interesting idea, but I see two main issues with this.
First, anyone who pays and gets to the resulting link can trivially share that link; of course, you can always ask them nicely not to do so, and in some contexts that will work, but in general the security model just doesn't work unless you authenticate each paid user at the destination. You need to come up with an answer to this.
Second, if you market this as a link shortener which requires payment, I think you'll get backlash from people who currently use link shorteners to share links on Twitter and similar; from that perspective it feels like the kind of thing you'd see used by Twitter spammers/scammers. Suggested fix: flip it around, and present it as an astonishingly simple payment system based on URLs, which happens to behave like a shortener.
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.
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.
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)?
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 ;-)
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.
Another interesting variant might be: payment unlocks the destination link for X minutes. (After that, the true destination URL is changed somehow. Yes, that adds complication on the true hosting site or the necessity for Gumroad to proxy.)
So in a sense you don't care if people share the link for that period... maybe you even want them to, like a time-limited offer, so that they post to all their friends, "get it while it's hot!"
(The price could also rise or fall after each purchased open-period... perhaps even, depending on the number of downloads during the last open period.)
I like the idea of the proxy, why not have it so you do a direct link and gumroad takes a small percentage (1%?), and if you want it proxied gumroad takes a bigger percentage (5%-10%)?
In secret.php on your server you could then ask the Gumroad API (via another http request) how often this key was already used and deny or allow access. This would be super easy to implement for the seller - just paste in ~5 lines of PHP code.
You could allow access to that link about 5 times. After that, display a link that says something along the lines of "Thanks for using us. This link has been used 5 times already. If you wish to access it again, click here and we will send you an email with another authorization code (or whatever)".
That way your users don't lose access to their stuff, and you can keep track of abuse. It's not a perfect solution, but it's better than nothing.
I think #1 is a bit of a red herring. The security problem is not what this is solving. It's the ease of getting paid for some content, with less hassle overall.
Keep in mind that this is digital content so anyone could just rehost/resell/redistribute anything they bought or downloaded. But for something low-payment enough or the average silly download, why would they bother?
It's important to tell sellers that it's insecure so they don't assume it's locked, but please don't complicate this by adding DRM or sharing prevention. The most I'd do here is track downloads and let people kill their link and repost it if they sense abuse.
The difference: sharing the file violates the original author's copyright, but sharing the URL to it on the original author's site doesn't.
I actually wouldn't recommend adding DRM or sharing prevention. Instead, I'd just add a lightweight system to make it trivial to know who shared the URL. That will likely do wonders for getting people to play nice.
Optionally, you could add proxying through the gumroad site as an extra feature (perhaps at the cost of a higher margin on the sale), for people particularly concerned about the issue.
Think long term adjustment to the mentality of the site. If that link was worth something, why would the buyer just give it away? It's possible that the buyer would try to sell it and compete with the original seller, and all subsequent buyer might follow, but that would be something the original seller could take into account in pricing their product.
I agree that the link shortening aspect of this site cannot be it's product. Emphasizing that at all can detract from the truly novel idea that exists in selling and buying micro-properties of internet knowledge. People need to see the incredible nature of a site which allows you to sell information which has high demand and low supply, but has no other method of paid distribution. For everything too small to put in a book, and not small enough to just give away. I think its brilliant.
I haven't thought much about this solution, but wouldn't it be simple to just proxy the content back to the user? This would work fine for downloadable goods, maybe not so much for secret links to sites.
Here's how I would structure things to mitigate link sharing. It won't prevent it entirely, but will reduce it about 100x without affecting UX.
Your links can be one of two things: 1) a webpage, 2) a file.
For a file, I wouldn't worry about the DRM, as a person serving the file can have their own system, or you can use the system I'm going to propose for serving a webpage.
Essentially just use an iFrame.
So you have your public link: gumroad.url this leads to a paywall which then sends you to an auto-generated one-time link of gumroad.paidurl. This url is a simple page that loads an iFrame with the real private URL.
So gumroad.paidurl and gumroad.url both go to a paywall when user 2 tries to access it. And either paidurl or url will be the one that's shared. Yes, people can circumvent it by looking at the source of the iFrame, but 95%+ of people won't bother, and it's a heck of a lot easier than downloading and displaying the page through AJAX or server side.
Loving the simplicity of the idea. The simplicity is worth a higher cut (though maybe not 30% ;-)) and makes it a lot more attractive to use in small situations. One thing you need to beware of, though, is the filing requirements.. you might have to start issuing tons of 1099s and that process will cost you.
In the world of payments, that doesn't really matter at all. Payment processors can't afford to have high fraud % customers, so if fraud becomes a problem they'll just drop him.
Yes, how do you deal with the (hundreds, thousands, millions) of annoyed customers per day who were promised one thing but wound up paying for another?
This can't be a minor problem, either. At any given time the percentage of your users who are being ripped off by some nasty scam will be between 10% and 90%. You'll have to be very careful about policing things, otherwise the first mention of your business in the media will be "gumroad enables porn bait-and-switch scammers".
You can tell clients to check the http referrer for your domain. That would (mostly) stop people from posting now-useless destination URLs online.
http referrers are easily spoofed, of course, but it'll be enough to prevent most people from sharing secret urls on twitter. You could also pivot and allow people to upload files to your own server, but that's a different story.
That would hurt the UX. For example if someone gets the link to a blog-post-in-the-making they shouldn't have to go through Gumroad to access it every time.
Brilliant little idea, I think the big selling point is speed and ease of use. I might create a similar product to this for BitBuffet.com (a similar file selling service I created), as I think the process can be further streamlined.
Digital sale processes still need streamlining for everyday users (especially one-off users) and I can see a service like this taking off.
214 comments
[ 3.4 ms ] story [ 237 ms ] threadSo I built Gumroad. I coded/designed from 12PM -> 11PM on Saturday and 8AM -> 11PM on Sunday. There are still tons of features missing (I'm working on AJAX file uploading next!) but I think it's reached that - buzzword alert! - MVP stage where I want to see if anyone's actually going to use the darn thing (I'm thinking about taking a 30% cut).
Here's an example Gumroad link: http://www.gumroad.com/l/hjbaod - I use Stripe for payments. Here are some screenshots I took while making it: http://letscrate.com/gumroad/gumroad-progress - I didn't use Photoshop so no crazy time-lapses!
I think it has some potential. What do you guys think?
The only thing that I've seen that was commented on, but not objected to, is that it's 'similar to' PayPal fee structures. But even that's up to being refuted.
The 30% cut is way too high though. Especially for higher priced links - I wouldn't want to sell my $99 game engine[1] through your service. I think something like "5%, but at least $0.30" would make more sense. But maybe having such "highly" priced links wasn't your intention in the first place?
[1] http://impactjs.com/ (Can't mention it often enough :))
http://www.bitcoin.org/
But yes, it probably doesn't make much (commercial) sense right now.
Putting aside numerous other issues, bitcoin.org states "The total eventual circulation will be 21 million bitcoins".
[EDIT: DanI-S pointed out that bitcoins can already be subdivided. So this was switched from "there are too few bitcoins to support even American e-commerce" to "bitcoins are not valuable enough to support even American e-commerce". The number of fractional bitcoins is still an issue, but less immediately.]
At the current ~$0.70 / bitcoin, this means that every American will be able to have ~$0.05 in his or her electronic wallet, once all bitcoins are generated. Assuming that the rest of the world does not participate at all and that bitcoins are evenly distributed.
Sure, you could imagine an instant dollar-to-bitcoin-to-dollar conversion at the point of payment. Or you could imagine a bitcoin2.org that generates more coins. Or you could hope for a massive surge in the value of the bitcoin.
I'd put my money on Paypal sticking around, though.
I bet you could make some money facilitating lower fee transactions backed by bitcoins.
Also, the site owner could just trust the client to actually run his/her bitcoin-generating code for a couple of hours and send any generated coins - this should earn him/her ~$0.20/hour, rounded down because lots of people have crufty computers. Still not feasible, and generating bitcoins will only get harder in the future, but not as bad as I suggest below.]
Sure, if you're willing to leave your browser consuming 100% CPU for a couple of weeks. And if you're willing to pay the entire resulting 50 bitcoins (~$40-45) you generated (at the cost of ~$60 in electricty, I'd guess)[1], or trust the site to return you the rest. In either case, you'd need to trust the site code to tell you that it's generated a coin, instead of silently sending it back to the server and continuing to run.
At least, that's my understanding of how bitcoins work.
[1] Only GPU-based generation is currently profitable, and there's no way NaCl can be given full access to the GPU - GPUs typically have DMA access, so being able to run arbitrary code on them is more or less equivalent to kernel-level access. In theory, you could verify the GPU code - but that's an enormous job, and there are lots of GPUs that you'd need to check for security holes. And security was not design criterion #1 for these devices, I'd guess.
Something like DirectX/OpenGL access makes sense, but running crypto algorithms through OpenGL (instead of CUDA or the like) is probably infeasible.
Plus it's not clear to me that there are enough bitcoins to go around. Some comments below point out the fact that bitcoins can be divided down to multiple decimal places. That's great and all but I can't imagine a 'regular person' being comfortable with the idea that they currently posses .00152 bitcoins. I doubt most people think of a penny as .01 dollars, because fractions are confusing. Plus even if that .00152 bitcoins is enough to buy a car, it still just seems like a minuscule amount.
I don't mean to be a huge downer. I think bitcoins are an interesting idea, but if you want to sell things now a more traditional payment method would probably make sense.
Still, you need to take fees into consideration. Also, the seller has to pay another PayPal fee when transferring the money every month.
PayPal's TOS specifically prohibit running a payment gateway or aggregation service, ie collecting payments on behalf of many sellers and then re-distributing the proceeds.
A service like this would almost certainly draw their attention, since one could be selling warez, pr0n, stolen credit card numbers, or any number of other naughty files through this service...
Someone else posted a tale of woe within the last month about their "experience marketplace" getting impounded by PayPal, ostensibly for the same reason.
<<The solution was first announced last October when the company said that the upcoming feature would offer "a competitive fee structure for micropayments, with pricing at 5 percent plus 5 cents for purchases under $12.">>
I'm also thinking hard about "Preferred" accounts. Basically, you send an email to sahil@slavingia.com in the next 24 hours, whenever I do your balance at the end of the month you get as much as I can give without losing money on the transaction. ;)
1) How soon until the money reaches PayPal? 2) There are no assurances that the CC data is safe. It looks to be sent over HTTPS, but you're assumed to be trusted.
(TweetDeck, Beluga two examples)
What if you went with max (5%, 0.01/MB)? 30% of 0 is still 0, after all.
30% is definitely high. I understand 30% has become a buzzword these days, but in reality it cuts a lot into merchants' margins. You may want to research on current digital goods market sites such as e-junkie, payloadz etc. Most seem to have a combination of monthly pricing and a "low" per transaction fee. Monthly fee certainly going to be a barrier for casual merchants.
You'd have to write up some very specific usage scenarios that make that cut viable.
Apple's cut makes sense so far that you get some tangible advantages in terms of such things as exposure. You'll have to explain people what they get for the 30% cut.
Right now, I'm unconvinced that you get 30%'s worth. But, on another note, it's probably always better to start at a high price and dial it down than to launch a product and increase the prices over time. People will be crying bait and switch - justifiably.
PayPal's micropayments pricing is 5 cents plus 5% per transaction so this combination can be a big money saver.
We created a service for a niche market that was mostly using eJunkie at the time (lowest cost, word of mouth travels fast among groups of sellers) and we had to compete with them on price and features.
Of course, I don't make the profit. The syndicate makes the profit. And everybody has a share."
-- Milo Minderbinder, Catch 22
Clickable: http://gumroad.com/l/nbmeyt
If you only redirected based on successful payments, you could use this as a simpler paypal for charging clients on your site using unique gumroaded links.
Don't get me wrong. You did a great job getting this rolled out over a weekend and it looks nice. I must need some enlightening because I really don't get it.
If I had a bunch of files laying around my FTP that I never sold and would like to sell off for $5 a pop without the overhead of creating a store - I would use Gumroad.
Does that make it any better in your mind?
Instead of setting up a store somewhere to list your ONE item, you put the template up on your website and link to it through gumroad.
Then, you give out the Gumroad link on Twitter: "Need a sweet Fireworks iPhone UI template? Buy it for a buck: gumroad.url"
Your twatting friends click it, give you a dollar, get redirected to your website. They download the template, you get a dollar - all in like 2 minutes while your oatmeal was cooking.
If this really is possible, you'd have to create a user who is somehow whitelisted to get the linked item in question.
(Hmmm, you may need to give some thought to legal questions raised when you're suddenly making money by selling every possible type of pornography into every jurisdiction of the world.)
Kidding aside, I dare you (not sarcastically, I would love to see another approach to the same problem).
If anyone buys the access to a a non-unique-link (ie: http://mybook.com/book.pdf), and then shares the redirected URL to a third person, this third person could load the link without paying, right?
This doesn't take into account all cases but a good chunk to start with.
Also - once you've been redirected to the page, what's to stop you taking the link and sharing it yourself?
Also also: if I've got something to sell, can't I just bung it on ebay?
Not sure how you would sell JS scripts since showing a working demo would require the file to be accessible to the user.
The second question has been answered.
This is a completely different model than ebay.
These are really bad questions. I'm not putting you down - its no big deal, but just a little critical thought should answer these for you.
Cheers,
But that's the whole point. There's nothing that allows a seller to do this at the mo.
> The second question has been answered.
Sure, after my post. The answer to which seems to be "there isn't". So a valid question.
> This is a completely different model to ebay.
Perhaps from the platform's perspective, not from the sellers. The motivation is to enable someone to quickly put up an item for sale. I can pretty damn quickly put up a single item for sale on ebay too.
You are completely wrong. The model is entirely different from the seller's perspective. See the author's original comment. I've included it below.
>How does this work for art though? I mean you want to see the icon/graphic/design/whatever before you pay for it. This is also answered by the original comment.
"There have been many times in the past where I wanted to share a link - on Twitter or just through IM with a few friends - but did not want to go through the overhead of setting up a whole store."
The seller will be sharing a link with a person who they have a seller/buyer relationship with. The product in question is the last step in a process that the seller has complete control over.
No more of this. Cheers,
Right - and putting something up for sale on ebay and sending people the link is different... how?
I think all content should be uploaded to your servers otherwise if someone gets to the final link they can just send others to it.
First, anyone who pays and gets to the resulting link can trivially share that link; of course, you can always ask them nicely not to do so, and in some contexts that will work, but in general the security model just doesn't work unless you authenticate each paid user at the destination. You need to come up with an answer to this.
Second, if you market this as a link shortener which requires payment, I think you'll get backlash from people who currently use link shorteners to share links on Twitter and similar; from that perspective it feels like the kind of thing you'd see used by Twitter spammers/scammers. Suggested fix: flip it around, and present it as an astonishingly simple payment system based on URLs, which happens to behave like a shortener.
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.
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.
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)?
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.
So in a sense you don't care if people share the link for that period... maybe you even want them to, like a time-limited offer, so that they post to all their friends, "get it while it's hot!"
(The price could also rise or fall after each purchased open-period... perhaps even, depending on the number of downloads during the last open period.)
In secret.php on your server you could then ask the Gumroad API (via another http request) how often this key was already used and deny or allow access. This would be super easy to implement for the seller - just paste in ~5 lines of PHP code.
If Gumroad would be caching a file, this could be done using credit card security code re-entry every 5 attempts to DL or such.
Keep in mind that this is digital content so anyone could just rehost/resell/redistribute anything they bought or downloaded. But for something low-payment enough or the average silly download, why would they bother?
It's important to tell sellers that it's insecure so they don't assume it's locked, but please don't complicate this by adding DRM or sharing prevention. The most I'd do here is track downloads and let people kill their link and repost it if they sense abuse.
I actually wouldn't recommend adding DRM or sharing prevention. Instead, I'd just add a lightweight system to make it trivial to know who shared the URL. That will likely do wonders for getting people to play nice.
Optionally, you could add proxying through the gumroad site as an extra feature (perhaps at the cost of a higher margin on the sale), for people particularly concerned about the issue.
I agree that the link shortening aspect of this site cannot be it's product. Emphasizing that at all can detract from the truly novel idea that exists in selling and buying micro-properties of internet knowledge. People need to see the incredible nature of a site which allows you to sell information which has high demand and low supply, but has no other method of paid distribution. For everything too small to put in a book, and not small enough to just give away. I think its brilliant.
Your links can be one of two things: 1) a webpage, 2) a file.
For a file, I wouldn't worry about the DRM, as a person serving the file can have their own system, or you can use the system I'm going to propose for serving a webpage.
Essentially just use an iFrame.
So you have your public link: gumroad.url this leads to a paywall which then sends you to an auto-generated one-time link of gumroad.paidurl. This url is a simple page that loads an iFrame with the real private URL.
So gumroad.paidurl and gumroad.url both go to a paywall when user 2 tries to access it. And either paidurl or url will be the one that's shared. Yes, people can circumvent it by looking at the source of the iFrame, but 95%+ of people won't bother, and it's a heck of a lot easier than downloading and displaying the page through AJAX or server side.
How long until exact clones appear? What makes GumRoad the micro-paywall of choice?
How long until shortened<-->lengthened websites appear which reduces how many people pay up?
This can't be a minor problem, either. At any given time the percentage of your users who are being ripped off by some nasty scam will be between 10% and 90%. You'll have to be very careful about policing things, otherwise the first mention of your business in the media will be "gumroad enables porn bait-and-switch scammers".
http referrers are easily spoofed, of course, but it'll be enough to prevent most people from sharing secret urls on twitter. You could also pivot and allow people to upload files to your own server, but that's a different story.
If I buy something am I buying it from you or from the original owner?
How long do you hold onto the funds to deal with any potential chargebacks?
You're being shared Gumroad!
With the "You're being shared". Sounds confusing.
Digital sale processes still need streamlining for everyday users (especially one-off users) and I can see a service like this taking off.