Merge pull request #75 from uqbar-dao/TODOs

small edits/todos and KNS name change

src/apis/kernel.md

@@ -33,7 +33,7 @@ pub enum KernelCommand {
         capabilities: Vec<Capability>,
     },
     /// Tell the kernel to run a process that has already been installed.
-    /// TODO: in the future, this command could be extended to allow for
+    /// Note: in the future, this command could be extended to allow for
     /// resource provision.
     RunProcess(ProcessId),
     /// Kill a running process immediately. This may result in the dropping / mishandling of messages!

src/cookbook/manage_child_processes.md

@@ -69,7 +69,7 @@ impl Guest for Component {
         ) {
             Ok(spawned_process_id) => spawned_process_id,
             Err(e) => {
-                panic!("couldn't spawn"); //  TODO
+                panic!("couldn't spawn"); // 
             }
         }
     }

src/identity_system.md

@@ -5,37 +5,37 @@ This identity must be self-sovereign, unforgeable, and easy to discover by peers
 Kinode OS uses a domain system similar to [ENS](https://ens.domains/) to achieve this.
 It should be noted that, in our system, the concepts of `domain`, `identity`, and `username` are identical and interchangeable.
 
-Like ENS, Kinode domains (managed by our NDNS) are registered by a wallet and owned in the form of an NFT.
+Like ENS, Kinode domains (managed by our KNS) are registered by a wallet and owned in the form of an NFT.
 However, unlike ENS, Kinode domains never expire. Additionally, they contain metadata.osessary to both:
 - demonstrate the provenance of a given identity.
 - route messages to the identity on the Kinode network.
 
-NDNS provides both sensible defaults and flexibility.
+KNS provides both sensible defaults and flexibility.
 The cheapest option is also the default: minting a new NFT, a `.os` TLD.
-However, unlike ENS, NDNS is not restricted to a single set of NFTs.
+However, unlike ENS, KNS is not restricted to a single set of NFTs.
 Instead, it is designed to easily extend and wrap existing NFTs, enabling users to use identities they are already attached to as their Kinode identity.
 
 What does this look like in practice?
 
 It's easy enough to check for provenance of a given identity.
 If you have an Kinode domain, you can prove ownership by signing a message with the wallet that owns the domain.
-However, to essentially use your Kinode identity as a domain name for your personal server, NDNS domains have routing information, similar to a DNS record, that points to an IP address.
+However, to essentially use your Kinode identity as a domain name for your personal server, KNS domains have routing information, similar to a DNS record, that points to an IP address.
 
-A NDNS domain can either be `direct` or `indirect`.
+A KNS domain can either be `direct` or `indirect`.
 When users first boot a node, they may decide between these two domain types as they create their initial identity.
 Direct nodes share their literal IP address and port in their metadata, allowing other nodes to message them directly.
 Again, this is similar to registering a WWW domain name and pointing it at your web server.
 However, running a direct node is both technically demanding (you must maintain the ability of your machine to be accessed remotely) and a security risk (you must open ports on the server to the public internet).
-Therefore, indirect nodes are the best choice for the majority of users that choose to run their own node (TODO: what about those who have someone else run it? A hosting service?).
+Therefore, indirect nodes are the best choice for the majority of users that choose to run their own node.
 
 Instead of sharing their IP and port, indirect nodes simply post a list of *routers* onchain.
 These routers are other *direct* nodes that have agreed to forward messages to indirect nodes.
 When a node wants to send a message to an indirect node, it first finds the node onchain, and then sends the message to one of the routers listed in the node's metadata.
 The router is responsible for forwarding the message to the indirect node and similarly forwarding messages from that node back to the network at large.
 
 For more information about the architectural specifics of the networking protocol, see [Networking Protocol](./networking_protocol.md).
-The main takeaway for the identity system is that *domain provenance* and *domain resolution* are unified by NDNS.
+The main takeaway for the identity system is that *domain provenance* and *domain resolution* are unified by KNS.
 
-Like .eth for ENS, the NDNS domain space is fixed inside the `.os` top-level domain.
+Like .eth for ENS, the KNS domain space is fixed inside the `.os` top-level domain.
 However, we reserve the ability to expand domain availability in the future, and governance of the Kinode protocol will include the ability to manage domain names.
 Eventually, we hope to link various TLDs to existing NFT communities and other identity systems.

src/intro.md

@@ -28,8 +28,8 @@ Kinode's kernel handles the startup and teardown of processes, as well as messag
 Processes are programs compiled to Wasm, which export a single `init()` function.
 They can be started once and complete immediately, or they can run "forever".
 
-Peers in Kinode OS are identified by their onchain username in the "NDNS": Kinode Domain Name System, which is modeled after ENS.
-The modular architecture of the NDNS allows for any Ethereum NFT, including ENS names themselves, to generate a unique Kinode identity once it is linked to a NDNS entry.
+Peers in Kinode OS are identified by their onchain username in the "KNS": Kinode Domain Name System, which is modeled after ENS.
+The modular architecture of the KNS allows for any Ethereum NFT, including ENS names themselves, to generate a unique Kinode identity once it is linked to a KNS entry.
 
 Data persistence and blockchain access, as fundamental primitives for p2p apps, are built directly into the kernel.
 The filesystem is abstracted away from the developer, and data is automatically persisted across an arbitrary number of encrypted remote backups as configured at the user-system-level.

src/my_first_app/chapter_1.md

@@ -153,7 +153,7 @@ $ cat my_chat_app/pkg/metadata.json
 }
 ```
 
-Here, the `publisher` is some default value, but for a real package, this field should contain the NDNS id of the publishing node.
+Here, the `publisher` is some default value, but for a real package, this field should contain the KNS id of the publishing node.
 The `publisher` can also be set with a `kit new --publisher` flag.
 
 ## Building the Package

src/networking_protocol.md

@@ -71,7 +71,7 @@ struct RoutingRequest {
     pub target: String,
 }
 
-/// TODO indicate where to find Address, Rsvp, Message, and LazyLoadBlob type definitions
+/// Note: indicate where to find Address, Rsvp, Message, and LazyLoadBlob type definitions
 struct KernelMessage {
     pub id: u64,
     pub source: Address,

src/pki.md

@@ -1,12 +1,12 @@
 # Public Key Infrastructure
 
-The following is a high level overview of Kinode's public key infrastructure, the Kinode Identity System, or NDNS.
+The following is a high level overview of Kinode's public key infrastructure, the Kinode Identity System, or KNS.
 You can find a more general discussion of the Kinode [identity system](./identity_system.md) here.
 
 ## Identity Registration
 
-The NDNS Registry and Resolver are coupled in the same contract, the `NDNSRegistryResolver`.
-This contract issues nodes on the NDNS network and records the data.osessary for a node to interact with other nodes.
+The KNS Registry and Resolver are coupled in the same contract, the `KNSRegistryResolver`.
+This contract issues nodes on the KNS network and records the data.osessary for a node to interact with other nodes.
 
 At a high level, the PKI depends on two elements: public keys and networking information.
 
@@ -26,11 +26,11 @@ These router nodes communicate between indirect nodes and the network at large.
 
 ## Name Registration
 
-The `DotNecRegistrar` (AKA `.os`) is responsible for registering all `.os` domain names.
-It is also responsible for authorizing alterations to `.os` node records managed by the NDNSRegistryResolver. (Todo: just confused by this)
-`DotNecRegistrar` implements ERC721 tokenization logic for the names it is charged with, so all `.os` names are NFTs that may be transferred to and from any address.
+The `DotOsRegistrar` (AKA `.os`) is responsible for registering all `.os` domain names.
+It is also responsible for authorizing alterations to `.os` node records managed by the KNSRegistryResolver.
+`DotOsRegistrar` implements ERC721 tokenization logic for the names it is charged with, so all `.os` names are NFTs that may be transferred to and from any address.
 There is currently a minimum length of 9 characters for Kinode IDs.
 
-`DotNecRegistrar` allows users to create subdomains underneath any `.os` name they own.
+`DotOsRegistrar` allows users to create subdomains underneath any `.os` name they own.
 Initially this grants them control over the subdomain, as a holder of the parent domain, but they may choose to irreversibly revoke this control if they desire to.
 This applies at each level of subdomain.