Currently if you use lose the metadata you are SOL. We have plans to make it so that you can recover everything - the contracts, the metadata, and the files themselves - using just your wallet seed. This is probably several months away though.
@zubairzia Because there are higher priorities right now. Those things will definitely be on a future roadmap. Right now, I believe the devs limits themselves to putting on the roadmap items that can actually be accomplished in a reasonable amount of time.
I wanted to provide everyone with an update as we've been pretty quiet since the launch of the v1.0.0.
We have been, slowly but surely, increasing the amount of testing that we are doing and fixing the bugs that we run into along the way. We have found a large number of bugs, some of which I will describe below. We are in the middle of setting up a proper, long-running testnet. We have improved the control mechanics of some of the modules of our code so that we can more easily run local tests that simulate dozens of nodes (currently most of our tests are either on a single node or between two nodes).
Some of the bugs that have been fixed so far:
The host was not properly protecting file contracts as they were being revised. In particular, if the host was trying to perform an action such as a storage proof while a renter was uploading data, the host would potentially corrupt the file contract. This has been revised.
There was low tolerance for propagation differences between the renter and the host. Because Sia is a global network, it is frequently the case that a renter will have more blocks than the host it is talking to by a small number. When this was the case, the renter would potentially be unable to form file contracts. This issue has been resolved by having the host wait/sleep if there seems to be missing transactions or missing blocks.
The renter was not always adding a high enough transaction fee to the file contracts that it was creating, causing the host to reject all attempts to form file contracts.
The host was supposed to auto-disable if the host was having disk troubles. We've since realized that this is not the best way to respond to disk troubles. Furthermore, the host would frequently disable due to non-disk related issues, meaning that most hosts would have trouble staying online for more than a few hours because they would keep auto-disabling for the wrong reasons. The auto-disable code has been removed.
Miners were frequently having coins stolen because they were exposing their ports over the open internet, meaning that anyone with your IP address could talk to your wallet and ask for your coins. If you are a miner, your IP address is going to be visible to everyone via the node list, so it was easy for some attacker to scan the network and steal from any miner with an insecure network connection. This really isn't a bug, as miner's should have known better. However, enough people were doing it that we added some extra safety features to make sure miners wouldn't do it on accident. Now, before you can serve your API over the open internet, you must pass a special flag to allow you to do so, and you must also authenticate your API via an http password. It should be noted that this still only provides weak security - the API authentication is plaintext http, which means anyone who can snoop your connection will be able to steal the api pasword and then your wallet funds. This is significantly harder however than scanning the network and checking for unauthenticated and exposed nodes.
The host would occasionally reject renter file contracts in a way that the renter found confusing, so the renter would report the wrong error in the logs. This has been fixed.
The renter, when doing a revision, would corrupt the file contract revision if the connection to the host was disrupted at just the wrong time. Once the file contract revision was corrupted, the renter could no longer upload data anymore, and potentially certain data would also be unavailable for download. This has been fixed.
When trying to download files, the renter would incorrectly fetch the list of contracts/hosts that protect the files. This would often cause downloads to fail. This has been fixed.
The graphical client has seen a similar list of fixes, though in general they are less critical to the functioning of the network. By and large, most of these problems were able to make it into the release because of insufficient testing. We believe that a handful of bugs still remain, but our local tests for hosting and renting are now much more successful.
We will be releasing siad v1.0.1 and Sia-UI v1.0.2 in the next week or two. The first release candidate for these should be out in the next day or two. It may still take a long time to form contracts, and wallets with a heavy use history may take a very long time or may not be able to form contracts at all. Once contracts have been formed, there should be far fewer issues with uploading and downloading. I strongly recommend that everyone upgrade as soon as the release is available, as there are many bug fixes, including security fixes.
I would like to thank everyone for their patience. We have delayed the release of long-desired features such as instant-wallet-unlocking in favor of writing more testing and fixing the features that we've already implemented. As best we can tell, there are no major architectural issues, merely a lot of bugs that we need to work through. We have already worked through many of them, and will continue working through them over the next month.
Very nice to see transparency on current and projected issues.
Could you include a timeline for #2 ?
As a side effect of this morning's coffee I offer the following loose idea:
While adding a secondary block chain to simply manage what might cripple a single BC leading to your 100,000 person limit might be new territory for BC technologies, I think it's a valid direction to explore. Imagine current block chain models as a single strand of a double helix of DNA, now imagine what you get when you increase dimensionality and have two intertwined block chains, interdependent. Without digressing I would like to see better planning such that blockchains can merge into composite chains.
Hats off SIA team, file systems are tricky.
I have been entertaining a model to bring containers to block chain models, simply because I REALLY like the spoon.net hat they sent me - just kidding, but containers could be stored as files proxy of SIA as it stands, I am interested in a block chain file system - sure I like Microsoft's new Protogon (Resilient File System (ReFS), but I foresee an ability (while SLOW) to allow for a truly decentralized file system, if not in whole, in part- permissions and all. I am picturing a container, but INSIDE the container? it's 100% decentralized.
I'm settling for SIA and STORJ and QORA and various other solutions that are allowing for nice tidy files to be put into decentralized storage.
My take ? SIA and the likes are hands down my POV - the first and only REAL block chain technologies the 'average' consumer can make use of (beyond ledger/transaction tracking services such as bitcoin, [insert 750+ alt coins here]) hands on, no hastles - NO command line- just nice storage solutions comparable to the very centralized ones that placate the airwaves of most AM radio stations these days 'For $30 a month, user XYZZY - and we back up blah blah blah'. So GET THIS RIGHT SIA heh... the world is counting on you.
What will be MOST interested to me is if smaller companies start repackaging SIA services as front end storage services... nothing wrong with that, everyone wins. I see it. Who knows, maybe one day Amazon says 'yeah, let's just outsource another 30 petabytes to SIA this month, they can get us a lower cost than our datacenters'.
While you list some pretty serious issues above, I patiently await this offering. Such exciting times.