feat: design and implement a backup & restore system (P2P JSON + Tabs Restore)

[akhileshthite]

Backup & Restore System (P2P JSON + Tabs Restore)

Scope

Primary goals:

• Backup P2P app data and session state (tabs/windows).
• Restore from local file or IPFS/Hyper CID.
• Add an onboarding import flow for tabs from other browsers using a helper extension.

---

P2P Backup (Peersky Settings)

• Add a new Backup tab in peersky://settings/ Or add a dedicated backup page (e.g., backup.html in src/pages/), linked from settings.
• Create a single .zip backup file containing:
  • lastOpened.json
  • tabs.json
  • ensCache.json
  • ipfs/ directory
  • hyper/ directory
• Option to generate a CID for the backup zip for instant sharing.
• Add input to load/resolve CID and download backup zip to local.

---

Restore Options (Settings)

• Upload p2p backup zip file.
• Load backup from IPFS/Hyper CID.
• Upload Chrome/Firefox browsers backup zip file.

---

From AgregoreWeb/agregore-browser#315 (comment)

Browser Extension (Chrome/Firefox)

• Create a small extension under p2plabsxyz.
  • Export current windows/tabs to a file (JSON or ZIP).
  • Include tab URLs, titles, window grouping, and active tab indexes.
• Publish to Chrome Web Store and Firefox Add-ons.
• File format must be compatible with Peersky’s import pipeline.

Managing the repository and web store publishing will be handled by the maintainer.

---

Onboarding Flow (Tabs Import)

• On first launch, show onboarding.html (from src/pages/):
  • Prompt: “Import tabs from another browser?” → Yes/No
  • No → go to welcome screen (peersky://home)
  • Yes → show instructions to install the helper extension in Chrome/Firefox
  • Next step: import the generated file from that extension
• This flow is also be available from the Backup page as mentioned in "Restore Options" above.

---

Technical Notes

• Tabs state persistence already exists:

  • lastOpened.json for window state
  • tabs.json for tab groups and nav history
  • renderer localStorage uses peersky-browser-tabs for tab restores

• P2P cache data in userData:

  • ensCache.json
  • ipfs/ dir (repo, blocks, datastore)
  • hyper/ dir (Hypercore storage)

[ADARSH-IIIT]

@akhileshthite I am interested in this also I do have knowledge of internet security .

But I wanted to know, if we'll go to implement the public-private key features for confidentiality and integrity,

How we are assigning keys to users.

Like if we want , we can create keys in frontend
And there is very less possibility that 2 users have same pair of keys in practical world .

But in large scale and theoretically it is possible that will be a loophole.

To avoid this we need a central server, to which user request for public and private keys, and that server ensures that no two have same pairs. Do we have a backend server whom which our frontend can request?????

What are your opinion and suggestions in this

Rest backup part seems doable .
Should I start implementing that????

[akhileshthite]

Thanks for your showing your interest.
We’ll need to ship #59 first, so this isn’t a priority at the moment.