on master help sign in
Merge pull request #1060 from ynx0/master
3454f09L
userspace/_index.md+5
@@ -23,3 +23,8 @@ Resources on the flagship web client Landcape, through which most users interact
23## [Threads](@/docs/userspace/threads/_index.md)
23## [Threads](@/docs/userspace/threads/_index.md)
24
24
25Resources on threads - monadic functions useful for complex IO.
25Resources on threads - monadic functions useful for complex IO.
26+
27+## [Graph Store](@/docs/userspace/graph-store/_index.md)
28+
29+Resources on Graph Store, a non-relational database specialized for social media applications.
30+
userspace/graph-store/advanced-info.md+1−1
@@ -54,7 +54,7 @@ Right now, the only thing that `transform-add-nodes` is used for is to replace u
54
54
55Here is a stubbed out example of a `transform-add-nodes` to show its inputs and outputs:
55Here is a stubbed out example of a `transform-add-nodes` to show its inputs and outputs:
56
56
57−```
57+```hoon
58|= [=index =post =atom was-parent-modified=?]
58|= [=index =post =atom was-parent-modified=?]
59^- [^index ^post]
59^- [^index ^post]
60!!
60!!
userspace/graph-store/data-structure-overview.md+12−12
@@ -11,7 +11,7 @@ Let's go through the type definitions of some of the most used types when workin
11
11
12## Post
12## Post
13Here's `sur/post.hoon`
13Here's `sur/post.hoon`
14−```
14+```hoon
15+$ index (list atom)
15+$ index (list atom)
16+$ uid [=resource =index]
16+$ uid [=resource =index]
17::
17::
@@ -55,7 +55,7 @@ Here's `sur/post.hoon`
55
55
56
56
57### Index
57### Index
58−```
58+```hoon
59+$ index (list atom)
59+$ index (list atom)
60+$ uid [=resource =index]
60+$ uid [=resource =index]
61```
61```
@@ -67,7 +67,7 @@ Here's `sur/post.hoon`
67An index fragment is not an explicitly defined type, but since an index is `(list atom)`, it follows that the type of an index fragment is `atom`. This is what gives the developer the flexibility to use more than just numbers in an index: any type that is representable as an atom can be used in the index.
67An index fragment is not an explicitly defined type, but since an index is `(list atom)`, it follows that the type of an index fragment is `atom`. This is what gives the developer the flexibility to use more than just numbers in an index: any type that is representable as an atom can be used in the index.
68
68
69### Hashing (Part 1)
69### Hashing (Part 1)
70−```
70+```hoon
71:: +sham (half sha-256) hash of +validated-portion
71:: +sham (half sha-256) hash of +validated-portion
72+$ hash @ux
72+$ hash @ux
73::
73::
@@ -78,7 +78,7 @@ An index fragment is not an explicitly defined type, but since an index is `(lis
78These types are used to cryptographically sign a given post, so that the host of some content cannot act as an imposter, and post content impersonating as someone else. `signature` represents a triple of signed message of hash, author, and author's life at time of posting. These can be used to cryptographically attest to a message. The implementation is a form of asymmetric/public-key encryption, where `q` and `r` are data necessary to look up a ship's public key on azimuth, which can be used to verify the validity of the message.
78These types are used to cryptographically sign a given post, so that the host of some content cannot act as an imposter, and post content impersonating as someone else. `signature` represents a triple of signed message of hash, author, and author's life at time of posting. These can be used to cryptographically attest to a message. The implementation is a form of asymmetric/public-key encryption, where `q` and `r` are data necessary to look up a ship's public key on azimuth, which can be used to verify the validity of the message.
79
79
80### Content Types
80### Content Types
81−```
81+```hoon
82+$ reference
82+$ reference
83 $% [%graph group=resource =uid]
83 $% [%graph group=resource =uid]
84 [%group group=resource]
84 [%group group=resource]
@@ -107,7 +107,7 @@ These types are used to cryptographically sign a given post, so that the host of
107Currently, these are the only content types supported by Graph Store.
107Currently, these are the only content types supported by Graph Store.
108
108
109### Post
109### Post
110−```
110+```hoon
111+$ post
111+$ post
112 $: author=ship
112 $: author=ship
113 =index
113 =index
@@ -125,7 +125,7 @@ Post is a fundamental type that represents what we normally think of as a post o
125An `indexed-post` is a post with an associated index fragment that can be used to validate a post's index with an index fragment that is expected at the end of the index list.
125An `indexed-post` is a post with an associated index fragment that can be used to validate a post's index with an index fragment that is expected at the end of the index list.
126
126
127### Hashing (Part 2)
127### Hashing (Part 2)
128−```
128+```hoon
129+$ validated-portion
129+$ validated-portion
130 $: parent-hash=(unit hash)
130 $: parent-hash=(unit hash)
131 author=ship
131 author=ship
@@ -142,7 +142,7 @@ The parts of a `post` that are actually hashed to obtain a value of type the ear
142
142
143Here's `sur/graph-store.hoon`
143Here's `sur/graph-store.hoon`
144
144
145−```
145+```hoon
146+$ graph ((mop atom node) gth)
146+$ graph ((mop atom node) gth)
147+$ marked-graph [p=graph q=(unit mark)]
147+$ marked-graph [p=graph q=(unit mark)]
148::
148::
@@ -215,7 +215,7 @@ Here's `sur/graph-store.hoon`
215```
215```
216
216
217### Graph, Node, and Related Objects
217### Graph, Node, and Related Objects
218−```
218+```hoon
219+$ graph ((mop atom node) gth)
219+$ graph ((mop atom node) gth)
220+$ marked-graph [p=graph q=(unit mark)]
220+$ marked-graph [p=graph q=(unit mark)]
221::
221::
@@ -261,14 +261,14 @@ Here are some helpful Wikipedia pages for more info on what this data type repre
261
261
262### Tag Queries
262### Tag Queries
263
263
264−```
264+```hoon
265+$ tag-queries (jug term resource)
265+$ tag-queries (jug term resource)
266```
266```
267
267
268`tag-queries` is a mapping where the keys are `term`s and the values are a `set` of `resource`s (this pattern is called a `jug`). It is a simple tagging system that allows for various ad-hoc collections, similar to filesystem tags being used to sort different files/folders. While the type's name is `tag-queries`, there is no complex querying system as of now. Currently, you can add term/resources pairs into the tag queries, get a list of all terms in tag-queries, and get the whole `jug` out of Graph Store.
268`tag-queries` is a mapping where the keys are `term`s and the values are a `set` of `resource`s (this pattern is called a `jug`). It is a simple tagging system that allows for various ad-hoc collections, similar to filesystem tags being used to sort different files/folders. While the type's name is `tag-queries`, there is no complex querying system as of now. Currently, you can add term/resources pairs into the tag queries, get a list of all terms in tag-queries, and get the whole `jug` out of Graph Store.
269
269
270### Update (Part 1)
270### Update (Part 1)
271−```
271+```hoon
272+$ update [p=time q=action]
272+$ update [p=time q=action]
273::
273::
274+$ logged-action
274+$ logged-action
@@ -304,7 +304,7 @@ The `update` type is what is used to interact with Graph Store. It is used both
304If you want to check out a relevant code listing to see how graph store handles these pokes, check out the `graph-update` arm in the poke handler at [`app/graph-store.hoon`](https://github.com/urbit/urbit/blob/e2ad6e3e9219c8bfad62f27f05c7cac94c9effa8/pkg/arvo/app/graph-store.hoon#L221-L227)
304If you want to check out a relevant code listing to see how graph store handles these pokes, check out the `graph-update` arm in the poke handler at [`app/graph-store.hoon`](https://github.com/urbit/urbit/blob/e2ad6e3e9219c8bfad62f27f05c7cac94c9effa8/pkg/arvo/app/graph-store.hoon#L221-L227)
305
305
306### Update (Part 2)
306### Update (Part 2)
307−```
307+```hoon
308+$ update-log ((mop time logged-update) gth)
308+$ update-log ((mop time logged-update) gth)
309+$ update-logs (map resource update-log)
309+$ update-logs (map resource update-log)
310::
310::
@@ -320,7 +320,7 @@ It is important to note that the source of truth is actually the `update-logs`,
320The reason for having the main CRUD actions being `logged-update`s is so that Graph Store knows which order to process the log entries in when it is rebuilding its current state. The time associated with the `logged-update` is a way of specifying the canonical order to process operations. All other actions that aren't part of logged-update stand on their own and don't need a timestamp in order to properly apply them.
320The reason for having the main CRUD actions being `logged-update`s is so that Graph Store knows which order to process the log entries in when it is rebuilding its current state. The time associated with the `logged-update` is a way of specifying the canonical order to process operations. All other actions that aren't part of logged-update stand on their own and don't need a timestamp in order to properly apply them.
321
321
322### Permissions
322### Permissions
323−```
323+```hoon
324+$ permissions
324+$ permissions
325 [admin=permission-level writer=permission-level reader=permission-level]
325 [admin=permission-level writer=permission-level reader=permission-level]
326::
326::
userspace/graph-store/validator-walkthrough.md+6−6
@@ -33,7 +33,7 @@ The graph represents a chat channel and contains all chat messages in order. A c
33
33
34Here's the definition of the schema in the chat validator mark:
34Here's the definition of the schema in the chat validator mark:
35File: [`mar/graph/validator/chat.hoon`](https://github.com/urbit/urbit/blob/fbd85abf4e41d580654606a6defb764f6a97256d/pkg/arvo/mar/graph/validator/chat.hoon#L33-L40)
35File: [`mar/graph/validator/chat.hoon`](https://github.com/urbit/urbit/blob/fbd85abf4e41d580654606a6defb764f6a97256d/pkg/arvo/mar/graph/validator/chat.hoon#L33-L40)
36−```
36+```hoon
37++ grab
37++ grab
38 |%
38 |%
39 ++ noun
39 ++ noun
@@ -77,7 +77,7 @@ For example, it wouldn't make sense to give readers `%self`, because they do not
77Let's see how this permissioning system is implemented in the validator code.
77Let's see how this permissioning system is implemented in the validator code.
78
78
79Here is the `grow` arm of [`mar/validator/chat.hoon`](https://github.com/urbit/urbit/blob/fbd85abf4e41d580654606a6defb764f6a97256d/pkg/arvo/mar/graph/validator/chat.hoon#L7-L20)
79Here is the `grow` arm of [`mar/validator/chat.hoon`](https://github.com/urbit/urbit/blob/fbd85abf4e41d580654606a6defb764f6a97256d/pkg/arvo/mar/graph/validator/chat.hoon#L7-L20)
80−```
80+```hoon
81|_ i=indexed-post :: A
81|_ i=indexed-post :: A
82++ grow
82++ grow
83 |%
83 |%
@@ -132,7 +132,7 @@ The comments section holds all individual comment nodes, but comments are not si
132
132
133
133
134Here's the validator, located at [`mar/graph/validator/link.hoon`](https://github.com/urbit/urbit/blob/fbd85abf4e41d580654606a6defb764f6a97256d/pkg/arvo/mar/graph/validator/link.hoon#L49-L73):
134Here's the validator, located at [`mar/graph/validator/link.hoon`](https://github.com/urbit/urbit/blob/fbd85abf4e41d580654606a6defb764f6a97256d/pkg/arvo/mar/graph/validator/link.hoon#L49-L73):
135−```
135+```hoon
136++ grab
136++ grab
137 |%
137 |%
138 ++ noun
138 ++ noun
@@ -200,7 +200,7 @@ Let's analyze the permissions structure.
200
200
201Here's how it is implemented [(source)](https://github.com/urbit/urbit/blob/master/pkg/arvo/mar/graph/validator/link.hoon#L2-L27):
201Here's how it is implemented [(source)](https://github.com/urbit/urbit/blob/master/pkg/arvo/mar/graph/validator/link.hoon#L2-L27):
202
202
203−```
203+```hoon
204|_ i=indexed-post
204|_ i=indexed-post
205++ grow
205++ grow
206 |%
206 |%
@@ -287,7 +287,7 @@ Here's how it is implemented [(source)](https://github.com/urbit/urbit/blob/mast
287Here, a notebook, which is a collection of blog posts (called notes), is represented by the root graph. All data associated with the blog post is represented by the top level node, which is the note itself along with the associated comments. One level deeper, we see two container structures. The first one is the post revision container; it holds the edit history of your blog post. Every child node of this corresponds to the actual title and text of your blog post. The second one is the comments container. This represents the comment section of your blog post. Every child node of this is not a comment, but a comment revision container, which, as before, contains the edit history of your comment.
287Here, a notebook, which is a collection of blog posts (called notes), is represented by the root graph. All data associated with the blog post is represented by the top level node, which is the note itself along with the associated comments. One level deeper, we see two container structures. The first one is the post revision container; it holds the edit history of your blog post. Every child node of this corresponds to the actual title and text of your blog post. The second one is the comments container. This represents the comment section of your blog post. Every child node of this is not a comment, but a comment revision container, which, as before, contains the edit history of your comment.
288
288
289Here's its validator, located at [`mar/graph/validator.hoon`](https://github.com/urbit/urbit/blob/master/pkg/arvo/mar/graph/validator/publish.hoon#L56-L97)
289Here's its validator, located at [`mar/graph/validator.hoon`](https://github.com/urbit/urbit/blob/master/pkg/arvo/mar/graph/validator/publish.hoon#L56-L97)
290−```
290+```hoon
291 ++ noun
291 ++ noun
292 |= p=* :: 1
292 |= p=* :: 1
293 =/ ip ;;(indexed-post p) :: 2
293 =/ ip ;;(indexed-post p) :: 2
@@ -380,7 +380,7 @@ Let's take a look at the permissioning structure for Publish.
380
380
381[(source)](https://github.com/urbit/urbit/blob/fbd85abf4e41d580654606a6defb764f6a97256d/pkg/arvo/mar/graph/validator/publish.hoon#L6-L24)
381[(source)](https://github.com/urbit/urbit/blob/fbd85abf4e41d580654606a6defb764f6a97256d/pkg/arvo/mar/graph/validator/publish.hoon#L6-L24)
382
382
383−```
383+```hoon
384|_ i=indexed-post
384|_ i=indexed-post
385++ grow
385++ grow
386 |%
386 |%