What can I do to help?

General Beginners
1

I feel like I’d only get in the way if I want to help with coding or if I finally start to understand the code and be able to work a bit on the project, it’s already finished.

Are there any easy things to do?

3 Likes
2

It’s funny you just posted this. I just posted about this exact same thing on the safenet forum myself.

Seems to me, there are a good number of easy things, but they’re not documented due to lack of bandwidth/different focuses. Finding things to do, for me, has been a question of “try to hack my binary to make it do something cool” and then along the way stumble on bugs and fix them as I go. That’s my method at least.

Perhaps us, as community members, would be well-served by also participating in the bug-finding/triage process. Unfortunately, right now, that often boils down to “stare at the code until the bugs/refactors jump out at you.” That’s in general, not efficient, and I think that the biggest barrier to contributions right now is the minimum knowledge of the code required to help is rather high.

Idk though, anybody else have any thoughts on this.

4 Likes
3

Are you capable of fixing this issue?

That’s still going on.

[folaht@pjehrsohmehj safe]$ safe -V
sn_cli 0.19.0
[folaht@pjehrsohmehj safe]$ safe node -V
safe-node 0.19.0
[folaht@pjehrsohmehj safe]$ safe auth -V
safe-auth 0.19.0
[folaht@pjehrsohmehj safe]$ safe networks -V
safe-networks 0.19.0

It should be printing…

[folaht@pjehrsohmehj safe]$ safe -V
sn_cli 0.19.0
[folaht@pjehrsohmehj safe]$ safe node -V
sn_node 0.26.16
[folaht@pjehrsohmehj safe]$ safe auth -V
sn_auth 0.1.0
[folaht@pjehrsohmehj safe]$ safe networks -V
sn_cli 0.19.0
1 Like
4

Hmm, I’ll take a look at it and come back to report on it :+1:

Seems @bochaco tried once a bit ago, but ran into a snag with it. Granted he’s also got a bunch of other things to take care of, so maybe he just ran out of time also. He mentioned it’s governed by structopt, but maybe we can work some macro or pre-compile magic. We’ll see.

5

Yes, this is the case, I tried a couple of times but didn’t succeed, last time I’ve tried was recently and I just added a command for authd: $ safe auth version (that’s already in v0.19.0). But it’ll be good if anyone fixes it, I was looking at structopts doc and trying several things but no luck, so it’s a good one to fix, this’s been always confusing for people.

1 Like
6

@folaht is there an area that specifically interests you?

the lower level libs (especially node as @Scorch pointed out in the other thread), and more difficult to get into + changing a lot. higher level / API etc is more stable…

We used to (back a good while when there were more folk), try and pick out issues and label them for potential community contribution etc. Back then though there wasn’t much of that going on. Hopefully as things settle somewhat, we can get back to doing this.

w/r/t API, even firing in with desired features or bugs on github/issues is helpful I think.And then we can look to offer pointers / ideas on what might be achievable.

2 Likes
7

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).

The final set of commands might be:

safe --version
sn_cli 0.19.0

safe node --bin-version
sn_node 0.26.16

safe auth --bin-version
sn_auth 0.1.0

safe networks --version
Invalid

safe auth --version
Invalid

safe node --version
Invalid

Idk, thoughts?

Forum meta note

@moderators This sorta turned into two conversations, maybe spin the part having to do with --version into its own thread?

2 Likes
8

This is exactly what I was after in my recent (unsuccessful) attempt :smiley: , 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.

9

In that case, maybe this’ll do the trick. I opened up a PR that implements such a scheme here :grinning_face_with_smiling_eyes:

3 Likes
10

My interests in a nutshell:

  • Running a node on the safe network
  • Creating a website and several apps on it.
  • 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.

3 Likes
11

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.

3 Likes
12

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?

2 Likes
13

Some great ideas here.

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 :+1:

Good ieas. keep em coming! :clap:

2 Likes
14

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 :thinking:

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.

2 Likes
15

Yeh that’d be great.

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?

1 Like
16

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!).

2 Likes
17

I am an experienced Node.js Vue.js developer with zero knowledge of Rust. Is there anything I can help with at this point?

1 Like
18

I think there are quite a few possibilities.

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).

Welcome and good luck.

1 Like
19

Ahhh… I remember this thread.
I’m now doing an installation guide for ARM servers + podman containers as a start.

2 Likes
20

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.

2 Likes