I support @paulyoung 's proposal. It’s a small and relatively simple change to an isolated component (the HTTP gateway and the service worker), but unblocks a whole new class of services to be run on the IC.
I think you meant ICIP not IIP , so we would have ICIP vs EIP or BIP
I thought that Dfinity was going to be creating a user friendly UI to allow anyone to easily claim their seed or airdrop tokens. The current technical requirements are a significant barrier and it seems that it would be a basic requirement to create such a UI. It seems extremely unfair that non technical donors are just left to wait endlessly to be able to access their tokens.
Sadly it appears there is no plan to do so unless I have missed an announcement. In which case I propose that we add that as an item here. it is a relatively minor point and probably may be overlooked, but it’s really more than a nice to have item it’s almost a core requirement that should have been implemented on launch. Maybe this UI will have many other uses and benefits beyond just claiming.
Further exacerbating this issue are the rumours that unclaimed seed round tokens will be swept up. November was even mentioned as a date. I find this hard to believe since this action combined with the technical barriers presented to non technical donors mentioned above would be akin to theft.
Here is another feature I’d like to get on the way, if possible:
Certified queries
Our update calls are nicely certified by the system. The canister doesn’t have to do anything, and all these calls are signed by the subnet. This is not the case for query calls, which are pretty much insecure by default. Yes, in some cases canisters can use certified variables to fix that, but it’s not always possible, and even if it is, it is fairly non-trivial. So as @senior.joinu rightfully asks: “why don’t we make this safe by default”.
A very vague design was discussed internally once, in the document “Certified variables” (only internally visible, found the link in my browser history).
@diegop, do you have the authority to allow me to re-share my thoughts on the implementation publicly that I wrote into that document back then? I am not sure whether any of that might be considered a “secret” that I must not discuss publicly. But maybe it’s fine if the implementation is hashed out internally only, as long as we outsiders get the feature eventually 
It would be good to get this on the roadmap, as I think “secure queries by default” beholds the Internet Computer better than what we have right now. The current query methods could still be provided opt-in for those developers who made a deliberate choice.
Also, I think this can help with Inter-canister query calls; it might be the necessary solution for the question of “what do do with calls from query methods when in replicated state”. So it might be timely to discuss this variant too.
8 Likes
Agreed! It’d also be nice if that spec could support streaming uploads as well as streaming downloads, only the latter of which it currently supports.
2 Likes
Would also be really helpful if dfx could be open sourced.
Another thing: it’d speed up local development if the web server that’s bundled with dfx by default could be replaced with icx-proxy so that the dev environment is more similar to prod.
The current dfx web server constantly hangs in high throughput scenarios. Also, it doesn’t support http_request, making it really tough to test.
3 Likes
No I meant IIP, I think it works best, the first I stands for Internet Computer
Fwiw, we are working on a solution that is both safe and easier. The current best path is that Non-technical seed round folks should use the ledger nano app (in development for months, out soon). That’s the best safe way for them to claim their neurons.
To your point what I just said has not been communicated very well. Point well taken. I have told the team this.
I am not sure i do to be honest, but i know who does and I will ask them today.
Good point. This is actually happening very soon. I need to find out what status of this is. Last week it was “should be out soon”, so I will ask SDX team
4 Likes
Great point. This may be “a thing” or a simple feature someone can knock out. Let me ask them.
1 Like
This is great to hear. A ledger nano app would be a huge help and also far better for making easy to keep funds secured. So apologies for assuming the worst and thanks for letting us know the situation.
2 Likes
Linked from the main thread to @skilesare, who does a great job of explaining the issue. This is a request to add original_caller() in inter-canister calls to enable third party-composable services, which will be really important for DEFI and authorisation in other composable services.
1 Like
MVNO API ….
In telephony, a CFA or time slot w/ ability to collocate/scale.
Just tell us where to meet ya.
All the tools & the underutilized tariffs are there on the terrestrial side.
Am happy to be informed as to what real tangible opportunity in the IC system trumps this one.
Every client facing business plan in telecom/tech is about obtaining access and maintaining access to the client.
That is what this opportunity is ( it supercharges thousands of disparate business plans ) … oh including yours … yes I am talking to you … and you… all of you. All of your plans would get an octane boost from this.
You have built the world’s switchboard.
Asynchronous hoot ‘n holler is the easy part.
Let’s go.
Edit: moved to Idempotent egress messages (e.g send an email)
I propose that the Internet Computer provide a way to send some sort of idempotent egress messages. In practice, this would likely be a HTTP request to some external infrastructure.
One use case for this that comes up often is to allow canisters to send email.
@diegop explains some challenges with doing this here: https://www.reddit.com/r/dfinity/comments/p0ndzh/can_the_icp_host_email_apps/h88eg78/?utm_source=share&utm_medium=ios_app&utm_name=iossmf&context=3
I propose that those concerns be addressed by the following process:
- A canister makes a new system API call that is the equivalent of “Please make a HTTP request to X” (specifying appropriate payload, headers, etc)
- The “subnet” (perhaps every node, perhaps every node until some acknowledgement response is received) makes the HTTP request
- The receiver is configured to treat incoming HTTP requests as idempotent, using a request ID as an idempotency token.
- The receiver, depending on the nature of the action, can decide whether to take action once N requests with the same request ID have been received. For something harmless, it may perform the action when receiving the first message and do nothing when receiving subsequent requests with the same request ID. For added security, it may choose to only perform the action after receiving N requests with the same request ID.
In this scenario the receiver is the one actually sending the email, and it is up to them if and when to do so.
I’m sure there is a lot more nuance to this but I hope this straw man proposal isn’t a bad place to start.
8 Likes
Of course, it would be great if the canister could be informed of the response to the HTTP request (or some kind of acknowledgement that it was received)
i.e. the email was successfully sent
We would need to employ idempotency in a similar way for responses/acknowledgements as well.
See also: the Two Generals’ Problem
1 Like
Remove the limits of notify in Ledger canister:
There is a scenario where Alice transfers the ICP to Bob according to canister C’s request. At this time, Alice called the send function in the Ledger canister.
Now Alice wants to tell canister C that she has completed this behavior, and call notify in Ledger canister to let the Ledger canister notify the C canister, but it cannot succeed because the Ledger canister requires the transfer target and the notification target to be the same.
Of course, this will bring some risks, but if you do relevant checks in the receiver canister, you can avoid these risks.
1 Like
Just remove the restriction of to