You can find all the cool examples of the stuff that you’re trying to do at https://github.com/holochain/holochain/tree/develop/crates/test_utils/wasm/wasm_workspace.
1 Like
Basically, there’s no zome macro anymore (sort of like implicit by cargo project’s lib name, whose name is the zome’s name which can be queried from inside the zome via zome info - magic if you ask me), end-functions can simply be declared as hdk_extern, and voila! Plus they are atomic and have their own scratch space for a workspace (so if you commit an entry and in the next statement wish to retrieve it, then although technically the entry hasn’t been committed, you will still get the right entry back); those functions are simple enough wasm functions and accept one argument(which is great if you ask me) and return one result, both having a consistent convention(serialized arguments, ExternResult result type); you can have vanilla rust code almost everywhere else. Callbacks such as init are just the same and have their own consistent return type (InitCallbackResult for init and so on). With the new entry_defs, defining entries is a child’s trick! There’s no goddamn need to declare what entries you’ll be linking to what else like in the previous version (thank God they did away with that; was one hell of an experience!) There’re simple validation functions for entries and links, one for each (switch-style figure out what entry you’re dealing with, or use a syntactical sugar - i.e. validate_blablablaEntry that already does it for you and puts you in the appropriate context). Update loops don’t happen anymore, 'cause it’s header-hash that most hdk functions expect and return as opposed to entry hash; an ‘element’ is what you ‘get’ now, which is basically just an encapsulated header-entry pair. Plus there’s a lot of cool stuff like emit_signal that I haven’t really looked into yet; and a bit of absolutely meaningless useless scum that apparently got full first-class support in RSM (i.e. capabilities!! Never mind, it’s just my personal opinion). And lastly, you can skip all these HDK abstractions altogether and use the underneath API directly, giving you more control while doing more complicated operations that the seemingly simple hdk can’t handle (which quite frankly I don’t think are any!).
Experts, please correct me if I’m wrong anywhere 
1 Like
Looks 99.95% good to me! Thanks for providing this summary, @The-A-Man!
Only a few clarifications/corrections:
This is true about both host API functions and the callbacks you’re expected to write (including zome functions). My clarification is that the single argument could be seen as an ‘args object’, so any function that wants to take multiple parameters should have its own struct with params as properties. You see this in a lot of the host functions. Feels very Smalltalk-y to me
that was a hard adjustment for me, and I’m glad they have the syntactical sugar functions to make it easier. My correction is that the convention for validation callback names (given an entry type of foo) goes like this:
-
validate_create_entry_foowill only be called forcreateactions that speak entries of typefoointo existence -
validate_update_entry_fooandvalidate_delete_entry_foowill do the same forupdateanddeleteactions -
validate_create_entrywill be called for all app entries in this zome, even ones of typefoo -
validate_create_agent_id,validate_update_agent_id, andvalidate_delete_agent_idwill be called for the agent ID sys entry (there are two other sys entry types,cap_grantandcap_claim) -
validate_create,validate_update, andvalidate_deletewill be called for all app entry and system entry types -
validate_create_linkandvalidate_delete_linkwill be called for all links (created by this zome? not sure)
One interesting thing is that these functions ‘cascade’ – that is, if you’ve defined validate_create_entry_foo, validate_create_entry, and validate_create, all three of them will be called in descending order of specificity until one returns an indeterminate* or unsuccessful result.
* By ‘indeterminate’ I mean that maybe a create-entry action required some DHT data for its validation but that data couldn’t be pulled from the DHT – in this case your validation callback can give back a list of hashes it’s waiting for, and the conductor will try again later.
Glad you like the new HDK so far too — I got good feels from it when I got my first glimpses of it. (Except validation functions – I hate switch statements. Glad to see the added sugar now.) What is it you don’t like about capabilities?
Sorry to hear about everyone’s experiences on WSL2 — a few months back, I had someone help me test all the tutorials on WSL2 and he didn’t hit any roadblocks. Is it WSL itself that crashes, or the Holochain runtime, or the Rust compiler, or something else?
What I found frustrating with running Holochain in Docker is that, because the HTTP and RPC-over-WebSocket ports were bound to 127.0.0.1, everything UI-related had to be inside the Docker container. I tried so hard to set up SSH tunnels to the host and never could get it to work. Did either of you have any success?
2 Likes
Oh, I missed this resource:
2 Likes
Well, yeah, for me it was WSL that used to crash upon running any extensive workload in it (even hc-install would crash it sometimes)… Doubled the RAM of my VM and never had the same problem ever since.
Well, it has got more to do with the priorities… I can’t yet imagine any sense-making use-case for capabilities! It’s more of a leisure feature, and it’s not the time yet for Holochain to be building leisure-features! They’ve got their priorities all wrong (never mind please)! I would rather have loved to see countersigning be implemented first.
And yeah, now that you mentioned it, I remember thinking what Holochain’s approach might be regarding events (human actions that have repercussions sometime in the late future)… I think they’re unlike other use-cases like Artificial Intelligence which gladly Holochain doesn’t even pretend to support (unless you can model neurons as agent-ids, hahaha)! ‘Events’ is pretty much a very good candidate for social human-centered apps (i.e. Holochain-supported apps).
Let’s say that you would like your post to be automatically deleted after 40 days. In the microservices world, it was as simple as spawning some routine-deleter service which does it for any post that was published 40 days ago. However, in the Holochain world, there’s no obvious solution for such use-cases… Sure, you can say to your customers that “hey, we’re not your servants; if you wish to delete your post after 40 days, then set-up a reminder in your phone and then delete it yourself when the day comes!” - against which I can’t find any technical argument though, haha. And besides deferring such use-cases to a smart-enough user-interface (i.e. the ios/android app in this scenario), there’s not much you can do about it currently… Plus the below code doesn’t look safe (at least to me it doesn’t):
// HDK extern function
#[hdk_extern]
fn post_a_post (...) -> ... {
// commit the entry and stuff like that...
// wait for 40 days (sleep, or whatever)
// delete the entry
}
Any ideas???
It’s a much more general question about the limitations of agent-centrism, I understand… But there’s not much app-remodeling you can do either (at least without upsetting your customers, as illustrated above)… And modeling such time-bound use-cases as full-fledged agents, much like some ancient mythical God-Of-Time (or perhaps Doctor Strange in Marvel’s jargon) all spawned and maintained by the developer… would make for a great comic book! I guess our life as Holochain developers would be a lot simpler if everyone could just stay connected and paired to their host and peers online all-the-time! But the sad reality is that this isn’t the case, at least as of now… For instance, if that were the case, node-to-node messaging would have sufficed (no need for asynchronous DHT messaging) and thus privacy would have stayed preserved! But you can’t move to private-keys up the ladder and to the host’s device, 'cause that would mean a total loss of sovereignty, privacy and would become the same client-server model that dominates today… What’s the workaround???
Looks like it warrants it’s own thread
Moving the conversation on “events” to its own topic in general-discussions.
@The-A-Man are you worried about nodes going offline? I wanted to clarify your concern
@pauldaoust I do have questions about early stages where peer nodes are limited and some could go offline for periods of time. Is better to build inside the main membrane in the beginning? Or will Holo always maintain a certain number? Would it be a smart idea to just design failsafes into the DNA? ie recommended thresholds? Will it be easy to design our own gossip protocol or should we plan to piggy-back off Holo’s initially?
I hope these questions makes sense and lmk if they’re better asked in the WaterCooler or somewhere else. Thanks Paul
Good to hear from you @pqcdev.
Well, sort of both (both hosts going offline and the user going offline). You see, traditionally there was a server somewhere, always running and doing the stuff for you that you didn’t want to bother yourself with (could be collaborative filtering, could be auto-liking what others post, etc)… But in our world of Holochain??? Nothing! All those cool features (like auto-liking) sort of become impossible! And that’s a big drawback if you ask me… Sure there’s a lot of buzz over data-privacy and stuff like that, out there in the wild… But I don’t think people’s concerns over privacy are so much that they would rather trade-away those cool-functionalities that they’re so used to, all for privacy!
1 Like
I had the same concern till I fully understood the architecture. We gotta build all that stuff. It’s up to us, the devs. There could be weak dHapps (membranes) out there, sure, I think it’s important for the community to think about how to handle those situations. In the masses mind its always gonna affect the overall brand. PR will be important, I would like to see more of that from Holo eventually. My perception of the development team is that they’re strong. My favorite part about being here in this space is that so many people are enthusiastic as well as altruistic, especially the core team.
Still, I’m like you and analyze potential flaws, I tend to look for weaknesses wherever possible, clearly there is alot of value in that. Check DM we’ll talk about the quantum threat to all of cryptography.
The biggest initial factors of Holo success imo will be: software functionality, number of nodes as well as their efficiency + participation, marketing/PR/customer service, GUI
1 Like
Ahh, got it. If I can shed some light on that: capabilities are a prerequisite for countersigning, because countersigning is initiated via Alice RPC’ing Bob on the DHT. But Bob doesn’t want any old person calling any of his functions, because that gives them agency over his cell/source-chain/existence! So some functions (e.g., the “initiate countersigning” might be wide open – or, alternatively, assigned only to certain agents to prevent spam). That’s what capability tokens are for. Yes, you can reject callers in code, but I think Art and co expect it to be such a common use case that why not put it right in the framework?
Hmmm, I think I’m tracking with your questions? I’ll try answering and you tell me if I’m off base.
I think there is definitely a risk of having a DHT disintegrate. Some really common use cases I’m thinking of – private team chat channels (where a team is <= 5 people), for instance – would struggle with this problem all the time, not just at first. Two ideas come to mind:
- In situations where there’s an always-on computer (say, an office with a file server), make it really easy to install a headless Holochain + hApp that don’t contribute any of their own data but simply claim authority for the entire DHT address space.
- In situations where it’s just a bunch of people (say, family chat), the hApp dev can hire some Holo hosting time – but again, just as a DHT backup. There isn’t any guaranteed resilience, just market forces that make hosts more or less likely to pick up your app and host it. (Heck, the app publisher could run their own host and charge themselves 0 HF for that particular app!) The usual concerns/approaches about security apply here – consider encryption, or wait until a market for certified-privacy-compliant hosts appears.
2 Likes
Ahhh, now I see… Thanks really for explaining it in your words. Now it makes sense…
So how do I get started with RSN on Windows? Been waiting months now to get started with it but no-one has been able to help me even get it up and running yet…
I was holding out for it to be blessed but I really want to use it now…
I really hope someone can help…
I am surprised anyone else has been able to get it working if they followed the instructions on the site because they obviously do not work… 
From what I read its WSL2 itself that has some sort of memory leak so hopefully that will get fixed soon!
woah, actually my dev preview windows machine stopped booting at all 
For some unknown reason I have now started getting connection refused error messages back from the conductor? It was working yesterday and I have not changed any code or network config, etc so very odd!
Any ideas?
This is with redux version.
It is running in WSL2 in a nix-shell for holochain.love as per the docs.
Is it the conductor, NixShell or WSL2 that has started refusing the connection? How do I troubleshoot this? Thank guys.
Also, still waiting for CLEAR instructions on how to get onto RSM ASAP… As I said before the instructions on the site and do not work and you end up with just the Redux version as you can see from my above posts…
Cheers
D,
Hi @dellams I’ll have to defer to @thedavidmeister or @steveeJ on your connection refused issue, but as to this:
Yep, developer.holochain.org still has the old installation instructions; I’m hoping to rectify that by next week. In the meantime you can use this readme: https://github.com/holochain/holochain#using-nix-shell-on-a-local-clone (note that ‘local clone’ here means that you have to clone the holochain/holochain GitHub repo).
I was just assembling another minimal test happ but couldn’t get the tests working… (I’ve simply skipped Tryorama testing hitherto). Can someone please look in to see what I’m doing wrong? Though there are mostly core devs around here, I still think it’s something quite simple/silly that I’m doing wrong and shouldn’t be hard to spot for you experts… Waiting for reply…
After npm install,
Upon npm test,
Github link: https://github.com/the-a-man-006/damnpost
[Reusing @guillemcordoba 's test code for the calendar-app]
What seems to be the problem?
Tests seem to be running, the errors that you see are normal in real tryorama trying to connect to non-existing agents.
1 Like