You can follow the instructions here to create an account with test-coins and then try uploading files (:
Hey @Vort!
Yea, I think the link is dead, I am not able to reach the site. If you can re-upload it somewhere it’d be nice (:
Deleted- Filebin | npwlbpx63uaa2l2p
-
WDfiles — файлообменник бесплатный - загрузить файл
Maybe you can say which free hosting is better to use?
filebin worked for now
Maybe you can say which free hosting is better to use?
I usually use mega.nz (:
So from the initial looks of it, it seems like your node has been primarily suffering from MissingSecretKeyShare
error. Not sure if this is the case for all Prefix(10)
nodes, they do seem to get requests from their elders.
Another interesting thing here is that, node-to-node messages are the ones suffering from MissingSecretKeyShare
, whereas towards end of the log file, messages from the section itself are passing clean. Either way, we have a good starting point to look into this now. Thanks for the logs @Vort
Problem: I’ve been unable to upload or cat anything for a few days now. I can safe auth status
and see my Safe is unlocked, but cat or upload just sits there forever with no output or error message. In the past it either worked or gave an error after up to four minutes.
In the mean time I’ve put my laptop in suspend a few times, so maybe that has messed with things. Looks like @Blindsite2k has the same issue though still maybe it’s not me.
Question: if I kill my node and rejoin, does it retain anything or start from scratch?
It will
- Try and rejoin with same name
- Be relocated to another section with age/2 (or min age == 5)
- Will store any data it has locally stored (as it has NetworkAuthority we can do this with no cost)
It should anyway. Perhaps @yogesh can let us know if 3 is currently in place? (I Suspect we need to complete that)
Being cruel here, but what happens if
- multiple nodes try to rejoin with the same name - I can guess first come first served?
- or how easy/hard would it be for a parasitic node to replace s good node, if the parasite keeps trying to join as an existing valuable node (having obtained it’s name and secrets) and the existing node goes down long enough to lose its place?
Yup, we retain the data if we still have our db files(here).
Yip first come. It means somebody stole your keys or you gave them.
It’s the same thing really, somebody has stolen your keys or you gave/copied them. If the node comes back it’s age is 50% (so put far back in trust).
However, on relocate, @yogesh are we storing all data again to the network? We can then delete it as it’s of no use to us, but we need to make sure we stored it first.
We do not reset data on relocations, instead we start a new counter for space which leaves the older data as junk. Data does get replicated though, and are stored in the network even if we get relocated, so we are cool there. Raised an issue (here) for the same.
Is there still point to try to join as a node? Do you Maidsafe folks expect to gather some valuable information still? Or is there something specific you would like us to try?
I’m also thinking about uploading stuff in order to create demand for nodes, but I don’t really have any reasonable files on my Linux machine. Is there some easy way to create files of random data?
Adjust to fit…
That’s just because you are missing the --self-auth
flag. Why is this flag needed? you need to think of the purpose of authd, which is to act as the apps keys/permissions management app for the user, any app requiring access to the network on behalf of the user it’s requesting it through authd, but authd first needs a Safe to be unlocked by the user to be able to authorise apps and provide them with a keypair. This is why you potentially want to only unlock a Safe on authd without self-authorising, then any other app you had could start self-authorising. It’s confusing now that there is only the CLI app, once we have the Snapp (which includes an authd GUI), browser, etc. then it should be clearer.
I know we are looking at some issue related to a bad calculation on storage cost after a split, so perhaps that’s the root cause of these type of “not enough funds” incorrect errors some of you are seeing. I think we need some additional logging to confirm this, so we’ll have to check that as well. Thanks @davidpbrown
Ah… I’m one for jumping in and not rtfm… so, perhaps the abc needs an update for this as just hopped through those
doesn’t suggest that flag.
I’ll have a closer look later and the difference this makes. thanks
I think I have found a bug. When trying to dowload a file, for example:
safe cat safe://hygoygykdytfkxqmdazdgsrubwi5cozmuysaajupww9yoa7kh6zg4uejrbe > lazydog.jpg
And when lazydog.jpg
already exists, it should overwrite it, right? Instead it gets truncated to 0 B a and the safe cat command never finishes. Deleting the file and then downloading again works fine. OS is Linux (Manjaro).
Just to clarify on this, once the CLI has been self-authorised, i.e. it has been given a keypair with balance it can spend on write operations, the authd is not needed and not used anymore by CLI, you can even stop/kill it and keep using CLI. Authd is only needed for authorising apps like CLI, once that’s done CLI connects to the networks directly all the time for all read and write operations.
Problem: having not been able to download/upload for days - commands just sit there and never exit - I’ve done the following:
safe auth restart
# Check auth status: no safe unlocked
safe auth unlock --self-auth
# Enter secret/passphrase
# Check auth status: safe now unlocked
But the result is the same. The following was reported as working quickly 35 mins ago:
safe dog safe://hygoygykdytfkxqmdazdgsrubwi5cozmuysaajupww9yoa7kh6zg4uejrbe
and
safe cat safe://hygoygykdytfkxqmdazdgsrubwi5cozmuysaajupww9yoa7kh6zg4uejrbe > ~/Downloads/lazydog.jpg
But both are just sitting there for me. Is anyone else seeing this?