Excuse me but... what's the point? Syncthing basically does what you describe (let several device "subscribe to each other" and receive broadcasts that files are new/changed), except without any pesky centralized service, but in an almost fully peer-to-peer fashion (there is a central "discovery" service, I'd rather a DHT but they don't have that for now).
It is, of course, open source and everything, so I'm not sure why I would reinvent the wheel.
The thing above and beyond this that I would like to eventually see is being able to connect to Sia (without any centralized service) and access my files by simply using a passphrase, which could generate some kind of key on the fly.
Could you elaborate? By repair you mean that one or more of the original hosts are offline or no longer have the file? So, in that case if there is a local copy the file will be repaired? What happens if the file cannot be repaired? If it can still be retrieved from remaining hosts, is it renewed? If repair is attempted, and file does not exist locally, then what happens? Would be nice with a small flow diagram that outlines the intended, and currently implemented actions, that are taken at each juncture in the renewal/repair process.
By repair you mean that one or more of the original hosts are offline or no longer have the file?
Yeah, 'repair' happens when a host is no longer online and the redundancy of the file has fallen below some threshold. New hosts will be chosen and the file will be restored to full redundancy.
What happens if the file cannot be repaired? If it can still be retrieved from remaining hosts, is it renewed?
The file will be continued to be renewed as long as there's a minimum amount of redundancy. We'll probably implement it (in 050) so that if redundancy falls below some threshold the client will re-download the file and do proper remote repairs. Not fully sure yet.
Would be nice with a small flow diagram
Hopefully not needed. Ideally the file will repair itself under all circumstances. It'll do local repairs at some low threshold and remote repairs at a much higher threshold. You will run into problems if you don't run Sia often enough though, as Sia can't do any of the renewing or repairing if it isn't running. Right now you'd want to run it at least once a week, as the software matures we're hoping to get that out to 6 weeks or maybe even 12 months.
It's pretty close to priority number one. But it's also a difficult thing to do, at least to do efficiently. With our current erasure coding scheme, the only way to do a repair is to download the whole thing and then begin uploading it again. But Luke is now working full time on renter stuff, we should have a lot more features by Christmas.
A transaction is composed of inputs and outputs. The inputs fund the transaction, and the outputs decide who gets funding (or outputs can fund a file contract).
When you fund a transaction, that money is outgoing from the wallet. That's why the transaction inputs correspond to outgoing money, and the transaction outputs correspond to incoming money. It's a matter of looking at things in terms of the transaction instead of in terms of the wallet.
Locally, all you are keeping is a .sia file. When you delete the file locally, you're just removing the '.sia' file from your renter database. If you've got another copy of the '.sia' file somewhere else, you can use that to share the file or re-import it into your renter database.
The GUI was having issues because 'siad' was unable to connect to the updating server (for the record, that's a bug. The GUI should work even if the daemon isn't able to connect to our update server). If you are planning on using Sia for mining though, I recommend getting acquainted with 'siac' and using the command line. The gui is much less stable than the command line tools.