Decentralized registries via Ceramic, 3Box, IDX

1

Uses for Ceramic, 3Box, IDX

DID documents for nodes

Nodes can publish public keys so applications can check node signatures. Nodes can sign verifications for users, node lists and app information. Nodes can include information about themselves if they wish.

Node lists

Each node can maintain a list of other nodes it trusts. This way applications (including the BrightID reference app) can find other nodes to communicate with.

App Information

Apps (identified by DIDs) can upload and maintain their own information. Nodes can certify that they believe this information to be correct and maintain their own app lists linking to app information for other apps (including the BrightID reference app) to refer to.

Profiles

Users can upload and maintain some of their profile information (name, photo, other information they want to share with BrightID connections and apps) as 3Box or IDX profiles. The user would be asked if they want to share their profile with an app when it’s linked.

Encrypted data

Private profile data

Private profile data that is shared peer-to-peer in BrightID, but not meant to be widely viewable would be stored encrypted.

Encrypted contact lists

Connection data currently being stored by our backup server can be moved to Ceramic. Links to profiles would be stored encrypted to prevent plain-view traversal.

Accessing encrypted data

The methods for viewing encrypted profile data and contact lists will be governed by methods stored with the DID documents / IDX.

Social graph traversal

Can connections between profiles in IDX be selectively exposed for graph analysis? We would need to have ways to anonymize the traversal, such as blind find.

2

For storing backup data, I think we will have the same challenge we had with ipfs with ceramic too. Who should pin these info for users?

By default Ceramic will garbage collect any document that has been created, modified, or loaded after some period of time. In order to prevent the loss of documents due to garbage collection, you need to pin the documents that you wish to persist. Pinning instructs the Ceramic node to keep them around until they are unpinned.

I think the problem with decentralized storages is logical not technical.
I still think that It can be very helpful to have a decentralized storage service with democratically elected nodes for freely pinning reasonalbe amount of data for brightid verified users and charging users based on storage cost and replication factor for higher usage.

1 Like
3

What if we provide the option for an IDChain node operator to also run ceramic/IPFS and if they do they get an increase to their stipend?

4

At 1hive gardens we also would like to provide support for user profiles stored in IDX. We did some research on how to store encrypted data in IDX, but we are still in the beginning. I’ll look close to see the advances in this thread.

1 Like
5

Any updates to this thread? I’m interested in integrating BrightID through IDX for my project too.