Thanks for answering all my questions.
And if you guys keep the restrictions away then it will be eternally cooler!!
Thanks for answering all my questions.
And if you guys keep the restrictions away then it will be eternally cooler!!
Yay! Until there’s an installer for safe_client, this should all work with building it ourselves per instructions from the repo, correct? https://github.com/maidsafe/safe_client
Update : after starting the 4th vault window the uploader also freezes and system remains unresponsible when I close this extra vault:)
In case of churn (node joining or leaving an existing network holding data) event, the current vault implementation relies on routing to complete a proper account/data transfer.
However, due to the re-planning of sprint targets, the feature to support such is no longer part of the scope in this sprint for routing, which results in an in-proper cleanup of account/data in case of churn.
There is already a quick patch on vault level to resolve this issue, however it is still under discussion whether to merge it into master, as such patch will be a slightly divert from our main approach.
we probably wouldn’t need a dedicated installer for safe_client. Currently if you wanted to try the self_authentication example, then yes you will need to build that crate to get the example to run it against the network We will also be releasing prebuilt binaries of the various examples from the rust modules, so then even this wouldnt need to be “built”. Once App launcher gets sorted(future sprint), it should expose the functionality currently exposed by the example and should make this library a core client authentication library.
Worth noting that even now prebuilt binaries attached as part of the dns_example uses the same functions but just hides the self_auth feature by creating a temporary(random pin,keyword,pass) id to showcase the feature of the example - nfs & dns.
Great stuff guys, things are starting to take shape here ![]()
“It will also allow poisoning of the close groups with one way connectible nodes (no NAT traversal)”
What does this mean? If a node says hello but does not respond, why would the network do anything but ignore it and continue on happily?
Then another question: i do not see any activity on the vaults if not uploading anything. Is the proof of storage checks not implemented yet or do they also rely on unfinished layers?
I’m just speechless
But thank you to the SAFE devs (really really really thnx4 yor hard work) and everybody else who is here…
Felicitation to @shona & family ![]()
I’m going to play on this new playing ground & have fun ![]()
Amazing work!
A big thank you to all the developers behind this!
Great
to the team! This is really great work. And of course all best wishes to @shona!
What if I don’t finish an address with a .txt or a .html? Will it grab the index.html when I make safe:polpolrene ?? Could I make a blog under that address without pointing it to safe:blog.polpolrene?
The default service name is www … so
<1> safe:some-domain will fetch you index.html of service www in some-domain
<2> safe:www.some-domain will fetch you index.html of service www in some-domain
<3> safe:blog.some-domain will fetch you index.html of service blog in some-domain
<4> safe:some-service.some-domain/some-file.html will fetch you some-file.html of service some-service in some-domain
<5> safe:some-service.some-domain/some-file.exe will fetch you nothing if there is no some-file.exe in service some-service in some-domain - In this case the browser will indefinitely try to get it … you’ll have to cancel that tab (atleast for this iterations - might be timers and time-outs in the next, but not decided completely)
Further some-file for the sake of the back-end core code is the exact filename. It doesn’t matter if there is extension or not, it has to be the exact complete name. If however it is wanted to default to .html extension or something like that then that needs to be coded by the front-end apps. This would be confusing in some cases though if you have both some-file and some-file.some-extension in the same place. Then you need logics like if you cannot fetch some-file then try some-file.default-extension etc - but that’s frontend’s domain (what ever the app devs want to do).
Well done team, and thank you. You are amazing us! Wish I wasn’t in the middle of laying a floor!
Congratulations @Shona, and even more well done. You had the much tougher task! Wonderful inspiring news, amazing timing too. ![]()
I believe it is fair to say that a lot of work is being done in-house. The collaboration of crust with routing should bring us a few steps closer to (decentralised) cross-protocol NAT-traversal. I am sure @dirvine and @Peter_Jankuliak and @vinipsmaker will want to share much more off their work here soon ![]()
When you run a vault, you are providing a service to the network: it requires that the network can reach you to rely on that service. So you might be able to connect to the network with your vault, and the testnet (run on droplets) might be able to connect to you, but also another community-members vault needs to be able to connect to your vault. It is mostly that last step that has the final bits of work going into it.
The network follows an asynchronous, reactive design: currently there is not enough external (by clients and users) activity that probes your local network. The primary design is that overall usage produces the right amount of “energy” to scan and validate all content; more usage, more content to validate, more validation checks. This is already there when you do a get request, and will be further expanded upon with the implementation of safecoin farming
If you want to run multiple vault in the same terminal and don’t really care about the RUST_LOG:
“./safe_vault_linux &” and it will run in the background (You will be able to count how much you can open in the same time). Be careful to not do it quickly, after opening some it take time to initialize your next one and use a lot of CPU and cores to start up.
Thanks to the team to let us play a little before the true release.
Awesome stuff today, can’t t wait till I’m done @ work and try it myself @ home…
just a side note
as i just found out the safe-DNS is case-sensitive (so www.riddim is not the same as www.Riddim) I perfectly like it but it and it opens so many possibilities for website-naming! but it might cause confusion amongst windows users who are not used to this ![]()
little “bug” report - it allows you to publish urls like “www .test” and "www.test " (emty space) both cases hang FF while trying to acces.
Thanks for reporting
Will make a note definitely. Thanks Again