commit - 0ba0b62272524052a6446d9539773756fc2320d2
commit + fa19bf8240bbc41ef72f730f1471b64877e41b73
blob - /dev/null
blob + bbb4e23c1d842c8089c22b5859f017d2b4fc09c5 (mode 644)
--- /dev/null
+++ wiki.d/9.FNS
+version=pmwiki-2.3.20 ordered=1 urlencoded=1
+agent=w3m/0.5.3+git20230121
+author=jrmu
+charset=UTF-8
+csum=
+ctime=1692464686
+host=38.87.162.8
+name=9.FNS
+rev=3
+targets=
+text=(:title Request For Complaints #1:)%0aInter9 Engineering Task Force%0a%0aFile Name System (FNS)%0a%0aFNS is designed to replace the centralized domain name system with an alternative that can easily be federated and defederated.%0a%0aThe namespace is divided by the delimeter / like pathnames in a filesystem:%0a%0a[@%0aFNS path | DNS equivalent%0a====================+===================%0a/shelltalk/jrmu/www | www.jrmu.shelltalk%0a/cloud9p/mkf/mail | mail.mkf.cloud9p%0a/com/google/www | www.google.com%0a@]%0a%0aEach FNS server keeps track of its own entries (files and subdirectories) as well as a pointer to its parent, .. in a relative path system. It is analogous to how the UNIX filesystem works, where each inode contains listing of its own files/subdirectories and its parent ..%0a%0aIn the above example, /cloud9p/mkf/mail, / root handles the records for cloud9p; cloud9p handles the record for mkf; and mkf handles the record for mail. FNS queries are distributed in the same way that traditional DNS queries are handled.%0a%0aWhat makes FNS unique is that there is no concept of an absolute root, and there are no hard-coded root servers. Instead, to find root, clients must query the parent node .. recursively, until .. points to itself.%0a%0aBy definition, a root node is one where the .. entry points to itself. Because there are no official roots, there can and will exist multiple roots. Any node can declare itself a root simply by pointing its .. entry to itself. The lookup to root always involves recursively querying .. until the root is reached.%0a%0aPathnames are all relative and can be moved at any time moved to a new location in the hierarchy, or even a new root. To change the position in the FNS hierarchy, simply change the .. pointer to a new address. This ease of changing parent directories is designed to make it easy to switch FNS root nodes.%0a%0aBecause of the absence of hard-coded root servers, there are no absolute%0apaths, and any given FNS node only keeps track of its children and immediate%0aparent.%0a%0aEach FNS server chooses where it wants to join the hierarchy, namely, which / root it wants to belong to. It is possible to defederate from this / root and choose a new / root (a chroot FNS split).%0a%0aIn general, users will prefer to have fewer / roots in order to prevent confusion, for simplicity and ease of use. However, because pathnames are relative, it is possible and relatively easy for FNS nameservers to fork. A node simply needs to declare itself as root by setting the .. pointer to itself; and persuade other nodes to set their ... pointer to the new root. This forking mechanism allows forks to take a large chunk of the namespace with them, to deter an abuse of power from / root.%0a%0aEven though there are multiple roots, it is possible for one root to refer to another.%0a%0aFor example, consider the scenario where ircnow and ircnever both run their own separate, independent FNS roots. Suppose a user is connected to shelltalk, a subdirectory of the ircnow network. He would still be able to lookup and resolve the name turtlespeak on the ircnever namespace:%0a%0a/shelltalk/../ircnever/turtlespeak%0a%0aThe shelltalk user would first query .. to get to ircnow's / root, then query%0aircnow's / root to get the address for ircnever, then query ircnever to get%0athe address for turtlespeak.%0a%0aAlthough the two nodes, ircnow and ircnever, are independent roots, they can%0arefer to each other as children inodes with pointers, making it possible to%0aconnect to independent networks.%0a%0aIn the event of conflicts between networks, ircnever may choose to "sanction"%0aircnow by removing its directory listing, and ircnow may likewise remove%0aircnever's directory listing. The users within each respective network can%0astill resolve FNS entries within their own network, but can no longer resolve%0aon enemy networks. Resolving disputes can result in the restoration of broken%0alinks.%0a
+time=1692466206
+title=Request For Complaints #1
+author:1692466206=jrmu
+diff:1692466206:1692466182:=54,55c54%0a%3c on enemy networks. Resolving disputes can result in the restoration of broken%0a%3c links.%0a---%0a> on enemy networks. Peace will result in the restoration of broken links.%0a
+host:1692466206=38.87.162.8
+author:1692466182=jrmu
+diff:1692466182:1692464686:=50,54c50,54%0a%3c In the event of conflicts between networks, ircnever may choose to "sanction"%0a%3c ircnow by removing its directory listing, and ircnow may likewise remove%0a%3c ircnever's directory listing. The users within each respective network can%0a%3c still resolve FNS entries within their own network, but can no longer resolve%0a%3c on enemy networks. Peace will result in the restoration of broken links.%0a---%0a> In the event of conflicts between networks, it may ircnever may choose to%0a> "sanction" ircnow by removing its directory listing, and ircnow may likewise%0a> remove ircnever's directory listing. The users within each respective network%0a> can still resolve FNS entries within their own network, but can no longer%0a> resolve on enemy networks.%0a
+host:1692466182=38.87.162.8
+author:1692464686=jrmu
+diff:1692464686:1692464686:=1,54d0%0a%3c (:title Request For Complaints #1:)%0a%3c Inter9 Engineering Task Force%0a%3c %0a%3c File Name System (FNS)%0a%3c %0a%3c FNS is designed to replace the centralized domain name system with an alternative that can easily be federated and defederated.%0a%3c %0a%3c The namespace is divided by the delimeter / like pathnames in a filesystem:%0a%3c %0a%3c [@%0a%3c FNS path | DNS equivalent%0a%3c ====================+===================%0a%3c /shelltalk/jrmu/www | www.jrmu.shelltalk%0a%3c /cloud9p/mkf/mail | mail.mkf.cloud9p%0a%3c /com/google/www | www.google.com%0a%3c @]%0a%3c %0a%3c Each FNS server keeps track of its own entries (files and subdirectories) as well as a pointer to its parent, .. in a relative path system. It is analogous to how the UNIX filesystem works, where each inode contains listing of its own files/subdirectories and its parent ..%0a%3c %0a%3c In the above example, /cloud9p/mkf/mail, / root handles the records for cloud9p; cloud9p handles the record for mkf; and mkf handles the record for mail. FNS queries are distributed in the same way that traditional DNS queries are handled.%0a%3c %0a%3c What makes FNS unique is that there is no concept of an absolute root, and there are no hard-coded root servers. Instead, to find root, clients must query the parent node .. recursively, until .. points to itself.%0a%3c %0a%3c By definition, a root node is one where the .. entry points to itself. Because there are no official roots, there can and will exist multiple roots. Any node can declare itself a root simply by pointing its .. entry to itself. The lookup to root always involves recursively querying .. until the root is reached.%0a%3c %0a%3c Pathnames are all relative and can be moved at any time moved to a new location in the hierarchy, or even a new root. To change the position in the FNS hierarchy, simply change the .. pointer to a new address. This ease of changing parent directories is designed to make it easy to switch FNS root nodes.%0a%3c %0a%3c Because of the absence of hard-coded root servers, there are no absolute%0a%3c paths, and any given FNS node only keeps track of its children and immediate%0a%3c parent.%0a%3c %0a%3c Each FNS server chooses where it wants to join the hierarchy, namely, which / root it wants to belong to. It is possible to defederate from this / root and choose a new / root (a chroot FNS split).%0a%3c %0a%3c In general, users will prefer to have fewer / roots in order to prevent confusion, for simplicity and ease of use. However, because pathnames are relative, it is possible and relatively easy for FNS nameservers to fork. A node simply needs to declare itself as root by setting the .. pointer to itself; and persuade other nodes to set their ... pointer to the new root. This forking mechanism allows forks to take a large chunk of the namespace with them, to deter an abuse of power from / root.%0a%3c %0a%3c Even though there are multiple roots, it is possible for one root to refer to another.%0a%3c %0a%3c For example, consider the scenario where ircnow and ircnever both run their own separate, independent FNS roots. Suppose a user is connected to shelltalk, a subdirectory of the ircnow network. He would still be able to lookup and resolve the name turtlespeak on the ircnever namespace:%0a%3c %0a%3c /shelltalk/../ircnever/turtlespeak%0a%3c %0a%3c The shelltalk user would first query .. to get to ircnow's / root, then query%0a%3c ircnow's / root to get the address for ircnever, then query ircnever to get%0a%3c the address for turtlespeak.%0a%3c %0a%3c Although the two nodes, ircnow and ircnever, are independent roots, they can%0a%3c refer to each other as children inodes with pointers, making it possible to%0a%3c connect to independent networks.%0a%3c %0a%3c In the event of conflicts between networks, it may ircnever may choose to%0a%3c "sanction" ircnow by removing its directory listing, and ircnow may likewise%0a%3c remove ircnever's directory listing. The users within each respective network%0a%3c can still resolve FNS entries within their own network, but can no longer%0a%3c resolve on enemy networks.%0a
+host:1692464686=38.87.162.8
blob - /dev/null
blob + 6a7196649737d68ce25336d9c2a5cbbf41281506 (mode 644)
--- /dev/null
+++ wiki.d/9.IP
+version=pmwiki-2.3.20 ordered=1 urlencoded=1
+agent=w3m/0.5.3+git20230121
+author=jrmu
+charset=UTF-8
+csum=
+ctime=1692488983
+host=38.87.162.8
+name=9.IP
+rev=2
+targets=
+text=The best alternative internet involves an overlay network on top%0aof IP, by encapsulating IPv4 inside IP (basically IPSec).%0a%0aOnly slight modifications need to be made to IPv4.%0a%0aThe fundamental problem is that the Internet address space is controlled by by a single government agency (ICANN).%0a%0aTo prevent one single central authority from controlling the entire Internet, each autonomous system should have the ability to splinter and form its own separate internet. In place of one single Internet, there would exist multiple parallel internets.%0aEach autonomous system becomes truly autonomous, able to%0aleave or join an existing internet.%0a%0aThe advantage of encapsulating IP is that this overlay network benefits from%0athe packet-switching design of IP which overlay networks like Tor lack. For%0aexample, IP routing is highly optimized for latency/bandwidth, unlike the%0aconvoluted routing methods taken by tor. The low latency makes it suitable%0afor multimedia applications and heavy traffic.%0a%0aBy design, IP packet switching is more suitable for evading censorship of%0aVPNs, because encapsulated packets can easily route around censored nodes.%0a%0aEncapsulated IPv4 is familiar, predictable, and well documented. Existing software can be reused with virtually no modifications. The extra complexity of IPv6 is likely unnecessary given that the focus is on the free user community, which does not begin to approach 2^32 hosts.%0a%0aThis overlay network will allow users to host from home, since they can be assigned static IP addresses with proper reverse DNS networking. Their location and identity is also obscured by one extra layer of indirection.%0a
+time=1692489355
+author:1692489355=jrmu
+diff:1692489355:1692488983:=20,23d19%0a%3c %0a%3c Encapsulated IPv4 is familiar, predictable, and well documented. Existing software can be reused with virtually no modifications. The extra complexity of IPv6 is likely unnecessary given that the focus is on the free user community, which does not begin to approach 2^32 hosts.%0a%3c %0a%3c This overlay network will allow users to host from home, since they can be assigned static IP addresses with proper reverse DNS networking. Their location and identity is also obscured by one extra layer of indirection.%0a
+host:1692489355=38.87.162.8
+author:1692488983=jrmu
+diff:1692488983:1692488983:=1,19d0%0a%3c The best alternative internet involves an overlay network on top%0a%3c of IP, by encapsulating IPv4 inside IP (basically IPSec).%0a%3c %0a%3c Only slight modifications need to be made to IPv4.%0a%3c %0a%3c The fundamental problem is that the Internet address space is controlled by by a single government agency (ICANN).%0a%3c %0a%3c To prevent one single central authority from controlling the entire Internet, each autonomous system should have the ability to splinter and form its own separate internet. In place of one single Internet, there would exist multiple parallel internets.%0a%3c Each autonomous system becomes truly autonomous, able to%0a%3c leave or join an existing internet.%0a%3c %0a%3c The advantage of encapsulating IP is that this overlay network benefits from%0a%3c the packet-switching design of IP which overlay networks like Tor lack. For%0a%3c example, IP routing is highly optimized for latency/bandwidth, unlike the%0a%3c convoluted routing methods taken by tor. The low latency makes it suitable%0a%3c for multimedia applications and heavy traffic.%0a%3c %0a%3c By design, IP packet switching is more suitable for evading censorship of%0a%3c VPNs, because encapsulated packets can easily route around censored nodes.%0a
+host:1692488983=38.87.162.8
