From b957dae24a6f874a5c97c970e76ef763a7cf35d6 Mon Sep 17 00:00:00 2001 From: sneakers-the-rat Date: Wed, 7 Jun 2023 21:00:57 -0700 Subject: [PATCH] reading spritely --- src/chapter_1.md | 1 - src/comparison/dmc.md | 5 +++++ src/comparison/eris.md | 5 +++++ src/comparison/index.md | 9 +++++++++ src/comparison/nostr.md | 41 ++++++++++++++++++++++++++++++++++++++ src/comparison/spritely.md | 30 ++++++++++++++++++++++++++++ src/p2p_ld_docs.bib | 16 +++++++++++---- 7 files changed, 102 insertions(+), 5 deletions(-) delete mode 100644 src/chapter_1.md create mode 100644 src/comparison/dmc.md create mode 100644 src/comparison/eris.md create mode 100644 src/comparison/nostr.md create mode 100644 src/comparison/spritely.md diff --git a/src/chapter_1.md b/src/chapter_1.md deleted file mode 100644 index b743fda..0000000 --- a/src/chapter_1.md +++ /dev/null @@ -1 +0,0 @@ -# Chapter 1 diff --git a/src/comparison/dmc.md b/src/comparison/dmc.md new file mode 100644 index 0000000..b321088 --- /dev/null +++ b/src/comparison/dmc.md @@ -0,0 +1,5 @@ +# DMC + +Distributed Mutable Containers + +https://inqlab.net/projects/dmc/ \ No newline at end of file diff --git a/src/comparison/eris.md b/src/comparison/eris.md new file mode 100644 index 0000000..a3366d8 --- /dev/null +++ b/src/comparison/eris.md @@ -0,0 +1,5 @@ +# ERIS + +Encoding for Robust Immutable Storage (ERIS) + +https://eris.codeberg.page/spec/ \ No newline at end of file diff --git a/src/comparison/index.md b/src/comparison/index.md index e75b713..e122790 100644 --- a/src/comparison/index.md +++ b/src/comparison/index.md @@ -8,6 +8,7 @@ All of this is TODO. Comparison to existing protocols and projects (just to situ bittorrent ipfs hypercore +spritely ``` ```{toctree} @@ -17,6 +18,7 @@ activitypub ssb matrix at_protocol +nostr ``` ```{toctree} @@ -27,6 +29,13 @@ ld_fragments nanopubs ``` +```{toctree} +:caption: Data Structures + +eris +dmc +``` + ## To be categorized - Agregore diff --git a/src/comparison/nostr.md b/src/comparison/nostr.md new file mode 100644 index 0000000..d32033a --- /dev/null +++ b/src/comparison/nostr.md @@ -0,0 +1,41 @@ +# Nostr + +Again, though we have a general distrust of the anarcho-capitalists, it's worth a comparison. + +Nostr is an extremely minimal protocol: https://nostr.com/the-protocol . There just isn't a lot there worth speaking of. + +## DNS identity + +Like [AT Protocol](at_protocol), there is a NIP (noster implementation possibility) for using {index}`DNS` to map keys: https://github.com/nostr-protocol/nips/blob/master/05.md + +It seems to be Webfinger-like, using a .json file under a `.well-known` path on a domain. An identity issues an event indicating a `nip05` type: + +```json +{ + "pubkey": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9", + "kind": 0, + "content": "{\"name\": \"bob\", \"nip05\": \"bob@example.com\"}" +} +``` + +and then does a GET to `https://example.com/.well-known/nostr.json?name=bob`. If the response looks like this: + +```json +{ + "names": { + "bob": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9" + } +} +``` + +then the identity is considered verified. + +## Petnames + +And a notion of {index}`Petnames`: https://github.com/nostr-protocol/nips/blob/master/02.md + +## Not so good + +- Just a client-server architecture: clients must talk to relays, relays do not talk to one another. +- Very very little in the way of a formalized spec for relays +- Made by a bunch of bitcoin guys \ No newline at end of file diff --git a/src/comparison/spritely.md b/src/comparison/spritely.md new file mode 100644 index 0000000..9cc2695 --- /dev/null +++ b/src/comparison/spritely.md @@ -0,0 +1,30 @@ +# Spritely/Goblin + +The Spritely Institute is likely the closest in spirit and design to what we are considering with p2p-ld, and have significant experience having previously worked on [ActivityPub](activitypub). The primary point of departure is their focus on building applications and running code, rather than structuring and sharing data --- so their work is largely complementary. + +Overlapping design choices include +- Emphasis on making a social, rather than a technological system! +- Capability security vs ACLs - Containers of other identities might be a useful way of coordinating who gets capabilities, but implementing them as capabilities rather than access checks makes for a much richer space of interaction and mutation. +- `Goblins` as "addressable entities with encapsulated behavior" are similar to {index}`Container`s +- Distributed objects: we imagine containers as being instantiated in multiple places at once and being acted on by multiple actors. Spritely's use of the "Unum Pattern" focused on distributed behavior rather than distributed data is something we plan on following up on and re-evaluating some of our designs. One place we may diverge is in our emphasis of 'forking' and activity that doesn't need to be explicitly approved: actors need not necessarily operate on the same shared object, but might make their own assertions, links, and so forth that don't directly change the object as owned by the original actor. + +Stuff we can learn from +- A lot +- Promise Pipelining to reduce roundtrips +- Implementation of protocol agnosticisim in OCapN +- Discussion of safety of computing base and evaluation environment + +Their description of *portable encrypted storage* ({index}`Storage; Portability`) is also extremely useful: + +> 1. Documents must be **{index}`Content Addressed `** and **location agnostic.** In other words, the name of the particular resource is based on information stemming from the content itself rather than a particular network location. Generally this name is the hash of the corresponding document in the case of immutable documents and a public key (or hash thereof) in the case of mutable documents. +> 2. Both **{index}`immutable and mutable documents `** must be supported, with the latter generally being built upon the former. +> 3. Documents must be **{index}`encrypted `** such that the documents can be stored in locations that are oblivious to their actual contents. Only those possessing read capabilities should be able to access the documents' contents. +> 4. Documents should be **chunked** so that they are not vulnerable to sizeof-file attacks. +> 5. Reading (and, in the case of mutable documents, writing) documents must be accessed through abstract **capabilities.** +> 6. Files must be network agnostic, meaning that they are not only location agnostic but agnostic even to a specific network structure. peer-to-peer, client-to-server, and sneakernet networks all should be supported with the same object URIs between them. + +## References + +- {cite}`lemmer-webberHeartSpritelyDistributed` +- OCapN - https://github.com/ocapn/ocapn +- Golem - https://gitlab.com/spritely/golem/blob/master/README.org \ No newline at end of file diff --git a/src/p2p_ld_docs.bib b/src/p2p_ld_docs.bib index 936c169..77bff0a 100644 --- a/src/p2p_ld_docs.bib +++ b/src/p2p_ld_docs.bib @@ -1,10 +1,18 @@ +@online{lemmer-webberHeartSpritelyDistributed, + title = {The {{Heart}} of {{Spritely}}: {{Distributed Objects}} and {{Capability Security}}}, + author = {Lemmer-Webber, Christine and Farmer, Randy and Sims, Juliana}, + url = {https://www.spritely.institute/static/papers/spritely-core.html}, + urldate = {2023-06-07}, + archive = {https://web.archive.org/web/20230607200331/https://www.spritely.institute/static/papers/spritely-core.html}, + organization = {{Spritely Institute}}, + keywords = {archived,spritely}, + file = {/Users/jonny/Dropbox/papers/zotero/L/Lemmer-WebberC/lemmer-webber_the_heart_of_spritely.pdf;/Users/jonny/Zotero/storage/32A9YVLN/spritely-core.html} +} + @online{saundersDecentralizedInfrastructureNeuro2022, - title = {Decentralized Infrastructure for (Neuro)Science}, + title = {Decentralized {{Infrastructure}} for ({{Neuro}})Science}, author = {Saunders, Jonny L.}, date = {2022-08-31}, - year = {2022}, - month = {08}, - day = {31}, eprint = {2209.07493}, eprinttype = {arxiv}, eprintclass = {cs},