Support Taco Network

[julien51]

Instead of adding the data in a database, can we "publish" it on some kind of decentralized storage, and from there, of course we would need to "encrypt" the "secret" part using Taco!

This probably requires the user to first connect their wallet, when they setup a new frame, and then ""just"" add the Taco API + storage on a decentralized network (IPFS, Arweave)?

Nest steps: write a few user stories + investigate flow. Then: think about business model.

cc @piotr-roslaniec and @arjunhassard

[arjunhassard]

Apologies for the delayed follow-up. We're working on small compatibility upgrades to make an Unlock + TACo experience as frictionless for adopting developers as possible, and wanted to run this provisional spec by you. Note this refers to an underlying, generally applicable configuration that would enable token gated frames, as well as many other use cases.

(1) DKG ritual

• DKG initialization ritual (identified by ritualID) generates group of Threshold nodes (cohort) and a public key to encrypt with.
• DKG public key & cohort exclusively controlled by an address owned by Unlock DAO.
• One ritualID is used by all developers and end-users adopting the Unlock + TACo offering (included as an argument during encryption, decryption, etc).

(2) Allow logic contract

• Authorizes who can use the DKG public key (via ritualID) to encrypt data.
• Four-tier hierarchy of roles, where:
  • Unlock DAO = cohort admin. This role controls the DKG public key can add or remove auth admins based on arbitrary logic defined in its own contract(s).
  • Developers adopting the joint Unlock + TACo SDK = auth admins. This role can add or remove encryptors to the allow list based on arbitrary logic defined in their own contract(s).
  • End-users (data producers) = encryptors. This role can encrypt data using the DKG public key and specify/embed decryption conditions into the payload.
  • End-users (data consumers) are requestors. This can be anyone with an Ethereum or Polygon account.
• The allow logic contract can call an Unlock-defined contract to check if an auth admin is currently approved, if this is to be predicated on payment, for example.

(3) Encryptor authentication

• encryptor's EIP-712 signature is checked against the allow list for a given auth admin.
• The default configuraiton can be for every lock manager to be authorized as an encryptor, assuming that this role is typically predicated on having paid the subscription via Unlock. Auth admins can place additional conditions for addresses to become encryptors.

(4) Requestor authentication & condition resolution

• requestor's EIP-712 signature is used to authenticate ownership of an account.
• ERC721.balanceOf is used to verify the same account holds of the correct NFT(s).

(5) Fee model

• Unlock DAO acts as sponsor for all usage of mainnet TACo.
• The fee model includes a duration-based ('cohort rental') component and usage-based ('per-encryptor') component.
• One small fee, paid manually in advance, covers (for example) 12 months of cohort rental, and an encryptor pool with (for example) 1,000 credits. This encryptor total is shared between all appointed auth admins under this ritualID.
• For simplicity, auth admins will be considered the same as encryptors with regard to fees – adding either role will use up one encryptor credit.
• The encryptor credit can be increased or topped-up whenever is convenient or required. If all encryptor credits are used, then it will not be possible for Unlock DAO to add an auth admin, or for auth admins to add an encryptor. Existing encryptors will still be able to encrypt data, and requestors will still be able to retrieve that data.
• encryptors can be removed, thus returning a credit to the pool. This is helpful for testing or any use case with a lot of user churn.

(6) Storage

• The default storage layer can be Arweave via Irys. This was recently integrated into one of our demos.
• We can add ArDrive (another Arweave bundler) to this joint SDK in the near-term, if desirable.

If all the above makes sense, we can put together some archetypal developer & user stories that would utilize this configuration, jump on a call to discuss any customization required for the (2) allow logic contract, and get this joint SDK out the door fairly quickly.