Add basic near-sdk-go documentation

[vlmoon99]

In this pull request I added basic docs for Near SDK GO (https://github.com/vlmoon99/near-sdk-go)

0.Quick Start
1.Basic Anatomy
2.State (Storage)
3.Environment
4.Transfers & Actions
5.Cross-Contract Calls

[bucanero]

hello @vlmoon99 , thanks for the PR

We are going to test out the Go SDK and the steps you provided; if we find any issues, we'll ping back so we can clarify how to use this new SDK.

[vlmoon99]

@bucanero I’d like to ask you to test it again — I’ve released a new version of the SDK and a new version of the CLI, and I’ve also updated the documentation. If you run into any issues, feel free to reach out to me on Telegram: @vlmoon99, or on X (Twitter): @vlmoon99.

[bucanero]

Hello @vlmoon99 , I was able to test and build contracts using the Go SDK with no issues by following the proposed quick-start guide. 👍

Here are my comments and suggestions after testing the SDK and tools:

Reviewing the near-go CLI, I found that it's embedding the near binary (from the Rust CLI) into the Go binary. I see it as a security concern for developers using it.

• There's no support for macOS on Intel x64
• You can't ensure that the latest near (rust) CLI is being used, because it will be the version/binary bundled when you installed the near-go CLI. So even if you have the latest near (rust) CLI, when you use the near-go it might end up using an older /different version.
• You'll be forced to do a release even if you had zero changes on near-go when near CLI gets updated, or the Go CLI will stay behind with the embedded binary.
• (Security concerns) A compromised version by a bad actor could have a trojan near binary that simply acquires all your private keys, and then sends them somewhere, or a rootkit or malware of any kind. On the user perspective it would look like the regular near (rust) CLI running, but it could be a custom-made weaponized version.
• Missing clear instructions on how to build the near-go CLI from source code. (Updating the README.md on the Github repo should be enough for developers who want to build the CLI app from source and propose changes)

Some suggestions / ideas:

• remove the near binary embedding; the near-go can still execute the commands with the user's installed near CLI (you can state that installing near CLI is a requirement, and it needs to be in the PATH environment variable)
• keep the near-go CLI as a tool for building/testing Go contracts only ( either remove extra commands like deploy or call, or print out how the user should call the original near CLI)

Not a critical issue, but while testing I found that some near-go CLI commands need to run inside the contract folder, instead of the project-name folder. Maybe you can support both cases, or check if there's a contract folder somehow?

Happy to chat about Near Docs if you want to join or Telegram channel https://t.me/neardocscg 👍

[frol]

There's no support for macOS on Intel x64

@bucanero Which exact component does not support MacOS x64?

@vlmoon99 Would it be too hard to add MacOS x64 pre-built binaries for near-go CLI? Is it just a matter of a couple of lines in https://github.com/vlmoon99/near-cli-go/blob/main/build.sh?

You can't ensure that the latest near (rust) CLI is being used, because it will be the version/binary bundled when you installed the near-go CLI. So even if you have the latest near (rust) CLI, when you use the near-go it might end up using an older /different version.

@bucanero It is the same situation with cargo-near - it embeds near-cli-rs as crate dependency of some specific version. This ensures compatibility of the cargo-near / near-go tooling with the underlying implementation. There is no need to ensure the latest version of near CLI as we only use the small subset of it anyway, and it is pretty stable overall.

You'll be forced to do a release even if you had zero changes on near-go when near CLI gets updated, or the Go CLI will stay behind with the embedded binary.

@bucanero Not until there are relevant changes - for example, when new signing methods are added or more deployment options appear.

(Security concerns) A compromised version by a bad actor could have a trojan near binary that simply acquires all your private keys, and then sends them somewhere, or a rootkit or malware of any kind. On the user perspective it would look like the regular near (rust) CLI running, but it could be a custom-made weaponized version.

@bucanero There are so many other things can go wrong here that it is pointless to discuss this treat. If your concern is that the near-go will be compromized to have a malicious near-cli-rs, there is nothing the "non-embedded" near-cli-rs can do about it. near-go CLI already has access to the system, so it is already a game over regardless of whether near-cli-rs is embedded or not.

Missing clear instructions on how to build the near-go CLI from source code. (Updating the README.md on the Github repo should be enough for developers who want to build the CLI app from source and propose changes)

@vlmoon99 I see the build.sh script in the root of the CLI repo, but it would be indeed great to improve the README to make it helpful and first prioritize those who will use the tool, and second those who will want to go deeper and only then those who will contribute. Currently, it is quite the mix and the other way around:

[vlmoon99]

@frol @bucanero I update near-go cli docs, add mac x64 bins + improve scripts for setup and build repo