AbelsFire, I like the general line of thinking.  Sounds more like you're talking about backend stuff than a nice functional front-end though.  I always found bitcoin-otc to be quite cumbersome, and only natural to those who find it natural to use a command-line linux box.  Setting up a command-based architecture intended to be used by customers and sellers would only serve to limit the potential crowd of users.

But, that's not to say it wouldn't work as a fine backend for whatever front end web interface is created.

Markm, you're right that the bandwidth spent on blocks is another incentive for hosts to generally stick with a customer they are already serving.

Regarding torrenting, here is what I am picturing:
- A service that pays seeders for seeding particular files using funds sent by people who want those files to stay online.
- The person who wants the files backed up sets a daily rate that they are willing to pay in order to have the file available on demand via torrenting.  Say, $0.05 for 50 GB.
- The service takes those customer funds, and pays them out equally among the seeders.  So, if there were 10 seeders of the full file, then $0.005 to each seeder each day.

It seems like a perfect fit to me.  The customer can pay however much they like, though paying more will get more seeders, guaranteeing longevity of their file.  The seeders (or hosts) can get paid for simply using up some bandwidth and hard drive space.  And the load of any future downloads is split roughly evenly among the hosts.  The customer and/or the service can randomly check each host to ensure they have a complete set of the file.

Heck, perhaps the software could be built in such a way that the customer could just keep a few KB of the data on-hand, and have essentially infinite random checking of the files.  All that needs to be done is record a few bytes here and there of the file, then ask the seeders what is at that particular point in the file.  If the data returned from a particular host does not match the data on hand, then the customer knows there is a mismatch and can take appropriate action.  The hosts might also have incentive to periodically check other hosts too - the fewer hosts there are hosting the same data, the high the payout for each host.

So, the blocks torrented would be sought by more than just the original uploader, if for no other reason than that those seeding the blocks would receive a regular payout from the uploader.

The one thing I am unsure about, and perhaps someone with more knowledge of torrenting/programming can answer, is how the service could know who is seeding and pay them accordingly.  Perhaps it would have to be by IP address (i.e., you head to the website of the service, sign up with a particular IP address, then seed from that IP address)?  Or maybe there is another way?

Beyond that little hiccup, I think this could work perfectly.

Any chance you could add photo size to the photos?  You know, like 1680x1050, or whatever it happens to be.

It's a good idea, but there are a variety of ways to implement it, and the best route to go is still being discussed.

I actually really like that idea you just came up with.

It seemed almost implied, but I'll go ahead and state it:  The hosts who hold the valid data at the end of the given time period (which could be as short as a minute or as long as a month) split the fee paid by the customer.  So if the customer is paying $0.05/day for storing 100 GB, and 5 different hosts hold the data, then each host would receive $0.01/day as long as they are holding the data.

It also allows the customer to pay exactly what they want to pay, and the free market on the hosts side determines how many "backups" would be provided for that payment.  A customer paying only $0.01/day for a certain amount of data might only get 2 backups, while a person paying $0.04/day might get 8 backups.

The biggest downside is bandwidth.  There would be no reasonable way (that I can see) for a host to cap bandwidth on any data that they hold.  So they could potentially be required to serve the data 24/7 indefinitely.  I suppose this is workable - it mainly just means that hosts will have to take into account their bandwidth limits, and only host that space accordingly.

This is starting to sound more like paid torrenting than anything.

"16 Also it causes all, both small and great, both rich and poor, both free and slave, to be marked on the right hand or the forehead, 17 so that no one can buy or sell unless he has the mark, that is, the name of the beast or the number of its name."
That's the New King James Version, and it says "on".  I'd be interested to see the original Greek words, and maybe attempt to decipher whether it truly should be in or on?

Regardless, it does say "the name of the beast or the number of its name" is what the mark will be made up of.  So, how exactly could the mark be unique for each person if the Bible explicitly states that it will be the name/number of the beast?

You still haven't answered my question though:  Why pay a developer in Devcoin instead of Bitcoin?
I have no idea what you mean by this.  Again, the goal of the project is to match up users with too much storage with users with too little storage.
I don't like the idea of assuming the loss of data can have a set price on it.  Lots of people would deem their personal files that they hope to never lose as "priceless", especially pictures, videos, etc.

Having a facilitator manage a market of storage vendors would be interesting.  Again, the issue of having 3 different metrics (size, speed, and bandwidth) would be present.  Paring that down to a single metric, size, would be potentially doable, so long as a minimum speed and bandwidth are prerequisites to becoming a host in the first place.

So, I would imagine a storage asset would represent storage in the following manner:
- 1 storage asset = 1 GB stored for 1 month.
- The host is under contract to provide the stored data on demand one time at any point in that 1 month period in order to be paid.  In other words, bandwidth down and bandwidth up would exactly equal the storage amount.
- The facilitator would act as escrow and hold the funds to be paid to the host.  If a dispute is generated, then the facilitator finds out whether the host still has the files or not, and distributes the funds back to the buyer if the host does not.  Simply put, the host does not get paid if they cannot provide the files at the end of the month long period, or at any period within that month (if the user requests their files for download prior to the end of the month).
- It is up to the user to pay for and store their files on multiple hosts, if they so desire, in order to provide for redundancy.

This would aid in providing a marketplace for storage, where each storage asset is more or less equal, and the user knows what they are getting.

I think it would be possible to eventually expand the marketplace to account for all three metrics (size, speed, and bandwidth) for purposes of hosting large files for other people to download, but obviously, it adds complexity to the accountability of the services, and would perhaps mandate the use of a feedback-like system for host rating.

Devcoins are virtually worthless - I don't know why a developer would work to gain them.  And why not use Bitcoins?  How is Devcoin ANY better suited to pay developers than Bitcoin, aside from name?  I didn't mention developers getting paid because it absolutely depends on who is willing to develop something like this, and whether they would like to be paid or not.  If there is a central entity involved, then it is fairly likely that they would take a cut of the hosting fees gathered, and would be willing to front the costs of having a platform like this developed.  If it is a truly decentralized project with no central entity involved, then either some developer needs to believe in it enough to put it together without pay, or some bounty needs to be posted by users interested in seeing it happen.

I made it all about the users because, ultimately, a platform developed without the users in mind is worthless.  So, first figure out what the users want, then decide on how it will be developed and managed.  Right now, we're still in the "figure out what the users want" bit, which means how the platform is developed and whether developers are paid or not is largely irrelevant.  All I was saying in my previous comment is, I'd like to see a platform that allows developers to be paid, either via a central entity taking a cut of the fees, or via a bounty.  That's not a necessity, and obviously, it depends on what users want and need.

I don't know why home users should be ignored, either.  If they can provide storage at a lower cost than VPS providers (which are typically very expensive), then why not include them?  Reselling professional hosting is not the goal here.

I am not typically interested in any project that isn't "in it for the money".  Namely because those projects usually fail, either due to lack of developer incentive (who wants to put a bunch of time and effort into something that doesn't give them something in return?), or lack of updates, or lack of moderation, or lack of users, etc.  Money gives project organizers and users incentives to use the project, which is why I like projects in which the developers (and/or users) receive monetary compensation.  As you've seen with retroshare, not many people are inspired to continue to use a product that is virtually useless to them unless they are being paid to do so.

Also remember that a lot of people using Bitcoin are only in it for the money too - either in it for the long run, because they believe Bitcoins will be more valuable in the future, or in it to make money mining, etc.  Some use it because they believe in the fundamentals of decentralized and deflationary currency, but I doubt that the majority of Bitcoin users fit that profile...

I don't think insurance for users' data would be necessary if all customers paid the same price, and all hosts received the same compensation.  Make 2 the minimum number of hosts at which data can be stored with, and if one of those hosts drops offline (which would likely happen very rarely, if 99%+ uptime hosts are chosen), then the 2nd host would simply copy the data over to a 3rd host.

A pass-through app utilizing multiple smaller free hosting solutions would be interesting, but I wonder what the developer incentive would be to create and continually update such an application.  I also wonder if various hosts with free storage would simply block that application from using their storage since it could be seen as an abuse of their free accounts.

I think you're still missing the mark on the retroshare - those people didn't stay online namely BECAUSE there was no incentive, present or future, offered.  If they knew they could make money by staying online (or similarly, if they could build up host reputation to then rely upon to make money at some point in the future), then many more of them would likely still be running the software.

You do bring up a good point about a person being "outbid".  After all, what host wouldn't just drop their current users in favor of users offering more money for the same storage space?  One way to mitigate that problem might be to use a central entity to receive payments, then pay out those payments equally to all hosts offering storage.  The cost to store would be equal to the highest minimum price paid for storage available.  Expanding on my previous 5 hosts example then:

Host 1 charges $0.03/GB/month
Host 2 charges $0.04/GB/month
Host 3 charges $0.05/GB/month
Host 4 charges $0.05/GB/month
Host 5 charges $0.06/GB/month
Host 6 charges $0.07/GB/month
Host 7 charges $0.07/GB/month
Host 8 charges $0.08/GB/month
Host 9 charges $0.09/GB/month
Host 10 charges $0.09/GB/month

If all of the customers combined only needed enough storage to warrant the use of 6 of those hosts, then the lowest-priced 6 hosts would be used to determine price.  The customer would be charged the rate of host 6 for ALL of their storage (for example, for 3 hosts, they'd be charged $0.07*3 = $0.21/GB), and the payout would be equal to all hosts ($0.07/GB/month).  In this way, there would be no incentive for a host to change whose files they are storing, though it would make it more expensive and variable-cost for the customer.  Again, it'd be like the GPUMax of storage.

Aside from that solution or doing the "pay to recover/download" model, I can't think of any other way to make it work.  I do like the pay to recover method for its simplicity though.

MarkM, I respectfully disagree with your assessment that fly-by-night random hosts would require more copies of the data.  The whole idea of host uptime is to ensure that fly-by-night random hosts aren't used.  Right from the start, files would only be stored on hosts with more than, say, 99% uptime, and priority of storage would be given to hosts with the greatest uptime beyond that.

Retroshare did not offer your friends from Bitcointalk enough incentive to stay online, so they went offline.  But if someone is paying me to keep my computer online, especially when my computer is already online 24/7 anyway, then I'll keep running the software, even if it is only giving me pennies a day.  That's still more than I had the day before.

Does Google drive charge only for what it used?  That is another manner in which this could be a useful service.  Not forcing users to pay for more storage than they actually use.  That said, GDrive pricing is very competitive!

I'd be willing to go even lower on my personal computer to compete too.  Heck, I'd rent out 100GB for $1 a month!  That'd make use of my currently-unused 1TB WDG drive, to the tune of $10/month if fully rented.

True, but what he said is still pure speculation.  There is no proof that BFL mines on the units before they ship them.

That's not necessarily true.

When someone is testing a new CPU overclock, what do they do?  Well, they might run Prime95.  But they don't just run Prime95 for 5 seconds, then call it good because "it is giving the correct results".  No, they run it for 24 hours or longer, to be absolutely certain that the processor is stable for long periods of time.  Some people report errors as far as 15 hours into the testing.

So, BFL's testing period is 12 hours, after which, the units are packed up and shipped out.

Now, if you want to argue that BFL is purposefully holding on to units in order to get an extra $2.50 a day, well, to me, that's just silly.  But either way, it's purely speculation and goes directly against what BFL says they do.

I do not know how many different sites dropbox has with redundant data.  A cursory google search reveals no further details on it either.

On pricing, I don't think it needs to be a managed item as long as it is built in to the software.  For example, there might be 5 hosts available with 100 GB of free storage space.

Host 1 charges $0.03/GB/month
Host 2 charges $0.04/GB/month
Host 3 charges $0.05/GB/month
Host 4 charges $0.05/GB/month
Host 5 charges $0.06/GB/month

I go to rent 100 GB of space.  I am given 3 options:  2 hosts, 3 hosts, or 4 hosts, with prices for each level.  2 hosts will (currently) cost me $0.07/GB/month.  3 hosts will cost me $0.12/GB/month.  And 4 hosts will cost me $0.17/GB/month.  More hosts will protect my data more securely.  But, if one host goes offline, then another host will take its place, although possibly at a higher price (if no further lower priced hosts are available).

I think it would certainly be possible to utilize a modified version of Tahoe-LAFS, but I do not have the knowledge or ability to make the code changes necessary myself.  That's why I haven't really spoken to what software should be used much - it would be more up to the programmer creating the software than anything else, as to whether he'd like to start from scratch or build on an existing project, and which project that might be.

So you are seriously suggesting DVD's as a potential competitor.  Who wants to wait for 200 DVD's to burn?  On top of that, who actually trusts that, out of 200 DVD's, none of them will have an error when you try to restore from them?  On top of that, there's the convenience issue of not being able to access your data immediately if you need it.  On top of that, what "offsite storage location" is going to offer you safe storage for zero cost?  A family member's house?  What if they lose them?

I agree that the pricing model is complicated.  It seems that at least three metrics would need to be calculated and available.  Storage space, bandwidth, and speed.  And determining a pricing matrix between the three would be quite arbitrary and, well, confusing.  So perhaps, reducing it to one metric (storage space), and imposing certain minimum standards on the other two would be appropriate.  A host much be able to provide download speeds of at least 100 KB/s, and must be able to provide bandwidth equal to or greater than the storage space rented on a per-month basis.  Anything above and beyond that would be a bonus.

Or, looking at it from a different perspective, perhaps a central agency (I know, naughty words here) could match up buyers and sellers as appropriate.  The agency would know who has what storage, bandwidth, and speed capabilities.  For each buyer, they might choose a host with lots of speed, a host with lots of storage, and a host with lots of bandwidth, then serve from each of the three depending on how often the person needed the data.  If they end up needing the data often, work with the host with lots of bandwidth.  If they end up needing the data infrequently, let them download at higher speeds.  Etc, etc.  Yes, it would be complicated, but maybe less complicated than trying to figure out a decentralized way of matching up buyers and sellers.

Certainly, the simplest method of conducting such a project is to have a page where people host files to be downloaded, with a bounty in the future if they need it.  This would mean the host with the most space would have the largest chance at being able to provide a file that is needed, and would also mean the host with the most speed would have the biggest chance at providing the file more quickly than anyone else.  Yes, it is uncertain for sellers of space, but it may only take a handful of recoveries to make up for it entirely.  I actually think this would be the most practical route to go, and it's an interesting idea that hasn't been done before (AFAIK).

I still don't see why you want to move away from Bitcoins though.  How would tracking a karma score be any different from tracking Bitcoins themselves?  They're both just numbers...

I don't understand why any sort of concept of karma is necessary if people just use Bitcoins for it.  Pay Bitcoins if you need space, receive Bitcoins if you rent it out.

Why couldn't the client encrypt the data before sending it?  Why does each server need to encrypt it?

If cloud storage is superior, then why is it so expensive?  $125/TB/month?

MarkM, I wish you could be a bit less wordy.  You have good thoughts, but your posts are incredibly difficult for me to follow, for some reason.

Anyhow, if I understand you correctly, your proposal is that people pay for files only when they need them?  So they say, "hey, I might need these files in the future, store them for me and I'll pay you $10 if I need them in the future".  Those with higher amounts of bandwidth would perhaps be able to provide those files more quickly, and thus more likely to receive the bounty for a file download in the future if it is necessary.  That's an interesting twist...  I just wonder if people would be willing to store files if future payment is unknown.

I am not sure how the original idea would work with regards to bandwidth vs storage.  Maybe one provider would only be able to provide 100 GB of bandwidth even though they have 1 TB of storage.  Or it might be vice-versa for another.  Perhaps a "bandwidth/storage" ratio would also be provided, along with how much storage is available.  And of course, an "uptime" indicator and data-checker would be a necessity.d

Markm, you're COMPLETELY missing the point.

If I wanted to swap space with other users, I'd look at using freenode, or something else.

What this idea aims to accomplish, is to match up people who aren't using all of their storage, with people who are using all of their storage and still need more.  I have a couple TB's of extra HDD space, and wouldn't mind renting it out to other people to use.  I don't have any files that I want to store on their systems.  So, in my case, any kind of a "swap" system is fail.  I don't want it.

Similarly, my sister is into photography, and stores the .RAW files of all pictures taken, which obviously eats up hard drive space fairly quickly.  She only has 750 GB total.  She needs more space.  Rather than deleting the old files permanently, she asked how much online storage would cost.  It was outrageous - to the point where buying a new 1TB drive would cost less than renting 1TB of online storage for 2 months.  So, she needs more storage, and doesn't have any extra storage space to store other people's files as well.  Again, in her case, your "swap" system is fail.

I (and my sisters) don't have any criminal wishes, and I don't know why you want to imply that anyone who wants to make money hosting files is attempting to do so with criminal intent.  That is not at all the purpose here.  This is more about allowing people with lots of extra hard drive space a way to make money with that space, and giving people who need more space an opportunity to purchase it at a price that isn't insane.

Also, S3 is still high priced.  $125/month for 1TB of storage.  I'd be willing to provide 1TB of storage at a far lower price than that.

Question - would that new version help stale proof of work at all?  I have 4 BFL's running, and don't ever get a lack of work, but do get stale proof of work from time to time.

Wow, well that sounds like the perfect thing to start from...

Price drop!  3 BTC.