A Kaspa networking experiment achieved something that normally demands router configuration: two private nodes connected automatically through the barriers created by typical home networks. The feature now works on devnet, Kaspa’s development network, after repeated testing and adjustment.
That result could make running a reachable node easier for people who cannot or do not want to configure port forwarding. But during August 2 to August 9, the work crossed only the first major threshold. Its developer is now asking volunteers to test a source-built branch under real mainnet conditions, where the diversity of routers and network setups will provide a much harder test.
Meanwhile, SilverScript moved closer to its first stable release, although its pre-release audit continued to produce breaking changes.
The week in one minute
- Automatic TCP connections between private nodes behind home routers are now working on devnet. Mainnet testing is requested, so this remains experimental rather than production-ready. Source
- The networking prototype aims to remove the need for manual peer-to-peer port forwarding in at least some home setups.
- SilverScript received several breaking changes as its developer audits the compiler before version 1. More small syntax changes may still emerge. Source
- One SilverScript pull request was merged, while the compiler’s lower-level output target may be renamed from
scripttobytecodeto avoid confusion. Source - Neither the networking prototype nor SilverScript’s remaining naming and syntax questions should be mistaken for a finished release.
The big story: A devnet connection escaped the port-forwarding maze
Imagine installing a node at home and discovering that other computers cannot initiate a connection to it. The software is running, the internet works, and yet the router stands between the node and the outside world like a receptionist who will not accept unannounced visitors.
The usual workaround is port forwarding: manually telling the router which incoming traffic should be sent to the node. That can be inconvenient, unfamiliar, unavailable under some internet providers, or simply undesirable for people who want software to work with minimal network administration.
This week, Luke reported that automatic TCP hole punching between private or NATed Kaspa nodes is working on devnet after “many more rounds of testing and tweaking.” TCP is a standard way for computers to maintain reliable internet connections. NAT, or network address translation, is the router mechanism that lets multiple devices share one public internet address while hiding their individual addresses.
Hole punching tries to help two devices behind such barriers establish a direct connection by coordinating their outgoing traffic. The metaphor sounds more violent than the operation: no router is physically or permanently opened. The nodes attempt to create compatible network paths using connections initiated from inside their respective private networks.
The practical promise is straightforward. A person running a Kaspa node behind an ordinary home router might be able to participate in peer-to-peer networking without configuring a public port first. That could reduce setup friction and make nodes easier to connect across a wider range of households.
The important word is “might.”
The prototype has demonstrated the behavior on devnet, where developers can experiment without treating the result as established main-network software. Luke has updated a public development branch and asked testers to try it on mainnet, Kaspa’s live network, preferably from behind normal home routers with peer-to-peer port forwarding disabled. Testers must build the branch from source and are encouraged to enable detailed diagnostic logging. Source
That request marks the experiment’s next test. Home networking equipment varies enormously, and a method that succeeds between controlled test nodes may encounter different router policies, timeouts, firewall behavior, or provider restrictions in ordinary use. The archive does not yet report mainnet results, broad compatibility, a merge into the main codebase, or a release.
For developers: The test branch is rk-with-tcp in Luke’s rusty-kaspa repository. The requested debug configuration covers the libp2p and connection-handler components, which should help reveal where connection attempts succeed or fail. The request specifically targets source-built mainnet runs without existing P2P port forwarding.
The week’s achievement is therefore real but bounded: automatic TCP hole punching is working on devnet. Whether it can become a dependable improvement for ordinary node operators now depends on evidence from less predictable networks.
What else moved forward
SilverScript is nearing version 1, and stability is now the hard part
SilverScript’s push toward version 1 produced a burst of changes, including multiple warnings that updates would break existing code. A breaking change alters behavior or syntax in a way that may require current users to update their programs.
The archive does not describe the contents of those changes, so their exact effects cannot be assessed here. What is clear is their timing: Ori said the work was being driven toward version 1, then later explained that the code was under audit before that release. Source
An audit at this stage is a close examination for inconsistencies, overlooked cases, and design choices that could become expensive to change after users begin relying on a stable interface. Finding disruptions before version 1 can be healthy. It is cheaper to correct an awkward rule before it becomes a compatibility promise.
At the same time, repeated breaking changes create uncertainty for early adopters. Pull requests 193 and 194 were each announced as breaking changes early in the week, followed by another such notice for pull request 206 on August 9. The Telegram discussion does not explicitly say that all three were merged, so they should not be presented as completed releases. Source
When Michael Sutton asked whether the latest update would be the final syntax change, Ori said no additional changes were expected but left room for small revisions if the audit exposes edge cases. Source
For builders, the message is clear: SilverScript is converging, but its syntax is not yet guaranteed to be frozen.
One merge landed, while other changes remain less certain
Not all of the week’s SilverScript activity was prospective. Ori explicitly reported that pull request 138 had been merged. Source
The archive provides no description of what that pull request changes, so the responsible conclusion is limited: the merge is confirmed, but its practical impact cannot be inferred from the discussion alone.
That distinction matters during a fast pre-release cycle. “Discussed,” “submitted,” and “merged” describe different levels of completion. A link to a breaking pull request shows active work; an explicit merge announcement shows that a change entered the project’s shared code history. Neither automatically means a stable version has been released.
A small naming debate exposed a larger usability problem
The compiler’s lower-level output target is currently called script, but SilverScript itself is the higher-level language. Ori proposed changing the target name to reduce that ambiguity, with asm and bytecode as the candidates. Source
Bytecode is the compact, low-level instruction form produced for execution by a software machine. Assembly, often shortened to asm, usually refers to a human-readable representation of low-level instructions. IzioDev reasoned that bytecode might be more direct if the target converts expressions into bytecode, and Ori said that was also the preferred option. Source
This is more than cosmetic tidying. When one project uses “script” for both a high-level language and a lower-level compiler target, documentation, commands, and error reports can become needlessly confusing. A clearer name would help users understand what stage of compilation they are working with.
Still, the discussion records a preference, not a confirmed final decision. No message in the archive announces that the rename was implemented or merged.
What is decided, and what is not
Completed or confirmed
- Automatic TCP hole punching between private or NATed nodes is working in devnet testing after multiple rounds of adjustment. Source
- A public
rusty-kaspatest branch has been updated and made available to prospective mainnet testers. - SilverScript pull request 138 was explicitly reported as merged. Source
- SilverScript is being audited in preparation for version 1.
Proposed, experimental, or still unanswered
- TCP hole punching has not yet been shown in the archive to work reliably across varied mainnet home-network configurations.
- The networking branch has not been reported as merged into the main codebase or released for general use.
bytecodeappears to be the preferred replacement for the compiler target namescript, but the archive contains no final implementation announcement.- SilverScript’s syntax may still receive small breaking changes if the audit uncovers edge cases. Source
- No version 1 release was announced during the covered period.
What happens next
- Watch for reports from mainnet testers using ordinary home routers without manual peer-to-peer port forwarding.
- Look for evidence about which router and network configurations allow or prevent automatic TCP hole punching.
- Watch whether the networking experiment advances from Luke’s public branch toward review or integration.
- Follow SilverScript’s audit for any final edge cases that require syntax changes.
- Look for a confirmed compiler-target rename and, eventually, an explicit SilverScript version 1 release announcement.
This week’s most promising result removed a networking obstacle in a test environment, not yet in the full variety of the real world. The next meaningful step is not another claim that the connection works. It is a collection of mainnet tests showing where it works, where it fails, and whether home node setup can genuinely become less of a router puzzle.