remove interplanetary node and use cases

Author: MylesBorins

MANIFESTO.md

@@ -3,7 +3,7 @@
 We the undersigned agree on the the following,
 
 * Getting modules "right" is one of the biggest existential threats to JavaScript
-* This affects a large number of people on this planet (and future planets), with varying interests including but not limited to:
+* This affects a large number of people with varying interests including but not limited to:
   - web applications
   - serverside applications and services
   - command line interfaces
@@ -17,15 +17,6 @@ We the undersigned agree on the the following,
 * While compromise is neccessary, it is important to recognize when Node.js needs to lead and attempt to influence change at an industry level
 * The closer the Node.js and Web platform remain the better the developer experience will be
 
-* The Node.js implementation of ESModules must have the following features:
-  - Compliant to ECMA-262. It is important to follow the standard. If we need changes in the standard we should attempt to accomplish them at TC39.
-  - Interoperability. It is important to be able to utilize ESModule code from CommonJS and vice versa.
-  - Hooks. It is important to be able to have hooks into the lifecycle of a Module.
-  - Multiple Goals. e.g. wasm. It is important that our implementation scales to any number of future goals.
-* Packages written with the Node.js implementation of ESModules must have the following features.
-  - Dual mode. It is important that a single package should be capable of being loaded as both ESM and CJS. This does not have to be the default.
-  - Web Compatible. It is important that a published package be capable of running on both the web and node.js platform without any source changes. This does not mean all APIs need to be compatible.
-
 Without working together there will be no chance of a successful module system. "Together" is larger than the undersigned.
 
 Signed,