1 fa19bf82 2023-08-21 jrmu version=pmwiki-2.3.20 ordered=1 urlencoded=1
2 fa19bf82 2023-08-21 jrmu agent=w3m/0.5.3+git20230121
4 fa19bf82 2023-08-21 jrmu charset=UTF-8
6 fa19bf82 2023-08-21 jrmu ctime=1692464686
7 fa19bf82 2023-08-21 jrmu host=38.87.162.8
11 fa19bf82 2023-08-21 jrmu 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
12 fa19bf82 2023-08-21 jrmu time=1692466206
13 fa19bf82 2023-08-21 jrmu title=Request For Complaints #1
14 fa19bf82 2023-08-21 jrmu author:1692466206=jrmu
15 fa19bf82 2023-08-21 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
16 fa19bf82 2023-08-21 jrmu host:1692466206=38.87.162.8
17 fa19bf82 2023-08-21 jrmu author:1692466182=jrmu
18 fa19bf82 2023-08-21 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
19 fa19bf82 2023-08-21 jrmu host:1692466182=38.87.162.8
20 fa19bf82 2023-08-21 jrmu author:1692464686=jrmu
21 fa19bf82 2023-08-21 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
22 fa19bf82 2023-08-21 jrmu host:1692464686=38.87.162.8
