Alpha
As in Pre-Alpha version; Alpha version of JACS will have an intra-domain scope as well as address allocation over the Ethereum dAPP.
Beside the operation over the major Linux distributions; Alpha version will allow the operation of JACS over latest Windows, MAC-OS operating systems as well as inside containers.
The IDP part of JACS addresses, assigned during the Alpha version, is set as: FC0000 (AFI is: FC and IDI is: 0000; that means geolocation disabled) and the dAPP will assign the DSP part of the address as the case with the Pre-Alpha version (requesting nodes and delegates).
Beta
New Internet Goal
Generally speaking, it is necessary for any change to be deployed in an incremental manner, allowing graceful transition from the current architecture without disruption of service
The ultimate goal of JACS involves transition to a new worldwide Internet which operates much as the current Internet, but with CLNP replacing IP and with JACS NSAP addresses replacing IP addresses.
One way to achieve the intended smooth transition would be to allow a solution, like TUBA to come into play as a transitional step, thus for a certain host in order to initiate communication with another host; the host will obtain a public address in the same manner as it normally does, except that the address would be larger (in our case: JACS address). In the legacy way, the host would contact the DNS server, obtain a mapping from the known DNS name to a public address, and send TCP or UDP traffic encapsulated in CLNP.
As we don’t want to touch the existing Internet, like the need to allow the DNS servers to deal with JACS addresses or maybe the need for Internet routers to natively forward CLNP packets; we are going to depend on blockchain and some other mechanism as will follow.
Also, depending on dual-stack nodes as gateways for JACS enabled domains is not scalable at all. At the end of the day; the ability of a gateway, to handle the increasing traffic from and to its internal domain, is very limited, so the need for another scalable mechanism becomes a must.
Adopters as Enablers
How would a JACS-enabled site access the public internet that is solely and purely based on IP?
In Beta version, the early adopters of JACS, will be allowed to avail their powerful nodes distributed around the globe, hence become enablers for JACS solution.
One critical requirement for any offered node, though, is to be a powerful ‘dual-stack’, meaning that it supports both JACS and IP natively.
Then comes the real value (what is in it?); that is to incentivize these enablers with JACS tokens.
On the technical side; we must tunnel the JACS traffic from a JACS-enabled site all the way through the Internet, to terminate on one of the offered nodes, from where it could get translated to access the public services. The procedure is somehow identical to how VPN services work nowadays.
Depending on the community for a viable solution, will allow the maximum adoption as opposed to the non-incentivized approaches like traditional transition plan (for example RPKI); where we saw how only one tenth (1/10) of the total Class-C subnets owned are being protected by the RPKI
Innovative ways exist on how to tunnel JACS traffic over the public Internet all the way to the enablers’ nodes, and the good news is that blockchain is the control part of all of these ways.
Allowing blockchain to perform all the control plane functions of layer-2 tunneling techniques, while keeping the tunneling technique itself untouched, perfectly achieves the goal.
Last but not least for the Beta version; the IDP part of JACS addresses, assigned during this version, is set as: FD0000 (AFI is: FD and IDI is: 0000; that means geolocation disabled) and the dAPP will assign the DSP part of the address as the case with Pre-Alpha and Alpha versions
