I need a pointer here please. I am working my way through the codebase and just need one thing

Support
1

I hope someone who has been through this can save me much time searching.

Having spent some time looking at the code base following various paths I am wanting now to compile the code base that would work on the current network. I want this to make sure I am building the modules correctly.

The github says I need to change the defaults for the keys. It then says github secrets ???

Is there somewhere I can get the keys necessary to run the code. I assume I have no need for private secret keys, but the public keys for node and sending tokens etc.

Where would be best to find these so i can set them when compiling the code.

Thank you to whomever can help

3 Likes
2

I asked this in the following topic which didn’t get a response, so I opened an issue which didn’t get a response, so I asked Rusty who got me an answer, which I quoted in the issue, which is linked at the bottom of the OP below:

Not exactly frictionless or encouraging of app developers.

PS the API will be done this month :thinking:

6 Likes
3

Don’t worry, it took me like 4 days to get a build working against the Beta network :laughing: and then a further 7 days to expose the Libp2p raw swarm, any one would think they didn’t want us in the code yet :stuck_out_tongue: remembering that my rust knowledge is like zero…

I’m building from Visual Studio, having to use the C linker for rust, and the Windows 10/11 SDK else I’ve not been able to get a traceable debug build out.

I’m currently setting “global” environment variables on my dev box using “edit the system environmental variables” from system properties - avoid a whitespace at end, else rust will panic and you will spend ages trying to find out why :wink:

building against “stable” currently has the below system wide environmental variables set - VS is meant to be able to pass a config.toml with a [env] block to set compile time environment, but it completely ignored them…;

FOUNDATION_PK = 84418659a8581b510c40b12e57da239787fd0d3b323f102f09fae9daf2ac96907e0045b1653c301de45117d393d92678
GENESIS_PK = 8829ca178d6022de16fb8d3498411dd8a674a69c5f12e04d8b794a52ab056f1d419d12f690df1082dfa7efbbb10f62fa
NETWORK_ROYALTIES_PK = 8c027130571cea2387a0ceb37c14fec12849015be1573ea6d0a8e4d48da2c1fbe2907ae7503bb7c385b21e2d7ac9d6ff
PAYMENT_FORWARD_PK = 8c2f406a52d48d48505e1a3fdbb0c19ab42cc7c4807e9ea19c1fff3e5148f3bbe53431ec5a07544aaeef764e073e4b2f

you will need a custom launcher, I’m using in my launch.json;

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "type": "lldb",
            "request": "launch",
            "name": "Debug executable 'sn_peek'",
            "cargo": {
                "args": [
                    "build",
                    "--bin=sn_peek",
                    "--package=sn_peek",
                    "--features=network-contacts,network-httpd,network-trace"
                ],
                "filter": {
                    "name": "sn_peek",
                    "kind": "bin"
                }
            },
            "args": ["dht","--peer","/ip4/<removed>","--network autonomi-beta"],
            "cwd": "${workspaceFolder}"
        }
    ]
}

you will need to tweak the executable name, bin, package - you can use the --features comma separated to enable from cargo.toml - and can pass arguments through in the args, comma separated.

in the cargo.toml if you want to build against the stable crates, you will need to change the dependencies from linking to ../sn_network version=...…

sn_client = { version = "0.109.0" }
sn_logging = { version = "0.2.31" }
sn_protocol = { version = "0.17.6" }
sn_peers_acquisition = { version = "0.4.1" }
sn_networking = { version = "0.17.1" }
sn_registers = { version = "0.3.16" }
sn_transfers = { version = "0.18.9" }

also in the cargo.toml if using vs, then you can get the pdb debug files including; (obviously, if you were going to publish a release build, remove the debug)

[profile.release]
debug = true

[profile.dev]
debug = true
6 Likes
4

Can I ask where you found the keys?

off to do more reading

Thank you both

4 Likes
5

Would be nice to have that info highlighted in a topic called “How to build an Autonomy app in Visual Studio”.

I’m just using the CLI and VSCode in Linux. Haven’t even tried using a debugger - I’m just printing messages to the terminal.

Good to see another developer getting stuck in @Jadkin, and opening useful issues.

And you too @neo, I don’t know what took you so long, especially as you and I don’t have that much time left :rofl:

6 Likes
6

I got it to compile and hit a road block of it cannot find peers. LOL guess the file location is not in the github coding

7

You need to enable “network-contacts” macro in the features in cargo.toml so something like…

[features]
default = ["network-contacts"]
local-discovery = [
    "sn_client/local-discovery",
    "sn_peers_acquisition/local-discovery",
]
network-contacts = ["sn_peers_acquisition/network-contacts"]

Then make sure in code you include;

use sn_peers_acquisition::PeersArgs;
use sn_client::*;
use bls::SecretKey;

#[derive(Parser)]
#[command(author, version)]
struct Opt {
    #[command(flatten)]
    peers: PeersArgs
}

then parse the command line args, which will populate with Maidsafe peers.

let opt = Opt::parse();

opt.peers will be bootstrap peers to use

so you can,

 let bootstrap_peers = opt.peers.clone().get_peers().await?;
 println!(
      "Connecting with {} bootstrap peers",
       bootstrap_peers.len(),
      );

const CONNECTION_TIMEOUT_SECS: Duration = Duration::from_secs(60);

let client = Client::new(SecretKey::random(), bootstrap_peers, Some(CONNECTION_TIMEOUT_SECS), None)
        .await?;
5 Likes
8

I had simply downloaded the peer file and used SAFE_PEERS env value

1 Like
9

or you can do that :smiley:

3 Likes
10

It dies after a number of minutes. So it connects get PUTs then dies.

Well this is a tomorrow problem and in my case tomorrow maybe next week now

2 Likes
11

A good way to start out is with a known good example so you will know it’s not your code or how you are building.

You could start with the sn examples but I’m not certain they have been maintained.

There always awe but I don’t think that’s what you want and a bit more involved to build anyway.

So maybe try the examples and open an issue if the README instructions don’t work. Once you have one of those working you have a good model of how to build something that connects.

3 Likes
12

It worked fine and participated in the network storing data till some event triggered a error in a 3rd party package.

It was an error from another project so I am guessing there is some issue crept in there. I didn’t change anything so its all Maidsafe code and other packages they connect to. Anyhow will get into it later, have other things that need to be done now and the project to put 50 watt lasers on shark’s heads is coming up sometime soon. Oops not shark’s heads but in machinery, they wouldn’t let me use sharks

EDIT: and I also considered it could be another env value they use when compiling the code. They do not seem to include all this in the github (eg the peers file location)

1 Like
13

I had crashes in one of the network libs (quic?) and opened an issue for it a while back. What’s interesting is I’ve never had that with local testnets. Yes, the docs are out of date. I don’t see the latest plan as realistic or a healthy situation tbh. Have fun with the lasers, sounds cool. FYI, a few years ago I knew a guy who’s business was selling laser cutters which was called Sharks with Lasers or similar.

2 Likes
14

So sorry you guys are battling against the current here. I will try and see what we can do and bring it up internally.

The secrets part @neo is seeing is likely CI/CD stuff. That is all magic to me and very very complex (release path). Building local nodes should not involve any of that stuff.

13 Likes
15

You’re a breath of fresh air David!

8 Likes
16

Cheers Mark, Chris is gonna check in on this one. He has it :muscle:

5 Likes
17

I’ve opened issues for most if not all these things so they should be in the system.

I’m nearly finished adding some options to interrogate registers using awe which will make testing and reporting that easier, although the issue I filed is already easy to replicate. I thought it might go away after the network stabilised but it continues (getting different versions of a register when sync’ing #issue 2030).

4 Likes
18

This should be kinda OK. The client on read should merge these (they all merge be design) and repost back to the nodes. This is maybe not documented but should be. The CRDT approach specifically allows this and sigs ensure it’s secure.

3 Likes
19

I’m sorry about the problems people have had here.

It definitely is the case that if you want to build safenode, or safe, to connect to the current public beta network, you do need to define these environment variables with the keys.

Clearly this applies to developers, but it would also apply to people who wanted to build safenode from source to connect to the public network.

The documentation needs to be updated for both of those things, to include the keys. As it is currently, it makes reference to our own release process, and Github Secrets. That isn’t really necessary and I think has also been the source of some confusion here. Those references should be removed.

I will see about doing this. I’m not sure exactly when, but I will do it as soon as I can.

7 Likes
20

I’m not sure that’s it. The is all from one client doing sync, modify, sync and has never happened with a testnet.

When I use sync now to get that register I get different results each time - just repeating the same sync (get) of the register, sometimes 2 entries, sometimes 12 entries (which is correct).

1 Like