Build apps, run nodes from you’re apps and … well have some fun and help us get the API’s simpler and smoother as we go. (the last part will never stop happening )
just install via pip install XXX
Here’s how to run a node for instance
pip install safenode
from safenode import SafeNode
import os
initial_peers = [
"/ip4/142.93.37.4/udp/40184/quic-v1/p2p/12D3KooWPC8q7QGZsmuTtCYxZ2s3FPXPZcS8LVKkayXkVFkqDEQB",
"/ip4/157.245.40.2/udp/33698/quic-v1/p2p/12D3KooWNyNNTGfwGf6fYyvrk4zp5EHxPhNDVNB25ZzEt2NXbCq2",
"/ip4/157.245.40.2/udp/33991/quic-v1/p2p/12D3KooWHPyZVAHqp2ebzKyxxsYzJYS7sNysfcLg2s1JLtbo6vhC"
]
# Create and start node
node = SafeNode()
initial_rewards_address = "0x1234567890123456789012345678901234567890" ### CHANGE THIS TO YOUR WALLET
node.run(
rewards_address=initial_rewards_address,
evm_network="arbitrum_sepolia",
ip="0.0.0.0",
port=12000,
initial_peers=initial_peers,
local=True,
root_dir=None,
home_network=False
)
# or change root dir etc. as you wish
## or see internals of routing table
def demonstrate_network_operations(node):
print_section("Network Operations")
try:
# Get routing table information
kbuckets = node.get_kbuckets()
print("\nRouting table information:")
for distance, peers in kbuckets:
print(f"Distance {distance}: {len(peers)} peers")
for peer in peers[:3]: # Show first 3 peers at each distance
print(f" - {peer}")
except Exception as e:
print(f"Network operation failed: {e}")
Seems like a good day today. @dirvine has delivered what many have been waiting for and we are now >30000 network size mostly from home IIUC.
Download speeds are good and while from my small 40 node PoV it seems attos are slower than before, they are still trickling in to my three wallets.
I’d like to suggest the Registers API is given some loving care by someone [cough] who understands what it is supposed to provide. I’m updating my awe demo for the new APIs and having to make some changes to the API.
Some minor ones to uploading of directories to add a little flexibility and efficiency I’ll submit as a PR.
But the Registers API has lost the ability to do very much. It has been reverted to a current value(s) with no access to history. I can fix that for myself by maintaining a fork of the API, but it would be best if the API itself was designed for either some use cases involving history, or to re-expose the MerkeReg itself so client apps can do this for themselves.
Either that or give a clear statement that history is no longer a goal for the network, at least for the time being.
Both Register and Transactions are on my radar here. My big use though is friction. We had an issue where we needed ENV vars to build and we got rid of that. Now the initial peers and bootstrap nodes need to be invisible to users. We should be able to pass a node address to bootstrap off of in emergency, but apart for that nodes and clients should be caching those to restart from their cache. So that has to go 100% for sure.
Then the data Interface needs a realignment into one area where we have all data types and their operations clearly identified with tests and examples. That is not massive work, but absolutely needs done and the team must focus on that part of rework, it’s very tiny code wise but huge for devs and uses of the API. The team are way more than capable and I am hoping beyond hope the python APIs allow the team to see very easily and first hand where the friction is and remove it immediately we see it.
So a few bits of brushing and cleaning up but I am 100% with you @happybeing We just need to have some focus here, it won’t take long at all, but as the team have nodes pretty stable here and are still measuring and tweaking we must focus on uses of the network from a utility perspective.
We will get there quicker now I hope as folk can just do a Jupyter notebook and show exactly what fails and why etc. So I hope this eases us moving forward much faster.
These are the magic words I want to hear! as a core Internet utility for humanity is what I hope we can reach
Now if only I could convince you to at least add temp data in addition to permanent data!! – starting with temp data going onto the roadmap at some point in the future - doesn’t have to be before Jan.
I know, I’m being a selfish slave driver here … but I just want what I think will really open the doors up for a lot more use-cases and vastly more users – as well as greater network stability.
At this stage, it’s just a whole lot of cluelessness and a whole lot of code that I got to read to exactly understand what the Replit agent did. This is why I welcome attos, will give us a lot of room to not make costly mistakes when testing.
Yeah this is cheating, but 2 years from now maybe we’ll all have our coding assistance…