First up, this script is not really suitable for distribution due to the data required to make it work in a suitable fashion. (millions of records)
The help that I am seeking is for people to supply a peer ID for me to test.
Background
Given a target node, specified by its 52 character ID, the script will reach out to it and request a quote from it.
This gives the ability to confirm the node is able to receive requests for quotes across the Autonomi network. From this, one can be reasonably certain that the target node is capable to earn as well.
Reliability - It is not guaranteed to be able to contact the node. But the larger the (static) data used by the script is the better chance it has to contact the node. It should have zero problems with a network of a million nodes at this time, and I am building the data file further. This is something I would love to have up on Autonomi as an App since Autonomi could host the data as well.
Drawback - the user cannot check their own node due to the issue I posted about in Support where hairpin routing is rarely available/enabled in routers.
Operation is basically using a chunk that is as close as possible to the node’s XOR address and use the client to attempt to upload the chunk. The client will also be trying to upload 2 other chunks, but they are ignored in determining if the target node responded.
By using the standard client there is standard communications used ensuring proper operation. It is the static data that allows a suitable file to be used to attempt to upload.
If the node runner is running something like vdash showing the store cost, then the fact a quote was given will cause vdash (or similar) to see a quote was given by the node.
Sure, give these a go : I gave the same thing a go a few months ago and the results weren’t great, heavily dependent on where you peered in the network to what you could see. Also the getQuote function would randomly flick between peer-id’s with a distance which wasn’t the closest to the xor address, so will be interesting to see what you get.
Yep, can see the requests coming in
Records have some variance : I include Storage / and Token Transactions in the number of records so maybe why my REC: is greater in some cases ?
Storage Cost is correct, uptime is correct, forward balance (FB) looks correct as well.
Yes the number of records stored is greater than the number of records your node is responsible for. The /metrics shows both values and vdash should show the records your are responsible for.
So are you able to extract the multi-addr from libp2p yet looking for the ‘p2p-circuit’ identifier, so we can get stats on how many peer’s are routing via a relay nodes ?
would be really interesting to be able to expose those stats.
(That one with the 25 x 1 nano payments is a bit of an oddity. I’m not complaining - it just seems odd considering how even this network is. Unfortunately that site will be going down forever at the end of this month so even if the earnings would have continued I won’t get them.)
I cant cut n paste from the node launchpad, but feel free to give it try
here is the image of these 5 home safenodes,
Its a good service for sure, probably should be added to the client to query some SC Dapp running in a VM attached to a blockchain overlay as part of some overall DEX , which in theory is possible , checkout Spiderchain for some ideas in this regard, although it is UTXO on BTC stuff …
Yes some oddities.
Thank you for helping and also @Jadkin thank you as well.
Only need one or 2 more to see this as a success. Shouldn’t need that much testing as the basic principle is straight forward. The real testing is making sure the script doesn’t fall over or make mistake in working out xor address & file contents to use.
@JPL The chunks I am uploading for your nodes are closer than any of the other closest nodes to that xor, so my script is saying those nodes cannot be reached by clients
which in theory is possible , checkout Spiderchain for some ideas in this regard, although it is UTXO on BTC stuff …
