Yea, looking at it now what @folaht was originally asking for could be feasible with a bit of macros I think and by explicitly adding a version field to the subcommands. But, to me, the issue is that overriding the -v doesn’t make much sense behaviorally. I interpret -v or --version is intended to indicate some version of the compiled software itself.
Since certain safe subcommands delegate to other executables at specified paths, depending on the path of the executable being delegated to, something different will pop out if you point to different paths. Thus, -v doesn’t have behavior that’s specified at compile time, and overriding the -v behavior might even end up being misleading since it gives the impression that the version is statically compiled into the cli binary. This could be even more confusing since some of the commands DONT delegate to the outside binary. Example: Some of the auth commands actively work by launching or killing the authd executable, and some work by only sending remote procedure calls to the daemon. The former relies on the version of authd external executable and the latter relies on the version of cli you’re using (specifically the version of the auth subcommand, but we don’t distinguish between the cli version and the subcommand version since they’re all compiled into the same binary under one version number) .
Example below:
I would posit that this is the expected behavior since its the version that sn_cli is using. It’s the same number since we don’t version our subcommands independently. I’m not saying its not worth fixing, but I’m saying we could retool the command line arguments to make that distinction clearer.
Maybe something like safe node --bin-version, safe auth --bin-version, etc. to indicate that we’re not fetching something “built-in”? The only thing is that changing syntax would require dependencies who already use safe auth version to change, so safe auth version would be deprecated by such a change. But I consider it to be semantically clearer.
In relation to the fact that we don’t version our subcommands, I think it might make sense also to add no_version and AppSettings::DisableVersion to the subcommands to make that clearer (Example here).
This is exactly what I was after in my recent (unsuccessful) attempt , so if this works I’d vote for this, then we have those sub-commands for the bin versions as you suggest. The main issue here is that users just think that -V is for the subcommand too, and that’s what we need to really solve regardless how we allow them to check for those/any other binaries versions.
Unless someone else does it, creating a cryptocoin with the advantages of both Duniter, Safe Network Token and the digital yuan, that is to say a national cryptocoin that will sends it’s newly created coins to it’s citizens. This requires knowledge of the Safe Network Token.
Considering all of this, I currently just want to see the Safe Network work as quickly as possible.
I think I will keep concentrating on bug reporting and look into the unit tests.
I think this is the best advice by far. Aim high, try to make something with the Safe network, and note or solve deficiencies along the way. If the APIs are capable to do what you want, then the APIs are ‘complete’, but they’re probably not and so there’s plenty to polish or add.
Hmm, considering how this topic has come up a few times at various points, I’m wondering if maybe us community contributors can do something or provide resources to lower the barrier to entry for contributions and to ease the “how do I help” question for people.
I’m just spit-balling ideas here. I don’t know if it’s even possible at the current state of the project to keep up such resources in spite of the rate of change of the code, but maybe it’s worth it to brainstorm some ideas on how & if we think this could be done. After that it might be possible to formulate an actionable plan to establish an organized, concerted community effort to, not only create, but maintain resources in the long term for newcomers (of all skill levels) who want to help but don’t know how.
It might be worth it to have that conversation on the regular SafeNet forum though. There are plenty of technical people there who could contribute ideas or volunteer to help, but who aren’t on this forum.
Some examples off the top of my head (I imagine we’d need to limit scope a bit due to manpower, so we can’t do everything, but I’m just imaging some possible options):
A dedicated wiki to describe code aspects beyond what’s mentioned in the primer. Things like general architecture and major functions/data-types that are useful to know on a per-crate basis. There’s function and module level documentation, but something slightly more high-level than that so people know which functions and modules to go to for further info (e.g. describing the messaging and duties systems in sn_node).
Side Note: There was a wiki for sn_api I think a while ago, but I can’t find it now. It also didn’t really cover things from other crates or, perhaps more importantly, give much help regarding the “how do I help” question that we’re trying to alleviate here.
Introducing some way to keep git issues clean (e.g. a bot to remove stale issues)
Coordinating with devs to catalogue major ongoing development efforts (including community and MaidSafe projects) and feature wish-lists
Centralizing ongoing efforts into a single repo/test suite for stress-tests and performance scripts that go beyond unit tests (in the line of what @mav often does).
Others?
All that said there are a TON of unknowns and this is no small amount of work. Is the code finally stable enough to warrant this sort of effort or should we wait for beta or later? How many people would we need to do such a thing? Are there enough interested parties to support this in the long term or is the community still too small/not willing in spite of the recent contribution uptick? Can we ensure all this will be maintained without pulling too much bandwidth away from MaidSafe devs and core development work?
I’ve wanted to toy about w/ a bot for issues eg. I’m not sure how handy it’d be at the moment with us (as you’ve noted), doing a lot off the github piste right now.
I think for such things, if the focus is in the slower moving places (api/cli/nodejs/browser etc), then efforts will be more impactful.
We should most definitely do some issue cleaning there (i’m not sure how the above repos look in general, thogh I know there’s a lot of browser issues and that needs a cleanup).
Coordinating with devs to catalogue major ongoing development efforts (including community and MaidSafe projects) and feature wish-lists
I’m sure we can organise this if it’s helpful. Just a matter of starting and fielding Qs to the right people. I’m happy to try and prod this along if we think it’s useful
Definitely agreed here, that’s probably a good use of time.
Also another idea that I thought of based on issues I see @folaht running into a lot. I wonder if we set up a simple web page or designate a central location for reporting binary compatibility between various versions versions sn_cli, sn_node, and sn_authd. Perhaps we could even automate it
It would save time and eliminate the need for some of support threads that get started when a new release causes a breakage. Not to mention speedier/more organized bug-reporting.
On a related note, it might be a good idea to gather ideas and start a poll on SafeNetForum to gauge interest. I think a handful of volunteers to maintain a wiki cataloguing ongoing projects and provide high-level technical docs as an entry point to development or work on any of these projects. But beyond that, it really would depend on the size/willingness of the community to support some other tangential ideas.
I was thinking bare minimum this has to be documented in the readme. and if it’s there we should be able to extract it (I don’t think there’s any other way to automate it atm.)
Eventually, we should eg, have CLI tests running against node on CI. That’d give us a window into knowing the compatible versions. So perhaps it’s a simple doc/post for now and we try and keep it up to date and move to automation once we have that?
I think it is difficult for those outside of the core team to make changes to the core libs. I understand that people want to help, but there is obviously dialogue going on between team members that may not be obvious to those outside.
If this was a mature product that wanted to encourage outside developers to work on the core, then I would expect lots more effort to open up to the outside world. However, it feels like this is the wrong time for this - there are lots of substantial changes still going in, some of them breaking changes.
Personally, I plan to start looking at what apps and utils can be written to build from the edges of the core. I’d like to integrate with the safe_api/safe_client. For example, one idea is to create a simple MQ, which uses appendable data, but wraps it in MQ terminology and allows easy 2-way connections, standard message formats, easy key choice to send message privately to a consumer, etc.
I’ve noticed that even appending to a sequence via CLI is currently broken (with latest binaries), so even here work is ongoing, but I can see where it is leading and I feel I can be patient. I’m not sure that I would be able to help resolve the issues, as clearly they are being worked on heavily within the team.
Perhaps we could identify some cool utilities and apps that would add value further downstream? Other ideas would be an ecommerce framework, which could work from CLI (initially) and from a browser (using WASM) when possible. Building out the business logic and the data structures will be necessary regardless to core state. Perhaps it would result in some useful libraries on-route too (e.g. to access data more easily, to integrate with payment services, etc).
Just some thoughts anyway. It’s hard to get in the middle of the thick of it when so much is still changing, but there is plenty to do at the periphery (as long as that periphery doesn’t change too much!).
If you want to work with node.js and view.js or similar web frameworks I think you may have to wait until the APIs are updated and stable enough to integrate, but you could still be preparing an app (or demos and tutorials for others) before interacting with Safe Network APIs (e.g. in Safe browser). I did some of this using the old APIs but those demos will need updating for the latest API when that gets updated.
If you want to learn Rust (which I recommend) you could help with the main codebase at some point or right now with something like vdash which would be a good learning project (I no longer have time to maintain it but do my best and can help if you need it).
I cant reply right now on the forum so hoping you will pick this up here
I connected -eventually after deleting an existing ~/.safe/prefix_map and removing all dirs from ~/.safe/node/
but …
willie@gagarin:~$ safe files put 5MB.zip
Error:
0: ClientError: Problem finding sufficient elders. A supermajority of responses is unobtainable. 4 were known in this section, 7 needed. Section pk: PublicKey(0033..599d)
1: Problem finding sufficient elders. A supermajority of responses is unobtainable. 4 were known in this section, 7 needed. Section pk: PublicKey(0033..599d)
Location:
/rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/core/src/result.rs:1914
Backtrace omitted.
Run with RUST_BACKTRACE=1 environment variable to display it.
Run with RUST_BACKTRACE=full to include source snippets.
Keep at it and thank you as always for your hard work, enthusiasm and persistence.
Do we have a bug in that when we have only a few nodes (<7), we get this error msg consistently
Error:
0: ClientError: Problem finding sufficient elders. A supermajority of responses is unobtainable. 4 were known in this section, 7 needed. Section pk: PublicKey(0033..599d)
1: Problem finding sufficient elders. A supermajority of responses is unobtainable. 4 were known in this section, 7 needed. Section pk: PublicKey(0033..599d)
despite the fact that the REAL no of nodes is probably between 4 and 7?
@Neik has three running, I have one (and more to come when I get the AWS security groups right as well as what I can get later with podman locally)and you @folaht have at least one. THen there are the attempts by @JPL and @Josh
I can only see four .
83.163.103.119:12000 through 83.163.103.119:12003 and my own static IP 92.blah25:12000 out of logs sn_node.log.2022-01-05-16 through to -21
How many did we get?
I joined at age 68.
IIRC genesis node is age 256 and then the next node is 96(?) and subsequent nodes are 2 less. So if I was age 68 (96-68)/2 By this possibly flawed logic I was the 14th node so we should have had plenty Elders.
Assuming that the second node is always age 96 but Im sure its something like that. Wish Id stored the old logs outside of ~/.safe though… or I could check this theory
I only got 19.1MB chunks.
I think we need to start with a critical mass of 7+ nodes for future testnets.
All credit to @folaht though, I am looking harder at podman now.
Here is the error I get when running this script as above…
willie@gagarin:~/projects/maidsafe/ELK$ ./sjefolaht.sh
ERRO[0000] error loading cached network config: network "podman" not found in CNI cache
WARN[0000] falling back to loading from existing plugins on disk
Error: error configuring network namespace for container 093f7468bbba0e4df2f3fee7e7a6154a35b93cbda5955ef2ffa01a7bff4bde68: error adding pod troon123_troon123 to CNI network "podman": failed to allocate all requested IPs: 10.0.0.5
Error: can only create exec sessions on running containers: container state improper
Error: can only create exec sessions on running containers: container state improper
1
Error: can only create exec sessions on running containers: container state improper
2
Error: can only create exec sessions on running containers: container state improper
3
Error: can only create exec sessions on running containers: container state improper
4
Error: can only create exec sessions on running containers: container state improper
5
Error: can only create exec sessions on running containers: container state improper
6
Error: can only create exec sessions on running containers: container state improper
7
Error: can only create exec sessions on running containers: container state improper
8
Error: can only create exec sessions on running containers: container state improper
9
Error: can only create exec sessions on running containers: container state improper
10
Error: can only create exec sessions on running containers: container state improper
willie@gagarin:~/projects/maidsafe/ELK$
As you can see I have a bit to learn about podman syntax so I am hoping between us we can crack this.
, so if this works I’d vote for this, then we have those sub-commands for the bin versions as you suggest. The main issue here is that users just think that -V is for the subcommand too, and that’s what we need to really solve regardless how we allow them to check for those/any other binaries versions.
