Give API for fdp-storage library for dApps

[nugaon]

the active user wallet is handled by the extension which is used to manage the personal storage of the user.

we need to provide all functionalities that fdp-storage has, but initialized with the wallet handled in the extension. The interface should be available in the extension's library that maps all functions/classes of fdp-storage, but the business logic should be replaced by calls towards the extension instead. The easiest approach may be using proxy object for the fdp-storage instance on the library side. These event calls should trigger the background script, where the "normal" fdp-storage instance is initialized with the active wallet to perform the actions that came from dApp side. Of course, the event calls have to be permission checked whether the dApp requests its own POD, etc.

[tfius]

a popup should open and present to user 'agree to create pod', 'agree to create folder', 'agree to add file' also 'allow app to access your storage ?' and 'allow app to write (data schema) to your storage and there should be a checkbox 'always allow app for action xxx'

• allow app to access 'pod name'
• 3 'create actions', (pod, directory, file)
• allow app to write 'data schema' to 'pod name'
• allow app to read file from 'pod name'

[crtahlin]

Give feedback here, and we tackle it at the bonfire session @nugaon @tfius @tomicvladan @IgorShadurin @molekilla @asabya

[molekilla]

We need

Claims / Scopes feature

To grant/deny access to certain features

API modeled after WalletConect (client side JSON RPC)

Calls between client API must be in JSON RPC, eg lookup current accounts you send eth_accounts

Support extensions to HW / WalletConnect, and others

We will need an option to allow external signers

Add missing recovery or replace/reset password

If I lose my password and mnemonic?

Allow ENS transfer to another address (like create react app eject) and deactivate account

A docusaurus docs.fdp-storage.bzz

A catchy name for fdp-storage

[tomicvladan]

Settings data structure For each dapp that have access to fdp-storage, we need to store an object describing level of access. For example, one dapp can only access one specific pod, and do only read operations, etc. We need to define this data structure.

UI/UX of the dapp permissions What would be the best UI/UX for letting the user choose what's accessible by certain dapps. Maybe similar as on mobile devices when installing a new app, list all permissions that the dapp requires?

FDP API Dapps will access fdp-storage through the library. What will be the API of the library? Should we wrap each function of the fdp-storage library with a similar function in the blossom library. Or to use some more generic approach.

Extension manifest V3 issues As we discussed before, in the manifest v3, service worker's state is transient. We need to find a way to persist user's private key/wallet.

Tests Communications between dapps and the extension will go through the library. So in order to run puppeteer tests for this communication we need the library. Does it makes sense to put these kind of tests into the library subproject?

[molekilla]

Extension manifest V3 issues

We can just use plain old WebCrypto to export key to browser with exportable: false and we add a hash to it. It will be revoke/deleted if the hash is not the latest (eg kind of a inverse Certificate Transparency use case)

[nugaon]

By default, dApps should have their own generated pods.

How we differentiate different versions of a dApp and letting to still reach out their original pod is a havier question. I suggest that we should only let ENS/SoC address referenced dApps to reach their own pods first. Later, it is possible to require a signature in the index.html webpages that Blossom could interpret and recover the public key from the signature in order to map to its separated POD.

So in the first release version I don't think we need more such as asking for permission to another POD than the applications' own PODs.

FDP API

The interface of the Blossom fdp-storage instance should be identical to the original fdp-storage instance except the sync methods will be async because the method calls will ask Blossom to give an answer which goes trough an RPC-like communication channel. (see the high-level idea in the issue desc.) On request, the Blossom will identify the source (dApp origin) and according to that give permission to the action or not. E.g. if it wants to list pod content of an other dApp then this request will throw 403. In this perspective, the Blossom acts as a proxy. We should list up what actions in the fdp-storage should be restricted and how.

The other way can be that we gradually add APIs with a new Blossom defined interface for reaching out pods and operations on it, but it may lengthen the implementation and maintenance time and raise the complexity.

Extension manifest V3 issues

on every fdp-storage requests, the blossom should bring up a popup window IF the serviceworker terminated and the private key has to be decrypted by the password again.

Tests

I think the library subproject will be a great place for tests of the library.

[crtahlin]

Hey team! Please add your planning poker estimate with ZenHub @nugaon @tfius

[tfius]

check with https://github.com/fairDataSociety/FIPs/issues/12