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
Great point. This may be “a thing” or a simple feature someone can knock out. Let me ask them.
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.
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.
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.
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.
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
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.
Just remove the restriction of
What are we doing about SEO? Sites within the IC will want to be findable by the old internet. Can we return the raw files to bots and allow them to read them normally at the boundary level?
For example: User A wants to make a cool newsletter site using ICME but notices it never appears on Google Search. Even if he puts in an extremely specific exact search. His newsletter is unnoticed by the general population. He may consider putting it back into the old web just to get the normal SEO.
I propose this be a high target item on the roadmap. Not as just dev. But as someone who understands real world problems that big tech is eating up. Um, um.
That seems to be in the control of the individuals and services providing those web pages rather than the network itself.
A proposal to dig deeper into our strategy to increase our decentralized fleet size.
I wonder how we could leverage the community to help design and implement software changes to the IC.
On-chain governance in the form of the NNS is unique to the IC, and could help the network evolve much faster than other blockchains. (Look how long it’s taking for ETH 2.0.)
I’d bet there are quite a few of us who would be willing to help actually write the Rust code to add features to the IC. Being bottlenecked by the DFINITY Foundation on all of these large-scale changes doesn’t seem to be sustainable (or fast enough) in the long term. If we have a more formalized reward system and proposal review process for decentralized source code contributions, I think this could be a huge advantage for the IC.
Well, as you know, in one of my proposals I did actually write the code to implement the proposed change.
I agree that there may be a bottleneck with waiting on the DFINITY foundation to implement features that are voted upon. However, in this situation I think the bottleneck is not in the implementation, so I also agree that an improved process around proposing changes is needed.
Is it really unique? I understand that Tezos has had on-chain governance, including changing the core protocol and code in an on-chain governance-driven way, long before the IC existed?
But yes, a discussion on how the design and development can be actually community-owned is very welcome IMHO
One easy first step could be to allow pull requests here: https://github.com/dfinity/ic
A good next target seems to be open sourcing all code with each repository accepting pull requests from DFINITY and the community. If we can get to that point we’ll be in a good position to allow individuals, companies, DAOs, etc to start contributing.