Megathread: Community Submissions for DFINITY Foundation’s Roadmap

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:

I propose that those concerns be addressed by the following process:

  1. 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)
  2. The “subnet” (perhaps every node, perhaps every node until some acknowledgement response is received) makes the HTTP request
  3. The receiver is configured to treat incoming HTTP requests as idempotent, using a request ID as an idempotency token.
  4. 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

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

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. :stew:


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.

1 Like

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 :slight_smile:


One easy first step could be to allow pull requests here:


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.

1 Like

Having a tighter link between pull requests and NNS proposals would be nice too.

For example, a PR can’t be merged until its associated proposal is voted on and approved.


The canister needs more detailed permission control. For example, the controller can upgrade the code and view the canister status; the observer cannot upgrade the code, but can only view the canister status.

Use a canister to manage the canisters of different users, just to get the status of these canisters, you need this function.


I agree with you. This will be key for not just SNS but just in having canisters updated by multiple devs.


There are any specific road map or initiative regarding FOOD

At the risk of embarrassing myself, I have to ask: I am not sure what “FOOD” means. is that the new way of saying FUD on the interwebs or something completely different? :slight_smile:

1 Like

I have seen at least two threads about opening up more information from canisters to other canisters.

Canister controller and cycle balance need to be public (10 likes in this thread)

and here as well:

would love to see this considered. It is especially important if you are doing something with DAO’s like I am currently



1 Like

Hi everyone,

I’m not an expert on the ICP ecosystem yet but yes in the blockchain.
This is my first review after completed the staking process and the following neurons>

I don’t very know if the followees are verified teams and if someone could create one as a ICP holder.
In that case for a staking period of 7+ years I see some kind of risk associated, for both
parts the token holder and the ICP ecosystem, since I know
this neurons has a lot of power.

What about to make a partnership with VeChain for the verification process?
They’re solving real world challenges for the Carbon footprint, Web3, DAO and Sustainability and they have strong partnerships in the quality audits.

And also a way to see all of this verified token holders on a list.

Kind regards

1 Like