herocode/secureweb
12
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
373820ec8a
secureweb/specs/architecture.md
despiegk 373820ec8a ...
2025-05-11 12:55:47 +03:00

3.2 KiB
Raw Blame History

Secure Browser-Hosted Website Architecture

This document outlines the architecture for a secure website hosted entirely within the user's browser, with all content and metadata retrieved from IPFS.

Core Principles

  • Decentralization: All website assets (metadata, markdown pages, images) are stored on IPFS, removing the need for a centralized web server for content delivery.
  • Browser-Based Execution: The website logic runs directly in the user's browser using standard web technologies (HTML, CSS, JavaScript).
  • IPFS Client: A client-side IPFS library is used to fetch content based on content identifiers (CIDs/hashes).
  • Metadata-Driven: The website structure, navigation, and content references are defined by a set of JSON metadata files.
  • Security: The architecture prioritizes security by leveraging the immutability and content-addressing properties of IPFS.

Components

  1. Browser Environment: The user's web browser, responsible for executing the website's code and rendering the content.
  2. Website Code: HTML, CSS, and JavaScript files that constitute the website's front-end logic. These files are initially loaded into the browser (potentially also from IPFS, though the initial load mechanism is outside the scope of this document).
  3. IPFS Client Library: A JavaScript library running in the browser that interacts with the IPFS network to fetch data.
  4. Metadata Files: JSON files stored on IPFS that define:
    • Header structure
    • Footer structure
    • Navbar structure
    • List of all available pages, including their IPFS hashes.
  5. Content Files: Markdown files and image files stored on IPFS, organized into collections.

Workflow

  1. The user's browser loads the initial website code.
  2. The website code uses the IPFS client library to fetch the main metadata file (which itself could be referenced by a known IPFS hash or other mechanism).
  3. The main metadata file contains references (IPFS hashes) to the header, footer, navbar, and pages list metadata files.
  4. The website code fetches these individual metadata files using the IPFS client.
  5. Based on the navbar metadata and pages list, the website renders the navigation.
  6. When a user navigates to a specific page:
    • The website code identifies the corresponding entry in the pages list metadata.
    • It retrieves the markdown content for the page from IPFS using the associated hash.
    • It parses and renders the markdown content.
    • Any referenced images within the markdown (which are part of the same collection) are also fetched from IPFS using their respective hashes.

Advantages

  • Security: Content immutability on IPFS prevents tampering after publication.
  • Resilience: Content can be served from any IPFS node that has it, reducing reliance on a single server.
  • Efficiency: Content addressing means fetching is based on content itself, not location.

Considerations

  • Initial loading mechanism of the website code.
  • Handling of IPFS network connectivity and potential errors.
  • Caching strategies for metadata and content.
  • Search and indexing of content (requires external services or pre-computation).