One of the things is the caller-pays model.
Certain functions (i.e my-contact-list) could be free; but certain other functions (assuming I was a genius ; which I am NOT; my-NFT-holdings-as-percent) could be called by others on paying some cycles.
I am baking this into the UI
While on the topic of pub-sub, the other use-case is:
In multi-sig scenario,
Assuming all principals have their own wallets,
how to notify principals of needing
accepting a proposal
prior to signing the proposal
If it just shows up in their list, it could be chaos (unless there is payment associated with putting it in their list). Also accepting a proposal should likely involve payment.What would an example usecase of this be?
Multi-sig where 2 of 3 members of a board must approve a transaction of tokens to another account.
Scenario Setup:
Two Souls
A. Needing to calculate USD value of spawned ICP as a result of merging maturity of a neuron.
B. Providing the service of calculating this USD value by tracking value of ICP at relevant time interval.
Soul A knows about Soul B service and asks permission to call SoulB’ s service for a price; passing the principal.
SoulB accepts and Service is enabled for Soul A.
SoulA call the requested service and gets a total value of the icp spawned to be reported to tax authority.
So the 3 board members would be owners of the same onchain wallet (by adding their principals to the onchain wallet’s owner list), and when they create and sign a multisig transaction the onchain wallet would use call_raw to make a function call to the plug wallet that initiates the token transaction? How does the onchain wallet have access to make that call? Even if you give the onchain wallet the plug wallets principal, dont you still need a password or something?
No, they would call the canister directly. The canister would own the tokens. Plug would.onky be used by the users to approve. It wouldn’t hold any tokens.
Oh, so the wallet owners would be the plug principals. @mparikh brought this up but how would the plug wallets get notified to sign a multisig proposal?
That is a bit of a different problem for an organization to solve. Ideally the person making the proposal would get a link and notify the other signers by email/msg to go and approve/reject. You could script this out to auto notify as well similar to how the NNS telegram bot works.yoi would need an endpoint to list open proposals.
Is anyone working on this bounty yet?
So this turns out to be quite interesting. The pending proposals is a view from a signing principal. As noted in the UI, the signing principal may have pending proposals from different requesting principals. The signer can sign multiple proposals at the same time.
Two main questions:
(a) how does the signer get the proposal to be signed in the first place and how does the signer actually sign
i propose a pub-sub mechanism similar to kafka; except that internal storage occurs within the signing canister. This solves the issues of malicious canisters making the calling canister wait forever.
(b) how does the signer verify plain text of the proposal against what the proposal actually does
Acttually insert the proposed payload into the proposal
EDIT : This means a pull from the signing canisters (heartbeat) and storing watermarks ala kafka consumer.
EDIT 2: The Voted-On proposals will go through a similar reasoning establishing the need and use-case for pub-sub
I don’t think anyone is working on this yet. However it is a pretty interesting and ambitious project. If done correctly, this can be very influential. It does require a distributed pub-sub mechanism
Yes it looks challenging indeed, but I would like to give it a go, I could also use some help on the way.
I will wait for a confirmation from @skilesare
If you don’t mind, as suggest in this post by @skilesare , let’s iron out the major architectural issues and roadmap ahead of time.
I am trying to reason it out through the UI and what would we need to build out the backend. That pub-sub is non-trivial; but absolutely critical as many are facing the same issue… what to do about buggy/malicious canisters.
I got a lot out of the questions asked by @JaMarco and answered by @skilesare .
EDIT : For example, we could do away with multi-sig for the first version.
Well I was in the process of understanding the all the requirements with the intent on working on it.
cool ! We have a team. Actually this work could use a grant. I know dfinity is matching this; but this is more substantial. @diegop @skilesare your opinion?
@jorgenbuilder was working on it, but is currently distracted by Supernova. We should check with him about his status, but I think if others are ready to work on it then we could figure something out.
@mparikh. Can you explain the pub sub a bit? I think we’re fairly safe with doing synchronous calls as one can be responsible for vetting the called canisters themselves. If it is safe to have sync calls from plug it should be safe to do so from here. Unless I’m missing something!
Pub Sub would be interesting for sure, but I’m not sure it is required.
The voted-on proposal is also the view of the signer. It turns out that this view requires a “roundtrip” back to the calling canister… also accomplished through pub-sub. However here the eventual disposition of the proposal is also recorded…therefore the data structure in pub-sub would need, amongst other things, a witness (in context of a merkel tree).
Here’s the background and reasoning about the pub-sub. This is going to be a W(all)OfT(ext).
But the main reason that we need a pub-sub is because of my reading of this spec:
//calls the function and either executes the function or creates a proposal to execute the function;
call(principal: Principal, function: Text, data: Blob) → async CallResult;
As I mentioned before, this function could await for a non-trivial (1 day?) time-frame because in a multi-sig scenario you would need a majority of principals to sign…if all principals need to sign on a manual basis, it could take a while. How/When would you return the value? My reading of this specification could be wrong.
A secondary point is to automate the notifying of the proposal to be voted on. Essentially we are polling on this from a pub-sub standpoint; except that we are doing in all in context of IC.
The other stuff is more visionary. Essentially I want to turn the narrative of cycle-wallets on it’s head to become a “digital twin” of a soul/person. I want this “wallet” to represent me in the digital world.
In the condensed version, I want the ability for this canister to hold my tokens, my nfts. But in addition, I want to publish services under my control that others could find to be useful to call (my rolodex,my pics etc). I want to develop my reputation on-line in a provable fashion; so that others can trust my reputation. I want to participate in group economic activities.
In this context, I want to be a signer to multiple called canisters; each one of them doing a myriad of different things. In this world, point-to-point connectivity is not scalable, imo. Imagine a world in which signing a proposal to add a principal as a signer to a multi-sig wallet is only one of many other use cases.
I can expand on anything required.
EDIT: The best way to negate/rebut the need of pub-sub is to go point-wise and see whether these features are actually required or not (as mentioned in the UI/ and this WOT) and if they are required, how is that envisaged to work. For example, @skilesare brings up an good point of communicating out-of-channel on which proposals to vote on (email, bot etc).
It’s fine, I just didn’t see any one expressed their intent to work on it.
I can be your fallback if you decided not to take it, or we can team up, either ways it’s fine by me.
@mparikh your UI frames actually helping visualize how this could work and laying the foundation for the architecture, thanks for that.
