reading spritely

src/chapter_1.md

@@ -1 +0,0 @@
-# Chapter 1

src/comparison/dmc.md

@@ -0,0 +1,5 @@
+# DMC
+
+Distributed Mutable Containers
+
+https://inqlab.net/projects/dmc/

src/comparison/eris.md

@@ -0,0 +1,5 @@
+# ERIS
+
+Encoding for Robust Immutable Storage (ERIS)
+
+https://eris.codeberg.page/spec/

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

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

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 <Content Addressing>`** 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 <Mutability>`** must be supported, with the latter generally being built upon the former. 
+> 3. Documents must be **{index}`encrypted <Encryption>`** 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

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},