Protocol to facilitate content encryption and sharing

It’s very frequent that some content must be private. This spans from instant messengers to sharing a document with collaborators.

In the case of 1:1 content sharing, normally sender would encrypt with receivers public key and only receiver would be able to decrypt.

In NEAR, each account can have many keys. Also if keys are stored on hardware device or in some other form of custody - it would be extremely hard for receiver to actually decrypt.

There has been a proposal described in Stackoverlow answer:

There are few more advanced tools like proxy re-encryption that exist as well, which may allow to simplify the interaction flow in expense for more cryptography and computation off chain.

Curious to discuss the proposal and if there are alternatives here. Ideally we should formalize something to the form of implementable milestones.


It’s great to see a proposal relating to data encryption / sharing, however I don’t feel it’s the right approach to build this into the blockchain layer.

I’m the founder of Verida that provides an open source library for off-chain data storage and real time messaging.

There is an existing body of work around identity and storage standards:

I recommend the implementation of a NEAR DID method allowing decentralized identities to be native to NEAR.

This is roughly how it would work:

  • User generates a keypair (K1) within their NEAR account (or new user creates implicit account)
  • The private key is used to deterministically generate an additional keypair (K2) and a signing key (K3)
  • A new DID document is created (using the DID-core standard) that publishes the public keys for K2 and K3, signed by K1 to prove the DID document is owned by “did:near:”. (This DID document could be stored on chain, or could be stored off-chain with a URI stored on chain)

Users can then authorize party applications to add new “serviceEndpoint” entries to their DID document effectively publishing what third party / off-chain services are available.

These external services could be Encrypted Data Vaults or Identity Hubs as being developed in the confidential storage spec, it could be DIDComm communication channels, Verida encrypted Vaults etc.

Interestingly, due to NEAR’s unique account system, it could be possible to rotate the on-chain keys then update the DID document which still references the same DID (did:near:) providing a robust key rotation system.

As a new user I could only put two links in my post, so here’s some more references: