Skip to content

Commit 9ade6e0

Browse files
authored
Initial Draft (#1)
* Update README * Fix spellcheck config * Remove line lenghth checks * Spelling * A few more * Remove redundancies * Tighten up a few sections * Fix footnote * Fix a couple links * Remove appendix, move to links * Update dictionary * Cite source * Apply a few of ZL's suggestions * Remove redundant bullet point * Fix where it . * Link to AWS Lambda * And I would have gotten away with it too, if it weren't for that meddling spellcheck * Add more than Lambda * WIP * Cut and rearrange a bunch of audience text * Fix much spelling * Add to dictionary * ZL's nits
1 parent 8b1d9a0 commit 9ade6e0

File tree

6 files changed

+278
-1
lines changed

6 files changed

+278
-1
lines changed

.github/CODEOWNERS

+5
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
1+
# These owners will be the default owners for everything in
2+
# the repo. Unless a later match takes precedence,
3+
# @global-owner1 and @global-owner2 will be requested for
4+
# review when someone opens a pull request.
5+
* @expede @zeeshanlakhani

.github/workflows/dictionary.txt

+117
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,117 @@
1+
APIs
2+
Acknowledgements
3+
Agoric
4+
Akiko
5+
Akiko's
6+
Antigoals
7+
Bacalhau
8+
Berners-Lee
9+
CBOR
10+
CIDs
11+
CRDTs
12+
Cap'N
13+
Cap'n
14+
CapTP
15+
DAG-CBOR
16+
DAG-JSON
17+
ERTP
18+
Enum
19+
Fastly
20+
Gozalishvili
21+
Hardt
22+
Holmgren
23+
Homestar
24+
IPFS
25+
IPLD
26+
IPVM
27+
IPVM's
28+
Invoker's
29+
Invokers
30+
IoT
31+
Irakli
32+
JSON
33+
JSONPath
34+
JWT
35+
JWT-encoded
36+
Krüger
37+
Lakhani
38+
Lamport
39+
LamportsProblem
40+
Lemmer-Webber
41+
Marsen
42+
OAuth
43+
OCapN
44+
PKI
45+
Philipp
46+
Pluggable
47+
PoPs
48+
Pre-Draft
49+
Proto
50+
RPC
51+
Raison
52+
SemVer
53+
Spritely
54+
TCP
55+
TTL
56+
Tesler's
57+
UCAN
58+
UCAN's
59+
UCAN-IPLD
60+
UCANTO
61+
UCANs
62+
URI
63+
URIs
64+
Vagg
65+
Varsig
66+
Wasm
67+
WebAssembly
68+
Worthington
69+
Zeeshan
70+
Zelenka
71+
atomicity
72+
auth
73+
backend
74+
base64url
75+
cacheable
76+
canonicalized
77+
composable
78+
cryptographic
79+
cryptographically
80+
d'Être
81+
dataflow
82+
de
83+
debuggable
84+
delegator
85+
dholms
86+
expede
87+
expressivity
88+
facto
89+
implicits
90+
interpretable
91+
invariants
92+
invoker
93+
microservices
94+
multiformat
95+
outmost
96+
parallelize
97+
permissionlessly
98+
pipelined
99+
pipelining
100+
pre-vacation
101+
prenegotiation
102+
referentially
103+
requestor's
104+
responder
105+
signalling
106+
simple-but-evolvable
107+
struct
108+
subdelegated
109+
subdelegation
110+
subtype
111+
trustless
112+
ucanto
113+
unlabelled
114+
unpadded
115+
url
116+
v0
117+
validator

.github/workflows/linkcheck.cfg.json

+10
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,10 @@
1+
{
2+
"ignorePatterns": [
3+
{
4+
"pattern": "https://share.ansi.org/Shared%20Documents/Standards%20Activities/American%20National%20Standards/Procedures,%20Guides,%20and%20Forms/2020_ANSI_Essential_Requirements.pdf"
5+
},
6+
{
7+
"pattern": "https://share.ansi.org/Shared%20Documents/Standards%20Activities/American%20National%20Standards/Procedures,%20Guides,%20and%20Forms/2020_ANSI_Essential_Requirements.pdf"
8+
}
9+
]
10+
}

.github/workflows/linkcheck.yml

+19
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,19 @@
1+
name: Check Markdown links
2+
3+
on:
4+
push:
5+
branches:
6+
- main
7+
pull_request:
8+
9+
jobs:
10+
markdown-link-check:
11+
runs-on: ubuntu-latest
12+
steps:
13+
- uses: actions/checkout@master
14+
- uses: gaurav-nelson/github-action-markdown-link-check@v1
15+
with:
16+
use-quiet-mode: "yes"
17+
check-modified-files-only: "yes"
18+
base-branch: "main"
19+
config-file: "./.github/workflows/linkcheck.cfg.json"

.github/workflows/spellcheck.yml

+17
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,17 @@
1+
name: "spellcheck"
2+
on:
3+
push:
4+
branches:
5+
- main
6+
pull_request:
7+
8+
jobs:
9+
spellcheck:
10+
runs-on: ubuntu-latest
11+
steps:
12+
- uses: actions/checkout@v3
13+
- uses: matheus23/[email protected]
14+
with:
15+
files-to-check: "README.md"
16+
files-to-exclude: "LICENSE.md" # optional
17+
words-to-ignore-file: ".github/workflows/dictionary.txt"

README.md

+110-1
Original file line numberDiff line numberDiff line change
@@ -1 +1,110 @@
1-
# northstar
1+
# 🌟 North Star
2+
3+
# Meta
4+
5+
> If your starting-point is unknown, and your end-point and intermediate stages are woven together out of unknown material, there may be coherence, but knowledge is completely out of the question.
6+
>
7+
> — Plato, The Republic
8+
9+
This document is an informal description of IPVM's high-level goals. It forms the basis for reasoning about the project from first principles. It expected to only rarely change.
10+
11+
This is meant to provide the basis for reasoning from first principles, but it is written in prose and not first-order logic. It "merely" provides a basis for aligning the people working on the project. Principles often contain some limited internal tension: use your best judgment and discuss with your peers when ambiguities inevitably arise.
12+
13+
This text should be kept short, to the point, and as unambiguous as possible. Define any project-specific jargon, avoid editorializing, and limit subtle language. Use diagrams and imagery where appropriate.
14+
15+
# Raison d'Être
16+
17+
> Had the [Web] been proprietary, and in my total control, it would probably not have taken off. You can’t propose that something be a universal space and at the same time keep control of it.
18+
>
19+
> — Berners-Lee, [FAQ][TBL FAQ]
20+
21+
IPVM intends to do nothing less than connect all of the world's users and services. It can be thought of as "the HTTP of compute": open, interoperable, and everywhere. Following the model of the Web being the network of linked documents, IPVM is the network of linked computation. It allows anyone to permissionlessly tie into the network without prenegotiation.
22+
23+
TCP/IP and HTTP were successful for a number of reasons. Networking was always possible, but doing this from scratch for every application is infeasible. Hypertext provided a single mechanism for many applications to interconnect. Application agnosticism is a major pillar of [such an approach][W3F Principles]: anything can run on this substrate, and it's easy to join. IPVM works equally well with traditional Cloud-based services as it does local-first compute and trustless architectures. To be successful, IPVM must have a path towards becoming substantially better than a pure Cloud architecture. It does not stand in opposition to the Cloud, but rather extends and contains it.
24+
25+
The internet is no longer purely client/server. Consumer devices are now significantly more powerful than when the LAMP stack and Cloud infrastructure were being co-developed. Devices today are heterogeneous: there are powerful browsers, heavy servers, microservices, edge PoPs, tiny IoT devices, smartphones, and commons networks like BitTorrent, IPFS, and blockchains. IPVM provides a way to tie applications together with robust invocation, routing, and trust layers.
26+
27+
Finally: the volume of data that modern applications requires leads to a situation known as data gravity. Given the speed of light, the amount of data that we produce and modify grows faster than is possible to sync to all locations, and the rate of change makes it physically impossible to ever catch up. There are also still many cases where the data is small and.or infrequent enough to be practical to move around on the network. To meet the needs of such a heterogeneous network, IPVM provides a flexible model that takes into account the [costs and trade-offs of distributed computing][Fallacies of Distributed Computing] by ad hoc moving data to where the code lives, as well as ad hoc moving code to where the data lives.
28+
29+
# Audience
30+
31+
> Every application has an inherent amount of complexity that cannot be removed or hidden. Instead, it must be dealt with, either in product development or in user interaction.
32+
>
33+
> [Tesler's Law]
34+
35+
> I think that, collectively, we are infatuated with these two notions of easy ["near-at-hand" and "in your current skill set"]. We are just so self-involved in these two aspects; it's hurting us tremendously.
36+
>
37+
> — Hickey, [Simple Made Easy]
38+
39+
IPVM is intended for general distributed computation, but excels at tasks that would be found in systems like [AWS Lambda Step functions], [Fastly Compute@Edge], and [Temporal Cloud]. The IPVM network itself is focused on machine-to-machine interaction — where each node acts as the user's agent — but is not expected to be interacted with directly when on the happy path.
40+
41+
The word "simple" is often used interchangeably with "easy" to mean making a common use case require little effort. This is goal directed: "easy for who or what?" IPVM aims to make distributed computing easy by [abstracting away][Fault Oblivious] the common challenges of that context. In the same way that TCP/IP handles machine-to-machine networking concerns in an application agnostic way, IPVM doesn't attempt to enforce which kinds of services can be interconnected.
42+
43+
Standardizing on Wasm also highlights IPVM's core audience. At time of writing, there is comparatively little Wasm written; but the belief is that will change quickly. IPVM uses Wasm in its emphasis to decompose compute into simpler units that are composable, cacheable, reusable, and tractable for a distributed setting. Per [Tesler's Law], solving these [common problems for the distributed setting][Fallacies of Distributed Computing] means that something else has to be traded off. Running arbitrary code designed for local-only execution doesn't work in these settings. Much like depending on techniques like read-your-writes or CRDTs at the data layer, IPVM requires low-level implementations use certain tools and techniques. Following the tactic of "do one thing well", concerns of providing familiarity is pushed above the network layer to good libraries and tools.
44+
45+
# Goals
46+
47+
IPVM means to provide:
48+
49+
- Task matchmaking network / marketplace
50+
- A trust layer (e.g. verifiable compute, encryption, PKI, capabilities)
51+
- The ability to tie together external services seamlessly
52+
- Interfaces open to extension
53+
- First-class P2P payments
54+
- The ability to run everywhere (servers, browsers, mobile applications, etc)
55+
- Application agnostic
56+
- Abstract concerns of locality away from the programmer
57+
58+
## Antigoals
59+
60+
IPVM will _not_ attempt to develop into a:
61+
62+
- replacement or upgrade of IPFS internals
63+
- high level language for distributed applications
64+
- custom Wasm runtime
65+
- blockchain or other global consensus mechanism
66+
- a web server framework
67+
68+
IPVM focuses on execution, networking, dataflow, and trust. It is important to make the internals debuggable and friendly where possible, but only when it doesn't conflict with the core aim at this layer: efficiency and abstracting away distributed systems concerns. Human-friendliness is important, but many human-oriented features should be pushed into higher layers. These may include high-level APIs, language integration, etc.
69+
70+
# Design Principles
71+
72+
> You can prove anything you want by coldly logical reason — if you pick the proper postulates.
73+
>
74+
> — Asimov, "I, Robot"
75+
76+
1. Proliferate!
77+
2. Open world / extension without prenegotiation
78+
3. Participatory: anyone can consume, serve, or both
79+
4. Learn into our strengths: IPVM is not k8s, so don't try to be
80+
5. Common things should be simple, and complex things should be possible
81+
6. Handle low-level details (networking, failure, trust) so that others can focus on business logic
82+
7. Build in layers with clear audiences (machine-to-machine, end-user, etc)
83+
84+
When in doubt, optimize for proliferation. Get implementations into many hands, find services that already tie-in at the RPC and trust layers ([UCAN]), and avoid having the core IPVM team become a bottleneck for extending the network. Unix and C have been describes as being like [(helpful) computer viruses][Models of Software Acceptance] due to how they spread and integrate with other systems.
85+
86+
IPVM simplifies distributed dataflow. It's tempting to think of it as moving unconstrained centralized code to a logically centralized executor, but IPVM actually lowers the barrier of entry to distributed code. A distributed context is fundamentally different from writing code for a single machine[^LamportsProblem].
87+
88+
[Homestar] is the reference implementation of the IPVM protocol. Homestar is intended to be largely self-contained, and to run on as many systems as possible.
89+
90+
[^LamportsProblem]: As Leslie Lamport says, "a distributed system is one in which the failure of a machine you have never heard of can cause your own machine to become unusable".
91+
92+
<!-- Internal Links -->
93+
94+
<!-- External Links -->
95+
96+
[AWS Lambda Step functions]: https://docs.aws.amazon.com/lambda/latest/dg/lambda-stepfunctions.html
97+
[Fallacies of Distributed Computing]: https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing
98+
[Fastly Compute@Edge]: https://docs.fastly.com/products/compute-at-edge
99+
[Fault Oblivious]: https://rebelsky.cs.grinnell.edu/~rebelsky/Courses/CS302/Fun/fault-oblivious.html
100+
[Homestar]: https://github.com/ipvm-wg/homestar/
101+
[How do we tell truths that might hurt?]:https://www.cs.virginia.edu/~evans/cs655/readings/ewd498.html
102+
[Models of Software Acceptance]: https://dreamsongs.com/Files/AcceptanceModels.pdf
103+
[Richard Gabriel]: https://en.wikipedia.org/wiki/Richard_P._Gabriel
104+
[Simple Made Easy]: https://www.infoq.com/presentations/Simple-Made-Easy/
105+
[TBL FAQ]:https://www.w3.org/People/Berners-Lee/FAQ.html
106+
[Temporal Cloud]: https://temporal.io/
107+
[Tesler's Law]: https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity
108+
[UCAN]: https://github.com/ucan-wg
109+
[W3F Principles]: https://webfoundation.org/about/vision/history-of-the-web/
110+
[structured programming]: https://en.wikipedia.org/wiki/Structured_programming

0 commit comments

Comments
 (0)