About the RSM Technical Discussion! category

After re-installing, My zome now looks like this:

#![feature(proc_macro_hygiene)]

use hdk::prelude::*;

use hdk_proc_macros::zome;

// see https://developer.holochain.org/api/0.0.51-alpha1/hdk/ for info on using the hdk library

// This is a sample zome that defines an entry type "MyEntry" that can be committed to the

// agent's chain via the exposed function create_my_entry

#[derive(Serialize, Deserialize, Debug, DefaultJson, Clone)]

pub struct MyEntry {

    content: String,

}

#[zome]

mod my_zome {

    #[init]

    fn init() {

        Ok(())

    }

    #[validate_agent]

    pub fn validate_agent(validation_data: EntryValidationData<AgentId>) {

        Ok(())

    }

    #[entry_def]

    fn my_entry_def() -> ValidatingEntryType {

        entry!(

            name: "my_entry",

            description: "this is a same entry defintion",

            sharing: Sharing::Public,

            validation_package: || {

                hdk::ValidationPackageDefinition::Entry

            },

            validation: | _validation_data: hdk::EntryValidationData<MyEntry>| {

                Ok(())

            }

        )

    }

    #[zome_fn("hc_public")]

    fn create_my_entry(entry: MyEntry) -> ZomeApiResult<Address> {

        let entry = Entry::App("my_entry".into(), entry.into());

        let address = hdk::commit_entry(&entry)?;

        Ok(address)

    }

    #[zome_fn("hc_public")]

    fn get_my_entry(address: Address) -> ZomeApiResult<Option<Entry>> {

        hdk::get_entry(&address)

    }

}

Is this correct? Still looks like the old version?

hc --version still gives: hc 0.0.51-alpha1 but holochain --version gives holochain 0.0.1. So which version is it?! lol

Cheers
D.

@guillemcordoba @sidsthalekar @hedayat @pauldaoust @pospi @raphisee @rayzer @philipbeadle @e-nastasia @martin

Any ideas? :slight_smile: Thanks.

REALLY keen to get stuck into RSM and port HoloNET, OASIS API, .NET HDK and Our World to RSM ASAP! :slight_smile: :slight_smile: :slight_smile: :heart: :heart: :heart:

I trust it is now ready for use following the latest dev pulses? :slight_smile:

How you all finding it? :slight_smile:

I know it is a LOT faster and hopefully easier to use? :slight_smile: Wish it was as easy to setup! :wink: lol

Cheers
D.

Would have been easier to set up had they chosen to stick with docker files and volume mount for source files. It would have meant reproducible builds without all this hassle! But perhaps weā€™ll all have to just ā€œgo with the flowā€ā€¦ Ought to say, weā€™re in the same boat, man. As for the new RSM syntax, Iā€™d recommend reading https://github.com/holochain/holochain/tree/develop/crates/hdk 's README by David Meister & Stefan Junker. Itā€™s the only succinct documentation on RSM that actually makes sense!!! (Forgive the pun)

1 Like

The elemental-chat happ has been updated and the tests are running perfectly as of latest, so you can play with that too.

2 Likes

Ok great thanks bro. :slight_smile: I just need to get it working first! :wink: lol

I have no idea if the zome I posted above is RSM or not? What version numbers do you get for hc and holochain? :slight_smile:

Cheers
D.

P.S. YES! Docker or something similar would have been a LOT easier! :slight_smile: Things were MUCH easier before NIX came along, HoloNET and the .NET HDK could auto-start/shutdown conductors then because there was an actual windows binary I could use, now itā€™s not possible with the Nix shell and it causes all sorts of memory leaks and problems on Windows with the WSL2. I PRAY one day they can grace us with a windows binary again! :wink: hint hint, nudge, nudge! :wink:

1 Like

Well, obviously itā€™s redux! And as for the second question, yeah holochain --version is 0.0.1 as of now. And donā€™t worry about the hc command, it wonā€™t be shipped in the future nix-shell builds (no idea when theyā€™ll remove it though).

Yeah, on WSL it did crash a few times for me tooā€¦ Letā€™s see how the future unfoldsā€¦

2 Likes

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 :slight_smile:

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 :slight_smile:

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_foo will only be called for create actions that speak entries of type foo into existence
  • validate_update_entry_foo and validate_delete_entry_foo will do the same for update and delete actions
  • validate_create_entry will be called for all app entries in this zome, even ones of type foo
  • validate_create_agent_id, validate_update_agent_id, and validate_delete_agent_id will be called for the agent ID sys entry (there are two other sys entry types, cap_grant and cap_claim)
  • validate_create, validate_update, and validate_delete will be called for all app entry and system entry types
  • validate_create_link and validate_delete_link will 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

@The-A-Man

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?

@pqcdev

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ā€¦ :wink: