Mitigating NNS Power w/ Canister Data Exports

Developers
1

As many of you know, I have taken a much more adversarial position towards the NNS post taggr incident.

Consequently, we (Departure Labs) have moved away from the IC being our primary target. But, we do still believe the tech, team, and mission are strong. Today, the IC is still the best positioned platform to host robust, accessible, decentralized protocols. The IC cannot rely on this being the case forever.

I personally don’t have a proposal for a better NNS design. Even if I did—I’m unsure the NNS would be willing to relinquish the level of control it presently has. Yes, stakeholders (the NNS) in the IC have the absolute right to control what content exists on the IC in the same way stakeholders in Ethereum do. As I’ve previously stated, the NNS is unique in that it can mutate itself much quicker than ETH could ever dream of. This property of the IC provides unique benefits. But, it also provides unique risks to projects targeting the IC.

With the tooling available to projects today I feel the NNS is an existential risk to all projects building on the IC.

I believe this risk could easily be mitigated by giving projects adequate tooling to leave the NNS hosted IC. If providing this choice makes you uncomfortable I encourage you to reflect on why before engaging in this discussion.

In a way I’m asking the NNS to define the relationship with projects and developers. I think most would be more than happy to pay rent to utilize the benefits the NNS IC provides. But, I don’t think this entitles the NNS IC ownership of the data in those hosted canisters.

Give projects the ability to leave. I firmly believe this will result in a net gain of trust in the IC.

I’m interested in proposing this via the NNS but I don’t presently have the bandwidth to make that happen. I’m more than happy to give what I can to make this happen in a much more limited capacity.

Finally, I ask all of you who took the time to read this to completion to take some time and consider what a YES or NO vote conclusion would signal via the NNS.

Hazel

10 Likes
2

image
image1088×877 58.4 KB

cya

1 Like
3

this doesn’t include heap, isn’t verifiable post export, requires explicit usage of stable, and requires every developer to roll their own export system ;).

dfx export <principal_id> --heap, stable

4

What specific part of leaving are they not able to do?

5

If you are looking for a tool to download the canister-data, check this library out: canister_tools - Rust. You can download the canister heap data and stable-memory.

For verifiability you can call the download methods with replicated query mode so you get certification on the responses and even save the certificate of each call if you want.

2 Likes
6

Appreciate you sharing this. However, I think a more straight forward solution would still be allowing the heap and stable state to be directly exported from the IC. As far I can tell the canister_tools crate still relies on serialization strategies to export data.

Maybe it would be helpful to summarize my ask a bit more concisely:

As a canister controller I should be able to download a copy of my canister data in its entirety and run it elsewhere.

2 Likes
7

Also, imagine the case where I have N-GiB of personal photos stored to the IC.

Using canister defined export mechanisms I would incur substantial cycles cost far outside of what is actually required.

Instead of just giving me the blessed data stored for the canister, now we have to have the IC invoke the canister, copy the data from stable into heap, pass that data back though the wasm boundary to the host over the network back to the user.

4 Likes
8

You know what, you’re right.

We need a swift exit mechanism just in case some guys in the US want to fork the Internet Computer and we need a quick way to migrate all the dapps.

Or you could use ic-stable-structures and open source an API to download the memory in chunks smaller than the egress limit.

What’s the narrative here, person who hasn’t posted in 4 months??

9

@borovan - I dream to clone the entire IC into IC-MEGA-XL_stable_diffusion.exe :smiling_face_with_tear:

Just kidding… or am I?

No, seriously though. I think this is functionality that has been placed on the back-burner for some time and is slowly ramping up to becoming a serious threat to all projects on the IC.

I am no longer actively developing on the IC so I’m approaching this from the perspective of someone who wants to continue using the IC. Also, as a developer, the NNS IC is the best positioned platform for building robust decentralized protocols, I want to continue to aid in its growth but I can’t in good faith until I feel confident we’re not going to get screwed… Trust, but verify. I’m verifying right now.

To be clear I’m advocating data exports by canister controllers. SNS projects will not be able to just exit unless they vote to do so. I think having the ability to exit will make the SNS an even more powerful tool outside of the IC by assuring the NNS remains aligned with the needs of the projects it’s protecting. Competition is good.

Moreover, even if someone did manage to clone the IC they’re be lacking all of the institutional knowledge the foundation has collected. It wouldn’t work. Now, whether or not this is a good thing is outside the scope of this discussion lol…

Also low-key can’t believe you forgot me already person who has remained active :sob:

5 Likes
10

Oh I’m aware of what you’re doing, but there’s a subtle anti-foundation narrative being peddled by some people so forgive me if I lump you in the same basket as them.

What you’re saying seems like an overly-contrived scenario, and I’ve seem similar posts recently. The default position, in my opinion is that we have 270 amazing people contributing to never-seen-before technology and we should be standing on their shoulders.

Are you giving up on web3? If you don’t mind me asking what platform are you going to focus on now?

I tend to assume that anybody who’d jump ship as early as this has been influenced by somebody with an agenda.

2 Likes
11

My stance on the Foundation hasn’t changed since mainnet launch. Please do not misunderstand my public criticisms—If I believed the foundation had nefarious intent I would say it directly.

I was very public about my feelings that the foundation was doing too much in the app layer and needs to focus on making the IC protocol as robust as possible. I’ve spoken in public and directly to the team about my concerns regarding developer experience, apparent limitations v.s marketing, etc.

To me its clear the foundation is committed to making the IC the best it can be even if I don’t agree with a lot of their decisions :woman_shrugging:.

What you’re saying seems like an overly-contrived scenario, and I’ve seem similar posts recently. The default position, in my opinion is that we have 270 amazing people contributing to never-seen-before technology and we should be standing on their shoulders.

I want to argue my stance as a developer. But, I have to ask that you sympathize with this ask as a user. Users / Projects deserve to own their data. Providing this mechanism creates a clear reference to judge all future data ownership models from. Furthermore, this is something you get for free from other blockchains. The “Private” data model of the IC is powerful and should be a huge asset. But, without this I feel its a liability.

Are you giving up on web3? If you don’t mind me asking what platform are you going to focus on now?

No, I’m not giving up on web3. But, am fully committing to another more balanced approach of how we use it—Web3 should be reserved for the parts of the protocol that explicitly deal with trust.

So, we’re building an open source product stack. I want to take all of my experiences building product in Web2 and all of the experiences I just had with the IC, to make it as simple as possible for small teams to build great product. I think the biggest problem we’re having with decentralizing the web is its too damn hard to build great product.

Part of this stack enables building decentralized “cloud” apps. But, getting these apps to do anything useful will require building trusted protocols—something the IC can provide. And, something it provides better than anyone else.

I want to build a complimentary product to the IC. I don’t think it’s possible to express how completely disinterested I am in building anything that needs to manage trust like the IC does. We’re building everything that the IC isn’t.

edit* For what we’re building to be useful, I think we’re ultimately going to need to direct teams back towards some web3 stack to build very significant parts of their applications. In my mind the obvious choice should be the IC. I need to be fully confident on that decision so I’m back to cause trouble :).

I tend to assume that anybody who’d jump ship as early as this has been influenced by somebody with an agenda.

Naw, I smashed my face into this thing for over a year. I legit just think we’re using this thing the wrong way right now. It’s novel and new. Remember the “ditch your database” slogan? Pretty sure we’re just trying to put the shape into the wrong slot.

7 Likes
12

Perhaps you should join Origyn team, they are building something has plenty of potentials (if they can execute…)

14

Sorry, not quite following here. Is it possible you replied to the wrong thread?

15

Glad to see developers coming ahead and being open about this.

But… where’s DFINITY’s Developer Relations team? Do officials from DFINITY care to comment on this or are they going to ignore it? :thinking:

16

Can you give examples of this overreach into the app layer?

Of course they should be involved, look at the mess with token standards and the recent ICRC innovations. I’ve heard this line repeated a lot, but usually without any concrete reason why the team who built the IC should be restricted only to the “protocol layer”.

1 Like
17

Probably just roll their eyes, click the back button and check the next thread.

18

I don’t understand why it is important to exit the IC.

Each user should be able to download their data to their machine and we can call that a win. Transferring all the data from each app to another chain is not necessary right now. Honestly, the foundation is doing all it can to get it to grow. I think that is the best allocation of its resources. I don’t think there has been one app that has reached global popularity.

I mean this is why it is impossible.

The best way to exit is to sell out of ICP. I think the multichain world outside $$ is providing a solution to a problem that doesn’t exist.

I think each user should be able to copy their data and I think that should be possible. Prob good to have in case anything is whipped out. However cloning the whole chain is impossible and unnecessary.

19

Honestly, I thought this would be a widely popular suggestion and a huge home run in terms of “shows of good faith” for the NNS. Is it possible that the forums just aren’t where these discussions are happening anymore?

Still…

I didn’t expect to get hit with passive accusations challenging the nature of my intentions. Moreover, I certainly didn’t expect to be met with resistance on a proposal that essentially asks to build a mechanism allowing me to access my own damn data in a canister.

If the intention was to drain the small amount of bandwidth I had left to commit to trying to have a positive impact here, then I’m going to pick my battles and give you that.

Anyways, I hope someone can continue the carry the torch here.

“cya” :wink:

4 Likes
20

Hey Hazel,

Good to see you here!

Providing platform support for snapshotting and exporting is something that was discussed during the last ICP.Lab on Storage and Scalability, and is something that DFINITY wants as well.

Maybe @dsarlis or @ulan can give an update on the state of these features.

Just FYI:
There’s also the recently released dfx deps feature, which makes it easier to provide and download wasm modules related to canisters, and there are ecosystem projects like LightIC which provide alternative implementations to run canisters outside the IC.

6 Likes
21

You can access the data, just create a method for it and stay under the 2mb egress limit. I don’t see why this is such a big deal