You’ve never had to deal with obfuscated code then. Easy to understand intent and readability is important.
I think it’s great that you’ve changed the name from “vault” to “node”.
Calling it anything other than “node” creates an unnecessary differentiation. Since the word “node” already exists for describing the concept, there is no reason to use any other word.
However if the application wants to call it “vault” or whatever, sure I guess. I personally don’t see the reason because I think “node” explains more accurately what it is, but then again, I don’t know how a regular person who doesn’t know what a node is thinks.
Overall, I think it’s great that you’re taking the time to think through naming and things like that. I think the fact that you’re actually thinking about these things is far more important than what things actually end up being called since there rarely is a truly correct way to name something.
Assumptions are a weak route to proving a point.
Consistency is important; also, simple flux is a good route to making robust code. The devs are skilled enough to know what they are doing and due some respect for what they prefer to do.
That may be true but your response only indicates to me that the assumption was correct.
The first lesson you learn, is that errors follow from assumptions…
I welcome the move from vault to node. Ascribing network-like behaviour to something called a ‘vault’ never felt right when @polpolrene and I were writing the Primer, and we often ended up using ‘vault’ and ‘node’ interchangeably. But I think at a UI level the term vault should remain, at least as an option if not the official name, because it describes the secure storage of data very well and is much more visual and concrete than node.
What about the change in prefix from ‘safe_xxx’ to ‘sn_xxx’? I can’t be the only one that had such a stomach turning visceral reaction?
P.s. I like node too. I recall a conversation with neo a couple years ago when he told me to stop calling them safe nodes, and instead I need to refer to them as safe vaults.
safe_ is prettier and generally I’d agree that more explicit naming is better, but if ‘safe’ typically has another meaning in this context then I understand why the decision was made.
But does it have a different meaning in this context? I don’t think so. The intent is to have safe and secure node code for the Safe Network. Devs naturally attracted to the development of safe and secure code for the promise of a safe and secure perpetual Safe Network is who you want to attract. This is a bold project, I really can’t understand the change…
I really appreciate the work put into the naming standardization. Thank you, team!
(FWIW, I also happen to like “node” better than “vault”, especially since I imagine we might be sharing not only hard drive space but e.g. processor power too in the future.)
Well I can’t see anything about “safe” in the Rust naming conventions https://github.com/rust-lang/rfcs/blob/master/text/0430-finalizing-naming-conventions.md . Would be interesting to know where this issue arose.
Not as of yet, but we want to move from any misleading names like safe where devs might think save_vector is one that never fails. Luckily we don’t have too many reverse deps so yanking might work. Where we have generic crate name like lru_time_cache we keep it like that with no sn_ name.
safe_ vs sn_(safe network) doesn’t bother me much. Nbd there. I welcome the vault to node adjustment because safe network “node” very well could one day be much more responsible than just sharing files around. Who knows what it will turn into long after this network is potentially made.
Keep grinding, looking forward to something innovative and new to play with once the refactoring is done and nodes can communicate p2p w newer protocols.
Sometimes I am curious if this project could have been developed much faster leveraging existing open source webservers such as nginx or apache and running those locally and bootstrapping them w custom functionality such as lua w nginx(openresty) or other tooling for apache(im not a big apache fan so dunno there). Maybe this was long debated years ago early in the project though . Can’t say I fully comprehend how the hole punching and discovery and how all the networking would work there with localhost web-servers communicating remote with other actors in a p2p network but I imagine its possible.
Much love, thank you!!
I like the new name node versus vault. More generic so in the future with the nodes doing more stuff will be less confusing. As it’s under the hood anyway, won’t be a point of confusion for users IMO. If it were me though I’d have gone camel-case and moved it around like this: nodeSN (lol)
It’s purely the English meaning of safe, it is not secure access for everyone, it’s the opposite of dangerous. So devs seeing a package called safe_XX assume the XX is somehow made safe, secure, etc. and possibly cannot fail. They won’t think that safe means for the Safe Network.
Worth noting though, the tags/labels we will have Safe Network, etc. so the safe network will still be something we can search for and get all crates, like maidsafe atm.
I had made peace with the prefix changes on github, but in all honesty the follow-up statement above now has me totally confused. It would appear to be a change in messaging. Since I started following the project a few years ago, my interpretations of the language, descriptions, homonyms, and word play used around the project and SAFE acronym have been intentional and part of the Safe Network brand. I do not believe I was alone in this interpretation.
The English word ‘safe’ has many meanings, that’s what makes it so darn clever for this project. In the context of this project and our heretofore use of the term I’ve interpreted it as referring to something that is “protected” more so than “not dangerous”.
This has all been part of the allure and promise of the Safe Network: a globally distributed network of data vaults (a ‘vault’ is a synonym for a ‘safe’) so a network of safes that offer a new internet where client data and privacy has been “made-safe by MaidSafe” through secure communications and a true keep the data safe not the server approach, a perpetual/permanent web concept that keeps our collective public history safe, a new cryptobased payment system that is safer and easy enough for average Joe and Jane to use, a one time payment for data uploads that ensures your data is safe in perpetuity for the life of the network, the way that the network ensures it’s users are safe from censorship, how they’re safe from corporate data mining, how users are empowered to keep their own data and personal information safe through personas and self authentication, the safeness that emerges from true online privacy, security, and freedom.
Maybe I’ve misinterpreted things again, so please correct me if I’m wrong. Forum posts are not always the easiest form of communication. I have been a diehard supporter here since the first day I joined, no the first time I viewed some whiteboard presentations on YouTube, so it is not easy for me to make such a fuss so openly in a weekly dev update. There is no mal-intent, just complete and utter bewilderment at the possible change in tone/messaging/vision/ideals/confidence.