nice one! cool stuff - this could become and awesome music player! =)
http://dir.random.safenet
=> excluding default templates
http://app.ghost07.safenet
http://a.random.safenet
http://blog.riddim.safenet
http://example.ghost07.safenet
http://eye.eye.safenet
http://frabrunelle.safenet
http://frostbyte.safenet
http://hello.safenet
http://ithanium.safenet
http://marble.play.safenet
http://me.too.safenet
http://oldhold.southside.safenet
http://pacman.safenet
http://polpolrene.safenet
http://safe.share.safenet
http://the.best.safenet
http://the.teapot.safenet
http://this.is.safenet
http://web.chunky101.safenet
http://yvette.safenet
pirated the bay http://pirate.savage1.safenet
I wonder there is an issue for user experience, following dust that can be created by failure, which then prevents a user fixing any fragments of failed creation of accounts or upload.
Failure to create publicID; directory; or file, doesnât allow retry.
Beyond that, my experience of this Stable Droplet network has been really good. No other issues to report.
I just now logged into the account for http://test.bluebird2.safenet after an interval of five days and the website came straight up. So thatâs very strong evidence for an improvement in data retention with this version of the vault.
To which I shall add that beyond not losing any of my accounts, Iâve also not seen any issue with any website.
http://dir.random.safenet
=>
http://app.ghost07.safenet
http://a.random.safenet
http://blog.riddim.safenet
http://example.ghost07.safenet
http://eye.eye.safenet
http://frabrunelle.safenet
http://frostbyte.safenet
http://hello.safenet
http://ithanium.safenet
http://marble.play.safenet
http://me.too.safenet
http://oldhold.southside.safenet
http://pacman.safenet
http://pirate.savage1.safenet
http://polpolrene.safenet
http://safe.share.safenet
http://the.best.safenet
http://the.teapot.safenet
http://this.is.safenet
http://web.chunky101.safenet
http://yvette.safenet
A thought occurred about the nature of the beast⌠that I wonder is worth putting out thereâŚ
Building a network that can work, is something; building a network that cannot fail, is another.
So, understanding the real limit of the networkâs ability to meet challenges, and different types of challenge, is important. Obviously that is where the testing in different ways, becomes most important.
Such questions to be resolved then as: Does the network properly accommodate âneverâ events?.. where those events do occur what error does the user see? Are the limits of the network declared? Is the user aware of the state of their data?.. eg dust that isnât obvious, getting in the way; failed uploads etc⌠does the validation work and make apparent the state of data? Where there is failure, how is that managed? - considering an event where each element fails, how do the otherâs respond? etc
These are interesting problems and I am very impressed at how well Maidsafe is approaching all this.
man, I made this really cool game and i keep trying to upload it to the droplet network but canât for the life of meâŚ
farthest I got was 78% on one of the triesâŚ
really want ppl to see it lol i think itâs pretty cool
Now it just keeps Going from 0% To âfailed to make directoryâ
If itâs above 4MB. or so it will fail. If itâs a lot of small files, above 33 files will be blocked as well.
Ok thanks Iâll try to downsize while still being functional
Well I took out all the audio and got it down to 9 files total, but still:
Whatâs the size of the biggest file? Is it above 4MB?? And how much together? Should be below 100MB.
For now, donât try overwriting an existing directory - or one that had been tried. Might not be obvious but a failed upload appears to block further attempts with that error atm.
Just for some clarity, forgive this long post:
âTotal of 100MB cap per client accountâ isnât maybe the best way to state the current cap. Itâs actually âTotal of 100 PUT operations per client account(not POST or DELETE or GET)â This is where its set in code
Now why Iâm stating this as a difference is cos, say when you create an account, that translates to 1 PUT of StructuredData
and this is tiny (well SD itself can only get to 100KB before it gets broken down further). Now if the client goes onto creating 99 more SD even at max size of 100KB, after this point they would be getting LowBalance
error. In this scenario theyâd have only stored roughly 10MB before hitting the cap. If the 99 PUT of SD was smaller, then the total would ofc be much smaller than even this 10MB could even be a few KB.
Now with ImmutableData
, we got SelfEncryption
in play, so say we created an account which made us store a SD and then we upload a single 98MB file, we know with the current MaxChunkSize set at 1MB weâll get 98 Immutable Data chunks and 1 SD DataMap
which each need a PUT operation in the network. Now this would all succeed and PUT operations past this would start failing with the same LowBalance
error. In this case however we would have stored about 98MB + tiny bytes of account SD + DataMap SD before reaching the client cap.
Now these are extreme cases, in reality add in folders(not just ones created by user but also stuff like root directory listing and app sandbox folders and then yes ofc folders created by client apps)/dns-records/public-id and we got more SD we store at varying sizes but factors into the PUT operation count. similarly for SelfEncryption
if the file weâre storing is between the MinChunkSize and MaxChunkSize weâll still end up with 3 ImmutableData chunks and thereby 3 PUT operations. less than MinChunkSize does some more funky stuff but should result in just 1 PUT operation Iâd think.
Overall, the number of PUT operations donât hold a strong bearing on size and can change based on the use-case. Before we go into the âThen why use PUT operations to limit client storage?â discussions, Worth of-course noting this is merely a current test feature. When Safecoin features are implemented, thatâd be serving as the limiting factor to check if a client storage operation can be allowed or not instead of some magic number being set in code.
Saying this, for now while we donât have Safecoin implemented in code, I think @Krishna_Kumar is looking at some options to present a visual status in Launcher of how close an account is getting to itâs storage cap(with safecoin it can still serve the same purpose in a different way based on safecoin availability with the account). This info also needs a âsmallâ amount of work in Vault code to return that info to clients which it currently doesnât yet do. So that hopefully helps a bit than having to calculate the number of PUT operations weâve done so far in some other way like grep "Sending PUT Request" Client.log | wc -l
Try community1 for a comparison (pm me for the port). It is testnet3 binary so data doesnât last but it might complete your upload at least and we can see the game for a while.
Yeah I figured. I learned to give it a brand new name every time I tried uploading it again.
Still nothingâŚ
Keep trying, always with different names but always this same error after showing 0% for a quick second
Different names but the same login credentials?
Yes. Now trying deleting all the log files etc and making a new account and trying that.
2% now!!!.. success???