Passing AgentPubKey from UI to backend

Technical Discussion App Development
#1

Hi all -

I’m experimenting with UI development a bit more, and have made pretty good progress using the awesome RAD scaffolding tools.

Something I’m a bit confused about is how to handle different data types, and how to correctly call Holochain functions from values obtained in the UI. The example I currently have is as follows:

  • I have a list of all current users in my UI. The data from my ‘list_users’ function returns:
    nickname: string
    playerId: Uint8array
  • My console output shows the playerId value as base64:
    Profile { player_id: AgentPubKey(uhCAklmrhG4uKAWJsJI64rqOTBj47L1fDbRuqsM82BbcwQ6WFDqbY), nickname: "alex" }
  • In my UI I want to select a player to issue a cap grant to. This selection will either give me a JSON object or a string.
  • Now I need to pass this value in to my ‘create_capgrant’ function:
await appWs.callZome({
          cap: null,
          cell_id: cell_id,
          zome_name: 'myzome',
          fn_name: 'create_capgrant',
          payload: {
            function: "some_function",
            agent: var_containing_selected_agent_pubkey,
          },
          provenance: cell_id[1],
      });

But this is giving me errors and I think it’s about the way that the UI is sending back a valid AgentPubKey for the function to use.

So - in the UI I can see all AgentPubKey’s as Uint8Arrays. I have tried to convert these to Base 64 before sending back, but the resulting value is quite long and doesn’t look similar to what I see in the console.

What is the correct way for me to send AgentPubKey back to the create_capgrant function?

Thanks for your help - alex.

1 Like
#2

actually I just noticed in Holochain Gym on Capability Tokens page (Intermediate: Capability Tokens: Holochain Gym) it says:

  • Calls from the UI (this is not working yet)

So does this mean it’s not even possible ??

#3

Thanks for asking this question! I’m actually trying to do something very similar at the moment,. Passing a header hash to the UI, then back to the DNA, but can’t get the DNA to recognize it as a header hash when it comes back…

#4

yeah, same issue!
I have a feeling it’s something to do with base64 vs not-base64. I recall there were some changes in approach to this (?) over the last few versions of holochain.

My app is in 0.0.115, and doesn’t use any base64 entries. I was looking at GitHub - holochain-open-dev/profiles: Profile management with at least a nickname as a reference, which is 0.0.118 and seems to explicitly use base64 for agentpubkey - which is used to pass from UI to backend for some functions.

Might be a red herring, but I’ll try and follow that pattern to see if it makes a difference.

1 Like
Error: source chain head has moved since the bundle began
#5

I came across this wiki page describing one way to get the hash (HeaderHash in my case) from the dna to the ui as a string, not a byte array: How To Pass A String to a Client Instead of A Buffer for Hashes · holochain-open-dev/wiki Wiki · GitHub

This worked, but it’s the other direction that’s my actual problem (ui to dna), and this library did not seem to help me there.

I tried another approach: pass a base64 string to the client and pass the same string back to the DNA and manually convert it to a header hash. For this I used holo_hash, something like this example:

But none of the string to hash conversions from holo_hash were available, even when I copied one verbatim from the holo_hash unit tests.

Then I noticed in the hc_utils cargo.toml they specify that they want the encoding feature of holo_hash:

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

…so I’ll try this next — adding the same to my cargo.toml — and see if it helps.

#6

I wrote that old article, the modern incarnation is HeaderHashB64, such as : syn/commit.rs at 198e9d7a84472ce6071b6372d38b1038be573868 · holochain/syn · GitHub

1 Like
#7

Yup, that worked, thanks @Connoropolous .

@robot5x does this fix your issues as well?

#8

Btw…
this will solve things when dealing with HeaderHash, AgentPubKey, EntryHash, etc, in your own Zome/DNA/happ codebase, but won’t solve for you if you have to convert back to a Buffer/Uint8Array and call non-zome AppWebsocket (appInfo) or AdminWebsocket calls… those will all expect Buffer/Uint8Array style hash encodings… so…

to read deeper into how those conversions can work, here’s a couple pointers…

While writing up a section of the happ-client-call-tutorial @jost.schulte and I tried to inquire into the situation. You can see here we tried to diagnose it: Add TypeScript example & update readme by jost-s · Pull Request #2 · holochain/happ-client-call-tutorial · GitHub

One of the references for that discussion, and a utility that Holo uses a lot in its client side code is GitHub - Holo-Host/cryptolib-js: Cross-compatible cryptographic utilities for node/web which handles these holochain specific conversions between string hashes and Buffers.

1 Like
#9

Great info Connor, thanks! On the last point, there is another client side lib for converting hashes between strings and bytes: GitHub - mjbrisebois/js-holo-hash: A Javascript library for managing Holochain's HoloHash types — mentioning in case it helps readers of this thread.

1 Like
#10

Ok good to know, I’d missed that one. I know @brisebom has a bunch of good stuff though that I’m not sure many people know about yet!

#11

it turns out this issue was ‘related’ to the very dumb mistake I made in another thread. The cause was very stupid but, because I didn’t think I could make such a stupid mistake, I went down a rabbit hole thinking it was about all these other things. Phew.

Once I’d sorted my profile management out, it turns out I can just pass the UInt8Array straight back to holochain from the UI and it works fine. :woman_shrugging:t5:

on the plus side, your issue is fixed and I learnt A LOT more about holochain data types :upside_down_face:

1 Like
#12

coding, 25% of the time

1 Like