Thank you! Yes I’d love to, I’ll do that later today.
1 Like
Hi everyone, I’ve just read through the Paths exercise and I have some more feedback to share 
The visual examples are great, once again, and I think the explanation for the index-style notation is good too. While I won’t give too much feedback on the prose of the exercise for now, I’d say that re-iterating high-level points from this sub-section of the core concepts at the beginning of the gym exercise would help ease developers into the task at hand.
Conceptually, I’m having trouble understanding why Paths are different to Links. Having read through the gym chapter and played around with the visual example, I’m not confident that I now have the ability to tackle the exercises or understand how I go about working with the Path structure. Heading over to the docs and reading through the functions, it doesn’t seem like the hdk content matches the lesson in the gym.
Here is my impression about what paths are: they are entries with a string that can be interpreted as a path because of their period delimiter. Maybe.
While the Core Concepts chapter indicates that Paths/Anchors serve as Entry/Link combination indexes for users to find data, functionally it appears to me that Paths are simply entries with the ability to be searched as though they had links.
So before I can begin to understand and appreciate the utility of Paths, it would be great to have the following clarification:
- How are Paths different from Links
- When do I want to use a Link vs a Path
- Where are the functions I need to begin playing around with Paths
- How do I denote a path inside my entry
- What does it mean that I can access paths [A D] over [A B C]
I noticed that on the updated Remote Call exercise that there’s a code example straight from the docs - having that in the Paths chapter would be really great to see.
~
Other things. I’ve made a PR on the developer-exercises, ready for comment and review. Would you also like me to have a go at re-writing/editing the links chapter on the gym to update the information there?
1 Like
Hi @_pyramid,
I’m probably not the best person to answer your questions, since I’m on the same part of the learning curve as you are.
Assuming I’m not making mistakes: Paths are the successors of or an improvement on anchors. The docs are not brought up to date yet. I believe the team is laser focused on adding functionality.
That said I’m currently using the following analogy in my head.
Paths are like labels in gmail: you can have 3 mails with these label:
mail 1 - work
mail 2 - work/projectx
mail 3 - work/projectx/meeting
When you fetch mails for the label: work you get 3 mails, mails for label projetx: 2 and for meeting 1.
And links, in my mind are more like mailthreads. There is an incoming mail, then I reply, then I get a reply on the reply. This would be something for what you would use links.
I cannot really help you with this at the moment. Still learning myself.
I’m merging it in the solution branch at the moment. I will merge into master, after the tests have run on solution.
Yes go ahead!!
1 Like
I’m thinking about improving the setup of holochain-gym users:
The idea is as follows:
you start nix-shell from one place only, the root of the repo
$ ~/developer-exercises: nix-shell
and you build and run test with scripts
$ ~/developer-exercises/basis/0.entries: ./run_build.sh
$ ~/developer-exercises/basis/0.entries: ./run_tests.sh
In these scripts is a check that verifies if you are running in a nix-shell.
You can check it out in my fork: https://github.com/tixel/developer-exercises
Let me know what you think.
ping: @guillemcordoba @_pyramid
Hi @tixel, thanks for the reply and explanations, it’s helped me better understand the utility of Paths. Seems to me like Paths offer a richer pattern to discover data by way of node hopping - that is, if you know the work path then you can hop to meeting without having to return and query projectx in the middle. Once the docs are up to speed, I’d like to see the interplay between Links and Paths. It looks like you can actually gather link data with this children function, which seems to indicate that you query a Path, find the deepest section that relates to your data and then return the links. Keeping in theme with the mail client, this might be a good exercise to try: query the Path down to the level of meeting and get all the entry posts that have been linked with the ‘meeting’ link.
You can check it out in my fork: https://github.com/tixel/developer-exercises
Looks good, this would definitely cut down on the number of nix environments we need to make! I can’t imagine there would be many instances where we’d need to change the environment, only to add more packages relating to specific examples. In that case, we might as well load it all up on the first nix-shell call.
Hi @tixel and @_pyramid thanks for all the work and interest
I like a lot the simplification for the setup. It seems the nix files setup is quite hard to understand at first because it’s not really that usual, so simplifying is cool.
About paths:
- Paths are just another entry: in reality the hdk only exposes helper functions to help you, but you could achieve the same things by implementing your own functions. Paths themselves don’t add any other primitive to what we already have available: entries, links and headers.
- Paths are the successor of anchors:
- Anchors are normal entries that are committed to the DHT, but everyone is able to compute them beforehand (eg with a hardcoded function in the zome code).
- Since everyone knows the anchor’s content, everyone can compute it’s hash without any request.
- Example:
- Everyone agrees that when creating a
Postentry, a link will be attached from the anchor to the post. - If I want to get all posts in the DHT I just need to do a get_links on the anchor, and I will get the hashes of all the posts.
- Everyone agrees that when creating a
- Paths are like a tree of anchors: to avoid having a million links attached to the same anchor, we subdivide them into “little anchors” segmented by what the app deems important to query for (in the gym example, this is by time).
- With this, you sacrifice storage (you are committing more entries and links) for much better performance when the DHT scale: instead of having to load the million posts in this DHT, you can just get the 50 from the latest hour.
I think we need a first exercise on Anchors, where we could manually implement anchors to see that there is no magic underneath, just normal entries, and then go ahead and delve into the complexity of paths. What do you think?
3 Likes
Wow. This is a great explanation! I understand much more about Paths now, so thank you for writing all of that 
I think we need a first exercise on Anchors, where we could manually implement anchors to see that there is no magic underneath, just normal entries, and then go ahead and delve into the complexity of paths. What do you think?
I think this would be good stepping stone, yes. When we give the user an ‘aha’ moment by showing them how anchors are just entries that can be pre-computed, adding Paths on top of that becomes a lot smoother. What do you think @tixel
1 Like
Yes, seems like a good idea. I do think anchors should be part of the intermediate section if they build on entries, headers & links.
I’m thinking about the following structure working as guide for tackling more chapters.
BASIC
entries
hashes
headers (rewriting this at the moment; taking out the update/delete stuff)
elements? (not sure if this merits a complete chapter)
source-chain (could be expanded a little bit more)
visibility (public/private entries)
links
INTERMEDIATE
dht
anchors
paths
remote-call
capability
update & delete?
Does this make sense?
1 Like
It does… I would put links before headers I think, the basic thing you are dealing with when coding holochain are entries and links, so for me it makes sense to start with that.
And also mabye update&delete before remote-call? It feels more natural that way
1 Like
Agree with guillem’s suggestions, that makes sense to me.
elements? (not sure if this merits a complete chapter)
I think this could be useful; even a shorter chapter is better than not knowing. I’d also like to see a chapter for how to handle Validation, which might come under the Advanced header. On that note, what other topics would potentially be covered in that section?
Over the next few days I’ll work on re-writing the links chapter and consider writing up a challenge task for links, which might just involve using the code in Master to write a more in-depth test for Tryorama.
1 Like
With all this movement, it is starting to be necessary to have some sort of task tracker thing. Are you okey with me setting up a github project to keep track of it? @_pyramid @tixel?
2 Likes
Yes I think that’s a good move; it’ll save us from having to backtrack through the forum to figure out who is doing what 
Happy for you to set that up
@tixel are you okey with me putting the links exercise before headers? And is the headers exercise ready to be published? No worries, I can deal with the reorganization of the folders and the exercises - as always, amazing work
Yes links might be a good fit after hashes. We should try it.
Headers chapter is done for now. So publish away. I did not have the time to publish this morning.
Thanks for the heads up on rearranging folders. Always ennoying when you want to merge changes at the same time folders change places
1 Like
Just published the headers chapter 
3 Likes
Hi Tixel! Just read through the Headers chapter and I have some feedback
Loved the thorough write-up of this one. I felt it touched on some important areas such as reinforcing the conceptual split between headers (as lightweight) and entries (as clean). Also good to highlight how Linux Epoch time shouldn’t be used as a ‘clock of truth’ within the entry. I made some notes during my readthrough so I’ll paste them in here:
Is there a missing section in the Getting Ready Holochain Playground panel? I only see 3 panels: Call Zome fn, source chain and entry contents. There should be a panel that returns the content of the get_ calls, right?
When you click on the blue square, you will see a blob of json data, similar to the one you see below. The response you get is something that is called an element in Holochain language.
This section is interesting because the Element structure displayed in the code box is different from the content of the Entry Contents panel when we click on the top-most blue header. It might be worth clarifying here that the header entry contents and the standard holochain element are different (I think?). Otherwise the impression of this text section is that a user should click on the blue box and then expect to see a 1:1 header with entry and signed header.
Nice little explanation of the need to unwrap the ExternResult get call with that WASM-specific piece of code
When you mention Linux Epoch time as an attack vector, that might be a good time to suggest an alternative such as header_seq or something else for chronology? Probably don’t want to crowd the reader with too much detail so you could say the alternative and then defer to another section.
**
I’m going to try my hand at the actual exercise right now + solutions so I’ll report back with any suggestions about that.
Also did you write up the anatomy section in Requirements? For some reason I only just saw that recently; anyway that whole Requirements section is brilliant stuff.
1 Like
Whoops point 1. is my fault, I recently split out the results from the CallZomeFns panel. I’ll add that in.
Just for clarification, elements are headers plus their accompanying entries. Some elements have entries (for example when the header is of type Create), some elements don’t have entries (for example when the header is of type CreateLink).
I think it would be good to have a separate Elements exercise after the header’s one? We are discussing that with @tixel here.
1 Like
I also like the exercise, although I feel it could be split up between headers (just focusing on the header and what it contains) and elements (creating an entry returns the hash of the element, getting by header hash returns the element).
I also put some feedback for the source chain exercise here @tixel , but maybe it’s not that practical to be commenting on the issues themselves… Maybe creating a forum thread here for every discussion is better and just have github issues for task management?