Update 8th August, 2024

Most of the action this week has been behind the scenes, particularly staging our release process so we can formalise updates more smoothly. For example, we may decide to have community testnets using the official release candidates prior to a final release. No promises but we may find that’s a good option. You can see the improvements made to the current RC here .

We’ve also been redesigning the Launchpad UI so that it gives more valuable information, to help people work out if their nodes are functioning properly or not, and whether they are earning nanos. As you know, the way the network ensures good performance is by shunning bad nodes. A node could be “bad” due to a temporary loss of bandwidth, such as someone in the house starting up a multiplayer online game, or for VPN users it could be that the shared tenancy has become overloaded at the provider end, or it could be too many nodes on one machine choking things up, a lack of memory, disk space, or an overloaded CPU. The new-look Launchpad will enable users to check node health and key metrics at a glance.

For those happy with parsing log files, the string to watch out for that indicates a shunning is consider us as BAD.

If nodes have been shunned, or are otherwise behaving badly, the best thing to do is to reset (Ctrl-R) and start again with fewer nodes. If that works, you can add a few more at a time.

For those who haven’t seen @jimcollinson’s latest video, this will be 1 min and 44 seconds of your precious time very well spent. You’ve all heard the maxim: “not your keys, not your coins.” It’s true, but what we really should be saying is: “not your keys, not your data.”

General progress

@rusty.spork has been his usual helpful self over on Discord, as well as soaking up the occasional bit of user angst. Still some issues with people not receiving nanos, possibly those using the Launchpad primarily. This could sometimes be due to nodes getting shunned by others. We are building visibility for that into the Launchpad UI now.

Some good news from @bzee who has been conferring with the libp2p guys. Apparently an outstanding issue with libp2p’s Autonat in combination with QUIC is not an issue anymore, so we’ll be getting that integrated in forthwith. The libp2p refactor adds an option to dial from a different port than which we’re listening on. This is important for both TCP with port reuse and QUIC (which uses the same port by default). Reusing ports facilitates hole punching.
However, accidental hole punching was causing nodes to come to the wrong conclusions about nodes being reachable. This transport redesign paves the way for a next version of AutoNAT.

More good news, @mazzi reports significant progress with the Launchpad redesign, with better application flow and improved UI and options for users. It’s all looking very nice.

@dirvine is leading a review into code bloat. As he says, for every thousand lines of code there will be three bugs. As things change it’s easy to leave legacy code in the codebase, and every so often we need to go in and have a good old clean up.

And together with @dirvine, @joshuef is leading the foray into GetRange land. Briefly put, this is a way of ensuring a Sybil actor is not able to place multiple nodes close to a chunk of data and thereby block access to it.

@chriso has been focused on getting a new release candidate for the network up and running. A RC is a minimum viable product that is ready for testing before a proper release.

@qi_ma raised a PR to resolve the corrupted wallet issue caused by forced termination of the upload process.

@roland found a bug in the safenode-manager where we are currently setting a port range even if we’re starting a single node, e.g. 13000-13000, which fails. You can now manually specify the metrics, node and RPC port when running a local network.

And @mick.vandijke has been doing some deep diving into self-encryption and chunking. He finally managed to understand what was going on when some files only upload one chunk instead of the minimum of three. The reason for this is when all chunks are identical (possible for very small chunks) only one gets uploaded. The data map will then need to know how many times that chunk needs to be repeated.

57 Likes

First…let me hope…

17 Likes

Seconds now to read

14 Likes

Third third third

16 Likes

May the fourth be with me!!

17 Likes

Ha! :ok_hand:

12 Likes

Great news, keep up good work. :grinning:

13 Likes

Thanks so much to the entire Autonomi team for all of your hard work! :muscle: :muscle: :muscle:

And good luck to everyone trying to earn beta rewards! :four_leaf_clover:

13 Likes

This is still unclear to me.
Reset after a how many occurrences of seen as bad.
Being seen as bad ‘times out’ right?

I find it super confusing.

14 Likes

One step at a time :tada:

11 Likes

This all sound great, thank you team for bringing us closer to launch :rocket:

10 Likes

May we get a hint on what shunning rate (per hour/24h or so) can be considered a well and healthy node and what rate would indicate a unhealthy node…?

I’m tracking occurrences of exactly the suggested string for weeks now but didn’t manage to come to a useful indicator for node health so far…from @Josh s comment I interpret he’s having a similar issue…
(I didn’t manage to completely get rid of shunning so some level seem just seems to be expected…but I’ve never seen the numbers rise before I felt uncomfortable with increasing the node count further due to system resources starting to get exhausted or recognising a decrease in responsiveness … )

9 Likes

me three im looking forward to it being in the metrics as well :slight_smile:

6 Likes

Same, been tracking it for ages. Being seen as bad is almost expected at this point, everything appears to continue as normal.

Honestly if I saw no occurrences of bad I would think that I have a problem :joy:

12 Likes

Thx 4 the update Maidsafe devs

:clap: :clap: :clap:
Keep coding/hacking/testimg super ants

5 Likes

Unfortunately there is no formula for this. There are a number of factors that determine if its a problem.

The issue is that your node relies on connecting to enough peers to get good connections.

Thus it depends on

  • how long does the shunning nodes remain online
  • how many new nodes have inserted themselves between your node and the nodes that shunned you
  • When those restart they will be in a new place and no longer shunning anyone the moment they restart
  • when your node is really in a bad way the shun message rate will be small, perhaps almost zero since your node is not getting the messages since its bad.

Basically the node being shunned has to determine if it can talk to the essential peers in its neighbourhood. This is the real metric to determine how bad off your node is. And this has to consider that it may have been shunned but the shun message did not reach it.

Hopefully the team have set up the health metric to be one where the node is active in checking it is talking to its neighbourhood still in a healthy way. The number of shuns or rate of shuns is a very poor metric to use.

And remember the worse off your node is the less of the shun messages it will actually see.

11 Likes

All of which means the OP is misleading, which I think is what @Josh finds confusing (and me too).

8 Likes

In the last week the only person in discord who has said their launchpad usage results in anything working properly is @JimCollinson . People come in saying they are not earning and often its launchpad people, well mostly, and there is another who just posted in discord about running launchpad and not earning for some days.

@Dimitar who has incredibly been helping dozens of people says that of those (>20) running launchpad, none have earned.

I tested it here on a device that was earning with port-forwarding (did reset then run launchpad) and there was an initial flurry of activity as the node started then nothing, the nodes were running, launchpad says all fine (running) but bandwidth monitor showed no traffic, zip, nothing from the nodes after the initial flurry of traffic. Somehow the nodes are not working with the relay nodes and I checked that the flag was set in the json file.

Its not a perhaps a problem with using launcher but a systematic problem since the upgrade.

Thought you needed to know

14 Likes

Works for me too.

8 Likes