A standard for user owned data canisters?

As I learn, my understanding now is that a service (as of 0.9.2) could spawn a new canister for each user and that canister would have only the user as the only controller.

Updates to and reads from this user owned canister are made by forwarding calls to this canister through any interface or dapp, thus removing the dependance on the original dapp / service / creater of the user canister.

A standard might enable this at scale by specifying types of data to be stored and retrieved by such a “User Data Canister”

Independant interfaces, like Candid interface and more user friendly frontends could be used along side dapp vendor interfaces.

The standard way to interact with your data on the IC should not depend on the service / dapp that created the data for you

6 Likes

I’ve been thinking along these lines as well.

The only thing I’ve seen that even attempts to do something like that at the moment is IC Avatar by @kpeacock.

This doesn’t extend to things like blog posts or other content though.

It would be great if things like that were not only portable but also acted as a single source of truth. Publish content in one place and have it be visible in multiple apps.

cc @rckprtr @AndraGeorgescu (not sure how to mention people from Taggr and Nuance)

2 Likes

Discovered that for Taggr it’s @TaggrX

1 Like

Yes!

A standard like this is more like a “standard of standards”. It specifies a collection of standards, like a token standard but also standard for a blogpost, video post, a file, a Distrikt user profile, an NFT wallet etc. and also specifies the standard pub-sub pattern to publish and consume the content.

Then at one point we will have a desktop like dashboard with different explorers, search machines, and management tools to interact with all these standards

As I learn, my understanding now is that a service (as of 0.9.2) could spawn a new canister for each user

I’m curious why this is possible only now as of 0.9.2? I thought it was possible before as well.

1 Like

Yoy may be right, I’m not very experienced. But I read something about setting controller of a new canister…

Anyway, I’m not smart enough to design the standard anyway, so have to wait and see! Just very excited about all this

The goal for Social Fabric is to have a common protocol for sharing content (blogs, articles, posts, etc) on the IC. Social Fabric is what currently powers DSCVR and we are trying to flush out exactly what the schema for this protocol would look like. We want to make it versatile enough that it can support a diverse set of content, while still being simple to use. The current definition is still in flux, but changes are becoming less overtime and I imagine in time we will be able to open it up.

2 Likes

Tagging @dostro as well.

@TaggrX said:

Thanks for tagging me. For some reason I can’t create posts on the dev forum (anti-bot protection I guess), so I’m responding here.

The idea is definitely interesting, especially from the user perspective. From the dapp builder’s perspective, on the first glance, it does not seem to add a tangible value to the dapp itself. Also this is not possible on #IC as of now due to absence of inter-canister queries: if I’d only hold the message index on a #Taggrcanister and then get the messages from users’ canisters, the latency would render the service unusable because every query would go through the consensus.

I think I fully understand how it’s very valuable from the user perspective, but it’s hard to imagine right now how to make it attractive to integrate for dapp makers, you know. Or did I miss something?

2 Likes

@justmythoughts as discussed on the Twitter Space today.

1 Like