🌐 Decentralized Extension Distribution (P2P "Bodega"/"Hoard")

[akhileshthite]

Organize and distribute WebExtensions via decentralized hosting (e.g., IPFS, Hypercore) using a predictable folder structure.

Tasks:

• Define folder structure convention:

/extensions/{name}/{version}/extension.zip
/extensions/{name}/index.json

• Design compatibility layer to install directly from P2P URLs (e.g., peersky://extensions/...).
• Use chrome-extension-fetch to archive Chrome Web Store extensions:
  • Fetch CRX → convert to ZIP → drop into /extensions/{name}/{version}/.
  • Automate index.json updates with metadata { version, P2P_URL, fetchedAt }.
  • Immediately ipfs add (or Hypercore) that folder, capture the P2P link.
  • Feed that P2P link back into the browser’s install step.
• Add settings toggle: “Load from P2P”.
• Add optional support for loading curated extension hoards (index.json) from trusted sources.
• Explore automated updates from trusted hoards.
• Clarify trust model: publisher-controlled integrity, browser-enforced sandboxing.

Behaviour:

Normal user (Archive to P2P before install):

1. User visits a Chrome Web Store page (e.g., uBlock).

2. Browser detects it’s a WebExtension and shows the install icon.

3. When clicked:

• chrome-extension-fetch downloads and converts the extension.
• It saves it under a structured P2P-friendly folder.
• It updates index.json with metadata.
• It publishes that folder to IPFS, Hypercore, etc.
• Finally, it installs the extension from the decentralized source, not from Google.

P2P user:

1. A friend sends User X a P2P link:
   hyper://abcd1234/extensions/ublock/1.0.0/extension.zip

2. User X opens this link in Peersky or Agregore.

3. The browser:

• Fetches the .zip over a peer-to-peer network (like Hypercore).
• Reads the manifest.json inside.
• Shows an "Install Extension" prompt.

4. User X confirms → browser installs the extension just like any other.

No central store. Fully distributed. Great for local communities or devs sharing their own tools.

cc @RangerMauve @autonome

[RangerMauve]

Thoughts on the format of index.json? Could be good to see what chrome/firefox do for their APIs.

I think also a set of versions and latest would be good so we don't need to readdir.

[akhileshthite]

Thoughts on the format of index.json? Could be good to see what chrome/firefox do for their APIs.

I think also a set of versions and latest would be good so we don't need to readdir.

Totally agree — having a latest pointer and explicit versions in index.json will make things more efficient, especially over P2P where readdir isn't ideal.

Links:
https://developer.chrome.com/docs/extensions/how-to/distribute
https://extensionworkshop.com/documentation/publish/self-distribution/#hosting-your-own-update-server

Example format (feel free to edit):

{
  "name": "ublock",
  "latest": "1.0.2",
  "versions": {
    "1.0.0": {
      "url": "peersky://extensions/ublock/1.0.0/extension.zip",
      "fetchedAt": "2025-06-01T12:34:56Z",
      "sha256": "3a7bd3e2360e0b6d8c1e9b2a40c5c8c9f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6",
      "manifestVersion": 3,
      "minBrowserVersion": "1.0.0"
    },
    "1.0.1": {
      "url": "peersky://extensions/ublock/1.0.1/extension.zip",
      "fetchedAt": "2025-06-02T08:21:30Z",
      "sha256": "4b1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c",
      "manifestVersion": 3,
      "minBrowserVersion": "1.0.0"
    },
    "1.0.2": {
      "url": "peersky://extensions/ublock/1.0.2/extension.zip",
      "fetchedAt": "2025-06-02T18:45:12Z",
      "sha256": "5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d",
      "manifestVersion": 3,
      "minBrowserVersion": "1.2.0"
    }
  }
}

[RangerMauve]

Example seems decent. I feel like the URL should be relative to the index.json like ./1.0.2/extension.zip or better yet if we standardize on the file name we could probably remove the url entirely and construct using the version and the path the index.json is residing.

Would minBrowserVersion mean tying extensions to a specific browser? Feels like we'd get more utility to focus on extension system version instead. Also, could the sha256 be optional if we're loading from p2p since data is already content addressed there?

[akhileshthite]

Example seems decent. I feel like the URL should be relative to the index.json like ./1.0.2/extension.zip or better yet if we standardize on the file name we could probably remove the url entirely and construct using the version and the path the index.json is residing.

Would minBrowserVersion mean tying extensions to a specific browser? Feels like we'd get more utility to focus on extension system version instead. Also, could the sha256 be optional if we're loading from p2p since data is already content addressed there?

Yeah, targeting an extension system version instead of a specific browser would offer better cross-compatibility. The sha256 can be optional (or used only as a secondary integrity check if desired).

[HarshalAtre]

Hi @akhileshthite , I’m Harshal Atre, a B.Tech ECE student at NIT Surat. I went through the Peersky Browser project on implementing a P2P Extension Store and found it interesting.

I was a Software Engineering Intern at Amazon this winter, where I worked on production-grade JavaScript systems, handled packaging and deployment workflows, and took end-to-end ownership of features in distributed environments.

Based on the project description, the work involves JavaScript, Electron, browser extensions, and P2P-based distribution. I believe this aligns well with my experience, and I’m confident I can contribute effectively. I’d like to understand the expected approach and how I can get started with contributions.

I’m new to open-source contributions, so I’d appreciate your guidance on where I should start contributing to this project.

[RangerMauve]

We should be able to load extensions off of p2p now using the session.fetch().

Maybe publish the extension files as a folder in a hyperdrive, and then sync it to a folder which we then load the extension from