HDK Wish list

Open guillemcordoba opened this issue 3 years ago • 22 comments

Pretty much needed

[x] Remove unnecessary verbose types:
- https://docs.rs/hdk/0.0.101/hdk/prelude/struct.Links.html
[x] Ability to get the provenance with maybe agent_info? (agent pub key that called the executing function).
[ ] Ability to easily call another cell in the same happ referring to it by its nick.
- Right now I have to hardcode the hash of the DNA in the other DNA's properties, not ideal and will break with change of UID or properties.
[x] Sleep. // For now, this may be covered by schedule()

Pretty please? :)

[ ] Improve developer experience of converting an arbitrary type from and to LinkTag (with SerializedBytes?).
- This is how it is right now, a bit confusing.
[ ] remote_signal requires an ExternIO::encode that is not necessary in other similar HDK functions.
[x] Ability to get the names of different zomes in the DNA.
[x] Right now it's pretty verbose to have a workable timestamp from sys_time's Duration.
[x] Remove Links type, it seems a leftover from the days in which only types with SerializedBytes could pass the wasm boundary, right now I think it only adds complexity, it's a bit confusing for new devs until you find .into_inner().
[x] Remove HeaderHashes and HeaderHashedVec, same reason as with Links.
[x] Enable Get Agent Activity in validation rules. This has been discussed with @thedavidmeister as changing the input of that function to a range of header hashes to make it deterministic.
[ ] Add the author of the link to the link struct.

Other ideas

[ ] host fn builder to batch heterogeneous fn calls

Jul 23 '21 07:07 guillemcordoba

Pretty much needed

[x] post_commit (interested in helping)

Pretty please? :)

[x] ability to query source chain for a specific Entry in constant time? (e.g. query by EntryHash)... might be shooting for a moon here

Jul 28 '21 08:07 tatssato

Just some quick responses to some of these items from @guillemcordoba & @tatssato

Pretty Much Needed Items

Yes... to all of these with one caveat, I think it will be confusing to have caller info in the agent_info (which is about who YOU are). However, I've documented a call_info() which let's you inspect the context the current running zome call was made including:

source -- network, client API, local cell, cross-zome (within current DNA), etc.
provenance -- calling agent info
permitted functions -- the functions unlocked by the cap token
captoken hash -- which captoken is currently in play (maybe?? -- I'm not sure wasm should be able to access this because it could leak secrets in the captokens)

Aug 18 '21 17:08 artbrock

Pretty please

[x] Find out own source chain top hash in constant time (Current only way is to call hdk::chain::query() with no filter)
[ ] Create links with the base or target or both on a header hash instead of entry hash

Sep 30 '21 12:09 timotree3

Request

[ ] Be able to get the UID back from AppInfo call. Maybe this is what distinguishes AppInfo from ZomeInfo?

Sep 30 '21 16:09 zippy

[ ] maybe this https://github.com/holochain/holochain/issues/743#issuecomment-896446332

Oct 04 '21 10:10 thedavidmeister

[ ] and this https://github.com/holochain/holochain/issues/976

Oct 04 '21 10:10 thedavidmeister

[x] and this https://github.com/holochain/holochain/issues/339

Oct 04 '21 10:10 thedavidmeister

Timestamp has been heavily refactored and standardised by @maackle and also sys_time returns a Timestamp instead of a Duration so we don't need to move between the two so much, which is awkward anyway as the former is an absolute time and the latter is an amount of time - there's no way to automatically move between the two without making some big assumptions about what the Duration is relative to

Oct 04 '21 10:10 thedavidmeister

at least a test for https://github.com/holochain/holochain/issues/693

Oct 04 '21 10:10 thedavidmeister

[x] another common request is that permissions issues should not panic either

Oct 04 '21 10:10 thedavidmeister

Request

* [x]  Be able to get the UID back from AppInfo call.  Maybe this is what distinguishes AppInfo from ZomeInfo?

This is going to be available in Properties in AppInfo call.

Oct 19 '21 19:10 artbrock

[ ] new structure for AppSignal to indicate the zome that the signal came from, along with a more structured payload

Instead of this:

 AppSignal = {
    type: string;
    data: {
        cellId: CellId;
        payload: any;
    };
};

this:

AppSignal = {
    type: string;
    data: {
        cellId: CellId;
        zome_name: string
        payload: {name:string, data:any};
    };
};

[ ] Improved documentation on what the type field represents..
[ ] An expected Payload struct type in rust for zomes { name:string, data:any} where we can get the signal name and than arbitrary data with any structure

Nov 11 '21 18:11 nphias

[ ] an as_ref_mut accessor to the Vec<Component> list in a Path ( this allows it to be used with vec append)

Nov 11 '21 20:11 zippy

[ ] re-export holo_hash with the "encoding" feature so we don't have to keep enabling it in our Cargo.toml if we want to use B64 hashes:

[dependencies]
derive_more = "0"
serde = "1"

hdk = "0.0.115"
holo_hash = {version = "0.0.12", features = ["encoding"]}

Nov 12 '21 09:11 guillemcordoba

[ ] allow local signals to be emitted from post_commit callback

Dec 07 '21 18:12 pdaoust

[ ] have dna_info() return also a "base dna hash", i.e. a dna hash generated from the dna without or with default properties, and expose this also in the conductor's APIs.

I think this would greatly improve implementation of cross-cell UI's in that it would be possible for UI's to detect compatible cells within the conductor. Concrete example: A calendar UI can easily ask the conductor for all dna's of one or multiple compatible base dna hash(es), although they each have a different network seed, and render all calendar events from all compatible cells.

Sep 05 '22 11:09 matthme

have dna_info() return also a "base dna hash",

I almost wish that the DNA identifier contained two parts concatenated together: the hash of the wasm, and the hash of the meta info (netseed + properties + origin_time + ...), so that one could always determine the "base hash" for compatibility reasons, but use the concatenation to determine the network identity. That might be too invasive at this point though.