Import Export tool

[srieteja]

Feature Description A tool to export data from a secondary in a format that is importable by another secondary.

Requirements

• Allow users to specify filters that specify which data is extracted/exported
• Expose a writer method that the user can use to export data irrespective of the format
• Option to encrypt export exclusively for specific atSigns

Decisions to be taken

• Does data need to be deleted from the exporter's atsign [perhaps optionally]?

Tasks

• [x] Demo/Proof of concept
• [x] Analyse all possible cases of keys and define ownership of keys post export
• [ ] Implementing said rules through code
• [ ] Create/Identify writer object in Dart
• [ ] Tests/Testing
• [ ] Documentation
• [ ] Publish

[srieteja]

Would like your input on this topic @nickelskevin @tallent @cconstab. It would also be great if you could put down your requirements/expectations from this tool

[ksanty]

Move to medium after arch call discussion

[VJag]

Motivation:

If an IoT device has an @ sign, it could be recording data for someone else. This could be the owner of the device or a third person for whom the device is working. This someone can change with time. For example, a "pulse oximeter" in a hospital will be recording oxygen saturation levels for different patients at different times. If the "pulse oximeter" is recording the saturation levels in its own secondary there is a need to make the data available to the patient to whom the data belongs.

Given this scenario, there is probably a need to export the data from a secondary in order to make it available for someone else. This exported data can then be imported back into the secondary server of the person for whom it is imported.

Design considerations:

1. Import export functionality is envisioned to be a separate library and not part of SDK

2. Three main questions need to be answered while exporting the data:

   • What keys to export? ~ regex ~ date range ~ what types of keys? public, self, shared ~ can cached keys be exported? ~ can the cached/shared keys shared by someone else be exported (Not the same person it is being exported for)

   • How to export? ~ format of the export ~ csv/json or someother format
     ~ masking

   • Where to export? ~ Disk-based file/Cloud storage/In memory file etc..

3. Following questions needs to be answered while importing the data:

   • What will be the format of the keys when imported? ~ Does a public key become a public key? ~ Does a shared key become a shared key? ~ Should the information that is exported from some other at sign needs to be preserved in the metadata or some other place?