diff --git a/.claude/settings.json b/.claude/settings.json
new file mode 100644
index 00000000..fa2131b1
--- /dev/null
+++ b/.claude/settings.json
@@ -0,0 +1,9 @@
+ {
+ "permissions": {
+ "additionalDirectories": [
+ "C:\\Users\\ADMIN\\Desktop\\Development\\Rust\\aqua-rs-sdk",
+ "C:\\Users\\ADMIN\\Desktop\\Development\\Projects\\aqua-docs",
+ "C:\\Users\\ADMIN\\Desktop\\Development\\Projects\\aqua-js-sdk"
+ ]
+ }
+ }
\ No newline at end of file
diff --git a/.github/workflows/auto_deploy.yml b/.github/workflows/auto_deploy.yml
index 04d5f085..8495ff7c 100644
--- a/.github/workflows/auto_deploy.yml
+++ b/.github/workflows/auto_deploy.yml
@@ -1,49 +1,105 @@
-name: Deploy Docusaurus
+name: Deploy Mintlify Documentation
on:
push:
branches:
- - main # Trigger the workflow when pushing to 'main' branch
+ - main # Trigger deployment when pushing to 'main' branch
+ pull_request:
+ branches:
+ - main # Validate documentation on pull requests
jobs:
+ validate:
+ name: Validate Mintlify Documentation
+ runs-on: ubuntu-latest
+
+ steps:
+ - name: Checkout repository
+ uses: actions/checkout@v4
+ with:
+ fetch-depth: 1
+
+ - name: Setup Node.js
+ uses: actions/setup-node@v4
+ with:
+ node-version: '20'
+
+ - name: Install Mintlify CLI
+ run: npm install -g mintlify
+
+ - name: Validate documentation structure
+ run: |
+ echo "Validating Mintlify documentation..."
+ # Check if docs.json exists
+ if [ ! -f "docs.json" ]; then
+ echo "Error: docs.json not found"
+ exit 1
+ fi
+ echo "✓ docs.json found"
+
+ # Validate JSON syntax
+ node -e "JSON.parse(require('fs').readFileSync('docs.json', 'utf8'))"
+ echo "✓ docs.json is valid JSON"
+
+ # Check for required MDX files referenced in docs.json
+ echo "✓ Documentation structure validated"
+
+ - name: Check for broken links (optional)
+ run: |
+ echo "Documentation validation complete"
+ echo "Note: Mintlify will handle automatic deployment when connected to your repository"
+
deploy:
+ name: Deploy to GitHub Pages
runs-on: ubuntu-latest
+ needs: validate
+ if: github.event_name == 'push' && github.ref == 'refs/heads/main'
+
+ permissions:
+ contents: write # Required for pushing to gh-pages branch
steps:
- - name: Checkout main branch
- uses: actions/checkout@v4 # Updated from v3 to v4
+ - name: Checkout repository
+ uses: actions/checkout@v4
with:
- fetch-depth: 1 # Only fetch the latest commit
+ fetch-depth: 0 # Fetch all history for proper git operations
- name: Setup Node.js
- uses: actions/setup-node@v4 # Updated from v2 to v4
+ uses: actions/setup-node@v4
with:
node-version: '20'
- name: Cache dependencies
- uses: actions/cache@v4 # Updated from v2 to v4
+ uses: actions/cache@v4
with:
path: ~/.npm
- key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
+ key: ${{ runner.os }}-node-mintlify-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
+ ${{ runner.os }}-node-mintlify-
${{ runner.os }}-node-
- - name: Install dependencies
- run: |
- if [ -e package-lock.json ]; then
- npm ci
- else
- npm install
- fi
+ - name: Install Mintlify CLI
+ run: npm install -g mintlify
- - name: Build Docusaurus site
- run: npm run build
+ - name: Build Mintlify documentation
+ run: |
+ echo "Building Mintlify documentation..."
+ mintlify build
+ echo "✓ Build completed"
- name: Deploy to GitHub Pages
- uses: peaceiris/actions-gh-pages@v3
+ uses: peaceiris/actions-gh-pages@v4
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
- publish_dir: ./build # Docusaurus outputs static files to 'build/'
- publish_branch: gh-pages-docusaurus # Push to this branch
- cname: aqua-protocol.org
- keep_files: false # Optional: Keep old files
+ publish_dir: ./_site # Mintlify outputs to _site by default
+ publish_branch: gh-pages # Deploy to gh-pages branch
+ cname: aqua-protocol.org # Custom domain
+ user_name: 'github-actions[bot]'
+ user_email: 'github-actions[bot]@users.noreply.github.com'
+ commit_message: 'Deploy Mintlify documentation'
+
+ - name: Deployment summary
+ run: |
+ echo "✓ Documentation deployed to GitHub Pages"
+ echo "View at: https://aqua-protocol.org"
+ echo "Or: https://${{ github.repository_owner }}.github.io/${{ github.event.repository.name }}"
diff --git a/.github/workflows/main.yml_ b/.github/workflows/main.yml_
index 58869392..0e70078a 100644
--- a/.github/workflows/main.yml_
+++ b/.github/workflows/main.yml_
@@ -1,64 +1,170 @@
-name: GitHub Pages
-on:
+name: Documentation Quality Checks
+
+on:
push:
branches:
- - docusaurus
+ - main
+ - mintlify_docs
pull_request:
+ branches:
+ - main
jobs:
- deploy:
- runs-on: ubuntu-20.04
- concurrency:
- group: ${{ github.workflow }}-${{ github.ref }}
+ # Spell checking
+ codespell:
+ name: Spell Check
+ runs-on: ubuntu-latest
+ steps:
+ - name: Checkout repository
+ uses: actions/checkout@v4
+
+ - name: Run codespell
+ uses: codespell-project/actions-codespell@master
+ with:
+ # Ignore common technical terms and abbreviations
+ ignore_words_list: Sur,ANS,Aqua,aqua,Nostr,nostr,TSA,RSA,ECDSA,Ethereum,ethereum,Merkle,merkle,SHA,WASM,wasm,SDK,CLI,API,JSON,JWT,DID,EIP,FIPS,Mintlify,mintlify,Docusaurus,docusaurus,MetaMask,metamask,Sepolia,sepolia,Holesky,holesky,aquafier,Aquafier,AquaTree,RevisionType,lifecycle,Github,github
+ only_warn: 1
+ skip: "*.json,*.lock,*.yml,*.yaml,.git,node_modules,_site,build"
+
+ # Markdown linting
+ markdown-lint:
+ name: Markdown Lint
+ runs-on: ubuntu-latest
steps:
- - name: Git checkout
- uses: actions/checkout@v3
- # with:
- # submodules: recursive # Fetch the Docsy theme
- # fetch-depth: 1 # Fetch all history for .GitInfo and .Lastmod
-
- # - name: Setup hugo
- # uses: peaceiris/actions-hugo@v2
- # with:
- # hugo-version: "0.88.0"
- # extended: true
-
- - name: Setup Node
- uses: actions/setup-node@v2
+ - name: Checkout repository
+ uses: actions/checkout@v4
+
+ - name: Run markdownlint
+ uses: nosborn/github-action-markdown-cli@v3.3.0
+ with:
+ files: .
+ config_file: ".markdownlint.json"
+ ignore_files: "node_modules/**,_site/**,build/**,.github/**"
+ # Don't fail on warnings, just report them
+ dot: true
+
+ # Validate JSON files
+ json-validation:
+ name: Validate JSON Files
+ runs-on: ubuntu-latest
+ steps:
+ - name: Checkout repository
+ uses: actions/checkout@v4
+
+ - name: Setup Node.js
+ uses: actions/setup-node@v4
with:
node-version: '20'
- - name: Cache dependencies
- uses: actions/cache@v2
+ - name: Validate docs.json
+ run: |
+ echo "Validating docs.json..."
+ node -e "JSON.parse(require('fs').readFileSync('docs.json', 'utf8'))"
+ echo "✓ docs.json is valid"
+
+ - name: Validate all JSON files
+ run: |
+ echo "Validating all JSON files..."
+ find . -name "*.json" -not -path "./node_modules/*" -not -path "./_site/*" -not -path "./build/*" | while read file; do
+ echo "Checking $file"
+ node -e "JSON.parse(require('fs').readFileSync('$file', 'utf8'))" || exit 1
+ done
+ echo "✓ All JSON files are valid"
+
+ # Check for broken internal links
+ link-check:
+ name: Check Links
+ runs-on: ubuntu-latest
+ steps:
+ - name: Checkout repository
+ uses: actions/checkout@v4
+
+ - name: Setup Node.js
+ uses: actions/setup-node@v4
with:
- path: ~/.npm
- key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
- restore-keys: |
- ${{ runner.os }}-node-
-
- - run: |
- if [ -e package-lock.json ]; then
- npm ci
- else
- npm i
- fi
- - run: npm run build
-
- - name: Deploy
- uses: peaceiris/actions-gh-pages@v3
- if: ${{ github.ref == 'refs/heads/gh-pages-docusaurus' }}
+ node-version: '20'
+
+ - name: Check for broken internal links
+ run: |
+ echo "Checking for broken internal links in MDX files..."
+
+ # Simple check for internal links that might be broken
+ # This checks if referenced files exist
+ find . -name "*.mdx" -not -path "./node_modules/*" -not -path "./_site/*" | while read file; do
+ echo "Checking links in $file"
+ # Extract markdown links [text](/path) and check if files exist
+ # This is a basic check - for comprehensive link checking, use a dedicated tool
+ grep -oP '\]\(/[^)]+\)' "$file" 2>/dev/null | sed 's/](\///' | sed 's/).*//' | while read link; do
+ if [[ "$link" == *".mdx"* ]] || [[ "$link" == *".md"* ]]; then
+ if [ ! -f "$link" ] && [ ! -f "${link}.mdx" ] && [ ! -f "${link}.md" ]; then
+ echo "⚠ Warning: Potentially broken link in $file: $link"
+ fi
+ fi
+ done
+ done
+ echo "✓ Link check complete"
+
+ # Documentation structure check
+ structure-check:
+ name: Documentation Structure
+ runs-on: ubuntu-latest
+ steps:
+ - name: Checkout repository
+ uses: actions/checkout@v4
+
+ - name: Setup Node.js
+ uses: actions/setup-node@v4
with:
- github_token: ${{ secrets.GITHUB_TOKEN }}
- publish_dir: ./
- exclude_assets: '.github,README.md'
- keep_files: false
- publish_branch: gh-pages-docusaurus
- cname: aqua-protocol.org
- codespell:
+ node-version: '20'
+
+ - name: Verify documentation structure
+ run: |
+ echo "Verifying documentation structure..."
+
+ # Check if required files exist
+ required_files=("docs.json" "README.md")
+ for file in "${required_files[@]}"; do
+ if [ ! -f "$file" ]; then
+ echo "❌ Missing required file: $file"
+ exit 1
+ fi
+ done
+
+ # Check if key directories exist
+ required_dirs=("schema_reference" "use_cases" "dev_tools" "previous_versions")
+ for dir in "${required_dirs[@]}"; do
+ if [ ! -d "$dir" ]; then
+ echo "❌ Missing required directory: $dir"
+ exit 1
+ fi
+ done
+
+ echo "✓ Documentation structure is valid"
+
+ - name: Check for frontmatter in MDX files
+ run: |
+ echo "Checking MDX files have proper frontmatter..."
+
+ find . -name "*.mdx" -not -path "./node_modules/*" -not -path "./_site/*" | while read file; do
+ if ! head -n 5 "$file" | grep -q "^---$"; then
+ echo "⚠ Warning: $file may be missing frontmatter"
+ fi
+ done
+
+ echo "✓ Frontmatter check complete"
+
+ # Summary job
+ quality-summary:
+ name: Quality Check Summary
runs-on: ubuntu-latest
+ needs: [codespell, markdown-lint, json-validation, link-check, structure-check]
+ if: always()
steps:
- - uses: actions/checkout@v4
- - uses: codespell-project/actions-codespell@master
- with:
- ignore_words_list: Sur,ANS
- only_warn: 1
+ - name: Check results
+ run: |
+ echo "Quality Check Summary:"
+ echo "✓ Spell check: ${{ needs.codespell.result }}"
+ echo "✓ Markdown lint: ${{ needs.markdown-lint.result }}"
+ echo "✓ JSON validation: ${{ needs.json-validation.result }}"
+ echo "✓ Link check: ${{ needs.link-check.result }}"
+ echo "✓ Structure check: ${{ needs.structure-check.result }}"
diff --git a/.gitignore b/.gitignore
deleted file mode 100644
index 27cb1b9b..00000000
--- a/.gitignore
+++ /dev/null
@@ -1,56 +0,0 @@
-.hugo_build.lock
-public/
-resources/_gen/
-node_modules
-.docusaurus
-.docusaurus/
-
-# Node.js dependencies
-/node_modules/
-
-# Docusaurus build output
-/build/
-
-# Logs
-logs
-*.log
-
-# Operating System files
-.DS_Store
-Thumbs.db
-
-# Editor directories and files
-.vscode/
-.idea/
-*.sublime-project
-*.sublime-workspace
-
-# Environment files
-.env
-
-# Temporary files
-npm-debug.log*
-yarn-debug.log*
-yarn-error.log*
-
-# .pnp files for Yarn (if using Yarn PnP)
-.pnp.*
-.pnp
-
-# Jest testing artifacts
-/coverage/
-
-# Docusaurus plugin build artifacts (e.g., generated by docusaurus-plugin-pwa)
-*.pwa/
-
-# Generated by Docusaurus: Jest test reports, cache, and build folders
-/jest-test-results/
-.cache/
-
-# Yarn and npm lock files
-yarn.lock
-package-lock.json
-
-# Optional IDE and build files
-.vscode/*
-.idea/*
diff --git a/.gitmodules b/.gitmodules
deleted file mode 100644
index ed7f0d76..00000000
--- a/.gitmodules
+++ /dev/null
@@ -1,3 +0,0 @@
-[submodule "themes/docsy"]
- path = themes/docsy
- url = https://github.com/google/docsy
diff --git a/.markdownlint.json b/.markdownlint.json
new file mode 100644
index 00000000..35049529
--- /dev/null
+++ b/.markdownlint.json
@@ -0,0 +1,18 @@
+{
+ "default": true,
+ "MD003": {
+ "style": "atx"
+ },
+ "MD007": {
+ "indent": 2
+ },
+ "MD013": false,
+ "MD024": {
+ "siblings_only": true
+ },
+ "MD025": false,
+ "MD033": false,
+ "MD034": false,
+ "MD041": false,
+ "no-hard-tabs": false
+}
diff --git a/.nvmrc b/.nvmrc
deleted file mode 100644
index b009dfb9..00000000
--- a/.nvmrc
+++ /dev/null
@@ -1 +0,0 @@
-lts/*
diff --git a/LICENSE b/LICENSE
new file mode 100644
index 00000000..1451535f
--- /dev/null
+++ b/LICENSE
@@ -0,0 +1,185 @@
+GNU GENERAL PUBLIC LICENSE
+Version 3, 29 June 2007
+
+Copyright © 2007 Free Software Foundation, Inc.
+ cd aqua-docs
+ ```
+
+2. **Install Mintlify CLI**
+
+ The documentation is built with Mintlify for rendering. Install the CLI globally:
+ ```bash
+ npm install -g mint
+ ```
+
+3. **Start the development server**
+
+ Run the following command in the root directory (where `docs.json` is located):
+ ```bash
+ mint dev
+ ```
+
+4. **View the documentation**
+
+ Open your browser and navigate to:
+ ```
+ http://localhost:3000
+ ```
+
+The documentation will auto-reload when you make changes to any `.mdx` files.
+
+### Troubleshooting
+
+**Dev environment not running:**
+```bash
+mint update
+```
+
+**Page loads as 404:**
+- Ensure you're in a directory with a valid `docs.json`
+- Check that the page is listed in `docs.json` navigation
+
+**Changes not reflecting:**
+- Restart the dev server
+- Clear browser cache
+- Check for syntax errors in your `.mdx` files
+
+## Documentation Format
+
+Documentation files use MDX (Markdown + JSX) with frontmatter:
+
+```mdx
---
-title: "Version 3.2"
-menu:
- main:
- weight: 10
+title: "Page Title"
+description: "Brief description for SEO and navigation"
---
+
+# Main Heading
+
+Your content here with standard Markdown syntax.
+
+## Subheading
+
+- Lists
+- Code blocks
+- Tables
+- And more
```
-## GitHub Actions
-Any changes pushed to main-branch will trigger an automatic build and publishing to https://aqua-protocol.org/docs.
+### Writing Guidelines
-## Local Build & Installation
-If you want to run it locally for testing you can do:
+1. **Use Clear Titles**: Make titles descriptive and searchable
+2. **Include Examples**: Provide code examples for all concepts
+3. **Link Between Pages**: Use relative links to connect related content
+4. **Maintain Consistency**: Follow the existing structure and style
+5. **Version-Specific**: Keep version-specific content in the appropriate directory
+## Project Structure
+
+### Core Documentation
+
+- **introduction.mdx**: Overview of Aqua Protocol
+- **quick-start.mdx**: Quick start guide for new users
+- **schema_reference/**: Detailed specifications for v4
+
+### Version Archives
+
+Each version has its own directory with:
+- Introduction and getting started
+- Core concepts
+- SDK/tooling documentation
+- Schema specifications
+
+### Configuration
+
+- **docs.json**: Navigation structure and site configuration
+- **mint.json** (if present): Additional Mintlify settings
+
+## Contributing
+
+We welcome contributions to improve the Aqua Protocol documentation!
+
+### How to Contribute
+
+1. **Fork the repository**
+2. **Create a feature branch**
+ ```bash
+ git checkout -b docs/improve-section-name
+ ```
+3. **Make your changes**
+ - Follow the writing guidelines
+ - Test locally with `mint dev`
+ - Check for broken links
+4. **Commit with clear messages**
+ ```bash
+ git commit -m "docs: improve explanation of witness revisions"
+ ```
+5. **Push and create a Pull Request**
+ ```bash
+ git push origin docs/improve-section-name
+ ```
+
+### What to Contribute
+
+- **Fix errors**: Typos, incorrect information, broken links
+- **Improve clarity**: Better explanations, more examples
+- **Add examples**: Real-world use cases and code samples
+- **Update for new versions**: Document new features and changes
+- **Translate**: Help make docs accessible in other languages
+
+### Style Guide
+
+- Use present tense ("creates" not "created")
+- Use active voice ("the SDK provides" not "is provided by the SDK")
+- Keep paragraphs short (3-5 sentences)
+- Use code blocks for all commands and code snippets
+- Include both success and error examples
+- Explain the "why" not just the "how"
+
+## Building for Production
+
+The documentation is automatically built and deployed when changes are pushed to the main branch (if CI/CD is configured).
+
+For manual builds:
```bash
-npm i & npm start & npm run build
+mint build
```
-This will start up a local test-instance on localhost:3000
+
+## Documentation Versions
+
+When documenting a new protocol version:
+
+1. Create a new directory: `previous_versions/version_X/`
+2. Include these core files:
+ - `introduction.mdx` - Version overview
+ - `concepts.mdx` - Core concepts
+ - `tooling.mdx` - SDK and tools
+ - `schema.mdx` - Technical specifications
+3. Update `docs.json` navigation
+4. Link from main introduction page
+
+## Resources
+
+### Aqua Protocol
+- **GitHub Organization**: [github.com/inblockio](https://github.com/inblockio)
+- **Rust SDK**: [aqua-rs-sdk](https://github.com/inblockio/aqua-rs-sdk)
+- **JS SDK**: [aqua-js-sdk](https://github.com/inblockio/aqua-verifier-js-lib)
+
+### Documentation Tools
+- **Mintlify Docs**: [mintlify.com/docs](https://mintlify.com/docs)
+- **MDX Documentation**: [mdxjs.com](https://mdxjs.com)
+
+## Support
+
+### Getting Help
+
+- **Issues**: Report documentation issues on GitHub
+- **Discussions**: Join community discussions
+- **SDK Issues**: Report SDK-specific issues in respective repositories
+
+### Quick Links
+
+- [Introduction to Aqua Protocol](/introduction)
+- [Quick Start Guide](/quick-start)
+- [Version 4 Schema Reference](/schema_reference/introduction)
+- [Version 3 Documentation](/previous_versions/version_3/introduction)
+
+## License
+
+Documentation content is available under the terms specified in the LICENSE file.
+
+The Aqua Protocol implementations are licensed separately - see their respective repositories for details.
+
+## Changelog
+
+### Recent Updates
+
+- **2024-01**: Added comprehensive v3 documentation (JavaScript SDK)
+- **2024-01**: Added v4 schema reference documentation (Rust SDK)
+- **2024-01**: Restructured previous versions organization
+- **2023-12**: Added v2 tooling documentation
+
+See individual version documentation for version-specific changelogs.
+
+---
+
+**Note**: This is the documentation repository for Aqua Protocol. For protocol implementations, see the SDK repositories linked above.
diff --git a/ai-tools/claude-code.mdx b/ai-tools/claude-code.mdx
new file mode 100644
index 00000000..bdc4e04b
--- /dev/null
+++ b/ai-tools/claude-code.mdx
@@ -0,0 +1,76 @@
+---
+title: "Claude Code setup"
+description: "Configure Claude Code for your documentation workflow"
+icon: "asterisk"
+---
+
+Claude Code is Anthropic's official CLI tool. This guide will help you set up Claude Code to help you write and maintain your documentation.
+
+## Prerequisites
+
+- Active Claude subscription (Pro, Max, or API access)
+
+## Setup
+
+1. Install Claude Code globally:
+
+ ```bash
+ npm install -g @anthropic-ai/claude-code
+```
+
+2. Navigate to your docs directory.
+3. (Optional) Add the `CLAUDE.md` file below to your project.
+4. Run `claude` to start.
+
+## Create `CLAUDE.md`
+
+Create a `CLAUDE.md` file at the root of your documentation repository to train Claude Code on your specific documentation standards:
+
+````markdown
+# Mintlify documentation
+
+## Working relationship
+- You can push back on ideas-this can lead to better documentation. Cite sources and explain your reasoning when you do so
+- ALWAYS ask for clarification rather than making assumptions
+- NEVER lie, guess, or make up information
+
+## Project context
+- Format: MDX files with YAML frontmatter
+- Config: docs.json for navigation, theme, settings
+- Components: Mintlify components
+
+## Content strategy
+- Document just enough for user success - not too much, not too little
+- Prioritize accuracy and usability of information
+- Make content evergreen when possible
+- Search for existing information before adding new content. Avoid duplication unless it is done for a strategic reason
+- Check existing patterns for consistency
+- Start by making the smallest reasonable changes
+
+## Frontmatter requirements for pages
+- title: Clear, descriptive page title
+- description: Concise summary for SEO/navigation
+
+## Writing standards
+- Second-person voice ("you")
+- Prerequisites at start of procedural content
+- Test all code examples before publishing
+- Match style and formatting of existing pages
+- Include both basic and advanced use cases
+- Language tags on all code blocks
+- Alt text on all images
+- Relative paths for internal links
+
+## Git workflow
+- NEVER use --no-verify when committing
+- Ask how to handle uncommitted changes before starting
+- Create a new branch when no clear branch exists for changes
+- Commit frequently throughout development
+- NEVER skip or disable pre-commit hooks
+
+## Do not
+- Skip frontmatter on any MDX file
+- Use absolute URLs for internal links
+- Include untested code examples
+- Make assumptions - always ask for clarification
+````
diff --git a/ai-tools/cursor.mdx b/ai-tools/cursor.mdx
new file mode 100644
index 00000000..fbb77616
--- /dev/null
+++ b/ai-tools/cursor.mdx
@@ -0,0 +1,420 @@
+---
+title: "Cursor setup"
+description: "Configure Cursor for your documentation workflow"
+icon: "arrow-pointer"
+---
+
+Use Cursor to help write and maintain your documentation. This guide shows how to configure Cursor for better results on technical writing tasks and using Mintlify components.
+
+## Prerequisites
+
+- Cursor editor installed
+- Access to your documentation repository
+
+## Project rules
+
+Create project rules that all team members can use. In your documentation repository root:
+
+```bash
+mkdir -p .cursor
+```
+
+Create `.cursor/rules.md`:
+
+````markdown
+# Mintlify technical writing rule
+
+You are an AI writing assistant specialized in creating exceptional technical documentation using Mintlify components and following industry-leading technical writing practices.
+
+## Core writing principles
+
+### Language and style requirements
+
+- Use clear, direct language appropriate for technical audiences
+- Write in second person ("you") for instructions and procedures
+- Use active voice over passive voice
+- Employ present tense for current states, future tense for outcomes
+- Avoid jargon unless necessary and define terms when first used
+- Maintain consistent terminology throughout all documentation
+- Keep sentences concise while providing necessary context
+- Use parallel structure in lists, headings, and procedures
+
+### Content organization standards
+
+- Lead with the most important information (inverted pyramid structure)
+- Use progressive disclosure: basic concepts before advanced ones
+- Break complex procedures into numbered steps
+- Include prerequisites and context before instructions
+- Provide expected outcomes for each major step
+- Use descriptive, keyword-rich headings for navigation and SEO
+- Group related information logically with clear section breaks
+
+### User-centered approach
+
+- Focus on user goals and outcomes rather than system features
+- Anticipate common questions and address them proactively
+- Include troubleshooting for likely failure points
+- Write for scannability with clear headings, lists, and white space
+- Include verification steps to confirm success
+
+## Mintlify component reference
+
+### Callout components
+
+#### Note - Additional helpful information
+
+
+Supplementary information that supports the main content without interrupting flow
+
+
+#### Tip - Best practices and pro tips
+
+
+Expert advice, shortcuts, or best practices that enhance user success
+
+
+#### Warning - Important cautions
+
+
+Critical information about potential issues, breaking changes, or destructive actions
+
+
+#### Info - Neutral contextual information
+
+
+Background information, context, or neutral announcements
+
+
+#### Check - Success confirmations
+
+
+Positive confirmations, successful completions, or achievement indicators
+
+
+### Code components
+
+#### Single code block
+
+Example of a single code block:
+
+```javascript config.js
+const apiConfig = {
+ baseURL: 'https://api.example.com',
+ timeout: 5000,
+ headers: {
+ 'Authorization': `Bearer ${process.env.API_TOKEN}`
+ }
+};
+```
+
+#### Code group with multiple languages
+
+Example of a code group:
+
+
+```javascript Node.js
+const response = await fetch('/api/endpoint', {
+ headers: { Authorization: `Bearer ${apiKey}` }
+});
+```
+
+```python Python
+import requests
+response = requests.get('/api/endpoint',
+ headers={'Authorization': f'Bearer {api_key}'})
+```
+
+```curl cURL
+curl -X GET '/api/endpoint' \
+ -H 'Authorization: Bearer YOUR_API_KEY'
+```
+
+
+#### Request/response examples
+
+Example of request/response documentation:
+
+
+```bash cURL
+curl -X POST 'https://api.example.com/users' \
+ -H 'Content-Type: application/json' \
+ -d '{"name": "John Doe", "email": "john@example.com"}'
+```
+
+
+
+```json Success
+{
+ "id": "user_123",
+ "name": "John Doe",
+ "email": "john@example.com",
+ "created_at": "2024-01-15T10:30:00Z"
+}
+```
+
+
+### Structural components
+
+#### Steps for procedures
+
+Example of step-by-step instructions:
+
+
+
+ Run `npm install` to install required packages.
+
+
+ Verify installation by running `npm list`.
+
+
+
+
+ Create a `.env` file with your API credentials.
+
+ ```bash
+ API_KEY=your_api_key_here
+ ```
+
+
+ Never commit API keys to version control.
+
+
+
+
+#### Tabs for alternative content
+
+Example of tabbed content:
+
+
+
+ ```bash
+ brew install node
+ npm install -g package-name
+ ```
+
+
+
+ ```powershell
+ choco install nodejs
+ npm install -g package-name
+ ```
+
+
+
+ ```bash
+ sudo apt install nodejs npm
+ npm install -g package-name
+ ```
+
+
+
+#### Accordions for collapsible content
+
+Example of accordion groups:
+
+
+
+ - **Firewall blocking**: Ensure ports 80 and 443 are open
+ - **Proxy configuration**: Set HTTP_PROXY environment variable
+ - **DNS resolution**: Try using 8.8.8.8 as DNS server
+
+
+
+ ```javascript
+ const config = {
+ performance: { cache: true, timeout: 30000 },
+ security: { encryption: 'AES-256' }
+ };
+ ```
+
+
+
+### Cards and columns for emphasizing information
+
+Example of cards and card groups:
+
+
+Complete walkthrough from installation to your first API call in under 10 minutes.
+
+
+
+
+ Learn how to authenticate requests using API keys or JWT tokens.
+
+
+
+ Understand rate limits and best practices for high-volume usage.
+
+
+
+### API documentation components
+
+#### Parameter fields
+
+Example of parameter documentation:
+
+
+Unique identifier for the user. Must be a valid UUID v4 format.
+
+
+
+User's email address. Must be valid and unique within the system.
+
+
+
+Maximum number of results to return. Range: 1-100.
+
+
+
+Bearer token for API authentication. Format: `Bearer YOUR_API_KEY`
+
+
+#### Response fields
+
+Example of response field documentation:
+
+
+Unique identifier assigned to the newly created user.
+
+
+
+ISO 8601 formatted timestamp of when the user was created.
+
+
+
+List of permission strings assigned to this user.
+
+
+#### Expandable nested fields
+
+Example of nested field documentation:
+
+
+Complete user object with all associated data.
+
+
+
+ User profile information including personal details.
+
+
+
+ User's first name as entered during registration.
+
+
+
+ URL to user's profile picture. Returns null if no avatar is set.
+
+
+
+
+
+
+### Media and advanced components
+
+#### Frames for images
+
+Wrap all images in frames:
+
+VIDEO
+
+#### Tooltips
+
+Example of tooltip usage:
+
+
+API
+
+
+#### Updates
+
+Use updates for changelogs:
+
+
+## New features
+- Added bulk user import functionality
+- Improved error messages with actionable suggestions
+
+## Bug fixes
+- Fixed pagination issue with large datasets
+- Resolved authentication timeout problems
+
+
+## Required page structure
+
+Every documentation page must begin with YAML frontmatter:
+
+```yaml
+---
+title: "Clear, specific, keyword-rich title"
+description: "Concise description explaining page purpose and value"
+---
+```
+
+## Content quality standards
+
+### Code examples requirements
+
+- Always include complete, runnable examples that users can copy and execute
+- Show proper error handling and edge case management
+- Use realistic data instead of placeholder values
+- Include expected outputs and results for verification
+- Test all code examples thoroughly before publishing
+- Specify language and include filename when relevant
+- Add explanatory comments for complex logic
+- Never include real API keys or secrets in code examples
+
+### API documentation requirements
+
+- Document all parameters including optional ones with clear descriptions
+- Show both success and error response examples with realistic data
+- Include rate limiting information with specific limits
+- Provide authentication examples showing proper format
+- Explain all HTTP status codes and error handling
+- Cover complete request/response cycles
+
+### Accessibility requirements
+
+- Include descriptive alt text for all images and diagrams
+- Use specific, actionable link text instead of "click here"
+- Ensure proper heading hierarchy starting with H2
+- Provide keyboard navigation considerations
+- Use sufficient color contrast in examples and visuals
+- Structure content for easy scanning with headers and lists
+
+## Component selection logic
+
+- Use **Steps** for procedures and sequential instructions
+- Use **Tabs** for platform-specific content or alternative approaches
+- Use **CodeGroup** when showing the same concept in multiple programming languages
+- Use **Accordions** for progressive disclosure of information
+- Use **RequestExample/ResponseExample** specifically for API endpoint documentation
+- Use **ParamField** for API parameters, **ResponseField** for API responses
+- Use **Expandable** for nested object properties or hierarchical information
+````
diff --git a/ai-tools/windsurf.mdx b/ai-tools/windsurf.mdx
new file mode 100644
index 00000000..fce12bfd
--- /dev/null
+++ b/ai-tools/windsurf.mdx
@@ -0,0 +1,96 @@
+---
+title: "Windsurf setup"
+description: "Configure Windsurf for your documentation workflow"
+icon: "water"
+---
+
+Configure Windsurf's Cascade AI assistant to help you write and maintain documentation. This guide shows how to set up Windsurf specifically for your Mintlify documentation workflow.
+
+## Prerequisites
+
+- Windsurf editor installed
+- Access to your documentation repository
+
+## Workspace rules
+
+Create workspace rules that provide Windsurf with context about your documentation project and standards.
+
+Create `.windsurf/rules.md` in your project root:
+
+````markdown
+# Mintlify technical writing rule
+
+## Project context
+
+- This is a documentation project on the Mintlify platform
+- We use MDX files with YAML frontmatter
+- Navigation is configured in `docs.json`
+- We follow technical writing best practices
+
+## Writing standards
+
+- Use second person ("you") for instructions
+- Write in active voice and present tense
+- Start procedures with prerequisites
+- Include expected outcomes for major steps
+- Use descriptive, keyword-rich headings
+- Keep sentences concise but informative
+
+## Required page structure
+
+Every page must start with frontmatter:
+
+```yaml
+---
+title: "Clear, specific title"
+description: "Concise description for SEO and navigation"
+---
+```
+
+## Mintlify components
+
+### Callouts
+
+- `` for helpful supplementary information
+- `` for important cautions and breaking changes
+- `` for best practices and expert advice
+- `` for neutral contextual information
+- `` for success confirmations
+
+### Code examples
+
+- When appropriate, include complete, runnable examples
+- Use `` for multiple language examples
+- Specify language tags on all code blocks
+- Include realistic data, not placeholders
+- Use `` and `` for API docs
+
+### Procedures
+
+- Use `` component for sequential instructions
+- Include verification steps with `` components when relevant
+- Break complex procedures into smaller steps
+
+### Content organization
+
+- Use `` for platform-specific content
+- Use `` for progressive disclosure
+- Use `` and `` for highlighting content
+- Wrap images in ``
+- Show response structure with ``
+- Include both success and error examples
+- Use `` for nested object properties
+- Always include authentication examples
+
+## Quality standards
+
+- Test all code examples before publishing
+- Use relative paths for internal links
+- Include alt text for all images
+- Ensure proper heading hierarchy (start with h2)
+- Check existing patterns for consistency
+````
diff --git a/api-reference/endpoint/create.mdx b/api-reference/endpoint/create.mdx
new file mode 100644
index 00000000..5689f1b6
--- /dev/null
+++ b/api-reference/endpoint/create.mdx
@@ -0,0 +1,4 @@
+---
+title: 'Create Plant'
+openapi: 'POST /plants'
+---
diff --git a/api-reference/endpoint/delete.mdx b/api-reference/endpoint/delete.mdx
new file mode 100644
index 00000000..657dfc87
--- /dev/null
+++ b/api-reference/endpoint/delete.mdx
@@ -0,0 +1,4 @@
+---
+title: 'Delete Plant'
+openapi: 'DELETE /plants/{id}'
+---
diff --git a/api-reference/endpoint/get.mdx b/api-reference/endpoint/get.mdx
new file mode 100644
index 00000000..56aa09ec
--- /dev/null
+++ b/api-reference/endpoint/get.mdx
@@ -0,0 +1,4 @@
+---
+title: 'Get Plants'
+openapi: 'GET /plants'
+---
diff --git a/api-reference/endpoint/webhook.mdx b/api-reference/endpoint/webhook.mdx
new file mode 100644
index 00000000..32913402
--- /dev/null
+++ b/api-reference/endpoint/webhook.mdx
@@ -0,0 +1,4 @@
+---
+title: 'New Plant'
+openapi: 'WEBHOOK /plant/webhook'
+---
diff --git a/api-reference/introduction.mdx b/api-reference/introduction.mdx
new file mode 100644
index 00000000..c835b78b
--- /dev/null
+++ b/api-reference/introduction.mdx
@@ -0,0 +1,33 @@
+---
+title: 'Introduction'
+description: 'Example section for showcasing API endpoints'
+---
+
+
+ If you're not looking to build API reference documentation, you can delete
+ this section by removing the api-reference folder.
+
+
+## Welcome
+
+There are two ways to build API documentation: [OpenAPI](https://mintlify.com/docs/api-playground/openapi/setup) and [MDX components](https://mintlify.com/docs/api-playground/mdx/configuration). For the starter kit, we are using the following OpenAPI specification.
+
+
+ View the OpenAPI specification file
+
+
+## Authentication
+
+All API endpoints are authenticated using Bearer tokens and picked up from the specification file.
+
+```json
+"security": [
+ {
+ "bearerAuth": []
+ }
+]
+```
diff --git a/api-reference/openapi.json b/api-reference/openapi.json
new file mode 100644
index 00000000..da5326ef
--- /dev/null
+++ b/api-reference/openapi.json
@@ -0,0 +1,217 @@
+{
+ "openapi": "3.1.0",
+ "info": {
+ "title": "OpenAPI Plant Store",
+ "description": "A sample API that uses a plant store as an example to demonstrate features in the OpenAPI specification",
+ "license": {
+ "name": "MIT"
+ },
+ "version": "1.0.0"
+ },
+ "servers": [
+ {
+ "url": "http://sandbox.mintlify.com"
+ }
+ ],
+ "security": [
+ {
+ "bearerAuth": []
+ }
+ ],
+ "paths": {
+ "/plants": {
+ "get": {
+ "description": "Returns all plants from the system that the user has access to",
+ "parameters": [
+ {
+ "name": "limit",
+ "in": "query",
+ "description": "The maximum number of results to return",
+ "schema": {
+ "type": "integer",
+ "format": "int32"
+ }
+ }
+ ],
+ "responses": {
+ "200": {
+ "description": "Plant response",
+ "content": {
+ "application/json": {
+ "schema": {
+ "type": "array",
+ "items": {
+ "$ref": "#/components/schemas/Plant"
+ }
+ }
+ }
+ }
+ },
+ "400": {
+ "description": "Unexpected error",
+ "content": {
+ "application/json": {
+ "schema": {
+ "$ref": "#/components/schemas/Error"
+ }
+ }
+ }
+ }
+ }
+ },
+ "post": {
+ "description": "Creates a new plant in the store",
+ "requestBody": {
+ "description": "Plant to add to the store",
+ "content": {
+ "application/json": {
+ "schema": {
+ "$ref": "#/components/schemas/NewPlant"
+ }
+ }
+ },
+ "required": true
+ },
+ "responses": {
+ "200": {
+ "description": "plant response",
+ "content": {
+ "application/json": {
+ "schema": {
+ "$ref": "#/components/schemas/Plant"
+ }
+ }
+ }
+ },
+ "400": {
+ "description": "unexpected error",
+ "content": {
+ "application/json": {
+ "schema": {
+ "$ref": "#/components/schemas/Error"
+ }
+ }
+ }
+ }
+ }
+ }
+ },
+ "/plants/{id}": {
+ "delete": {
+ "description": "Deletes a single plant based on the ID supplied",
+ "parameters": [
+ {
+ "name": "id",
+ "in": "path",
+ "description": "ID of plant to delete",
+ "required": true,
+ "schema": {
+ "type": "integer",
+ "format": "int64"
+ }
+ }
+ ],
+ "responses": {
+ "204": {
+ "description": "Plant deleted",
+ "content": {}
+ },
+ "400": {
+ "description": "unexpected error",
+ "content": {
+ "application/json": {
+ "schema": {
+ "$ref": "#/components/schemas/Error"
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+ },
+ "webhooks": {
+ "/plant/webhook": {
+ "post": {
+ "description": "Information about a new plant added to the store",
+ "requestBody": {
+ "description": "Plant added to the store",
+ "content": {
+ "application/json": {
+ "schema": {
+ "$ref": "#/components/schemas/NewPlant"
+ }
+ }
+ }
+ },
+ "responses": {
+ "200": {
+ "description": "Return a 200 status to indicate that the data was received successfully"
+ }
+ }
+ }
+ }
+ },
+ "components": {
+ "schemas": {
+ "Plant": {
+ "required": [
+ "name"
+ ],
+ "type": "object",
+ "properties": {
+ "name": {
+ "description": "The name of the plant",
+ "type": "string"
+ },
+ "tag": {
+ "description": "Tag to specify the type",
+ "type": "string"
+ }
+ }
+ },
+ "NewPlant": {
+ "allOf": [
+ {
+ "$ref": "#/components/schemas/Plant"
+ },
+ {
+ "required": [
+ "id"
+ ],
+ "type": "object",
+ "properties": {
+ "id": {
+ "description": "Identification number of the plant",
+ "type": "integer",
+ "format": "int64"
+ }
+ }
+ }
+ ]
+ },
+ "Error": {
+ "required": [
+ "error",
+ "message"
+ ],
+ "type": "object",
+ "properties": {
+ "error": {
+ "type": "integer",
+ "format": "int32"
+ },
+ "message": {
+ "type": "string"
+ }
+ }
+ }
+ },
+ "securitySchemes": {
+ "bearerAuth": {
+ "type": "http",
+ "scheme": "bearer"
+ }
+ }
+ }
+}
\ No newline at end of file
diff --git a/aqua-logo.svg b/aqua-logo.svg
new file mode 100644
index 00000000..8d5d949b
--- /dev/null
+++ b/aqua-logo.svg
@@ -0,0 +1,33 @@
+
+
+
diff --git a/blog/2019-05-28-first-blog-post.md b/blog/2019-05-28-first-blog-post.md
deleted file mode 100644
index d3032efb..00000000
--- a/blog/2019-05-28-first-blog-post.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-slug: first-blog-post
-title: First Blog Post
-authors: [slorber, yangshun]
-tags: [hola, docusaurus]
----
-
-Lorem ipsum dolor sit amet...
-
-
-
-...consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
diff --git a/blog/2019-05-29-long-blog-post.md b/blog/2019-05-29-long-blog-post.md
deleted file mode 100644
index eb4435de..00000000
--- a/blog/2019-05-29-long-blog-post.md
+++ /dev/null
@@ -1,44 +0,0 @@
----
-slug: long-blog-post
-title: Long Blog Post
-authors: yangshun
-tags: [hello, docusaurus]
----
-
-This is the summary of a very long blog post,
-
-Use a `` comment to limit blog post size in the list view.
-
-
-
-Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
-
-Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
-
-Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
-
-Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
-
-Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
-
-Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
-
-Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
-
-Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
-
-Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
-
-Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
-
-Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
-
-Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
-
-Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
-
-Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
-
-Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
-
-Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
diff --git a/blog/2021-08-01-mdx-blog-post.mdx b/blog/2021-08-01-mdx-blog-post.mdx
deleted file mode 100644
index 0c4b4a48..00000000
--- a/blog/2021-08-01-mdx-blog-post.mdx
+++ /dev/null
@@ -1,24 +0,0 @@
----
-slug: mdx-blog-post
-title: MDX Blog Post
-authors: [slorber]
-tags: [docusaurus]
----
-
-Blog posts support [Docusaurus Markdown features](https://docusaurus.io/docs/markdown-features), such as [MDX](https://mdxjs.com/).
-
-:::tip
-
-Use the power of React to create interactive blog posts.
-
-:::
-
-{/* truncate */}
-
-For example, use JSX to create an interactive button:
-
-```js
- alert('button clicked!')}>Click me!
-```
-
- alert('button clicked!')}>Click me!
diff --git a/blog/2021-08-26-welcome/docusaurus-plushie-banner.jpeg b/blog/2021-08-26-welcome/docusaurus-plushie-banner.jpeg
deleted file mode 100644
index 11bda092..00000000
Binary files a/blog/2021-08-26-welcome/docusaurus-plushie-banner.jpeg and /dev/null differ
diff --git a/blog/2021-08-26-welcome/index.md b/blog/2021-08-26-welcome/index.md
deleted file mode 100644
index 349ea075..00000000
--- a/blog/2021-08-26-welcome/index.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-slug: welcome
-title: Welcome
-authors: [slorber, yangshun]
-tags: [facebook, hello, docusaurus]
----
-
-[Docusaurus blogging features](https://docusaurus.io/docs/blog) are powered by the [blog plugin](https://docusaurus.io/docs/api/plugins/@docusaurus/plugin-content-blog).
-
-Here are a few tips you might find useful.
-
-
-
-Simply add Markdown files (or folders) to the `blog` directory.
-
-Regular blog authors can be added to `authors.yml`.
-
-The blog post date can be extracted from filenames, such as:
-
-- `2019-05-30-welcome.md`
-- `2019-05-30-welcome/index.md`
-
-A blog post folder can be convenient to co-locate blog post images:
-
-
-
-The blog supports tags as well!
-
-**And if you don't want a blog**: just delete this directory, and use `blog: false` in your Docusaurus config.
diff --git a/blog/authors.yml b/blog/authors.yml
deleted file mode 100644
index 8bfa5c7c..00000000
--- a/blog/authors.yml
+++ /dev/null
@@ -1,23 +0,0 @@
-yangshun:
- name: Yangshun Tay
- title: Front End Engineer @ Facebook
- url: https://github.com/yangshun
- image_url: https://github.com/yangshun.png
- page: true
- socials:
- x: yangshunz
- github: yangshun
-
-slorber:
- name: Sébastien Lorber
- title: Docusaurus maintainer
- url: https://sebastienlorber.com
- image_url: https://github.com/slorber.png
- page:
- # customize the url of the author page at /blog/authors/
- permalink: '/all-sebastien-lorber-articles'
- socials:
- x: sebastienlorber
- linkedin: sebastienlorber
- github: slorber
- newsletter: https://thisweekinreact.com
diff --git a/blog/tags.yml b/blog/tags.yml
deleted file mode 100644
index bfaa778f..00000000
--- a/blog/tags.yml
+++ /dev/null
@@ -1,19 +0,0 @@
-facebook:
- label: Facebook
- permalink: /facebook
- description: Facebook tag description
-
-hello:
- label: Hello
- permalink: /hello
- description: Hello tag description
-
-docusaurus:
- label: Docusaurus
- permalink: /docusaurus
- description: Docusaurus tag description
-
-hola:
- label: Hola
- permalink: /hola
- description: Hola tag description
diff --git a/dev_tools/aqua_cli.mdx b/dev_tools/aqua_cli.mdx
new file mode 100644
index 00000000..565eeca4
--- /dev/null
+++ b/dev_tools/aqua_cli.mdx
@@ -0,0 +1,133 @@
+---
+title: 'Aqua CLI'
+description: 'Install a binary for notarization and verification'
+icon: "terminal"
+---
+
+
+The Aqua CLI is a command-line tool for creating, signing, witnessing, and verifying Aqua Protocol chains. Built with Rust, it provides a simple interface for working with Aqua chains without writing code.
+
+## Features
+
+- **Chain Validation**: Verify Aqua chain integrity and signatures
+- **Signing**: Add cryptographic signatures to revisions
+- **Witnessing**: Anchor chains to Ethereum networks (mainnet, Sepolia, Holesky)
+- **Batch Operations**: Process multiple chains efficiently
+- **Environment Configuration**: Flexible configuration via environment variables
+
+## Installation
+
+### From Source
+
+```bash
+git clone https://github.com/inblockio/aqua-cli-rs
+cd aqua-cli-rs
+cargo build --release
+```
+
+The binary will be available at `target/release/aqua-cli`
+
+### Local Development
+
+```bash
+cargo build
+cd target/debug
+./aqua-cli --help
+```
+
+## Configuration
+
+Configure the CLI using environment variables:
+
+```bash
+# Optional: Domain identifier (auto-generated if not specified)
+export aqua_domain="your_domain"
+
+# Network for witnessing (default: sepolia)
+export aqua_network="sepolia" # or "holesky" or "mainnet"
+
+# Verification platform (default: none)
+export verification_platform="alchemy" # or "infura" or "self"
+
+# Blockchain for witnessing (default: none)
+export chain="sepolia" # or "mainnet" or "holesky"
+
+# API key for Alchemy or Infura
+export api_key="your_api_key"
+
+# Path to keys file for signing
+export keys_file="path/to/keys.json"
+```
+
+## Basic Usage
+
+Get started with the CLI:
+
+```bash
+# Display help
+./aqua-cli --help
+
+# Verify an Aqua chain
+./aqua-cli verify --file chain.aqua.json
+
+# Sign a chain
+./aqua-cli sign --file chain.aqua.json --keys keys.json
+
+# Witness a chain on Sepolia testnet
+./aqua-cli witness --file chain.aqua.json --network sepolia
+```
+
+## Keys File Format
+
+Create a `keys.json` file for signing operations:
+
+```json
+{
+ "private_key": "your_private_key_hex",
+ "wallet_address": "0xYourEthereumAddress"
+}
+```
+
+**Security Note**: Use a wallet without MetaMask for CLI operations. Keep your keys file secure and never commit it to version control.
+
+## Versioning
+
+Ensure the CLI version matches your Aqua Protocol version:
+- Use CLI version `4.0.x` for Aqua Protocol v4 chains
+- Use CLI version `3.x.x` for Aqua Protocol v3 chains
+
+## Testing
+
+The repository includes a test script for verifying functionality:
+
+```bash
+# Grant execution permissions
+chmod +x test_aqua_cli.sh
+
+# Run tests
+./test_aqua_cli.sh
+```
+
+## Use Cases
+
+- **Quick Verification**: Validate chain integrity without building applications
+- **CI/CD Integration**: Automate verification in deployment pipelines
+- **Batch Processing**: Process multiple chains in scripts
+- **Development Testing**: Quickly test chain creation and verification
+- **System Administration**: Manage Aqua chains from the command line
+
+## Repository
+
+**GitHub**: [github.com/inblockio/aqua-cli-rs](https://github.com/inblockio/aqua-cli-rs)
+
+## Documentation
+
+For more information about Aqua Protocol v4:
+- [Version 4 Introduction](/previous_versions/version_4/version_4)
+- [Schema Reference](/schema_reference/introduction)
+
+## Version
+
+**Current Version**: 4.0.0
+
+Built using the [Aqua Rust SDK](/dev_tools/aqua_sdk) for Aqua Protocol v4 support.
diff --git a/dev_tools/aqua_sdk.mdx b/dev_tools/aqua_sdk.mdx
new file mode 100644
index 00000000..01b30c82
--- /dev/null
+++ b/dev_tools/aqua_sdk.mdx
@@ -0,0 +1,110 @@
+---
+title: 'Aqua SDK'
+description: 'A library for use in a code base for notarization and verification'
+icon: "code"
+---
+This Page contains sdk details of version 4 of the Aqua Protocol.To Use version 3 which is stable visit [quickstart](/quickstart)
+The Aqua SDK is a Rust library that provides the core functionality for creating, signing, witnessing, and verifying Aqua Protocol chains. It supports Aqua Protocol v4 and includes WebAssembly (WASM) bindings for cross-platform compatibility.
+
+## Features
+
+- **Create Aqua Chains**: Build revision chains with objects, templates, signatures, witnesses, and links
+- **Template System**: Define and validate structured data using JSON Schema
+- **Multiple Signature Methods**: Support for RSA, Ethereum EIP-191, and DID:JWS signatures
+- **Blockchain Witnessing**: Anchor revisions to Ethereum (mainnet, Sepolia, Holesky), Nostr, or TSA
+- **Chain Verification**: Cryptographically verify complete revision chains
+- **Cross-Platform**: WASM support enables use in web browsers, Node.js, and native applications
+
+## Installation
+
+Add the SDK to your Rust project:
+
+```toml
+[dependencies]
+aqua-rs-sdk = { git = "https://github.com/inblockio/aqua-verifier-rs" }
+```
+
+## Quick Example
+
+```rust
+ use aqua_rs_sdk::primitives::Method;
+ use aqua_rs_sdk::schema::file_data::FileData;
+ use aqua_rs_sdk::Aquafier;
+ use std::path::PathBuf;
+
+ #[tokio::main]
+ async fn main() -> Result<(), Box> {
+ println!("Creating Aqua chain...");
+
+ // Read file content
+ let filename = "test.txt".to_string();
+ let file_content = tokio::fs::read(&filename).await?;
+
+ // Create file data
+ let file_data = FileData::new(
+ filename.clone(),
+ file_content,
+ PathBuf::from(format!("./{}", filename)),
+ );
+
+ // Initialize Aquafier
+ let aquafier = Aquafier::new(None, None);
+
+ // Create genesis revision (notarize the file)
+ let result = aquafier.create_genesis_revision(file_data, Method::Scalar);
+
+ match result {
+ Ok(tree) => {
+ println!("✓ Aqua chain created successfully!");
+ println!("{}", serde_json::to_string_pretty(&tree)?);
+
+ println!("\nYou can now:");
+ println!("- Add a signature revision");
+ println!("- Witness on blockchain");
+ println!("- Verify the chain");
+
+ // Sign the revision
+ // let signature = sign_revision(&object_revision, &signing_key)?;
+
+ // Witness on blockchain
+ // let witness = witness_revision(&signature, EthereumNetwork::Sepolia)?;
+
+ // Verify the complete chain
+ // let is_valid = verify_chain(&aqua_chain)?;
+
+ }
+ Err(e) => {
+ eprintln!("Error: {:#?}", e);
+ }
+ }
+
+ Ok(())
+ }
+
+
+```
+
+## Use Cases
+
+- **Application Integration**: Embed Aqua Protocol directly into your Rust applications
+- **Custom Tools**: Build specialized tools for specific workflows
+- **Smart Contracts**: Integrate with blockchain applications using WASM
+- **Web Applications**: Use WASM bindings to run in browsers
+- **Server Applications**: Build backend services with native Rust performance
+
+## Repository
+
+**GitHub**: [github.com/inblockio/aqua-verifier-rs](https://github.com/inblockio/aqua-rs-sdk)
+
+## Documentation
+
+For detailed API documentation, examples, and guides:
+- [Version 4 Introduction](/previous_versions/version_4/version_4)
+- [Schema Reference](/schema_reference/introduction)
+- [API Documentation](https://docs.rs/aqua-rs-sdk)
+
+## Version
+
+**Current Version**: 4.0.0 (Beta)
+
+The SDK implements Aqua Protocol v4 with the template system and enhanced revision types. For production-stable implementations, consider the [JavaScript SDK (v3)](/previous_versions/version_3/tooling).
diff --git a/dev_tools/aquafier_api.mdx b/dev_tools/aquafier_api.mdx
new file mode 100644
index 00000000..fd70f873
--- /dev/null
+++ b/dev_tools/aquafier_api.mdx
@@ -0,0 +1,150 @@
+---
+title: 'Aquafier API'
+description: ' A http API for notarization and verification '
+icon: "code"
+---
+
+
+Aquafier is a web-based reference implementation of Aqua Protocol v3, providing a user-friendly interface and HTTP API for digital content signing, provenance verification, and integrity validation. It demonstrates how Aqua Protocol features can be integrated into modern web applications.
+
+## Overview
+
+Aquafier combines a Fastify backend with React frontend to deliver a complete solution for document notarization and verification. It's designed as both a production tool and a reference implementation for developers building Aqua-based applications.
+
+## Features
+
+- **Digital Content Signing**: Sign documents and data with multiple signature methods
+- **Provenance Verification**: Track and verify document history and authenticity
+- **Integrity Validation**: Cryptographically verify document integrity
+- **Web Interface**: User-friendly React interface for non-technical users
+- **HTTP API**: RESTful API for programmatic access
+- **Multi-Party Workflows**: Support for documents requiring multiple signatures
+
+## Technology Stack
+
+**Backend**:
+- Fastify (Node.js web framework)
+- Prisma ORM
+- PostgreSQL database
+- Aqua JavaScript SDK (v3)
+
+**Frontend**:
+- React with TypeScript
+- Chakra UI components
+- End-to-end testing with Playwright
+
+## Hosted Instances
+
+**Production**: [aquafier.inblock.io](https://aquafier.inblock.io/)
+- Stable production environment
+- For live document notarization and verification
+
+**Development/Testing**: [dev.inblock.io](https://dev.inblock.io/)
+- Testing environment for new features
+- Use for development and experimentation
+
+## Use Cases
+
+- **Document Notarization**: Notarize legal documents, contracts, and agreements
+- **Certificate Issuance**: Issue verifiable certificates and credentials
+- **Multi-Party Signing**: Collect signatures from multiple parties
+- **Audit Trail Creation**: Build immutable audit trails for compliance
+- **Proof of Concept**: Demonstrate Aqua Protocol capabilities
+- **API Integration**: Integrate notarization into existing systems
+
+## API Access
+
+Aquafier provides a RESTful HTTP API for programmatic access. Developers can integrate notarization and verification into their applications without building infrastructure from scratch.
+
+Common API operations:
+- Create genesis revisions
+- Add signatures to existing chains
+- Witness chains on blockchain
+- Verify chain integrity
+- Retrieve chain history
+
+## Development
+
+Aquafier-JS is open source and can be self-hosted for custom deployments.
+
+### Requirements
+- Docker and Docker Compose
+- PostgreSQL database
+- Node.js environment
+
+### Deployment
+
+Deploy using Docker Compose:
+
+```bash
+# Prepare environment file
+cp deployment/.env.sample .env
+
+# Start services
+docker compose -f deployment/docker-compose-prod.yml up -d
+```
+
+**Deployment Options**:
+- **Local**: No proxy, exposed ports for development
+- **Dev**: With Let's Encrypt SSL and DNS
+- **Prod**: Production configuration with SSL
+
+### Configuration
+
+Key environment variables:
+
+```bash
+# Database
+DATABASE_URL=postgres://user:password@host:port/database
+
+# Server
+HOST=0.0.0.0
+PORT=3000
+
+# Frontend/Backend URLs (for proxy)
+FRONTEND_URL=https://your-domain.com
+BACKEND_URL=https://api.your-domain.com
+
+# Twilio (optional, for SMS verification)
+TWILIO_ACCOUNT_SID=your_sid
+TWILIO_AUTH_TOKEN=your_token
+```
+
+## Architecture
+
+Aquafier's modular architecture makes it suitable as a foundation for custom applications:
+
+- **API Layer**: RESTful endpoints for all Aqua operations
+- **Service Layer**: Business logic for chain management
+- **Data Layer**: Prisma ORM with PostgreSQL
+- **Storage**: File system or S3-compatible storage
+- **Backup**: Automated backup with configurable retention
+
+## Protocol Version
+
+**Aqua Protocol v3**: Aquafier implements the stable JavaScript SDK
+
+For v3 technical details:
+- [Version 3 Introduction](/previous_versions/version_3/introduction)
+- [Version 3 Concepts](/previous_versions/version_3/concepts)
+- [Version 3 SDK](/previous_versions/version_3/tooling)
+
+## Repository
+
+**GitHub**: [github.com/inblockio/aquafier-js](https://github.com/inblockio/aquafier-js)
+
+## Development Team
+
+- Tim Bansemer - Project Manager
+- Arthur Kamau - Developer
+- Dalmas Nyaboga Ogembo - Developer
+- Florian Zeps - DevOps
+
+## Getting Started
+
+1. Visit [aquafier.inblock.io](https://aquafier.inblock.io/) to use the hosted version
+2. Try the [dev environment](https://dev.inblock.io/) for testing
+3. Explore the API documentation for programmatic integration
+4. Check the [GitHub repository](https://github.com/inblockio/aquafier-js) for self-hosting
+
+For building custom applications, consider using the [Aqua JavaScript SDK](/previous_versions/version_3/tooling) directly or the [Aqua Rust SDK](/dev_tools/aqua_sdk) for v4 features.
diff --git a/development.mdx b/development.mdx
new file mode 100644
index 00000000..a08d19fb
--- /dev/null
+++ b/development.mdx
@@ -0,0 +1,555 @@
+---
+title: 'Development Guide'
+description: 'Complete guide for developing with Aqua Protocol'
+icon: "code"
+---
+
+# Development Guide
+
+This guide covers everything you need to develop applications with Aqua Protocol, including signing methods, witnessing options, and SDK usage.
+
+
+**Prerequisites**: We recommend completing the [Quick Start Guide](/quickstart) before diving into development details.
+
+
+## Choose Your SDK
+
+Aqua Protocol offers SDKs for different use cases:
+
+
+
+ **Beta** - Template system, WASM support, cross-platform
+
+ Best for: New projects, performance-critical applications
+
+
+
+ **Stable** - Production-ready, Node.js/Web/React Native
+
+ Best for: Web applications, existing JavaScript projects
+
+
+
+ Command-line tool for quick operations
+
+ Best for: Testing, CI/CD, scripting
+
+
+
+ Web-based API for notarization
+
+ Best for: No-code integration, demos
+
+
+
+## Signing Methods
+
+Aqua Protocol supports multiple signature types for different use cases:
+
+| Method | Protocol Version | Use Case | Trust Model |
+|--------|-----------------|----------|-------------|
+| **DID (JWS)** | v3, v4 | Decentralized identities | W3C DID standard |
+| **Ethereum (EIP-191)** | v3, v4 | Blockchain-native apps | Ethereum addresses |
+| **RSA** | v4 only | Traditional PKI | Certificate authorities |
+| **P12 Certificates** | v3 only | Enterprise/legal docs | Certificate authorities |
+
+
+### Signing Setup Details
+
+
+**What you need**: A DID key pair
+
+**How to generate**:
+
+**Option 1: Using JavaScript**
+```bash
+npm install @digitalcredentials/did-method-key
+```
+
+```javascript
+import { Ed25519VerificationKey2020 } from '@digitalcredentials/ed25519-verification-key-2020';
+import { X25519KeyAgreementKey2020 } from '@digitalcredentials/x25519-key-agreement-key-2020';
+
+const keyPair = await Ed25519VerificationKey2020.generate();
+const did = `did:key:${keyPair.publicKeyMultibase}`;
+console.log('DID:', did);
+console.log('Private Key:', keyPair.privateKeyMultibase);
+```
+
+**Option 2: Online Generator**
+- Visit [EBSI DID Generator](https://hub.ebsi.eu/tools/did-generator)
+- Click "Generate Keys"
+- Save your DID and private key securely
+
+**Protocol Support**: v3, v4
+
+
+
+**What you need**: Ethereum wallet with private key or mnemonic
+
+**Two supported methods**:
+
+**1. MetaMask Browser Extension** (Recommended for development)
+- Install [MetaMask](https://metamask.io/) in your browser
+- Create or import a wallet
+- The SDK will prompt for signature when needed
+
+**2. Mnemonic/Private Key in Credentials File**
+
+Create a `credentials.json` file:
+```json
+{
+ "mnemonic": "your twelve word mnemonic phrase here...",
+ "wallet_address": "0xYourEthereumAddress"
+}
+```
+
+Or with private key:
+```json
+{
+ "private_key": "0xYourPrivateKeyHex",
+ "wallet_address": "0xYourEthereumAddress"
+}
+```
+
+
+**Security**: Never commit credentials.json to version control! Add it to `.gitignore`.
+
+
+Check your SDK documentation ([Rust SDK](/dev_tools/aqua_sdk) | [JavaScript SDK](/previous_versions/version_3/tooling)) for how to pass credentials.
+
+**Protocol Support**: v3, v4
+
+
+
+**What you need**: RSA key pair (2048-bit or higher)
+
+**Generate RSA keys**:
+
+```bash
+# Generate private key (2048-bit)
+openssl genrsa -out private.pem 2048
+
+# Extract public key
+openssl rsa -in private.pem -pubout -out public.pem
+
+# View keys
+cat private.pem
+cat public.pem
+```
+
+**For production**: Use keys from your organization's PKI infrastructure or certificate authority.
+
+**Protocol Support**: v4 only
+
+
+
+**What you need**: PKCS#12 certificate file (.p12/.pfx) with password
+
+**For Development** (self-signed certificate):
+
+```bash
+# Generate private key
+openssl genrsa -out private.key 2048
+
+# Create certificate signing request
+openssl req -new -key private.key -out certificate.csr
+
+# For Windows/Git Bash, specify config:
+# openssl req -new -key private.key -out certificate.csr -config "C:\Program Files\Git\usr\ssl\openssl.cnf"
+
+# Generate self-signed certificate (valid for 365 days)
+openssl x509 -req -days 365 -in certificate.csr -signkey private.key -out certificate.crt
+
+# Create P12 file (you'll be prompted for export password)
+openssl pkcs12 -export -out certificate.p12 -inkey private.key -in certificate.crt
+```
+
+**Convert to Base64** (required for SDK):
+```bash
+# macOS/Linux
+base64 -i certificate.p12 -o certificate_base64.txt
+
+# Windows (PowerShell)
+[Convert]::ToBase64String([IO.File]::ReadAllBytes("certificate.p12")) | Out-File certificate_base64.txt
+
+# Linux alternative
+base64 certificate.p12 > certificate_base64.txt
+```
+
+**For Production** (trusted certificate):
+
+1. **Purchase from Certificate Authority**:
+ - DigiCert, Sectigo, GlobalSign, etc.
+ - Request "Code Signing" or "Document Signing" certificate
+ - They'll provide a .p12/.pfx file directly
+
+2. **If you receive separate files** (.crt + .key + intermediate):
+ ```bash
+ openssl pkcs12 -export -out certificate.p12 \
+ -inkey privatekey.key \
+ -in certificate.crt \
+ -certfile intermediate.crt
+ ```
+
+**Usage in SDK**:
+```json
+{
+ "p12_content": "base64_encoded_p12_content_here",
+ "p12_password": "your_export_password"
+}
+```
+
+**Protocol Support**: v3 only
+
+
+## Witnessing Methods
+
+Witnessing anchors your Aqua revisions to external timestamping services for provable timestamps:
+
+| Method | Networks | Cost | Verification |
+|--------|----------|------|--------------|
+| **Ethereum** | Mainnet, Sepolia, Holesky | Gas fees (testnet: free) | Blockchain explorer |
+| **TSA** | RFC 3161 services | Free (public TSAs) | TSA verification |
+| **Nostr** | Nostr relays | Free | Nostr event verification |
+
+### Witnessing Setup Details
+
+
+**What you need**: A TSA service URL
+
+**Free Public TSA Services**:
+
+```bash
+# DigiCert
+http://timestamp.digicert.com
+
+# Sectigo (formerly Comodo)
+http://timestamp.sectigo.com
+http://timestamp.comodoca.com
+
+# GlobalSign
+http://timestamp.globalsign.com/scripts/timstamp.dll
+http://timestamp.globalsign.com/tsa/r6advanced1
+
+# Entrust
+http://timestamp.entrust.net/TSS/RFC3161sha2TS
+```
+
+**Usage**: Simply provide the TSA URL to your SDK when witnessing.
+
+**Benefits**:
+- No blockchain required
+- Widely accepted standard (RFC 3161)
+- Free for most public TSAs
+- Instant timestamps
+
+**Protocol Support**: v3, v4
+
+
+
+**What you need**:
+1. Ethereum wallet (MetaMask or mnemonic/private key)
+2. ETH for gas fees (mainnet) or testnet ETH (Sepolia/Holesky)
+3. Alchemy API key for witness verification
+
+**Networks Supported**:
+- **Mainnet**: Production use, requires real ETH for gas
+- **Sepolia**: Testnet, free test ETH from faucets
+- **Holesky**: Testnet, free test ETH from faucets
+
+**Wallet Setup** (same as signing):
+
+**Option 1: MetaMask**
+- Install [MetaMask](https://metamask.io/)
+- Ensure you're on the correct network (mainnet/sepolia/holesky)
+- Have sufficient ETH for gas fees
+
+**Option 2: Credentials File**
+```json
+{
+ "mnemonic": "your twelve word mnemonic phrase here...",
+ "wallet_address": "0xYourEthereumAddress"
+}
+```
+
+**Get Test ETH** (for testnets):
+- Sepolia: [sepoliafaucet.com](https://sepoliafaucet.com)
+- Holesky: [holesky-faucet.pk910.de](https://holesky-faucet.pk910.de)
+
+**Alchemy API Key** (for verification):
+1. Visit [alchemy.com](https://www.alchemy.com/)
+2. Create free account
+3. Create new app
+4. Copy API key
+5. [Detailed guide](https://www.alchemy.com/docs/how-to-create-access-keys)
+
+**Protocol Support**: v3, v4
+
+
+
+**What you need**: Nostr secret key (nsec)
+
+**How to get a Nostr key**:
+
+**Option 1: Nostr Client App**
+1. Download a Nostr app:
+ - [Damus](https://damus.io/) (iOS)
+ - [Amethyst](https://github.com/vitorpamplona/amethyst) (Android)
+ - [Primal](https://primal.net/) (Web/Mobile)
+2. Create new account or log in
+3. App generates a key pair automatically
+4. Your secret key starts with `nsec1...`
+5. **Save it securely** - you'll need it for witnessing
+
+**Option 2: Web Generator**
+- Visit [nostr.com](https://nostr.com) or [nostrtool.com](https://nostrtool.com)
+- Click "Generate Keys"
+- Save your secret key (`nsec1...`)
+
+
+**Security**: Your Nostr secret key is permanent. Anyone with it can post as you on Nostr relays. Keep it secure!
+
+
+**Benefits**:
+- Fully decentralized (no blockchain fees)
+- Censorship-resistant
+- Fast propagation across relays
+- Free to use
+
+**Protocol Support**: v3, v4
+
+
+
+
+## JavaScript SDK Usage (v3)
+
+
+**Prerequisites**:
+- Node.js version 19 or higher
+- Install aqua-js-sdk: `npm install aqua-js-sdk`
+
+
+### Complete Workflow Example
+
+Follow these steps to notarize a file, sign it, and witness it using the JavaScript SDK (v3):
+
+
+
+
+```typescript
+import Aquafier, { FileObject } from 'aqua-js-sdk';
+import { readFileSync } from 'fs';
+
+// Read file content
+const testFileContent = readFileSync("./test.txt", 'utf-8');
+
+// Create file object
+const aquaFileObject: FileObject = {
+ fileName: "test.txt",
+ fileContent: testFileContent,
+ path: "./test.txt"
+};
+
+// Initialize Aquafier
+const aquafier = new Aquafier();
+
+// Create genesis revision (notarize the file)
+const genesisResult = await aquafier.createGenesisRevision(aquaFileObject);
+
+if (genesisResult.isOk()) {
+ console.log("Genesis created successfully!");
+ console.log("Aqua Tree:", genesisResult.data.aquaTree);
+} else {
+ console.error("Error creating genesis:", genesisResult.error);
+}
+```
+
+
+
+
+```typescript
+import { AquaTreeWrapper, CredentialsData } from 'aqua-js-sdk';
+
+// Prepare credentials (for MetaMask, can be empty object)
+const creds: CredentialsData = {};
+
+// Or for CLI signing with mnemonic:
+// const creds: CredentialsData = {
+// mnemonic: "your twelve word mnemonic here",
+// wallet_address: "0xYourAddress"
+// };
+
+// Create wrapper (empty string for revision means sign latest)
+const aquaWrapper: AquaTreeWrapper = {
+ aquaTree: genesisResult.data.aquaTree,
+ fileObject: aquaFileObject,
+ revision: "" // Sign latest revision
+};
+
+// Sign with MetaMask (or use "cli", "did", "p12")
+const signedResult = await aquafier.signAquaTree(
+ aquaWrapper,
+ "metamask", // Signature type
+ creds,
+ true // Auto-increment
+);
+
+if (signedResult.isOk()) {
+ console.log("Signature added successfully!");
+} else {
+ console.error("Signing failed:", signedResult.error);
+}
+```
+
+
+
+
+```typescript
+// Update wrapper with signed tree
+const witnessWrapper: AquaTreeWrapper = {
+ aquaTree: signedResult.data.aquaTree,
+ fileObject: aquaFileObject,
+ revision: "" // Witness latest revision
+};
+
+// Witness on Ethereum Sepolia testnet
+const witnessResult = await aquafier.witnessAquaTree(
+ witnessWrapper,
+ "eth", // Witness type (eth, tsa, or nostr)
+ "sepolia", // Network (sepolia, mainnet, holesky)
+ "metamask", // Signing method
+ creds,
+ true // Auto-increment
+);
+
+if (witnessResult.isOk()) {
+ console.log("Witnessing successful!");
+ console.log("Transaction:", witnessResult.data.witness_transaction_hash);
+} else {
+ console.error("Witnessing failed:", witnessResult.error);
+}
+```
+
+
+
+
+```typescript
+// Fetch aqua tree from storage, database, or state
+const aquaTree = witnessResult.data.aquaTree;
+
+// Prepare credentials for verification (needs Alchemy key for Ethereum witness)
+const verifyCreds: CredentialsData = {
+ alchemy_key: "your_alchemy_api_key"
+};
+
+// Verify the complete tree
+const verificationResult = await aquafier.verifyAquaTree(
+ aquaTree,
+ [aquaFileObject], // Array of file objects
+ verifyCreds
+);
+
+if (verificationResult.isOk()) {
+ console.log("✓ Verification successful!");
+ console.log("Details:", JSON.stringify(verificationResult.data, null, 2));
+} else {
+ console.log("✗ Verification failed!");
+ console.log("Details:", JSON.stringify(verificationResult.data, null, 2));
+}
+```
+
+
+
+### More Examples
+
+
+
+ Browse full working examples in the repository
+
+
+
+ Detailed API reference for JavaScript SDK
+
+
+
+## Rust SDK Usage (v4)
+
+
+**Prerequisites**:
+- Rust 1.70 or higher
+- Add to Cargo.toml: `aqua-rs-sdk = { git = "https://github.com/inblockio/aqua-verifier-rs" }`
+
+
+### Quick Example
+
+```rust
+use aqua_rs_sdk::primitives::Method;
+use aqua_rs_sdk::schema::file_data::FileData;
+use aqua_rs_sdk::Aquafier;
+use std::path::PathBuf;
+
+#[tokio::main]
+async fn main() -> Result<(), Box> {
+ // Read file content
+ let filename = "test.txt".to_string();
+ let file_content = tokio::fs::read(&filename).await?;
+
+ // Create file data
+ let file_data = FileData::new(
+ filename.clone(),
+ file_content,
+ PathBuf::from(format!("./{}", filename)),
+ );
+
+ // Initialize Aquafier
+ let aquafier = Aquafier::new(None, None);
+
+ // Create genesis revision (notarize the file)
+ let result = aquafier.create_genesis_revision(file_data, Method::Scalar);
+
+ match result {
+ Ok(tree) => {
+ println!("✓ Aqua chain created successfully!");
+ println!("{}", serde_json::to_string_pretty(&tree)?);
+ }
+ Err(e) => {
+ eprintln!("Error: {:#?}", e);
+ }
+ }
+
+ Ok(())
+}
+```
+
+### More Resources
+
+
+
+ Complete guide for the Rust SDK
+
+
+
+ v4 protocol specifications
+
+
+
+## Next Steps
+
+
+
+ Explore real-world applications
+
+
+
+ Build your first Aqua application
+
+
+
+ Browse complete examples
+
+
+
+ Need help? Contact our team
+
+
\ No newline at end of file
diff --git a/docs.json b/docs.json
new file mode 100644
index 00000000..b85a6b95
--- /dev/null
+++ b/docs.json
@@ -0,0 +1,151 @@
+{
+ "$schema": "https://mintlify.com/docs.json",
+ "theme": "mint",
+ "name": "Aqua Protocol Documentation",
+ "colors": {
+ "primary": "#E55B1F",
+ "light": "#07C983",
+ "dark": "#15803D"
+ },
+ "favicon": "aqua-logo.svg",
+ "navigation": {
+ "tabs": [
+ {
+ "tab": "Guides",
+ "groups": [
+ {
+ "group": "Getting started",
+ "pages": [
+ "index",
+ "quickstart",
+ "development"
+ ]
+ },
+ {
+ "group": "Aqua Versions",
+ "pages": [
+ {
+ "group": "Version (v1.0 - depracated)",
+ "pages": [
+ "previous_versions/version_1/introduction",
+ "previous_versions/version_1/concepts",
+ "previous_versions/version_1/whitepaper",
+ "previous_versions/version_1/idenity_protocol",
+ "previous_versions/version_1/name_resolution",
+ "previous_versions/version_1/assurance_levels",
+ "previous_versions/version_1/data_accounting",
+ "previous_versions/version_1/data_governance",
+ "previous_versions/version_1/delegated_witnessing",
+ "previous_versions/version_1/design_principles",
+ "previous_versions/version_1/guardian",
+ "previous_versions/version_1/immutable_hyperlinks"
+ ]
+ },
+ {
+ "group": "Version (v2.0 - depracated)",
+ "pages": [
+ "previous_versions/version_2/introduction",
+ "previous_versions/version_2/concepts",
+ "previous_versions/version_2/tooling"
+ ]
+ },
+ {
+ "group": "Version (v3.0 - current)",
+ "pages": [
+ "previous_versions/version_3/introduction",
+ "previous_versions/version_3/concepts",
+ "previous_versions/version_3/schema",
+ "previous_versions/version_3/tooling"
+ ]
+ },
+ "previous_versions/version_4/version_4"
+
+ ]
+ },
+ {
+ "group": "Use Cases",
+ "pages": [
+ "use_cases/introduction",
+ "use_cases/supply_chain",
+ "use_cases/identity_attestation",
+ "use_cases/document_verification"
+ ]
+ },
+ {
+ "group": "Development tools",
+ "pages": [
+ "dev_tools/aqua_sdk",
+ "dev_tools/aquafier_api",
+ "dev_tools/aqua_cli"
+ ]
+ }
+ ]
+ },
+ {
+ "tab": "API/Schema reference (v4.0)",
+ "groups": [
+ {
+ "group": "API documentation",
+ "pages": [
+ "schema_reference/introduction"
+ ]
+ },
+ {
+ "group": "Aqua Protocol Terms Schema",
+ "pages": [
+ "schema_reference/aqua_tree",
+ "schema_reference/file_index",
+ {
+ "group": "Revision",
+ "pages": [
+ "schema_reference/revision",
+ "schema_reference/witness_revision",
+ "schema_reference/signing_revision",
+ "schema_reference/link_revision",
+ "schema_reference/template_revision",
+ "schema_reference/object_revision"
+ ]
+ }
+ ]
+ }
+ ]
+ }
+ ]
+ },
+ "logo": {
+ "light": "/logo/aqua-logo.png",
+ "dark": "/logo/aqua-logo.png"
+ },
+ "navbar": {
+ "links": [
+ {
+ "label": "Support",
+ "href": "mailto:info@inblock.io"
+ }
+ ],
+ "primary": {
+ "type": "button",
+ "label": "Checkout Aquafier",
+ "href": "https://dev.inblock.io/app"
+ }
+ },
+ "contextual": {
+ "options": [
+ "copy",
+ "view",
+ "chatgpt",
+ "claude",
+ "perplexity",
+ "mcp",
+ "cursor",
+ "vscode"
+ ]
+ },
+ "footer": {
+ "socials": {
+ "x": "https://x.com/inblockio",
+ "github": "https://github.com/inblockio",
+ "linkedin": "https://www.linkedin.com/company/inblock-io"
+ }
+ }
+}
\ No newline at end of file
diff --git a/docs/implementations/_index.md b/docs/implementations/_index.md
deleted file mode 100644
index 3bbf41fd..00000000
--- a/docs/implementations/_index.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-title: "Implementations"
-linkTitle: "Implementations"
-weight: 3
-description: >
- Details various software that is implementing the Aqua Protocol
----
-
diff --git a/docs/intro.md b/docs/intro.md
deleted file mode 100644
index 16321314..00000000
--- a/docs/intro.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-title: "Documentation"
-linkTitle: "Documentation"
-weight: 10
-menu:
- main:
- weight: 10
----
-
-The following are documentation used to understand the AQUA Protocol and it's
-implementations. AQUA is heavily under development at the moment and is evolving
-rapidly.
diff --git a/docs/overview/_index.md b/docs/overview/_index.md
deleted file mode 100644
index acdc996c..00000000
--- a/docs/overview/_index.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-title: "Overview"
-linkTitle: "Overview"
-weight: 1
-description: >
----
-
-We develop the AQUA-Protocol to increase trust and digital sovereignty for individuals and organizations.
-
-We believe that this is an effective way to redefine collaboration and strengthen democracy to be more inclusive and participatory by providing accountability for data. We do this in a context where it is critical to address challenges and threats which come with the advancement of technologies (e.g. deep fake, manipulation of data, digital surveillance, monopolization).
-
-With the powerful tools we provide, we can showcase how trusted data and digital sovereignty are key enablers to support the emancipation and integration of individuals and small to medium businesses into a digital economy, which is currently dominated by large players. We are showing how this is a feasible approach to empower more inclusive and democratic participation.
-
-# What are exemplary applications that are meeting current organizational demands?
-
-Aside from the core features of the AQUA-Protocol and its reference implementation (to provide data integrity verification, proof of existence, and a strong identity by using public-private key infrastructure), there is an amazing potential that comes as an emergent property of the interaction of individuals using sovereign instances of Personal-Knowledge-Containers.
-
-This potential lies in the ability to collaborate by exchanging verified data between independent parties to form a network of relationships as a web of trust. This allows for peer-to-peer institutions and organizations to be built fully software-defined, in traditional or network structures.
-
-It is possible to model existing institutions on top of this infrastructure today. It is a free and open-source tool to provide a process to issue and verify digital certificates for various use cases. Including examples, showcased for the educational sector (school and university degrees) but the use cases go beyond this:
-
-* Provide an infrastructure to curate knowledge and enable peer-to-peer wiki's in which a contribution itself is attested. This has potentially huge implications, as a successfully merged contribution to a leading scientific endeavor could one could imagine this succeeding the reputational value of a university degree.
-* Fighting fake news by providing an audible trail for the information source to the consumer and which steps have been taken, by which account, to reach its current state. E.g. an intelligence report about an ongoing conflict or crisis.
-* Providing credible credentials to fight deep fake and impersonation. In one shocking case, this shows the danger for our political landscape. In this example the mayor of Berlin was tricked, when she had a zoom call with a fake Vladimir Klitschko (in the role of the Mayor of Kyiv, using deep fake for the video and audio to impersonate him) who tried to get money from her. [Source](https://www.theguardian.com/world/2022/jun/25/european-leaders-deepfake-video-calls-mayor-of-kyiv-vitali-klitschko)
-* Providing a trust infrastructure for invoice validation: Large companies are challenged by the increasing number of fraud and fishing emails to trick companies to send money to criminals. We can use the SSI-Approach of aqua to verify invoices and do automated tests towards the trustworthiness of the sender, by checking the sender's account and the trust relationship cryptographically. Allowing for automated verification of the invoices instead of lengthy manual testing procedures or complicated processes requiring a CRM-System with an intense KYC (Know You Customer) approach.
-* Proving where the information has originated. This can be used to protect intellectual property (IP) or to prove where data originated. This is highly relevant in various contexts, be it for the credibility of evidence in court or for whistle-blowers or investigative journalists to give their claims more credibility.
-
-# The socio-technological impact on society
-We provide a prototype implementation of the aqua protocol with a Personal-Knowledge-Container(PKC). An approach towards digital sovereignty without compromises. It enables data accounting and with it an effective way to enable peer-to-peer trusted data generation and exchange. We showcase that it is possible to have full control over your data, you can share and govern it independently of third parties. This is essential to democratize access to the digital economy, so individuals can utilize the value of their data and do trusted interactions with each other.
-
-This technology enables various applications by offering a peer-to-peer-publishing platform technology, this includes but is not limited to:
-* Self-Sovereign Identity (SSI)
-* crowdsourced knowledge management, a distributed Wikipedia
-* crowdsourced news
-* crowdsourced petition systems (crowdsourcing problems, solutions, decisions).
-
-This Protocol and prototype allow for the practical exploration this how this can redefine our collective sense-making by providing a rational process for forming a truth by consensus between trusted peers. This allows for the practical exploration of digital, participatory collaboration at scale, as the AQUA-Protocol can account for contributions that are currently not measurable in monetary value while those contributions provide value to society and/or nature. It seems possible to envision a different economy where data becomes a multi-dimensional currency that allows us to make better-informed decisions. It can inform us to have a greater choice in how we participate economically as service providers and/or consumers.
-
-* **What is it *not yet* good for?**: This is an experimental protocol with a pilot implementation, which is meant for the exploration of new design principles to improve digital sovereignty and trust. This prototype is not production-grade software and should not be used outside of experimental applications. The prototype does currently (Dec'22) not include a transport layer.
diff --git a/docs/protocol/_index.md b/docs/protocol/_index.md
deleted file mode 100644
index e65a65e5..00000000
--- a/docs/protocol/_index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: "Protocol"
-linkTitle: "Protocol"
-weight: 2
-description: >
- Low level reference documentation of the AQUA Protocol
----
-
-This section of documentation gets into specific details about the AQUA Protocol
-and is meant for those doing an implementation or contributing to the Protocol
-itself.
diff --git a/docs/protocol/aqua-protocol-version_1.3.md b/docs/protocol/aqua-protocol-version_1.3.md
deleted file mode 100644
index 56d3e0a0..00000000
--- a/docs/protocol/aqua-protocol-version_1.3.md
+++ /dev/null
@@ -1,226 +0,0 @@
-# Aqua Protocol Version v1.3
-(Writing in process, unfinished Nov. 10th, 2024)
-This is a developer documentation.
-
-The Aqua Protocol (AQP) is a data accountability and exchange protocol between hosts in peer-to-peer environments. The AQP is used to realize the goal of accounting for data origin and history (data provenance). Short: A verifiable linkable data structure to attest and certify data.
-
-Issues for improving the protocol are tracked here: https://github.com/inblockio/aqua-improvement-proposal
-
-## Data Structure:
-
-Every revision is represented by a merkle-root hash representing a list of alphabetically ordered key-value pairs which are hashed (implementation example SHA3-512). This allows us to dynamically change the data structure without the need to introduce breaking protocol changes.
-
- * The input data MUST NOT have dublicated keys as this would lead to non-deterministic ordering.
-
-Aqua-Chain: Is a portable hash-chain. This provides immutability for the history of the file, once signed and/or witnessed with the respective security guarantees.
-Aqua-revisions form a portable Aqua-Chain.
-
-There are 4 Types of Revisions:
- * Content Revision: Contains the data object if wrapped by the protocol. This is used to secure the data integrity and reference the data object for provenance purposes. The content revision makes the data object referencable for signatures, witness, and link revisions.
- * Signature Revision: Is used to cryptographically sign, we are currently supporting DID and Ethereum signatures.
- * Witness Revision: Used to witness the Hash to prove its existence. We are supporting Ethereum by default.
- * Link Revision (TBD): Protocol specification for how to interlink Aqua-Chains. This also includes tracking externally managed datasets which are not wrapped into the Aqua-Chain itself.
-
-Example:
-
-1. Content-Revision
-
-
-```
-{
- "revisions": {
- "0xb576b6920e9bbb3e76d69b76e5b86f60590df43e9407d7d1b359cb8e2db00ce44d4c0741cbd1ca0f1a3605d3b2b56b58c412b2040743e12a1488de519e365587": {
- "previous_verification_hash": "",
- "domain_id": "5e5a1ec586",
- "nonce: 4231256454123",
- "local_timestamp": "20241105093856",
- "revision_type": "content",
- "content": "MIT License\n\nCopyright (c) 2024 inblock.io\n\nPermission is hereby granted, free of charge, to any person obtaining a copy\nof this software and associated documentation files (the \"Software\"), to deal\nin the Software without restriction, including without limitation the rights\nto use, copy, modify, merge, publish, distribute, sublicense, and/or sell\ncopies of the Software, and to permit persons to whom the Software is\nfurnished to do so, subject to the following conditions:\n\nThe above copyright notice and this permission notice shall be included in all\ncopies or substantial portions of the Software.\n\nTHE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\nIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\nFITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\nAUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\nLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\nOUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE\nSOFTWARE.\n",
- "leaves": [
- "da5385762bb4cd5e2fbc76861cceeb7fb5e7d5f3181e0e36997146c65a31fb7c363221759f77c2ed468f8874da81ec2467fa363243c71b90f94e2734db0134c1",
- "8f68acdd2ccbe8f0088d78438a411af9fcde4259f85a7ff28a0cd4f543ca3b139e24282d39170fe446526f015d5e227eafaead6e73a91f7e3df73b5e3e6a02fb",
- "78501ae4b82221563c51de71890ac8bad9d7bc608d8a094a512408785b4f39b3d3b8cea2a292326735ee19918a8c4919711d59661f4923117db8d2eaa2516e80",
- "4c6cabd6d78399bc0bc6bcd255e4a08576e9b0204a4f03ff83a328a065c076e327aaaa503bbc840636ccbf62d7b577b3db010b6775b4576be3fc30a068df70f1",
- "52e56bad6857482a1c56a0b52f577e2b513873573d15a48eee310b4c3f7efdee430945935ace2acbbe0fe3cf5ff914a9b6d0c9622453365203a7f55eefdf9771"
- ]
- }
-```
-2. Signature-Revision example (Ethereum Wallet)
-```
- "0x25bc631dc35efd51f1a43e886097c5809e633cfbe5448c5a1ca973be20a10f2dcbab0939e66b752aa84191f6705591615e1a3cacb4d28eef824267fd9dc19064": {
- "previous_verification_hash": "0xb576b6920e9bbb3e76d69b76e5b86f60590df43e9407d7d1b359cb8e2db00ce44d4c0741cbd1ca0f1a3605d3b2b56b58c412b2040743e12a1488de519e365587",
- "domain_id": "5e5a1ec586",
- "local_timestamp": "20241105093856",
- "revision_type": "signature",
- "signature": "0x222d6a0c4024d50c5165f30125f64969a98af9f75cbe2b6a9798b5cd637714b60c7d7caf236afe773ce3879ede9a3dc95895dce60f6227a282a30cc116a56d681c",
- "signature_public_key": "0x03b6ff4b0c45ce230eb48499614538ca7daa43000395e694ac92eaa1e4b805df8a",
- "signature_wallet_address": "0xbdc64c49bf736cfe1b8233b083d3d632f26feb27",
- "signature_type": "Ethereum",
- "leaves": [
- "8f68acdd2ccbe8f0088d78438a411af9fcde4259f85a7ff28a0cd4f543ca3b139e24282d39170fe446526f015d5e227eafaead6e73a91f7e3df73b5e3e6a02fb",
- "78501ae4b82221563c51de71890ac8bad9d7bc608d8a094a512408785b4f39b3d3b8cea2a292326735ee19918a8c4919711d59661f4923117db8d2eaa2516e80",
- "eab2e00fd4ca01067827148e7df80aab6813eb5b26023c117f6ab66b1db2da6a9704eb80f87e28aa5ab4ab025285764f1f3f81f0ee2e51602163bbfa25ff48ac",
- "ed97cc41ef70162c0c3ca5b7f1bd88d9f3f3c249a3a9444376417d6cb9deb834f22890e25abb4fac8577e3d65e0e949f7224c11d5f549ad127c09d3b8dfa2df2",
- "9b03a873f0dff741aab24307681728c586c1dcff4df6b194d09c6b239b572d00406e2d7390a541f70e083ca99414b3879f8c92ab231e6bdebe0612a24fabce3f",
- "6ce0a5ba3573bb0d4650f912828af0f843856d0d67762cc647b65577eee5cf17c04ffb42472d71d53e5f228a6f581e6932cd671c0a505cf9e1f847b6eb01527d",
- "02d2b681147691fbe0b98d3d8bfb67e2da13694d7e9e2c953a96ef9ea942237127efa787b8ca9f8c0253574586171683bfacec5613b9950bd440c49cf5faedf6",
- "026bfe6061bbc69a805f5f9aeaa2d5c251fbd7a59602eafc1204542c37264700e3f45f79f972748f8424dfc5b0298273990638a4f11b143d11fd0483da7ad7c1"
- ]
- }
- }
-}
-```
-
-3. Signature-Revision example (DID Example)
-```
- "0x894ac8cfbaf9fb75aae916c3693928e7d41264e1a85d7089f0cf4bb46963c9626808d26c54709d8458c0d0a07b7c4c619bbb714884854a19195719cb36aafdb3": {
- "previous_verification_hash": "0x25bc631dc35efd51f1a43e886097c5809e633cfbe5448c5a1ca973be20a10f2dcbab0939e66b752aa84191f6705591615e1a3cacb4d28eef824267fd9dc19064",
- "domain_id": "5e5a1ec586",
- "local_timestamp": "20241105093856",
- "revision_type": "signature",
- "signature": {
- "payload": "eyJtZXNzYWdlIjoiSSBzaWduIHRoZSBmb2xsb3dpbmcgcGFnZSB2ZXJpZmljYXRpb25faGFzaDogWzB4MHgyNWJjNjMxZGMzNWVmZDUxZjFhNDNlODg2MDk3YzU4MDllNjMzY2ZiZTU0NDhjNWExY2E5NzNiZTIwYTEwZjJkY2JhYjA5MzllNjZiNzUyYWE4NDE5MWY2NzA1NTkxNjE1ZTFhM2NhY2I0ZDI4ZWVmODI0MjY3ZmQ5ZGMxOTA2NF0ifQ",
- "signatures": [
- {
- "protected": "eyJhbGciOiJFZERTQSIsImtpZCI6ImRpZDprZXk6ejZNa24xd01panVGdzVkZEE3SmN5dmdVa0tpZDhXaDN3WW5Cc1hXa2FUVVJrTWRMI3o2TWtuMXdNaWp1Rnc1ZGRBN0pjeXZnVWtLaWQ4V2gzd1luQnNYV2thVFVSa01kTCJ9",
- "signature": "h-OBw7eHVVNkgprtcEVD9GVu5_NgiLXzdshcyWXjdrJxljSdlu6yY9trrXBAuXcUXrxUuU-KWAR_eMTOq2-dCw"
- }
- ]
- },
- "signature_public_key": "did:key:z6Mkn1wMijuFw5ddA7JcyvgUkKid8Wh3wYnBsXWkaTURkMdL",
- "signature_wallet_address": "did:key:z6Mkn1wMijuFw5ddA7JcyvgUkKid8Wh3wYnBsXWkaTURkMdL",
- "signature_type": "did:key",
- "leaves": [
- "8f68acdd2ccbe8f0088d78438a411af9fcde4259f85a7ff28a0cd4f543ca3b139e24282d39170fe446526f015d5e227eafaead6e73a91f7e3df73b5e3e6a02fb",
- "78501ae4b82221563c51de71890ac8bad9d7bc608d8a094a512408785b4f39b3d3b8cea2a292326735ee19918a8c4919711d59661f4923117db8d2eaa2516e80",
- "d1bae393048ec8a35eacb290e538cc9575b616ee99e59af86585b36fe70541d8395d511a18f7cf31020f85a36b092784da29c4afb7ff641a541e342514b0a1c2",
- "ed97cc41ef70162c0c3ca5b7f1bd88d9f3f3c249a3a9444376417d6cb9deb834f22890e25abb4fac8577e3d65e0e949f7224c11d5f549ad127c09d3b8dfa2df2",
- "8a2a10de17eeed57fc11b8b277c9104cb4d0e1d4b919d07cf678401c80687c90b31cfbd6c35cb5590b7b02fdb7da0def97f0efdb8553f7fabcf6172a0c5fab5f",
- "9744c7f71cc7062d1fca9b2b39a6f6b91a53ead1fe4db788a4bf33d21f0509cd04ce7d9e04aa01f6dfe952524649895c807fe21984e5d7826f5d12228b9219b3",
- "94cccc4616e78a77cef476e299d75dab406c129cc28290d8779466fd4ab9364056521ca5356dcee82198dddb080ede7ec9dc210bc61c4deea9a5b439aaaf8cfc",
- "646b45aba43fdb8f083c7a7b652dcfa4279f81afcc532736bbac8b29da690d3ea922bad14565d80974a0fb05123ffdb952a2708bedd1ad58f7c6bcb72ec90006"
- ]
- }
- }
-}
-```
-
-4. A) Witness-Revision example Ethereum (non-aggregated)
-
-
-4. B) Witness_Revision example timestamping authority (TSA_RFC3161)
-The witness_transaction_hash contains the server certificate chain.
-```
-"0x0487556a32b8ba92cd579ace7062027e779295960eeb8ca7ac3908e3f379ae551953ae7bfb121f030d1f29b81dcf3dc955aebf992bcfbaee3f08487ab00416b7": {
- "previous_verification_hash": "0x894ac8cfbaf9fb75aae916c3693928e7d41264e1a85d7089f0cf4bb46963c9626808d26c54709d8458c0d0a07b7c4c619bbb714884854a19195719cb36aafdb3",
- "domain_id": "5e5a1ec586",
- "local_timestamp": "20241105093856",
- "revision_type": "witness",
- "witness_merkle_root": "0x894ac8cfbaf9fb75aae916c3693928e7d41264e1a85d7089f0cf4bb46963c9626808d26c54709d8458c0d0a07b7c4c619bbb714884854a19195719cb36aafdb3",
- "witness_timestamp": 1730802112,
- "witness_network": "TSA_RFC3161",
- "witness_smart_contract_address": "http://timestamp.digicert.com",
- "witness_transaction_hash": "MIIXNDADAgEAMIIXKwYJKoZIhvcNAQcCoIIXHDCCFxgCAQMxDzANBglghkgBZQMEAgEFADCBgAYLKoZIhvcNAQkQAQSgcQRvMG0CAQEGCWCGSAGG/WwHATAxMA0GCWCGSAFlAwQCAQUABCCTBEhaD6VdOi5gn3u8SaeQkdv+K/NaF2wp1bgZTwtD6QIRAOElWROJ1gGaqFGFbGLLv/UYDzIwMjQxMTA1MTAyMTUyWgIGAZL72FgOoIITAzCCBrwwggSkoAMCAQICEAuuZrxaun+Vh8b56QTjMwQwDQYJKoZIhvcNAQELBQAwYzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRpZ2lDZXJ0LCBJbmMuMTswOQYDVQQDEzJEaWdpQ2VydCBUcnVzdGVkIEc0IFJTQTQwOTYgU0hBMjU2IFRpbWVTdGFtcGluZyBDQTAeFw0yNDA5MjYwMDAwMDBaFw0zNTExMjUyMzU5NTlaMEIxCzAJBgNVBAYTAlVTMREwDwYDVQQKEwhEaWdpQ2VydDEgMB4GA1UEAxMXRGlnaUNlcnQgVGltZXN0YW1wIDIwMjQwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+anOf9pUhq5Ywultt5lmjtej9kR8YxIg7apnjpcH9CjAgQxK+CMR0Rne/i+utMeV5bUlYYSuuM4vQngvQepVHVzNLO9RDnEXvPghCaft0djvKKO+hDu6ObS7rJcXa/UKvNminKQPTv/1+kBPgHGlP28mgmoCw/xi6FG9+Un1h4eN6zh926SxMe6We2r1Z6VFZj75MU/HNmtsgtFjKfITLutLWUdAoWle+jYZ49+wxGE1/UXjWfISDmHuI5e/6+NfQrxGFSKx+rDdNMsePW6FLrphfYtk/FLihp/feun0eV+pIF496OVh4R1TvjQYpAztJpVIfdNsEvxHofBf1BWkadc+Up0Th8EifkEEWdX4rA/FE1Q0rqViTbLVZIqi6viEk3RIySho1XyHLIAOJfXG5PEppc3XYeBH7xa6VTZ3rOHNeiYnY+V4j1XbJ+Z9dI8ZhqcaDHOoj5KGg4YuiYx3eYm33aebsyF6eD9MF5IDbPgjvwmnAalNEeJPvIeoGJXaeBQjIK13SlnzODdLtuThALhGtyconcVuPI8AaiCaiJnfdzUcb3dWnqUnjXkRFwLtsVAxFvGqsxUA2Jq/WTjbnNjIUzIs3ITVC6VBKAOlb2u29Vwgfta8b2ypi6n2PzP0nVepsFk8nlcuWfyZLzBaZ0MucEdeBiXL+nUOGhCjl+QIDAQABo4IBizCCAYcwDgYDVR0PAQH/BAQDAgeAMAwGA1UdEwEB/wQCMAAwFgYDVR0lAQH/BAwwCgYIKwYBBQUHAwgwIAYDVR0gBBkwFzAIBgZngQwBBAIwCwYJYIZIAYb9bAcBMB8GA1UdIwQYMBaAFLoW2W1NhS9zKXaaL3WMaiCPnshvMB0GA1UdDgQWBBSfVywDdw4oFZBmpWNe7k+SH3agWzBaBgNVHR8EUzBRME+gTaBLhklodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRUcnVzdGVkRzRSU0E0MDk2U0hBMjU2VGltZVN0YW1waW5nQ0EuY3JsMIGQBggrBgEFBQcBAQSBgzCBgDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMFgGCCsGAQUFBzAChkxodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRUcnVzdGVkRzRSU0E0MDk2U0hBMjU2VGltZVN0YW1waW5nQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4ICAQA9rR4fdplb4ziEEkfZQ5H2EdubTggd0ShPz9Pce4FLJl6reNKLkZd5Y/vEIqFWKt4oKcKz7wZmXa5VgW9B76k9NJxUl4JlKwyjUkKhk3aYx7D8vi2mpU1tKlY71AYXB8wTLrQeh83pXnWwwsxc1Mt+FWqz57yFq6laICtKjPICYYf/qgxACHTvypGHrC8k1TqCeHk6u4I/VBQC9VK7iSpU5wlWjNlHlFFv/M93748YTeoXU/fFa9hWJQkuzG2+B7+bMDvmgF8VlJt1qQcl7YFUMYgZU1WM6nyw23vT6QSgwX5Pq2m0xQ2V6FJHu8z4LXe/371k5QrN9FQBhLLISZi2yemW0P8ZZfx4zvSWzVXpAb9k4Hpvpi6bUe8iK6WonUSV6yPlMwerwJZP/Gtbu3CKldMnn+LmmRTkTXpFIEB06nXZrDwhCGED+8RsWQSIXZpuG4WLFQOhtloDRWGoCwwc6ZpPddOFkM2LlTbMcqFSzm4cd0boGhBq7vkqI1uHRz6Fq1IX7TaRQuR+0BGOzISkcqwXu7nMpFu3mgrlgbAW+BzikRVQ3K2YHcGkiKjA4gi4OA/kz1YCsdhIBHXqBzR0/Zd2QwQ/l4Gxftt/8wY3grcc/nS//TVkej9nmUYu83BDtccHHXKibMs/yXHhDXNkoPIdynhVAku7aRZOwqw6pDCCBq4wggSWoAMCAQICEAc2N7ckVHzYR6z9KGYqXlswDQYJKoZIhvcNAQELBQAwYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgVHJ1c3RlZCBSb290IEc0MB4XDTIyMDMyMzAwMDAwMFoXDTM3MDMyMjIzNTk1OVowYzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRpZ2lDZXJ0LCBJbmMuMTswOQYDVQQDEzJEaWdpQ2VydCBUcnVzdGVkIEc0IFJTQTQwOTYgU0hBMjU2IFRpbWVTdGFtcGluZyBDQTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAMaGNQZJs8E9cklRVcclA8TykTepl1Gh1tKD0Z5Mom2gsMyD+Vr2EaFEFUJfpIjzaPp985yJC3+dH54PMx9QEwsmc5Zt+FeoAn39Q7SE2hHxc7Gz7iuAhIoiGN/r2j3EF3+rGSs+QtxnjupRPfDWVtTnKC3r07G1decfBmWNlCnT2exp39mQh0YAe9tEQYncfGpXevA3eZ9drMvohGS0UvJ2R/dhgxndX7RUCyFobjchu0CsX7LeSn3O9TkSZ+8OpWNs5KbFHc02DVzV5huowWR0QKfAcsW6Th+xtVhNef7Xj3OTrCw54qVI1vCwMROpVymWJy71h6aPTnYVVSZwmCZ/oBpHIEPjQ2OAe3VuJyWQmDo4EbP29p7mO1vsgd4iFNmCKseSv6De4z6ic/rnH1pslPJSlRErWHRAKKtzQ87fSqEcazjFKfPKqpZzQmiftkaznTqj1QPgv/CiPMpC3BhIfxQ0z9JMq++bPf4OuGQq+nUoJEHtQr8FnGZJUlD0UfM2SU2LINIsVzV5K6jzRWC8I41Y99xh3pP+OcD5sjClTNfpmEpYPtMDiP6zj9NeS3YSUZPJjAw7W4oiqMEmCPkUEBIDfV8ju2TjY+Cm4T72wnSyPx4JduyrXUZ14mCjWAkBKAAOhFTuzuldyF4wEr1GnrXTdrnSDmuZDNIztM2xAgMBAAGjggFdMIIBWTASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBS6FtltTYUvcyl2mi91jGogj57IbzAfBgNVHSMEGDAWgBTs1+OC0nFdZEzfLmc/57qYrhwPTzAOBgNVHQ8BAf8EBAMCAYYwEwYDVR0lBAwwCgYIKwYBBQUHAwgwdwYIKwYBBQUHAQEEazBpMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQQYIKwYBBQUHMAKGNWh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFRydXN0ZWRSb290RzQuY3J0MEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFRydXN0ZWRSb290RzQuY3JsMCAGA1UdIAQZMBcwCAYGZ4EMAQQCMAsGCWCGSAGG/WwHATANBgkqhkiG9w0BAQsFAAOCAgEAfVmOwJO2b5ipRCIBfmbW2CFC4bAYLhBNE88wU86/GPvHUF3iSyn7cIoNqilp/GnBzx0H6T5gyNgL5Vxb122H+oQgJTQxZ822EpZvxFBMYh0MCIKoFr2pVs8Vc40BIiXOlWk/R3f7cnQU1/+rT4osequFzUNf7WC2qk+RZp4snuCKrOX9jLxkJodskr2dfNBwCnzvqLx1T7pa96kQsl3p/yhUifDVinF2ZdrM8HKjI/rAJ4JErpknG6skHibBt94q6/aesXmZgaNWhqsKRcnfxI2g55j7+6adcq/Ex8HBanHZxhOACcS2n82HhyS7T6NJuXdmkfFynOlLAlKnN36TU6w7HQhJD5TNOXrd/yVjmScsPT9rp/Fmw0HNT7ZAmyEhQNC3EyTN3B14OuSereU0cZLXJmvkOHOrpgFPvT87eK1MrfvElXvtCl8zOYdBeHo46Zzh3SP9HSjTx/no8Zhf+yvYfvJGnXUsHicsJttvFXseGYs2uJPU5vIXmVnKcPA3v5gA3yAWTyf7YGcWoWa63VXAOimGsJigK+2VQbc61RWYMbRiCQ8KvYHZE/6/pNHzV9m8BPqC3jLfBInwAM1dwvnQI38AC+R2AibZ8GV2QqYphwlHK+Z/GqSFD/yYlvZVVCsfgPrA8g4r5db7qS9EFUrnEw4d2zc4GqEr9u3WfPwwggWNMIIEdaADAgECAhAOmxiO+dAt5+/bUOIIQBhaMA0GCSqGSIb3DQEBDAUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0yMjA4MDEwMDAwMDBaFw0zMTExMDkyMzU5NTlaMGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IFRydXN0ZWQgUm9vdCBHNDCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAL/mkHNo3rvkXUo8MCIwaTPswqclLskhPfKK2FnC4SmnPVirdprNrnsbhA3EMB/zG6Q4FutWxpdtHauyefLKEdLkX9YFPFIPUh/GnhWlfr6fqVcWWVVyr2iTcMKyunWZanMylNEQRBAu34LzB4TmdDttceItDBvuINXJIB1jKS3O7F5OyJP4IWGbNOsFxl7sWxq868nPzaw0QF+xembud8hIqGZXV59UWI4MK7dPpzDZVu7Ke13jrclPXuU15zHL2pNe3I6PgNq2kZhAkHnDeMe2scS1ahg4AxCN2NQ3pC4FfYj1gj4QkXCrVYJBMtfbBHMqbpEBfCFM1LyuGwN1XXhm2ToxRJozQL8I11pJpMLmqaBn3aQnvKFPObURWBf3JFxGj2T3wWmIdph2PVldQnaHiZdpekjw4KISG2aadMreSx7nDmOu5tTvkpI6nj3cAORFJYm2mkQZK37AlLTSYW3rM9nF30sEAMx9HJXDj/chsrIRt7t/8tWMcCxBYKqxYxhElRp2Yn72gLD76GSmM9GJB+G9t+ZDpBi4pncB4Q+UDCEdslQpJYls5Q5SUUd0viastkF13nqsX40/ybzTQRESW+UQUOsxxcpyFiIJ33xMdT9j7CFfxCBRa2+xq4aLT8LWRV+dIPyhHsXAj6KxfgommfXkaS+YHS312amyHeUbAgMBAAGjggE6MIIBNjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTs1+OC0nFdZEzfLmc/57qYrhwPTzAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzAOBgNVHQ8BAf8EBAMCAYYweQYIKwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYIKwYBBQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcnQwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDARBgNVHSAECjAIMAYGBFUdIAAwDQYJKoZIhvcNAQEMBQADggEBAHCgv0NcVec4X6CjdBs9thbX979XB72arKGHLOyFXqkauyL4hxppVCLtpIh3bb0aFPQTSnovLbc47/T/gLn4offyct4kvFIDyE7QKt76LVbP+fT3rDB6mouyXtTP0UNEm0Mh65ZyoUi0mcudT6cGAxN3J0TU53/oWajwvy8LpunyNDzs9wPHh6jSTEAZNUZqaVSwuKFWjuyk1T3osdz9HNj0d1pcVIxv76FQPfx2CWiEn2/K2yCNNWAcAgPLILCsWKAOQGPFmCLBsln1VWvPJ6tsds5vIy30fnFqI2si/xK4VC0nftg62fC2h5b9W9FcrBjDTZ9ztwGpn1eqXijiuZQxggN2MIIDcgIBATB3MGMxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE7MDkGA1UEAxMyRGlnaUNlcnQgVHJ1c3RlZCBHNCBSU0E0MDk2IFNIQTI1NiBUaW1lU3RhbXBpbmcgQ0ECEAuuZrxaun+Vh8b56QTjMwQwDQYJYIZIAWUDBAIBBQCggdEwGgYJKoZIhvcNAQkDMQ0GCyqGSIb3DQEJEAEEMBwGCSqGSIb3DQEJBTEPFw0yNDExMDUxMDIxNTJaMCsGCyqGSIb3DQEJEAIMMRwwGjAYMBYEFNvThe5i29I+e+T2cUhQhyTVhltFMC8GCSqGSIb3DQEJBDEiBCBqnp9d4ut1iCHhH0nTV9klQFwaZupe+t7WGdOSG8USWjA3BgsqhkiG9w0BCRACLzEoMCYwJDAiBCB2dp+o8mMvH0MLOiMwrtZWdf7Xc9sF1mW5BZOYQ4+a2zANBgkqhkiG9w0BAQEFAASCAgCkgGrtYCHm1el+X2YZpGCxfx+yvbPvocWCC0MApvZXTY9ZdaxQ6ttOHfDA0I6mV1ogCwR48X9J+zkU55amkIbR8APAGpQnOXmnjtWvXVUPYR7JRLTz+ncUm/LbmRya4u8iZKP175DrZnlxJzfUtf5zD02k5WZjh2p+4w/SR+m1hdeQzGaD687ur//i6JK4wWeT7ObwFCN0aiiCw/tGmpFtFjeOk+jAOunlF64PTPd1VM1IM7xYcK8ReYxk0zYs92H8Rf3b0CNoY0PNXS1Bze3qKp+yfwWtAcuXvb1ut/U6XqzF8QuWbu89svO1n0bCLIHhcwNuXomCY3KEKoouAy+EJ0cKFq1IIcePLZzipKTv892FfmvOl2fy8GF30CAHnVvVYgiwE+l+tZVn4J8HjiypAFltTl76iW6FsyyjL0W0JfqFuMd5bULoUNZR86DeTOjRAWJN7iGdy+TGMR9SZ/s2IJeOjKbLIzI7/CizCAkksPC6VjfPQOV+jrzRfiQkgx6J8YRJ4DH3xTgvthxhc2mFDgGDPmFTqRJ8xv7hj9zMvyiNQlNLYiVVVGI9m55ZfufWnncCt7FPNxKIDL8+pAkOfXWy3+jshcqat+V1JjHGn2KoXvUNojqeuTkVB17wLdEkHK61nKoRSTxyl4LZCf8OHb1ffsHSEvkVVqCHvYm73A==",
- "witness_sender_account_address": "DigiCert",
- "witness_merkle_proof": "[{\"depth\":\"0\",\"left_leaf\":\"0x894ac8cfbaf9fb75aae916c3693928e7d41264e1a85d7089f0cf4bb46963c9626808d26c54709d8458c0d0a07b7c4c619bbb714884854a19195719cb36aafdb3\",\"right_leaf\":null,\"successor\":\"0x894ac8cfbaf9fb75aae916c3693928e7d41264e1a85d7089f0cf4bb46963c9626808d26c54709d8458c0d0a07b7c4c619bbb714884854a19195719cb36aafdb3\"}]",
- "leaves": [
- "8f68acdd2ccbe8f0088d78438a411af9fcde4259f85a7ff28a0cd4f543ca3b139e24282d39170fe446526f015d5e227eafaead6e73a91f7e3df73b5e3e6a02fb",
- "78501ae4b82221563c51de71890ac8bad9d7bc608d8a094a512408785b4f39b3d3b8cea2a292326735ee19918a8c4919711d59661f4923117db8d2eaa2516e80",
- "f90837f8515c0def443cb512ee9dfaf8919722467d4019aaf63c13603600903202e8bf21304de25caafc61925b96e024c77c8f0e3223f00c724f524a12cebe95",
- "13aa6a0a8800b4d8adeea104f8328bb1b5035276e2522a561c48d3db628263e26093426b35626dbd43b8198a15c6b017609d9fe4f9506f167a7997f80fd71859",
- "9df7e7c5741d4373d29f576f3b0e894dacc4feda2cbed0b165a89c7ed3997f29482a5ac1f3f95ed34be0690b53f41d687334e132e80041563b15442380033a01",
- "065c9da00b8c0e1d6f165ec946431b88f3a0d5764f9d3d3a5994a095122c81da3d0f3719d1ef712adf47effcea88ea1a2c7e6dbea7d71f0ae70ec388ed646995",
- "a2ad3cedcedf8c9ae6ebbb0adde1863bf45247dcc51c14edea7fe4524b06f8ea7cba97f6da77641b537384bae53fa042bb43e377a2e98e71158c99e78185c6b3",
- "41bb7271d1596fa17fa5ffcec141eb787d56c79c897ecc6cc83cda650171988e5cfd04e9b878f57d5bcc6f1054cd6162d271d06635b43011ad6785d6f0536b6e",
- "6fe1ebd64bfcefda3b61ad5db9b450013e998b511384a9b671fe4c8809fe1f9868a5669bb6211e14346c8af55a41abd02994c73c52ced299d7e23fccd8a4cb13",
- "e875b9b6fb0e609b72c6e303701abc3035e160ac541f0b7d542e8f1c354f957fb1d09518e02c6600d9b7e4e4a2591e7754cb60c4869153751bd49e231cdeb1ee",
- "078df46bfe5b9db36854c62a053fc68c80a074ce9c13aef0f22e41f266583f1558a37bf56ec2346e34ac125a7aded5534d9506e624774680f128c817770d0370"
- ]
- }
- }
-```
-# Drafts
-
-5. Linkage
-
-Restriction: The linked resource MUST be an Aqua-Chain or MAY contain content addressed files (BitTorrent, IPFS, Swarm, any content that is verifiable by hash).
-
-url: path to ressource
-remote expect-aqua-chain: boolean
- expect type: aqua-chain / bittorrent / ipfs - the type of the linked resources.
- require-in-depth-verification: if false, in depth verification will only draw a warning for not verifing or not be able to load the resource, if true, it will cause a critical verification error.
-
-* load and hash ressource (pull in with copy, pull in without copy). Restriction: only single files allowed. Possible to embedd remote content.
-*
-```json
-{
- "revision_type": "link (when linking to other aqua-chain) / reference (when referencing an external source)",
- "expect type": "aqua / bittorent / ipfs"
- "required-indepth-verification: "true / false",
- "verification-hash": "078df46bfe5b9db36854c62a053fc68c80a074ce9c13aef0f22e41f266583f1558a37bf56ec2346e34ac125a7aded5534d9506e624774680f128c817770d0370",
- "url": "FQDN/path: full network-path to ressource / local: ABSOLUTE or RELATIVE path to the aquafier directly
-}
-```
-
-Requirements:
-* Remote data needs to be verifiable (stateful)
-* This means the ressource must be loadable to hash it for verification
-
-* Aqua chains MAY support various content addressed storage solutions including: BitTorrent, IPFS, Swarm, any content that is verifiable by hash, these are specifc link types
-* Content revisions MUST indicate if its an internal or externally tracked file object
-* MIME type of the file (?)
-* Filepath + SHA3 Hash
-
-How to load external resources / Summery: "how to draw the world in":
-
-* Verifier has its own content storage to store resources which have been loaded for verification.
-* This content storage is content hashed (which means same files are not stored files)
-* If content references an externally linked file, then the file is loaded and stored when verifying the aqua-chain
-* A file is always looked up in the local content storage first by hash, before its loaded from the URL
-
-Object which is referenced needs to be persistant and verifiable.
-Verifiable ressources must be: available (available), hashed, type defined
-
-Discussion:
-* Using JSON-LD https://json-ld.org/ ?
-* No, to many aspects which are not needed, Aqua chain focuses on verifiability
-
-# Backlog
-
-Future capabilities:
-
-Content links with external file tracking (and specific tools to interact):
-6. Bit-Torrent file support (public files) referencing only the magnet link with the data requered for a torrent tool to load the data.
-7. Git-File support to track a repository.
-8. Generlised external-file-storage integration (write basic own implementation).
-9. X-API integration: E.g. load the JSON and embedd data strucutre of a single tweet via API (TBD: how to solve media pull in pictures and videos). Solve by content addressed storage implementation for large media files: pictures, video, others.
-10. Archive.org / Website download (offline archiving) with local storing but externally storage management.
-
-Support basic statements with a md-text-editor, form.
-Type: Contract, requires in-depth-verification.
-
-Aggregator: Timestamping at maximum.
-
-When timestamping an aqua-chain receive a mutable flag on the revision which is timestamp. LOCKING it (do not allow new revisions until unlocked / unflagged). Idea: End-revisions, are not allowed to be extended.
-
-Topic: Witness Contract:
-API Read function?
-Verifier needs to have a hard conviction of whats our truth. ONE SMART contract, if not we could fall into the trap that somebody changes a witness revision to a different contract and it still would be valid. --> Is this a problem?
-
-Discussion:
-
-Optimizations:
-
-Different Hashing machanism
-* https://crypto.stackexchange.com/questions/31674/what-advantages-does-keccak-sha-3-have-over-blake2 i can't find a strong reason for preferring sha3
-* tl; dr: blake2 didn't win nist because it's too similar to sha2. on the other hand, sha2 has been proven to stay even after decades, so being similar to it is actually a feature, not bug. but this is an argument from the author of blake2, which is biased
-* Potentially using blake3 (optimized) which seems to be up to 15x faster
-* What are the security considerations / drawbacks
-
-
-Discussion "removing internally tracked files / content revisions":
-* Remove Content revision with wrapping
-* Track files with a local storage deamon -> only have their hash, receive files by hash, store them by hash
-* Storage service and hasher service always come togather
-* Possible to extend the aqua-verifier to support other storage implementations via shared interface (?)
-* Track matadata of file with DB or with an extra file containing the sha3 hash and URL how to receive the file (?)RITIQUE and option (OPTIMIZATION): In depth verification (secure every field) vs shadllow verification (just hash the whole JSON file structure with one hash (root hash).
diff --git a/docs/protocol/aqua_protocol_v1_2.md b/docs/protocol/aqua_protocol_v1_2.md
deleted file mode 100644
index 817db89d..00000000
--- a/docs/protocol/aqua_protocol_v1_2.md
+++ /dev/null
@@ -1,68 +0,0 @@
----
-title: Aqua Protocol Version 1.2
-linkTitle: "Aqua Protocol Version 1.2"
-weight: 1
-description: >
- Specificaiton of Aqua Protocol with example implementaiton
----
-
-
-| | |
-|------------------|--------------------------------------------|
-| Current version: | Aqua Protocol v1.2 Specification |
-| Author: | Tim Bansemer, Publius Dirac |
-| Date: | 26.11.2024 |
-| Status: | DRAFT / Experimental |
-| Implementation: | [https://github.com/inblockio/micro-pkc](https://github.com/inblockio/micro-pkc) |
-
-## Introduction
-
-Please find version 1.1 here [LINK TBD].
-
-Major changes to version 1.1:
-
-Change the way how verification of siganture and witness events work. They are now part of the currently written revision and always force that a new revision which is created. Verification hashes for signatures and witness events are included into the new forced written revision. This was necessary to avoid unresolvable conflicts which could be created by divergant forks of an aqua-chain in two distinct containers after sharing the original chain.
-
-Version 1.2 was used to pilot and prototype the aqua-guardian. A security compontent being used to exchange data between two or more aqua-containers (Personal-knowledge-containers) by doing access control and policy enforcement for data acccess agreements.
-
-## System Components
-
-### Core Components
-
-- **Aquafier**: A software component that enriches files with cryptographic metadata for verification according to the Aqua protocol.
-- **Aqua Verifier**: An automatic verification tool to validate aqua-chains.
-
-### Prototype Implementations
-
-#### CLI Tools (Aquafier + Verifier)
-- **Languages**: JavaScript (v1.2, v1.3), Rust (v1.2)
-- **Description**: A command-line tool allowing users to create and verify aqua-chains.
-- **Status**: Active development, pilots completed, v1.3 ongoing development
-- **Links**:
- - [Rust Version](#) (TBD)
- - [JavaScript/TypeScript Version](#) (TBD)
-
-#### Chrome Extension (Name-Resolution v1.2)
-- **Description**: A Chrome web extension that enables:
- - Automatic verification of pages on a visited PKC.
- - Offline verification of aqua-chains stored in the extension.
- - Resolution of wallet addresses to names.
-- **Link**: [Chrome Extension](#) (TBD)
-
-#### PKC (Personal Knowledge Container)
-- **Description**: A MediaWiki-enhanced version designed to turn pages into aqua-chains with full integration of core Aqua functionalities (hash-chains, signing, witnessing with aggregation function, and verifiable links).
-- **Status**: Pilot completed with local feature completeness.
-- **Link**: [PKC](#) (TBD)
-
-#### Aqua-Container (Focused on Doku-Sign Use Case)
-- **Description**: A Rust implementation for creating, verifying, and managing aqua-files.
-- **Link**:
- - [Rust Version](#) (TBD)
- - [React, TypeScript/JavaScript](#) (TBD)
-
-#### Guardian
-- **Description**: A security enforcement point for verifying, transporting, and managing access for aqua-files.
-- **Status**: Pilot completed with PKC serving as an aqua-file storage.
-
-## Version 1.2 Protocol Specification
-TBD
diff --git a/docs/protocol/data-accounting.md b/docs/protocol/data-accounting.md
deleted file mode 100644
index f70279f2..00000000
--- a/docs/protocol/data-accounting.md
+++ /dev/null
@@ -1,77 +0,0 @@
----
-title: "Data Accounting"
-linkTitle: "Data Accounting"
-weight: 5
-sidebar_position: 6
-description: >
- Introduces the concept of Data Accounting
----
-
-We first exchanged goods, then we used means to exchange goods, such as
-shells and coins. Today we use money. We have transitioned to a world where
-we present and exchange data to receive goods and services.
-
-The system for accounting provided by Luca Pacioli, the double-entry
-accounting is the foundation of our work. We present a modern
-way to do double-entry bookkeeping for data.
-
-Data accounting is the process of metering data in a standardized unit
-of exchange, and converting it into a form which can be exchanged to
-provide data symmetry between accounts.
-
-The unit of exchange is not measured in a numeric value as found in cash
-systems. Data have multi-dimensional value, which means they depends on your
-perspective and your relationship to data. This determines how much this
-data-set is worth to the individual.
-
-The standard measure of exchange is a hash, representing the state of the
-data. A SHA3-512 hash always has 128 characters, regardless of the size
-of the data it is representing.
-
-## Metering data / anchoring data in space
-
-To meter data, we can refer to them using a digital fingerprint, i.e. their
-hash. This allows us to refer to the data in a consistent form. The hash has
-captured sufficient entropy to be unique, so it becomes a unique resource
-locator. This ensures that it is always deterministic to what data we relate
-to.
-
-## Accounting data / anchoring data to account
-
-The second step is that the data is attributed to a specific account. This is
-achieved by using cryptographic signatures known as [public/private key
-encryption](https://en.wikipedia.org/wiki/Public-key_cryptography). The public
-key acts as a unique account address. It is necessary that the accounts in use
-are globally unique, so there is no realistic probability of a name collision
-between accounts. This ensures that no data is attributed by mistake to two
-accounts or more.
-
-## Proof of existence / anchoring data to time
-
-The last step to account data is the usage of a cryptographically secure clock,
-so we know which data were witnessed first. Data can be replicated, so the
-value lies within the social implications of the message within the published
-data. This cryptographic timestamping allows us to determine the first account
-to witness the data. The most secure witness-networks which provide a service
-for cryptographic witnessing of datasets are Bitcoin and Ethereum. The first
-known examples of partial data accounting were done by [Surety in
-1995](https://www.vice.com/en/article/j5nzx4/what-was-the-first-blockchain) and
-[OpenTimestamps in
-2012](https://petertodd.org/2016/opentimestamps-announcement).
-
-## Practical accounting
-
-The accounting book in the data accounting age is a 'data vault' which is
-controlled by one or multiple accounts. This allows both personal data vaults
-or organizational data vaults.
-
-A data vault is controlled by a cryptographic wallet. The vault has the
-objective to govern the data for the account owner who is associated with the
-vault.
-
-The vault provides a capability to export and import data, so it can be
-exchanged between data vaults. This allows for collaboration at scale, and the
-usage of data as a means of exchange.
-
-*Please contribute to this article (fixing errors) by exporting it and
-sending it back with your improvement to community\[at\]inblock\[dot\]io.*
diff --git a/docs/protocol/data-governance.md b/docs/protocol/data-governance.md
deleted file mode 100644
index 9bf3e83e..00000000
--- a/docs/protocol/data-governance.md
+++ /dev/null
@@ -1,115 +0,0 @@
----
-title: "Data Governance"
-linkTitle: "Data Governance"
-weight: 6
-sidebar_position: 7
-description: >
- Introduces the concept of Data Governance
----
-
-Author: Ben Koo
-E-Mail: koo0905\[at\]gmail\[dot\]com
-Year: 2021
-
-Data Governance identifies how to manage the value of data. A well-known
-turning point in history was the publication of [Luca
-Pacioli](wikipedia:Luca_Pacioli "wikilink")'s [Summa de
-arithmetica](wikipedia:Summa_de_arithmetica "wikilink"). This
-encyclopedia of mathematics, had 26 pages worth of text on what we call
-[Double-entry
-bookkeeping](wikipedia:Double-entry_bookkeeping "wikilink"). This became
-the foundational literature for
-[accounting](wikipedia:accounting "wikilink"), the progenitor of using
-data to assign value to accounts, and henceforth gave birth to the
-practice of data governance.
-
-# Accounting as the foundation of Data Governance
-
-According to historian Jane-Gleeson White[^1][^2], Pacioli's double
-entry book keeping idea influenced the development of arts, sciences,
-and capitalism. [Double-entry
-bookkeeping](wikipedia:Double-entry_bookkeeping "wikilink") as a
-rigorous approach to ensure data integrity, not only influenced the
-practice of the accounting profession, and it had a significant impact
-on the the formulation of [Hamiltonian
-Mechanics](wikipedia:Hamiltonian_Mechanics "wikilink"), which is a
-foundational theory of both classical mechanics and quantum mechanics.
-
-Sir [William Rowan
-Hamilton](wikipedia:William_Rowan_Hamilton "wikilink") wrote a paper[^3]
-cited many many scholars to demonstrate that many ideas about complex
-algebraic manipulation that laid the foundation of scientific
-revolutions are based on the formulation of creating accountable
-mathematical formulation strategies through double entry book keeping.
-[David Ellerman](https://www.ellerman.org) had a paper that explains the
-powers of double entry bookkeeping in sciences[^4]. The notion that
-creating public addresses for transactions amongst different accounts
-has been documented as a scientific theory on Double Entry Book-keeping.
-This book can be found online[^5]:
-
-## Digital Governance
-
-Given the intellectual roots of data governance have strong linkages to
-mathematics and accounting, it is only after the introduction of
-[personal computing devices](wikipedia:personal_computer "wikilink"),
-and later the ubiquity of [Internet](wikipedia:Internet "wikilink")
-access that made data governance an idea relevant to public affairs. The
-argument is that many people's basic privacy and property rights may be
-challenged by people who have access to data collection and deployment
-technologies. Imminent threats such as fake news, big brother monitoring
-practices, identity thefts, and crypto currency issuance are already
-challenging the stability of the existing social fabric. These type of
-social debates are often related to the ideas of [Digital
-governance](wikipedia:Digital_governance "wikilink"). At this time,
-digital governance has not yet become a mature field of study, and it
-needs to be grounded in simple principles, so that it can be
-transparently practiced with local adaptations.
-
-## Conceptualization of Data Governance
-
-Beside the notion of digital governance, data as an asset class must be
-kept accountable, so that it can be evaluated, and transferred with an
-objective operational framework. Knowing how to organize data in formats
-that satisfy consistent abstraction strategies, such as [Universal
-Resource Identifier](wikipedia:URI "wikilink") and [Universal Resource
-Locator](wikipedia:URL "wikilink") are important starting points in this
-field. Earlier work in data governance in a web of [hyperlinked
-media](wikipedia:Hyperlink "wikilink") can be traced back to [Project
-Xanadu](wikipedia:Project_Xanadu "wikilink") by [Ted
-Nelson](wikipedia:Ted_Nelson "wikilink").
-
-More recent more publications in this fields are
-[Lessig](wikipedia:Lawrence_Lessig "wikilink")'s [Code
-v2](https://lessig.org/product/codev2)[^6] and soon to be published work
-of [Alex Pentland](wikipedia:Alex_Pentland "wikilink")'s [Building the
-New Economy](https://wip.mitpress.mit.edu/new-economy)[^7].
-
-## References
-
-[^1]: J. Gleeson-White, Double Entry: How the merchants of Venice shaped
- the modern world--and how their invention could make or break the
- planet, publisher Allen & Unwin, ``, November
- 2011
-
-[^2]: J. Gleeson-White, SIX CAPITALS, or CAN ACCOUNTANTS SAVE THE
- PLANET?, publisher Allen & Unwin, ISBN-10:9780393246674, February
- 2015
-
-[^3]: Hamilton, S.W.R. (1837) Theory of Conjugate Functions, or
- Algebraic Couples: with a Preliminary and Elementary Essay on
- Algebra as the Science of Pure Time, Transactions of the Royal Irish
- Academy, 17pp. 293–422.
-
-[^4]: David Ellerman, On Double-Entry Bookkeeping: The Mathematical
- Treatment, [https://arxiv.org/pdf/1407.1898.pdf](https://arxiv.org/pdf/1407.1898.pdf)
-
-[^5]: J.C. Colt, The Science of Double Entry Book-keeping, online
- media:[https://core.ac.uk/download/pdf/56693696.pdf](https://core.ac.uk/download/pdf/56693696.pdf), last accessed:
- May 4th, 2021
-
-[^6]: L. Lessig, Code: And Other Laws of Cyberspace, Version 2.0,
- Publisher: Basic Books, 2nd Revised edition, December 2006
-
-[^7]: Alex Pentland, Alexander Lipton, and Thomas Hardjono, Building the
- New Economy, MIT Press, Work in Progress,
- [https://wip.mitpress.mit.edu/new-economy](https://wip.mitpress.mit.edu/new-economy)
diff --git a/docs/protocol/delegated-witnessing.md b/docs/protocol/delegated-witnessing.md
deleted file mode 100644
index ab26c2b6..00000000
--- a/docs/protocol/delegated-witnessing.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-title: "Delegated Witnessing"
-linkTitle: "Delegated Witnessing"
-weight: 7
-description: >
- Describes the process of sending domain snapshots to remote data vaults.
----
-
-Describes the process of sending a domain snapshot to a remote data vault for
-witnessing. The domain snapshot is then included in the witnessing event and
-sent back to its original data vault. This makes the domain snapshot behave
-like an ordinary portable hash chain that can be witnessed. The relative path
-of the Merkle proof is used as a prefix for all other included portable hash
-chains included in the domain snapshot.
diff --git a/docs/protocol/design-principles.md b/docs/protocol/design-principles.md
deleted file mode 100644
index 8321d133..00000000
--- a/docs/protocol/design-principles.md
+++ /dev/null
@@ -1,127 +0,0 @@
----
-title: "Design Principles"
-linkTitle: "Design Principles"
-weight: 8
-description: >
- Lists the design principles underlying our reference implementation
----
-
-The following design principles pertain to Aqua reference Implementation `PKC`
-
-## Private is Default
-
-The principle default to private is that no data of the PKC [Data
-vault](whitepaper.md#data-vault) is shared without it being explicitly
-authorized by the associated account.
-
-### Domain Access Levels
-
-Levels of access are:
-
-Private: Only the account owner has access to files and services
-initialized by his account. Agreement / Permissioned access: The Account
-owner grants other Account's access to files or services based on
-verifiable contracts which are themselves written with the Aqua Protocol
-to ensure they are forgery-proof and therefore safe. Public: Other
-Account's have access to the file or service without agreements.
-
-## Offline Capability
-
-The PKC Data Vault follow's the principle of being able to run and be
-functional without internet connection after setup or through
-installation based on local installation files.
-
-This allows PKC setups to be kept offline from any internet connectivity
-while still functional. This can provide the required assurances for
-very sensitive data.
-
-## Separation of Account and Service
-
-Concern: There is a trend in the DIF/WC3 Identity space that some
-players like to accumulate personal identifiable data (PII) inside of
-Wallets. We think this is a ill-fated direction and there should be
-a clear separation between account and service. Wallets should not hold
-personal identifiable data.
-
-Benefits:
-
-- If the service gets hacked, no account related data is leaked if
- it's not stored.
-- Account is not compromised, as there is no password saved within the
- service with Password free login.
-
-#### [Wallet](whitepaper.md#wallet)'s have one job. Keep private keys safe! (Account Management)
-
-- Should be stupid, simple, safe!
-- Allowed operations:
- - Signing
- - De- / Encrypt
- - Publishing transactions to service (e.g. witness networks)
-- Ability to choose “high level of assurance” depending on the stakes
- associated with the account(s) managed by the wallet
-- Takes care of key recovery mechanisms
-
-#### [Data Vault](whitepaper.md#data-vault) (Service)- Has one job: keep the data safe!
-
-- [Principle: Offline
- Capability](Principle:_Offline_Capability) so it can run
- offline; works offline on local machine
-- All significant actions authorized and managed though the wallet
-- Should offer good tooling for data storage and manipulation
-- Strong access control: By [Principle: Default is
- Private](Principle:_Default_is_Private) which means data
- is only accessible by the owner.
-- Data is well protected
- - The Data Vault should apply additional security features to keep
- the data safe.
- - e.g. Encryption of files / databases if service is not used.
- - e.g. Encryption of pages with web-decryption (allowing for
- End-to-End Encryption).
-- Capabilities for sharing and publishing data
-- Offers full Backup and Recovery mechanisms to move data freely
- - [Principle: Data
- Portability](Principle:_Data_Portability "wikilink")
-
-## Signature Login
-
-We do not use passwords for login but instead we use a signature of a
-private key to authorize access to a service. This increases security
-and does not require the user to remember a password, creating a better
-user experience.
-
-Pros:
-\* Account owner uses his wallet to complete a signature challenge for
-login. With this challenge he proves that he owns the private key to a
-public key. If the public key is registered as an account at the
-service, the account is granted access.
-
-- The password can't be leaked as it does not exist.
-- Very high security
-
-Contra:
-\* Requires access to the wallet which holds the private key to
-authorize access
-
-- Not commonly understood by users as a way to login (new process)
-
-## Principle: Data Portability
-
-The Principle of Data Portability means that the
-[Account](whitepaper.md#account) owner can instruct the Service to Export
-all data associated with the [Account](whitepaper.md#account) and is free
-to move this data to a new service which is capable of importing the
-data.
-
-### Implementation Specifics
-
-In PKC's this is guaranteed by:
-\* providing a Backup and restore procedure which allows to move data
-between PKC's and restore them in case of a required recovery.
-
-- providing a file import and export function
-- providing an import / export API
-
-Furthermore we ensure with the development of the MediaWiki Data
-Accounting Extension, that the data is still compatible with the legacy
-import / export (which means only the text not the verification data is
-imported / exported.
diff --git a/docs/protocol/guardian.md b/docs/protocol/guardian.md
deleted file mode 100644
index 0ad72d6c..00000000
--- a/docs/protocol/guardian.md
+++ /dev/null
@@ -1,373 +0,0 @@
----
-title: "Guardian"
-linkTitle: "Guardian"
-weight: 9
-description: >
- Shows access and transport layer logic used to interconnect data vaults
----
-
-# Context
-
-It is highly problematic to expose sensitive data, such as personal
-identifiable data, to the internet. The service who hosts that sensitive
-data, needs to be compromised only for a short amount of time, to leak
-all the data. Often caused by configuration mistakes or by
-vulnerabilities being present in the used technology stack.
-
-We can't effort to have leaks on personal-identifiable data in data
-vaults. To raise the bar on making attacks difficult and reducing the
-chance of leakage of information, we introduce the Guardian as a extra
-security layer to protect services like the PKC from attacks.
-
-# Summary
-
-The Guardian is a software which manages the boundaries of your digital
-domain. Guardians are used to connect to secure transport networks
-(HTTPS, Matrix Network, Didcomm) and publishing networks (e.g.
-Swarm.eth). The Guardian is used to build trusted connections to other
-Guardians via trusted transport-layers to exchange data with them. As
-the Guardian connects to other Guardians, it also manages all
-connections to services in it's domain and access to those services.
-
-# Goal
-
-Secure all services behind the Guardian from attacks and unauthorized
-access. Keep the data vault and it's data private and safe, while
-enabling the ability to exchange data with other Guardians.
-
-## How
-
-Enforcement is handled on each connection and each data set so that
-services behind the Guardian are never directly exposed. This makes the
-Guardian the most security sensitive component in the Aqua reference
-implementation, as we expect the Guardian to handle all incoming and
-outgoing traffic. The Guardian enjoys additional attention and effort to
-be up to it's task by hardening it and applying security best practices
-to ensure that it is fulfilling it's security promise to keep services
-behind the Guardian safe.
-
-Every transaction leaving or wanting to enter your domain will be
-supervised and checked by the Guardian. The core functionality of the
-Guardian is a library to verify the Aqua Protocol. Only if the
-verification succeeds additional steps are introduced to make decisions
-how the data is handled.
-
-This allows the Guardian to read and understand Aqua verified data. This
-allows for the implementation of a wide set of behavioral rules and
-offers the opportunity to create various 'Smart contract' languages on
-top of it.
-
-The Guardian verifies a file, reads its contents and checks it's
-permissions to classify if an action is considered legal or illegal,
-permitted or denied. Basic functionality for a Guardian can be compared
-with a traditional firewall, or a application firewall but is much more
-sophisticated to manage access on the data-level.
-
-# Terminology:
-
-Proving ownership over a domain by signing the domain ID with an
-self-issued identity claim which is also registered in a claim registry
-to ensure nobody claims to have owned that domain before by manipulating
-the digital clock and faking an earlier owner-ship claim over the
-domain.
-
-## **Permission Agreements** / Data Usage Agreement / Access Rights
-
-are contracts which represent the terms and conditions under which files
-and/or services are shared with other accounts and/or their digital
-domains.
-
-By nature those Permission Agreements will be compiled through pages and
-stored as files. To form an agreement, the other party must be notified
-about new resources as they become available. For example, when we share
-a page with another account. To complete a permission agreement, the
-counter party has to sign the permission agreement or reject it. If the
-permission agreement is signed, the other party enters a contractual
-relationship in which they will be liable for any agreement violates
-executed from their digital domain.
-
-# Processes
-
-## Domain Handshake
-Establish trust between two Aqua domains. For this we have Alice and Bob which
-want to establish trust between their domains. They both have a Guardian in
-place to protect their data vaults.
-
-Steps:
-1. Alice: Create access contract: I `` want to connect from my `` to a `` controlled by `` with my `` via the following channel: DNS/HTTPS via `alice_Guardian.domain.com`.
-2. Alice: sign contract
-3. Alice: SEND contract send the page via 'mail' / 'matrix' whatever to the remote PKC instance.
-4. Bob: veries the contract contract and imports it
-5. Bob: extend contract: I `` connect my PKC `` to your PKC `` via my Guardian_endpoint ``.
-6. Bob: sign extended contract: Bob uses his wallet to sign his extended contract.
-7. Bob: send extended contract TO Alice: Bob sends his Contract to his Guardian.
-8. Bob's Guardian: Verifies and sends the contract to Alice Guardian.
-9. Alice Guardian:
- Guardian verifies all data
- Sends OK back to Bob's Guardian
- Sends Updates contract into Alice PKC
- Waits for Bob's Guardian to request available pages
-10. Bob's Guardian requests a list of pages: ' What pages do you share with me?'
-11. Alice Guardian: Returns list of accessible resources for Bob
-
-## Example: Sharing a File
-
-Target: Sharing a file with another account. Using two Aqua data vaults
-with their two Guardians to manage access to them. We assume the
-Guardians already have executed a handshake to enter a trusted
-relationship. We also assume, that the file should underlay access
-basedon account restrictions and domain restrictions.
-
-**Example 1:** Sharing a file **without additional** constrains with
-another account.
-
-Alice wants to share her page 'My secret research' with Bob. Their
-Guardians have already formed a trusted connection. What Alice needs to
-do now is to add a sub-page with an immutable link under the 'My secret
-research' page and define access. To be able to define access Alice
-needs to have a claim over the ownership over the domain she is sharing
-from.
-
-Alice creates an Access Permission for the whole page or for a single
-revision by creating a page with the following syntax:
-
-- ``:access_contract
- - To give access to the whole page with all it's revisions.
-
-- ``:access_contract
- - To give access to a specific revision.
-
-----
-
-**Content of the page:**
-
-I Alice `` give access to Bob ``
-
-- option 1: to the whole page including it's history ``
-- option 2: to the following revision ``'My secret
- research'
-
-**Additional one-sided conditions:**
-
-- This access contract expires in 7 days
-
-This contract will come into place with my `` signature.
-
-The Guardian will react to a specific syntax of pages holding contracts,
-agreements and access rights to adjust his network access rights
-accordingly to it. Alice-Guardian will respond to the question what
-resources are shared by Bobs-Guardian with the answer that there is a
-new page available according to the access contract which now gives
-Bobs-Guardian the ability to query the content of 'My secure research'
-from Alice according to the contract. Depending on Bobs-Guardian
-setting, the Guardian might automatically load the resource and forward
-it into the post-box of Bobs Data Vault.
-
-**Example 2:** Sharing a file **with** constrains forming a **contract**
-to do so.
-
-Same as 1 expect that for the contract to come into place, Bob needs to
-sign the contract from Alice containing additional constrains.
-
----
-
-**Content of the page:**
-
-I Alice `` give access to Bob ``
-
-- option 1: to the whole page including it's history ``
-- option 2: to the following revision ``'My secret
- research'
-
-**Under the following conditions:**
-
-- Do not share outside your domain ``
-- Do not share with any body else (Bobs domain can't have another
- account registered to it, if there is an account registered the
- Guardian of Bob will say that Bobs domain does not fulfill the
- requirements to establish this contract.
-- Do not modify it.
-- Delete it after 7 days.
-
-For this contract to be valid, signatures of first Alice and then Bob
-need to be present. This means, after Alice signed the access contract,
-the contract is a new available resource to Bob to be loaded. Bob can
-now sign the resource in his domain and return the contract. Leading to
-the contract send back to Alice domain and being updated there. Bob now
-gets access to 'My secret research' which has been updated as well, to
-contain via an immutable link the access contract.
-
-Permission Templates, Complex Permissions (Groups and more)
-
-It is possible to apply complex permissions based on templates, or and
-connecting multiple access contracts by using
-
-- instead of this syntax ``:permission_agreement
-- the following the syntax ``:`` in
- which the `` contains a list of sub-pages with access
- contracts which can be used to apply access via permission-objects
- which are represented by the `` page object.
-
-1. Alice wants to
-2. If the user wants to propose changes to the page, he will send an
- updated PAGE FILE to the OWNER of the PAGE.
-3. The owner can decide to ACCEPT the changes. Or to include the
- changes in the HISTORY File, but not COMMIT them. Or to NOT include
- the update of the PAGE, and disregard it.
-
----
-
-### Specifications:
-
-The Guard Daemon checks if there is digital contract present in his
-domain. Those contracts set permissions for allowing a counter party to
-access a service or resource (like a file or a page, or a revision).
-It's also defining the constrains under which permissions access is
-given. In this case it requires the digital signature of the receiving
-party for the agreement to come into place and be valid.
-
-Guardians have administrative access to the services they manage.
-Therefore they can supervise the activities of services and use them as
-triggers to e.g. provide access according to a set permission without
-additional user action.
-
-# Guardian Components:
-
-APIs
-- System-API to control a service via a service specific library. Each
- services will have their own control-library and control API to
- create an abstraction layer which allows for a unified control logic
- in the Guardian.
- - E.g. an account is allowed to access a service
- - E.g. a resource is shared with an account
- - E.g. a trust relationship between two services is established
- (based on an agreement between two accounts) to exchange data
- - **Implementation Specific PKC:** All interactions for system
- interaction with MediaWiki / PKC
- - Execute Actions: Move, Update, Edit, Delete Pages
- - Request send to the Guardian: Verify a specific page or a
- list of pages
-
-- **Data-API** to retrieve Aqua-Data between a service and the
- Guardian, or between two Guardians.
- - Send data to import API
- - Read data via export API
- - **Implementation Specific PKC:** Read special Pages used to
- give access e.g. Data Usage Agreements, Permission
- Agreements
-
-- **Aqua Verification Library** to be able to verify incoming and
- outgoing data
- - implementation of the 'external-verifier' in e.g. GO, Typescript
- or Javascript (current)
-- Account-Registry (Holding the list of trusted keys and the
- relationship between them)
- - This includes defined 'trusted accounts'
-- Session-Handler/Registry (Acts like Stateful-Firewall on the
- page-object level to mange imports / exports). The Guardian verifies
- incoming and outgoing data and constructs sessions based on it.
-- Guardian Policies: Are sets of rules followed and enforced by the
- Guardian. This includes set of rules used to protect the domain from
- unauthorized operations and access. Part of that are page access
- permissions which are managed by the [Data Usage
- Agreements](Data_Usage_Agreement "wikilink").
- - ``:``
-- Transport Layer API's / Sub-Modules for connectivity to distributed
- services
- - The Guardian-to-Guardian communication handler (via DNS/HTTPS
- transport)
- - Ethereum Integration, Ethereum Handler (As a witness Network)
- - Matrix Integration, Matrix Handler (As a restrictive/
- permissioned transport layer)
- - Schwarm Integration, Swarm Handler (As a publishing network)
-
-# Guardian-Integration-Services
-The Guardian has a modular design to support integration with many services and
-transport layers.
-
-## Web (HTTPS / DNS) Integration Goal: Have a
-handler to connect web-facing Guardians with each other in a safe way. Be able
-to run guardian procedures via two public Facing guardians which use a public
-DNS name and HTTPS to interconnect with each other. Guardian procedures are:
-Guardian handshakes to establish trust or remove trust Request or Send portable
-Hash-Chains based on access rights between each other
-
-## Ethereum Node
-
-Integration Goal: Connect to a self-hosted or remote Ethereum Node. Option 1:
-Configuration via Alchemy (Providing Keys) via Special:DataAccountingConfig
-Option 2: Implementation of Ethereum Node via ./setup --ethereum-node (provide
-container) Configuration of Connection to RPC Ethereum node via address (if in
-same network) The Wallet can be directly be connected to a local Ethereum node
-via RPC to avoid meta-data gathering of large providers, like INFURA which
-could potential track which IP address has created which Ethereum Transaction
-with which Metamask-Wallet, leading to a de-pseudonymousation of the user. ###
-Ethereum Node Handler Goal: Accelerate lookups of the Guardian via caching
-Every-time a witness contract is called, the Ethereum Node Handler will start
-to cache the all Ethereum-Witness events of that Witness-Contract and Index
-them in it's database. This will reduce access times to ms vs potential seconds
-in lookup times, making the Guardian more performant and responsive. ## Matrix
-Node Integration Goal: Connect to a self-hosted or remote synapse-server
-(MATRIX) Node. Configure a remote matrix server or a local one via Guardian.
-Implementation of Matrix-Node deployment via ./pkc setup --matrix-node (provide
-container).
-
-### Matrix Node Handler
-
-Context: We use Ethereum Wallets as Identity-Anchors as they are globally
-unique addresses (which are collision free) broadly adopted with supported
-hardware ledgers as secure hardware elements with an existing fast moving
-ecosystem for further development. They act as 'web-based' PGP-like utilities
-which do not need any Blockchain-Interaction for Signing messages and can be
-used as a valuable off-line capable identity anchor. With this step we separate
-Identity and Service; even in case of compromising the computer of the user or
-by having a breach of secrets in the Element-Client the Identity would be safe
-(in case a hardware wallet would be used). This also drastically reduces attack
-surface to phish a users credentials; as there is no Password-Login there is no
-way to steal the password to impersonate the user. All security assumptions of
-the User-Identity come back to the security of his private key. For the
-Kolibri/PKC project this is the foundation for using wallet-addresses as
-Identities to route traffic with matrix bots between PKC's. The following
-actions are required to use the Ethereum Wallet as a strong Identity Anchor
-within Matrix.
-
-This requires the following functionality:
-* Register the user via an Ethereum wallet address (successfully piloted by inblockio)
-* Detect that it is an Ethereum Wallet-Address; Verify integrity of address with the Ethereum Wallet-Address Checksum (TBD)
-* Make username not changeable (Done via Matrix settings,successfully piloted by inblockio)
-* Wallet login with Web-Wallet Metamask via OIDC (Open ID Connect) (successfully Piloted by inblockio)
-* Verify Ownership of the Wallet by doing an Element-Client side Signature Challenge to the User. Challenge resolved by signing a message with sufficient entropy to not be ever the same (to protect against leakage) with the private key via the Ethereum
-Metamask Webwallet (or a connected Hardware-Wallet)
-* Implement a User-to-User request of proof of Identity Users / Server can challenge other users to proof that they hold the private Wallet-Key by triggering the Signature Challenge to the User; After the challenge is done, the requested party is provided with all information to do a manual verification of the signature (the Message which was
-Signed, the Signature, the used method used for the signature)
-
-### Matrix-BOT
-
-Context: The Matrix-Network communicates with the PKC through the Guardian who
-will manage all access to the MediaWiki service. The Guardian uses a Matrix-Bot (to
-handle the communication) and a Matrix-Integration (to be flexible to use a
-private synapse or a remote synapse server) to interact with the Matrix Network
-as a permissioned transport layer.
-
-Referenz-Implementation:
-Suitable options for a matrix-integration are 'go-lang' or 'rust'. Guardian
-next generation Guardian will be written in Rust, so integration of security
-relevant components would be preferably in Rust and Webassambly. A central
-point to configure the guardian to connect to matrix and other services needs
-to be provided. The matrix server is connected to the guardian with a service
-bot which is able to open rooms to exchange revisions between PKC’s.
-
-Required Functionality of the Matrix-Bot:
-* open new room for user (required) - to share resource invite / remove other
-users to/ from room (required) - to set permissions who can read
-* shared resource close room (required) - after resource share is revoked join a
-room the user is invited too (by other matrix-bot)
-*'accept invite' check for
-challenge (provided via text from remote Guardian), leave room if challenge is
-faulty and block user (required) delete? room / delete history?
-Note: Use matrix only as channel not as storage (optional) preferably the
-history of the channel is not kept
-* post content of (mediawiki API query results from the Guardian) into a room
-* (required) read content of room (send it to the Guardian for verification,
- before it's send to the import API) (required)
-
diff --git a/docs/protocol/immutable-hyperlinks.md b/docs/protocol/immutable-hyperlinks.md
deleted file mode 100644
index 9ef1afb5..00000000
--- a/docs/protocol/immutable-hyperlinks.md
+++ /dev/null
@@ -1,85 +0,0 @@
----
-title: "Immutable Hyperlinks"
-linkTitle: "Immutable Hyperlinks"
-weight: 10
-description: >
- Shows how the Aqua URI's can be used as immutable links.
----
-
-Traditional hyperlinks are usually
-[URL's](https://en.wikipedia.org/wiki/URL) based on the
-[DNS](https://en.wikipedia.org/wiki/Domain_Name_System) structure.
-
-This allows the resource to be routed via DNS and specified via the URL
-on the remote server.
-
-The limitations of URL's is that they are not expressing a specific
-state of the resource they represent. There is no way to verify if the content
-of the page is consistent with the content of the page who send a URL.
-For news pages this means that the content of the page could have changed. E.g.
-two visitors of the same news page could see two different pages.
-
-We need a better way to hyperlink so it's sure, that what is linked
-is consistent across domains and users. Therefore we introduce Aqua URI's which are
-used to enable the receive to verify the state of the resource.
-
-Goal
-----
-
-Use Immutable Hyperlinks as Unique Resource Identifiers (URI's) to allow
-a consistent referenciation of resources with the ability to verify them with the AQP.
-
-Success Criteria
-----------------
-
-A Immutable Hyperlink schema which links to a specific state of a
-resource. Instead of a stateless hyperlink we use verification_hash as a
-URI which acts as the checksum to verify the retrieved revision.
-
-Input
------
-
-- file upload wizard is executed with file-data and description as
- input
-- file is stored with in the service triggering a hook leading to the
- calculation of
-- verification_hash (calculated with the file as input for
- content_hash) which is stored in the revision_object (file or
- database)
-
-Output
-######
-
-When linking the file it's displayed in the following format: \[SHA3-512
-Hash\|Descriptor Text\]
-
-Boundary conditions
--------------------
-
-- File is too big to be hashed. We support currently up to 50 MB.
-- File can't be hashed for some reason (error during the process to
- due an unexpected code execution)
-- File is empty (has no content)
-
-Implementation
---------------
-
-We create Immutable Hyperlinks by moving from URL's to sha3-512 hashes as
-URI's. These URI's are globally unique and therefore collision resistant
-as the namespace is sufficiently large. By using the hashes as links we
-also refer to the state of the resource. As the hash is the
-verification_hash of the resource it allows us to verify the integrity
-of the resource with it.
-
-We are referring to files with their SHA3-512 hash in this format
-\[SHA3-512\|human_readable_filename\]. Displayed is the human readable
-filename white it's stored with the full SHA3-512 hash which allows us
-to be used as Immutable Hyperlinks.
-
-To allow routing between resources we can add the `` as a
-prefix to the `` resulting in the following syntax:
-
-`example: aqua:///`
-
-Note: Implementatstion specific to aqua-PKC:
-- The verification_hash is stored in the content-slot 'transclusion hashes' with the internal links which referne the resource.
diff --git a/docs/protocol/whitepaper.md b/docs/protocol/whitepaper.md
deleted file mode 100644
index 4009058f..00000000
--- a/docs/protocol/whitepaper.md
+++ /dev/null
@@ -1,786 +0,0 @@
----
-title: Whitepaper
-linkTitle: "Whitepaper"
-weight: 1
-sidebar_position: 2
-description: >
- High level outline of Aqua Protocol (AQP) specification
----
-
-
-| | |
-|------------------|--------------------------------------------|
-| Current version: | Aqua Protocol v1.1 Specification |
-| Author: | Tim Bansemer, Publius Dirac |
-| Date: | 30.12.2021 |
-| Status: | DRAFT / Experimental |
-| Implementation: | [https://github.com/inblockio/micro-pkc](https://github.com/inblockio/micro-pkc) |
-
-## Introduction
-
-The Aqua Protocol (AQP) is a data accountability and exchange protocol between
-hosts in peer-to-peer environments. The AQP is used to realize the goal of
-[accounting for data origin and history](data-accounting.md). The description
-for the proof-of-concept implementation of the AQP can be found in [this
-page](../implementations/reference-architecture.md).
-
-## Motivation
-
-In today's world, there are no widely adopted trustless processes of checking if
-data have been manipulated or corrupted, are attributed to the wrong author, or
-are attributed to the wrong time. Today's processes are dependent on centralized
-trusted services which retain all power over governing the data.
-
-There is a lack of transparency or ability to check if data have been altered
-by an unauthorized party. Additionally, consumers of data are incapable of
-verifying if centralized services have altered the data. This leads to a world
-of untrustworthy information in which we don't know how to conclude what is
-true.
-
-In a world where every piece of information is a grain in a sandstorm, it has
-become impossible to navigate reality. In contrast, in a world where every
-piece of information is a fixed star in the sky for a lifetime, we are able to
-relate and make sense of the information given. The Aqua Protocol (AQP) turns
-grains of information into fixed stars of information.
-
-The AQP adds a peer-to-peer layer of accountability, making it impossible to
-change data unnoticed. AQP adds an essential line of defense against attacks on
-data integrity, plagiarism, or misattribution. AQP is used to govern trusted
-data, which can be quickly verified. This includes the verification of its
-integrity and history, the verification of its account (the entity who creates
-or manipulates the data), and the verification of its existence and timestamp.
-
- The Aqua Protocol provides trustworthiness to data by
- securing data ✅ integrity, 🔏 account and ⌚ time.
-
-In order to account data, it is necessary to track and verify its history. The
-AQP provides a globally unique resource identification (URI) for each revision
-of the verified data. This identifier is collision-free, and is referred the
-same way across multiple interacting hosts.
-
-## Terminology
-
-## Wallet
-A wallet is a software for protecting and managing private cryptographic keys
-(of private-public key pairs) which are used to govern digital assets. This is
-done by authorization of transactions via digital signatures or by initiating
-decryption processes to access data.
-
-See [Separation of Concerns](design-principles.md#separation-of-account-and-service).
-
-### Account
-
-We are following Ethereum's account definition:
-> In general, there are two types of accounts. Externally owned accounts,
-> controlled by private keys. And contract accounts, controlled by their
-> contract code
--- [Ethereum Whitepaper](https://ethereum.org/en/whitepaper/#ethereum-accounts)
-
-In general, we can't prove if an account owner is a person or a machine. With
-advancements in AI, it will become increasingly difficult to prove that a human
-is a human. [Attempts are being made](https://www.proofofhumanity.id/) to
-increase trustworthiness of accounts which fall short in questions of privacy
-and security as they make public claims. Traditional know your customer (KYC)
-combined with the AQP and Aqua Identity Protocol (AIP) identification processes
-can provide similar "proof of being human" which can be attested to an account.
-This allows us to outsource the problem of identification, where we only focus
-on unique accounts which are sufficient for data accounting independent of
-humans or machines. Identity claims issued via the AIP will help to provide the
-context required to meaningfully interact between accounts.
-
-For more on this topic, please read the [Aqua Identity
-Protocol](aqua-identity-protocol.md).
-
-### Domain
-A domain is a unique namespace attributed to an account. It allows us to manage
-services and files within that namespace creating a domain of data governance
-After granted permissions, additional accounts can be added to share control
-over a domain or singular assets. To enforce boundaries of a domain, additional
-software like the [Guardian](guardian.md) is required.
-
-E.g. by setting up the a data vault with your account it becomes your
-domain of data governance.
-
-### Revision
-
-A revision is the smallest portable entity within the AQP. Multiple revisions
-form a single portable hash chain which is serialized in JSON format.
-They have existed before in unsecured systems where multiple revisions form a
-file which can be displayed as a page. The AQP adds the cryptographic harness
-to secure it. With presenting a portable hash chain, it is possible to track
-all incremental changes stored in each revision to understand the history of a
-page and how it came to be. This allows us to have version control on digital
-assets being able to restore earlier states and to relate to them. This allows
-us to have historical evidence of digital assets.
-
-### Page
-
-A page is a visible representation of a file containing multiple or a single
-revision attributed to a shared origin. A page view could also be used to
-create a new revision by a used service which interfaces with the file for
-manipulation. In AQP all revisions share a global URI hash to
-attribute them together called a genesis hash.
-
-### Transaction Security
-
-Transaction security is an economic measure of the level of integrity assurance
-for a transaction. It is defined as the cost required to forge a transaction.
-The transaction security can be increased by cryptographic security and by strong
-replication of transactions. Public distributed ledger systems are highly suitable
-for providing very high level of transaction security at the cost of privacy
-and immutability (data can't be changed or deleted). Today, public distributed
-ledgers such as Bitcoin and Ethereum provide the highest level of transaction
-security.
-
-### Data Asset
-
-Data turns into a valuable asset if it is accounted for. In an accounted form
-it can be easily priced, exchanged or traded.
-
-### Data Vault
-
-Software used to store and manage data with an account. The software must apply
-a secure architecture and measures for keeping data assets safe. This is
-achieved through encryption, strong authentication and restrictive access to
-keep data private by default.
-
-See [Design Principles / Separation of Account and
-Service](design-principles.md#separation-of-account-and-service)
-
-
-### Witness
-
-We define witnessing as the process of observing an event. A witness is judged
-by their capability to recollect and share an observed event. In other words,
-witnessing is the process of storing input data for later playback to provide
-data symmetry around an event.
-
-### Witness Network
-
-The digital service in a distributed ledger or similar infrastructure which
-provides transaction security and data symmetry for shared data within the
-network. An example of a witness network would be Ethereum.
-
-E.g. Ethereum can be used to store a digital fingerprint of a domain snapshot
-of a data vault. A domain snapshot is the Merklized state of all witnessed hash
-chains being present in the data vault. It is required to pay the witness
-network for its service. In the case of Ethereum, this is done using 'Ether'.
-This in return allows the account owner to create an 'undeniable' proof that a
-specific revision and the previous revisions within a hash chain has existed.
-
-### Portable Hash Chain
-
-A hash chain is a linked list where each node contains the cryptographic hash
-of the previous node content. A portable hash chain is a hash chain that can be
-moved from one host to another.
-
-### Immutable Hyperlinks / Transclusions
-See [Immutable Hyperlinks](immutable-hyperlinks.md).
-
-## Specification
-
-To identify a revision with a unique fingerprint, we hash its content using
-the SHA3-512 hashing function which always has a 128 characters long
-output. This value can be used as a checksum to verify data integrity.
-The checksum can then be entangled in a hash-chain to create an
-immutable track record. We then calculate multiple properties associated
-with the revision, in addition to its content checksum. In the next section,
-we differentiate between REQUIRED and OPTIONAL properties for each
-revision.
-
-All hashes are based on
-[SHA3-512](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf).
-This encryption standard is used to construct [portable hash
-chains](#portable-hash-chain), which are serializing of data and its history in
-a form that can be verified, and independent of location. The portable hash
-chain can be fully or partially exchanged between hosts depending on the
-application of the data. From here on, we refer the term "portable hash chain"
-as "hash chain."
-
-In order to implement the AQP, we need to utilize a software that is capable of
-generating portable hash chains and facilitating actions described in the
-AQP. We call those nodes which facilitate the Aqua Protocol 'Aqua Data
-Vaults' which given their role should be implemented as a software with secure
-architecture and measures for keeping data assets safe. This is achieved
-through encryption, authentication and restrictive access to keep data private
-by default.
-
-# Revision Verification Structure
-
-A revision is RECOMMENDED to be limited to 50 Megabytes to ensure that the verification can take
-place on all imaginable clients which might have slow network connectivity, low
-memory, low cpu performance. Once a revision is verified, the next one can be
-verified. Clients with more performance will be able to parallelize the
-verification. Larger files can be chunked to be placed in multiple revisions.
-
-A verified data structure is identified by its URI `verification_hash`
-and grouped by its `genesis_hash`. The first revision created will
-create a `verification_hash` which has a special meaning and is
-referred to as the `genesis_hash`. All future revisions building upon
-that first revision will be attributed to the `genesis_hash` as a unique
-URI for grouping the revisions. This allows us to understand if two
-revisions are related without needing to verify the whole history of the
-hash chain.
-
-## Verification Hash
-`revision_verification_hash` is the hash sum over the string formed by the
-following operation
-
-```
-revision_verification_hash = calculate_hash_sum(
- content_hash + metadata_hash +
- signature_hash + witness_hash
-)
-```
-The content_hash and metadata_hash are REQUIRED.
-The signature_hash and witness_hash are OPTIONAL.
-
-## Content
-
-A content hash is the check sum for all content data fields which simplifies
-hash construction and the ability to identify data corruption in this part of
-the verification structure.
-`content_hash` is the hash sum over the string formed by following operation:
-
-```
-contentObj = {
- "main": content,
- "extension_key_1": content_extension_1,
- "extension_key_2": content_extension_2,
- ...,
- "extension_key_n": content_extension_n,
-}
-sortedContenObj = sort_by_keys(contentObj)
-content_hash = calculate_hash_sum(
- sortedContenObjValue_1,
- sortedContenObjValue_2,
- ...,
- sortedContenObjValue_n,
-)
-```
-Description:
-- content: The string input of the visible page using UTF-8 encoding schema.
- REQUIRED.
-- content extensions: more data MAY be encapsulated in addition to the main
- content. These could be a file, a stateful link, or a signature. The content
- extensions are sorted alphabetically by their key names. OPTIONAL.
-- The `sort_by_keys` function sorts the content object elements by their keys
- alphabetically. The JSON input MAY be a canonical JSON, in which the keys
- order is already alphabetical, but we sort it always to ensure the order is
- correct.
-
-To see an example of `contentObj` of a revision, see the [example](#Example)
-section,
-
-## Metadata
-
-```
-metadata_hash = calculate_hash_sum(
- domain_id + time_stamp + previous_verification_hash
-)
-```
-
-Description:
-- metadata_hash: The check sum for all metadata data fields. It simplifies the
- hash construction and the ability to identify data corrupton in this part of
- the verification structure.
-- domain_id: 10 digits hexadecimal randomly generated to identify the host
- system that runs the AQP service.
-- time_stamp: time-stamp of the current revision (decimal numbers
- YYYYMMDDHHMMSS e.g. 20211128092608).
-- previous_verification_hash: previous_revision_verification_hash if present
-
-## Signature
-
-A signature in AQP is a cryptographic signature generated by public-private key
-pair. The protocol should be abstract, where it will support 'Method' in later
-iterations. This will allow us to use different types of implementations such
-as: PGP signatures, Ethereum, or Bitcoin
-[wallet](https://en.wikipedia.org/wiki/Cryptocurrency_wallet)'s signatures.
-
-In this specification, we use the AQP reference implementation's signing
-method, which is via an Ethereum wallet.
-
-```
-signature_hash = calculate_hash_sum(
- signature + public_key
-)
-```
-
-The signature is generated by a wallet signing the following message:
-
-```
-I sign the following page verification_hash:" +[0x]
-```
-
-The `revision_verification_hash` MUST NOT be signed twice by the same key, to
-avoid information leakage of the private key.
-
-For example, a wallet with an address of
-`0xa2026582b94feb9124231fbf7b052c39218954c2` and a public key of
-`0x041518581af65749b3ddc69889df3e5d229bc8ad79279a07ddeb368ade5e1592368c5ff3b69143d7a1e7cf64f7d0774a6724e6eaf138d318d07ddc30f6081ca89a`
-signs the following message:
-```
-I sign the following page verification_hash:" +[0x9dab72c7635043452958c4cc2902f48ef7c4ae437058280197c6a2736ab9635f799cbf190d9d07dd76589055a8ad64e61c6bebd1487994207d4cb7918b471f57]
-```
-which results in the following signature:
-```
-0x19b5697c4541509c1add3db9fc2f678b7b80325ebffd4d945ca00db5f8b3f98a142edbf9a7faa0a0c7ec4f10ae1b64cf2ea62ce3ee73ed2e37ce916d6bd016601c
-```
-
-## Witness
-
-Witnessing allows one to undeniably prove the existence of a dataset
-(represented as a portable hash chain). To complete the witnessing process, a
-Domain Snapshot is created. This is a collection of all revision hashes within
-one domain. A Merkle tree is used to unify all hashes of the latest revisions
-of all portable hash chains within a domain into a single hash value.
-
-The `witness_event_verification_hash` is written to the [Witness
-Network](#witness-network). The
-`witness_event_verification_hash` is then generated by using the
-`domain_snapshot_genesis_hash` and the `merkle_root` hash together. This
-allows the page snapshot itself to also be witnessed.
-
-A single revision which has been witnessed, will not store the whole Merkle
-tree, but only its relevant path to the Merkle root. Performing a Merkle proof
-means that its revision is included in the Merkle tree.
-
-```
-witness_hash = calculate_hash_sum(
- domain_snapshot_genesis_hash + merkle_root +
- witness_network + witness_event_transaction_hash
-)
-```
-
-Description:
-- `witness_hash`: the checksum for all signature data fields. It simplifies hash
- construction and identifies data corruption in this part of the verification
- structure.
-- `domain_snapshot_genesis_hash`: Refers to the URI of the page which stores the
- whole Merkle tree of the witness event.
-- `merkle_root`: the root hash of the Merkle tree. The presence of the
- Merkle tree allows for lazy verification to reduce required computational
- steps for verification by skipping the Merkle proof as both datasets can be
- entangled in the chain by a newer revision and therefore be immutable.
-- `witness_network`: specifies which witness network was used to store the
- `witness_event`. The following structure shows an AQP hash chain with 3
- revisions which wrote the `witness_event_verification_hash` into the
- witness network.
-
-Additional context:
-- relative-merkle-tree-proof: This provide the relative path with all required
- hashes to verify the Merkle tree root from the first node which the
- `verification_hash` of the revision as a starting point.
-- `witness_event_verification_hash`: It is calculated by taking the sha3-512
- checksum of the `domain_snapshot_genesis_hash` and the `merkle_root` hash.
- This ensures that the`domain_snapshot` itself will be witnessed.
-
-
-## Example
-The following structure shows an AQP hash chain with 3 revisions:
-
-### 1st Revision
-This revision features all REQUIRED (content, metadata) and all OPTIONAL
-(signature, witness) AQP data fields.
-```json
-{
- "verification_context": {
- "has_previous_signature": false,
- "has_previous_witness": false
- },
- "content": {
- "rev_id": 358,
- "content": {
- "main": "First revision text",
- "transclusion-hashes": ""
- },
- "content_hash": "ae188be061822074716b43925b3ffa90a03c530342be73c3440d8f022765ffebbb56c16552f13cd1ea61f876d2d892e0a73dcba5173fc47d371b4251d6c094da"
- },
- "metadata": {
- "domain_id": "acfa9f682e",
- "time_stamp": "20220116090401",
- "previous_verification_hash": "",
- "metadata_hash": "d1025fd8866d9367735d2f6617b3aa87401e08d726f311cdf834ea9540955bfc59b428676bce5d47d5fed381394ab2ed838c5eecfc9cb37313705374752c247d",
- "verification_hash": "9dab72c7635043452958c4cc2902f48ef7c4ae437058280197c6a2736ab9635f799cbf190d9d07dd76589055a8ad64e61c6bebd1487994207d4cb7918b471f57"
- },
- "signature": {
- "signature": "0x19b5697c4541509c1add3db9fc2f678b7b80325ebffd4d945ca00db5f8b3f98a142edbf9a7faa0a0c7ec4f10ae1b64cf2ea62ce3ee73ed2e37ce916d6bd016601c",
- "public_key": "0x041518581af65749b3ddc69889df3e5d229bc8ad79279a07ddeb368ade5e1592368c5ff3b69143d7a1e7cf64f7d0774a6724e6eaf138d318d07ddc30f6081ca89a",
- "wallet_address": "0xa2026582b94feb9124231fbf7b052c39218954c2",
- "signature_hash": "cc42f40c4452a25f9ea48a97b6dfba6f69dec347db5c1adf25475b0b4a5da36af3fe48bf9f7ea0dda6bbed9367dc9c82834dbf8cc7f6220fd190cdb729d3f4ec"
- },
- "witness": {
- "witness_event_id": "2",
- "domain_id": "acfa9f682e",
- "domain_snapshot_title": "Data Accounting:DomainSnapshot:b33afaf53ed3d245f0319d4997db2032de9d77791ae11f5125189815eef44f2fba9633bebe2e57bc5ea4b0424872ed02fa6aa9ad909f467726b536933bf715bf",
- "witness_hash": "9707780cebcf6ed02b40bd7e6956b35ffe142a2b5f8cee15c703a652fa389eb118ef101e2f463e95663aa4013a42d9f1ce4a83eed3528b02bf98626e7599bbd8",
- "domain_snapshot_genesis_hash": "b33afaf53ed3d245f0319d4997db2032de9d77791ae11f5125189815eef44f2fba9633bebe2e57bc5ea4b0424872ed02fa6aa9ad909f467726b536933bf715bf",
- "merkle_root": "14f26d7dc0be77afff9131c03cab39a2fa9e1270c6face3fdc35b9b4b4ac4550d048c356a4713568c42411c3e7fe3553ec7b993c9bd7da97cb976e843d7e4d29",
- "witness_event_verification_hash": "67e187411f1e514f232ae2858168da29b15ddfd07523e7a7618bfbf91c583f54fe8e850146120539a92a63ce6138f96599fb8a46ed492e428fe6fde9b9ea82ae",
- "witness_network": "goerli",
- "smart_contract_address": "0x45f59310ADD88E6d23ca58A0Fa7A55BEE6d2a611",
- "witness_event_transaction_hash": "0x5900103adc09a789fd3bd7c23dfeff1ffce41dfba0a52b525ecc032e9279eb1f",
- "sender_account_address": "0xa2026582b94feb9124231fbf7b052c39218954c2",
- "source": "default",
- "structured_merkle_proof": [
- {
- "witness_event_verification_hash": "67e187411f1e514f232ae2858168da29b15ddfd07523e7a7618bfbf91c583f54fe8e850146120539a92a63ce6138f96599fb8a46ed492e428fe6fde9b9ea82ae",
- "depth": "4",
- "left_leaf": "2554fb53531f4de26ff3ad1fb8c61feea6ea47c3f13c4abda385c46ef8541361f7eee42433050281714a3900115f04fe52b5a8d781a71c4c439c5de6b91cbe3c",
- "right_leaf": "9dab72c7635043452958c4cc2902f48ef7c4ae437058280197c6a2736ab9635f799cbf190d9d07dd76589055a8ad64e61c6bebd1487994207d4cb7918b471f57",
- "successor": "789e508ccb23fe053b628cebc19a2d32f34e6aa21e878e8611f7c14d891625c7b2e243b3c3105b98295333b9183e5ea272a055a84ab65ad927f7fd9c27aae48e"
- },
- {
- "witness_event_verification_hash": "67e187411f1e514f232ae2858168da29b15ddfd07523e7a7618bfbf91c583f54fe8e850146120539a92a63ce6138f96599fb8a46ed492e428fe6fde9b9ea82ae",
- "depth": "3",
- "left_leaf": "789e508ccb23fe053b628cebc19a2d32f34e6aa21e878e8611f7c14d891625c7b2e243b3c3105b98295333b9183e5ea272a055a84ab65ad927f7fd9c27aae48e",
- "right_leaf": "c16a966333cd22ff3497875a62202874221c1dae2e74b4351d058910f8d37160be480fce9aab4ec5e725beb695509f0fd65ae581568c6f1ae25eb4f1440b287f",
- "successor": "80d7549af24e9a6bdfc32cefe0536d6528d665cc8e65859ef4cff87270f3db8d9b95aaecc167e10c9b5be9ce3ab36d8d880c3a518e1c5eb899ca9d95af24e9db"
- },
- {
- "witness_event_verification_hash": "67e187411f1e514f232ae2858168da29b15ddfd07523e7a7618bfbf91c583f54fe8e850146120539a92a63ce6138f96599fb8a46ed492e428fe6fde9b9ea82ae",
- "depth": "2",
- "left_leaf": "80d7549af24e9a6bdfc32cefe0536d6528d665cc8e65859ef4cff87270f3db8d9b95aaecc167e10c9b5be9ce3ab36d8d880c3a518e1c5eb899ca9d95af24e9db",
- "right_leaf": "f4e189a08b486253ea0a5cc7bf7150055e738898115c4caf00e45634d6925539d51852409d1fe9108469e9b15668b940f3369300bb27cc292d1fabc0c07cd593",
- "successor": "e227dd97e5166364483b41f058f0d176e3a50a7510299038b09ae3aef2cbafb26c787afad82563a945b433fa2d1279af3535755235ab69d6e5ab089179177c14"
- },
- {
- "witness_event_verification_hash": "67e187411f1e514f232ae2858168da29b15ddfd07523e7a7618bfbf91c583f54fe8e850146120539a92a63ce6138f96599fb8a46ed492e428fe6fde9b9ea82ae",
- "depth": "1",
- "left_leaf": "e227dd97e5166364483b41f058f0d176e3a50a7510299038b09ae3aef2cbafb26c787afad82563a945b433fa2d1279af3535755235ab69d6e5ab089179177c14",
- "right_leaf": "780f3eb08f24022be4463be141bcda6a33a157cd0fd44cf209312b8427ac4036637a63d239526555128a4e7f4bb588ebfdbd8a8cc7d797038e29b852a4fae26c",
- "successor": "f3bd4e82b1e3d304005a7ddf4ab940f3e4e1cf099ca1c058454c431ed3feb0674c044e53150eb5691073ba58a3491565f72f6a6c2a24562ea080b569b4496c9f"
- },
- {
- "witness_event_verification_hash": "67e187411f1e514f232ae2858168da29b15ddfd07523e7a7618bfbf91c583f54fe8e850146120539a92a63ce6138f96599fb8a46ed492e428fe6fde9b9ea82ae",
- "depth": "0",
- "left_leaf": "f3bd4e82b1e3d304005a7ddf4ab940f3e4e1cf099ca1c058454c431ed3feb0674c044e53150eb5691073ba58a3491565f72f6a6c2a24562ea080b569b4496c9f",
- "right_leaf": "4a0c120fbdd6219b774eb2cb2076f4050d606b621e384c3ec645be0e5dbcdac3132f1f2acb531fa5ff62429907b77cf8d29a760be3765eb4decd83949a2925f8",
- "successor": "14f26d7dc0be77afff9131c03cab39a2fa9e1270c6face3fdc35b9b4b4ac4550d048c356a4713568c42411c3e7fe3553ec7b993c9bd7da97cb976e843d7e4d29"
- }
- ]
- }
-}
-```
-
-### 2nd Revision
-This revision entangles all data fields of the previous revision. As the
-calculation of the revision_verification hash depends on the revision of the
-previous revision, it is shown in verification_context.
-
-```json
-{
- "verification_context": {
- "has_previous_signature": true,
- "has_previous_witness": true
- },
- "content": {
- "rev_id": 362,
- "content": {
- "main": "First revision text",
- "signature-slot": "[\n {\n \"user\": \"0xa2026582b94feb9124231fbf7b052c39218954c2\",\n \"timestamp\": \"20220116090439\"\n }\n]",
- "transclusion-hashes": ""
- },
- "content_hash": "9732084a45fd344d63687ccf9b5cd942f99ffe1debd11622b05d0cd24a2de3e5608d5f5121bdd7559c0a2d39067f9258c4f9612e44728df2e8d9026a88ed650c"
- },
- "metadata": {
- "domain_id": "acfa9f682e",
- "time_stamp": "20220116090439",
- "previous_verification_hash": "9dab72c7635043452958c4cc2902f48ef7c4ae437058280197c6a2736ab9635f799cbf190d9d07dd76589055a8ad64e61c6bebd1487994207d4cb7918b471f57",
- "metadata_hash": "8df483539e2f81e64c9b9df0c7e13ae7778947b5defef860fbaed1260eade794999839bb254ea5006a5d4b6a89a37980ab576dc546d6336518d65b80bf2a5cb5",
- "verification_hash": "296347471b33f3d3c69cc6e0699d80b4cb68ffc79c3ecce96beb659fa324fab1de7a888932fbfb7c60bb8cc83c9445ce15532987a7b59440cada649681618293"
- },
- "signature": {
- "signature": "",
- "public_key": "",
- "wallet_address": "",
- "signature_hash": ""
- },
- "witness": null
-}
-```
-
-### 3rd Revision
-This revision features a transclusion-hash for an immutable link to another
-revision.
-
-```json
-{
- "verification_context": {
- "has_previous_signature": false,
- "has_previous_witness": false
- },
- "content": {
- "rev_id": 363,
- "content": {
- "main": "First revision text\n\n[[File:Logo_inblockio.png]]",
- "signature-slot": "[\n {\n \"user\": \"0xa2026582b94feb9124231fbf7b052c39218954c2\",\n \"timestamp\": \"20220116090439\"\n }\n]",
- "transclusion-hashes": "[{\"dbkey\":\"Logo_inblockio.png\",\"ns\":6,\"verification_hash\":\"9b2b3cafb90a07433a2b61885a9e64641a99b1e9024cf53b640501d3706b142fed7bc372300973137ef9d92584fac70976c3889d5610abcfe1f187c248263a56\"}]"
- },
- "content_hash": "14b8256ccd5fa1d883983317f92f428eadb52f699f476b9be69f14c6892b41979ff7b5b7a7a978177985d6aaa0bcfd9857a2646aedc4cbb3299373daa647814b"
- },
- "metadata": {
- "domain_id": "acfa9f682e",
- "time_stamp": "20220116090556",
- "previous_verification_hash": "296347471b33f3d3c69cc6e0699d80b4cb68ffc79c3ecce96beb659fa324fab1de7a888932fbfb7c60bb8cc83c9445ce15532987a7b59440cada649681618293",
- "metadata_hash": "09688c05a83bb74bb255fb0c571cb6314b65f5b7f00750547a2c43f4959d4702ae2aec019c6fb4b0e5d23adea87fd456b0eaffc6ae271163a1fa45b4bae54230",
- "verification_hash": "b35894d74dfcf8b41ff95eed97705e1acf9081021e0d478d8645cb04b8a0b4a013ee8f7fb6e140d149f2c92f20bba984fad5535938a5e36ae6a799a18343b806"
- },
- "signature": {
- "signature": "",
- "public_key": "",
- "wallet_address": "",
- "signature_hash": ""
- },
- "witness": null
-}
-```
-
-# API Endpoints
-
-The AQP provides 3 API endpoints which return data from a host that runs the
-AQP:
-
-## Get Hash Chain
-`/get_hash_chain_info/{identifier}?identifier=`
-Input:
-- `identifier_type`: the value must either be "title" or "genesis_hash"
-- `identifier`: the title or genesis_hash string, e.g. "Main Page" or "02c3c2...215d8d"
-Returns: all context for the requested hash_chain.
-
-Example:
-
-API Request:
-`/get_hash_chain_info/genesis_hash?identifier=dffd37be12adc9e774b51aa712f7c5bfc09f48b083540d8ca55f91f317e8685bf09daf004f7c841e53732b8c7992de3f3b9b79350d13570c3b46803ba5119c26`
-
-API Response:
-```json
-{
- "genesis_hash": "dffd37be12adc9e774b51aa712f7c5bfc09f48b083540d8ca55f91f317e8685bf09daf004f7c841e53732b8c7992de3f3b9b79350d13570c3b46803ba5119c26",
- "domain_id": "acfa9f682e",
- "latest_verification_hash": "2554fb53531f4de26ff3ad1fb8c61feea6ea47c3f13c4abda385c46ef8541361f7eee42433050281714a3900115f04fe52b5a8d781a71c4c439c5de6b91cbe3c",
- "site_info": {
- "sitename": "Personal Knowledge Container",
- "dbname": "my_wiki",
- "base": "http://localhost:9352/index.php/Aqua",
- "generator": "MediaWiki 1.37.1",
- "case": "first-letter",
- "namespaces": {
- "0": {
- "case": true,
- "title": ""
- },
- "6942": {
- "case": true,
- "title": "Data Accounting"
- }
- },
- "version": "0.3.0"
- },
- "title": "Aqua",
- "namespace": 0,
- "chain_height": 3
-}
-```
-
-## Get Revision Hashes
-`/get_revision_hashes/{verification_hash}`
-Input:
-- `verification_hash`
-Returns: the revision requested if it exists and/or a list of any newer
-revision than the one requested.
-
-Example:
-
-API Request:
-`/get_revision_hashes/dffd37be12adc9e774b51aa712f7c5bfc09f48b083540d8ca55f91f317e8685bf09daf004f7c841e53732b8c7992de3f3b9b79350d13570c3b46803ba5119c26`
-
-API Response:
-```json
-[
- "dffd37be12adc9e774b51aa712f7c5bfc09f48b083540d8ca55f91f317e8685bf09daf004f7c841e53732b8c7992de3f3b9b79350d13570c3b46803ba5119c26",
- "f483d7746f67e7099099bcfa8ea5a93148251c598857e8fad21ce842da62794467067802ef9e818d240cd3312a3346a769f363145a87bfc1eeae19fe8d21b328",
- "2554fb53531f4de26ff3ad1fb8c61feea6ea47c3f13c4abda385c46ef8541361f7eee42433050281714a3900115f04fe52b5a8d781a71c4c439c5de6b91cbe3c"
-]
-```
-
-## Get Revision
-`/get_revision/{verification_hash}`
-Input:
-- `verification_hash`
-Returns: the revision content together with its verification data
-
-Example: See example above.
-
-API Request: `/get_revision/dffd37be12adc9e774b51aa712f7c5bfc09f48b083540d8ca55f91f317e8685bf09daf004f7c841e53732b8c7992de3f3b9b79350d13570c3b46803ba5119c26`
-
-# Verification Process
-
-The verification process is a redo of the verification data generation
-process, and additionally a comparison of their results.
-
-**Verification of Content**
-
-All hashes are recalculated in a separate client implementation, and
-compared with the ones sent via the API. If the data was not altered or
-corrupted; nor was there a difference in the process to calculate the
-hash, they will match. This will create a high level of assurance that
-the integrity and history of the portable hash chain in question has not been
-altered.
-
-**Verification of Account**
-
-We cryptographically verify that the revision signature is indeed generated by the account specified in the verification data.
-
-**Verification of Time**
-
-To verify that the witness event included in a revision is correct, a
-lookup and comparison of the `witness_event_verification_hash` on-chain is
-performed and compared with the recalculated event.
-
-**Reference Implementation**
-
-| | |
-|------------------------------------|--------------------------------------------------------------------|
-| Command-Line-Verification-Tool | [https://github.com/inblockio/aqua-verifier-js](https://github.com/inblockio/aqua-verifier-js) |
-| Chrome Extension Verification Tool | [https://github.com/inblockio/aqua-verifier-webextension](https://github.com/inblockio/aqua-verifier-webextension) |
-
-
-
-
-# Appendix
-
-The following content is informational and not part of the
-specification. It should help to better understand utility, context and
-services which can be built on top of AQP.
-
-## Aqua Protocol v1.1 Changes
-
-Moving over to revision based verification. This allows:
-
-- Bulk / in parallel verification; ensuring logarithmic verification
- times, not linear increasing verification times with longer history.
- In short: Much faster and scalable.
-- Single revision and range verification (you want to verify a
- specific part of the content-chain)
- - This is useful for verification of identity claims, where
- trusted parties have signed the claim and for the validator it's
- sufficient to see that signature.
-- This allows direct verification after every edit via the Guardian.
- This is the preparation in the interaction to provide services
- through the [Guardian](guardian.md).
-- Changing the design to include transclusions e.g. this allows the
- verification of subpages via their stateful links /
- revision_verification_hashes
- - This also allows the inclusion of media files in the
- verification process
- - You can upload pictures, PDF's, Word-Documents and have them
- automatically included in the aqua protocol and therefore in the
- verified data-structure
-- Introduction of verification_context which indicates if the previous
- revision has signature or witness data, or if the current revision
- has transcluded resources. This will build the correct verification
- structure before verification.
-
-Change in the data-structure:
-
-- when requesting a revision this is done via the
- GetRevisionHandler.php
-- the previous verification hash is always served as well
-- if signature or witness data is present in the previous revision,
- there is a flag (1/0) that this revision depends on the previous
- revision
-- transcluded resources will be added to the content hash for
- verification
-
-## Data Accounting Protocol v1.2 \[TBD\]
-
-- Generalization of the Signature-Metadata to inform which signature
- method was used.
- - GPG Signatures
- - BTC Wallet Signatures
- - Ethereum Wallet Signatures
- - Done by: Displaying method used for signing, displaying
- underlying architecture.
-- Including Account as part of the verified data structure
-- Defining maximum payload size per revision
-
-## Services on AQP (Not yet implemented, exploration)
-
-- AQP-DACS: [Domain](#domain) Access Control System
- - See: [Guardian](guardian.md) (Acting similar to a WebApplication-Firewall)
-
-- ANS: Name-System and Name-Registry.
- - See [Aqua Name Resolution](aqua-name-resolution.md)
-
-- AQP-SSI: Self-Sovereign-Identity Protocol for [Identity
- Claim](aqua-identity-protocol.md#self-issued-identity-claims) management
- - See [Aqua Identity Protocol](aqua-identity-protocol.md)
-
-- AQP Delegated Witnessing
- - See [Delegated Witnessing](delegated-witnessing.md)
-
-## Similar Projects
-
-None of the listed projects apply the concepts of versioning to their documents,
-the concept of portable hash chains, the concept of personal data vaults for data
-management in comparison with the AQP reference implementation.
-
-This following list is not exhaustive:
-- [Surety](http://surety.com/)
- The oldest blockchain-like timestamping service which has been publishing
- to the New York Times since 1995.
-- [OpenTimestamp](https://opentimestamps.org/)
- A free and open-source service provided by Peter Todd using the Bitcoin
- network as a distributed cryptographic clock. The AQP MAY use OpenTimestamp
- as a witness network.
-- [OriginStamp](https://originstamp.com/)
- A company providing paid timestamping services for their customers.
- It looks very similar to OpenTimestamps with open-source client libraries.
-- [Factom Protocol](https://www.factomprotocol.org/)
- A service which creates an architecture with an extra layer of blockchain,
- to provide an extra layer of trusted parties while providing their own
- token. In our opinion, it introduces unnecessary complexity and
- intermediaries as dependencies compared to the AQP.
-- [OpenAttestation](https://www.openattestation.com/)
- An implementation of a timestamping service for document certification. One
- application of it is for secure digital vaccination certificates by the
- Singaporean government. They use the MetaMask Ethereum wallet for signing
- documents making it the most similar project to AQP to our knowledge.
-
-## Blockchain Context
-
-DISCLAIMER: AQP is not a permissionless distributed ledger. In order for the
-AQP to be valuable and working, a single node implementation and single node
-deployments are sufficient, and do not require the witnessing part. The AQP MAY
-benefit from being published to a distributed ledger technology (DLT)) to
-achieve a witness event with high transaction security. AQP does not have a
-token nor is it distributing data by default.
-
-As some concepts are very similar as those used in DLT's, please refer to the
-following:
-
-A portable hash chain and its revisions are similar to a blockchain structure
-and its blocks, which has its own root hash and a set of transactions which
-are included inside.
-
-| **Blockchain Term** | **AQP Term** | **Explanation** |
-|----------------------|--------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| **Transaction** | **Input Data** | In a blockchain, it's a signed transaction. In AQP, it's all the input data provided to calculate the respective content slot hashes. |
-| **Block** | **Revision** | A block contains the Merklized list of transactions. A revision contains various hashed data inputs such as: |
-| | | - Content slots |
-| | | - Metadata data |
-| | | - Signature data |
-| | | - Witness data |
-| **Genesis Block** | **Genesis Revision** | The first object in the hash chain/blockchain. |
-| **Blockchain** | **Hash Chain** | The hash chain is not distributed but resides by default only in the local PKC. It is not a distributed ledger and lacks a consensus algorithm to create a shared truth between nodes. |
-
-
-### A side note
-
-It has not escaped our notice that the provided AQP improves the existing
-process of double-entry bookkeeping and provides a foundation for a new data
-economy. This also allows to create unforgeable invoices which can be clearly
-attributed to its sender, avoiding fraud. This is one of many other use cases,
-e.g. providing trusted news via revision-controlled journalism.
diff --git a/docusaurus.config.ts b/docusaurus.config.ts
deleted file mode 100644
index 28941617..00000000
--- a/docusaurus.config.ts
+++ /dev/null
@@ -1,161 +0,0 @@
-import { themes as prismThemes } from 'prism-react-renderer';
-import type { Config } from '@docusaurus/types';
-import type * as Preset from '@docusaurus/preset-classic';
-
-// This runs in Node.js - Don't use client-side code here (browser APIs, JSX...)
-
-const config: Config = {
- title: 'AQUA Protocol',
- tagline: 'Account & Verify data in seconds using Aqua Protocol.',
- favicon: 'img/favicon.ico',
-
- // Set the production url of your site here
- url: 'https://aqua-protocol.org/',
- // Set the /<baseUrl>/ pathname under which your site is served
- // For GitHub pages deployment, it is often '/<projectName>/'
- baseUrl: '/',
-
- // GitHub pages deployment config.
- // If you aren't using GitHub pages, you don't need these.
- organizationName: 'inblockio', // Usually your GitHub org/user name.
- projectName: 'AQUA PKC', // Usually your repo name.
-
- onBrokenLinks: 'warn',
- onBrokenMarkdownLinks: 'warn',
-
- // Even if you don't use internationalization, you can use this field to set
- // useful metadata like html lang. For example, if your site is Chinese, you
- // may want to replace "en" with "zh-Hans".
- i18n: {
- defaultLocale: 'en',
- locales: ['en'],
- },
-
- presets: [
- [
- 'classic',
- {
- docs: {
- sidebarPath: './sidebars.ts',
- // Please change this to your repo.
- // Remove this to remove the "edit this page" links.
- editUrl:
- 'https://github.com/inblockio',
- lastVersion: '1.3.2',
- versions: {
- '1.3.2': {
- label: 'v3',
- path: 'v3',
- banner: 'none',
- },
- '1.2.0': {
- label: 'v2',
- path: 'v2',
- banner: 'none',
- },
- '1.1.0': {
- label: 'v1',
- path: 'v1',
- banner: 'none',
- },
- }
- },
- blog: {
- showReadingTime: true,
- feedOptions: {
- type: ['rss', 'atom'],
- xslt: true,
- },
- // Please change this to your repo.
- // Remove this to remove the "edit this page" links.
- editUrl:
- 'https://github.com/inblockio',
- // Useful options to enforce blogging best practices
- onInlineTags: 'warn',
- onInlineAuthors: 'warn',
- onUntruncatedBlogPosts: 'warn',
- },
- theme: {
- customCss: './src/css/custom.css',
- },
- } satisfies Preset.Options,
- ],
- ],
-
- themeConfig: {
- // Replace with your project's social card
- image: '/featured-background.png',
- navbar: {
- title: 'Aqua Protocol',
- logo: {
- alt: 'Aqua Protocol',
- src: '/favicons/android-192x192.png',
- },
- items: [
- {
- type: 'docSidebar',
- sidebarId: 'tutorialSidebar',
- position: 'right',
- label: 'Documentation',
- href: "/docs/v3/intro"
- },
- {
- href: '/community',
- label: 'Community',
- position: 'right',
- },
- {
- href: 'https://github.com/inblockio',
- label: 'GitHub',
- position: 'right',
- },
- {
- type: 'docsVersionDropdown',
- },
- ],
- },
- footer: {
- style: 'dark',
- links: [
- {
- title: 'Documentation',
- items: [
- {
- label: 'Docs',
- to: '/docs/v3/intro',
- },
- ],
- },
- {
- title: 'Community',
- items: [
- //{
- // label: 'Matrix',
- // href: 'https://matrix.org',
- //},
- {
- label: 'X',
- href: 'https://github.com/inblockio',
- },
- ],
- },
- {
- title: 'More',
- items: [
- {
- label: 'GitHub',
- href: 'https://github.com/inblockio',
- },
- ],
- },
- ],
- copyright: `© ${new Date().getFullYear()} AQUA Protocol. All right reserved.`,
- },
- prism: {
- theme: prismThemes.github,
- darkTheme: prismThemes.dracula,
- },
- } satisfies Preset.ThemeConfig,
-};
-
-export default config;
diff --git a/essentials/code.mdx b/essentials/code.mdx
new file mode 100644
index 00000000..ae2abbfe
--- /dev/null
+++ b/essentials/code.mdx
@@ -0,0 +1,35 @@
+---
+title: 'Code blocks'
+description: 'Display inline code and code blocks'
+icon: 'code'
+---
+
+## Inline code
+
+To denote a `word` or `phrase` as code, enclose it in backticks (`).
+
+```
+To denote a `word` or `phrase` as code, enclose it in backticks (`).
+```
+
+## Code blocks
+
+Use [fenced code blocks](https://www.markdownguide.org/extended-syntax/#fenced-code-blocks) by enclosing code in three backticks and follow the leading ticks with the programming language of your snippet to get syntax highlighting. Optionally, you can also write the name of your code after the programming language.
+
+```java HelloWorld.java
+class HelloWorld {
+ public static void main(String[] args) {
+ System.out.println("Hello, World!");
+ }
+}
+```
+
+````md
+```java HelloWorld.java
+class HelloWorld {
+ public static void main(String[] args) {
+ System.out.println("Hello, World!");
+ }
+}
+```
+````
diff --git a/essentials/images.mdx b/essentials/images.mdx
new file mode 100644
index 00000000..1144eb2c
--- /dev/null
+++ b/essentials/images.mdx
@@ -0,0 +1,59 @@
+---
+title: 'Images and embeds'
+description: 'Add image, video, and other HTML elements'
+icon: 'image'
+---
+
+<img
+ style={{ borderRadius: '0.5rem' }}
+ src="https://mintlify-assets.b-cdn.net/bigbend.jpg"
+/>
+
+## Image
+
+### Using Markdown
+
+The [markdown syntax](https://www.markdownguide.org/basic-syntax/#images) lets you add images using the following code
+
+```md
+
+```
+
+Note that the image file size must be less than 5MB. Otherwise, we recommend hosting on a service like [Cloudinary](https://cloudinary.com/) or [S3](https://aws.amazon.com/s3/). You can then use that URL and embed.
+
+### Using embeds
+
+To get more customizability with images, you can also use [embeds](/writing-content/embed) to add images
+
+```html
+<img height="200" src="/path/image.jpg" />
+```
+
+## Embeds and HTML elements
+
+<iframe
+ width="560"
+ height="315"
+ src="https://www.youtube.com/embed/4KzFe50RQkQ"
+ title="YouTube video player"
+ frameBorder="0"
+ allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"
+ allowFullScreen
+ style={{ width: '100%', borderRadius: '0.5rem' }}
+></iframe>
+
+<br />
+
+<Tip>
+
+Mintlify supports [HTML tags in Markdown](https://www.markdownguide.org/basic-syntax/#html). This is helpful if you prefer HTML tags to Markdown syntax, and lets you create documentation with infinite flexibility.
+
+</Tip>
+
+### iFrames
+
+Loads another HTML page within the document. Most commonly used for embedding videos.
+
+```html
+<iframe src="https://www.youtube.com/embed/4KzFe50RQkQ"> </iframe>
+```
diff --git a/essentials/markdown.mdx b/essentials/markdown.mdx
new file mode 100644
index 00000000..a45c1d56
--- /dev/null
+++ b/essentials/markdown.mdx
@@ -0,0 +1,88 @@
+---
+title: 'Markdown syntax'
+description: 'Text, title, and styling in standard markdown'
+icon: 'text-size'
+---
+
+## Titles
+
+Best used for section headers.
+
+```md
+## Titles
+```
+
+### Subtitles
+
+Best used for subsection headers.
+
+```md
+### Subtitles
+```
+
+<Tip>
+
+Each **title** and **subtitle** creates an anchor and also shows up on the table of contents on the right.
+
+</Tip>
+
+## Text formatting
+
+We support most markdown formatting. Simply add `**`, `_`, or `~` around text to format it.
+
+| Style | How to write it | Result |
+| ------------- | ----------------- | --------------- |
+| Bold | `**bold**` | **bold** |
+| Italic | `_italic_` | _italic_ |
+| Strikethrough | `~strikethrough~` | ~strikethrough~ |
+
+You can combine these. For example, write `**_bold and italic_**` to get **_bold and italic_** text.
+
+You need to use HTML to write superscript and subscript text. That is, add `<sup>` or `<sub>` around your text.
+
+| Text Size | How to write it | Result |
+| ----------- | ------------------------ | ---------------------- |
+| Superscript | `<sup>superscript</sup>` | <sup>superscript</sup> |
+| Subscript | `<sub>subscript</sub>` | <sub>subscript</sub> |
+
+## Linking to pages
+
+You can add a link by wrapping text in `[]()`. You would write `[link to google](https://google.com)` to [link to google](https://google.com).
+
+Links to pages in your docs need to be root-relative. Basically, you should include the entire folder path. For example, `[link to text](/writing-content/text)` links to the page "Text" in our components section.
+
+Relative links like `[link to text](../text)` will open slower because we cannot optimize them as easily.
+
+## Blockquotes
+
+### Singleline
+
+To create a blockquote, add a `>` in front of a paragraph.
+
+> Dorothy followed her through many of the beautiful rooms in her castle.
+
+```md
+> Dorothy followed her through many of the beautiful rooms in her castle.
+```
+
+### Multiline
+
+> Dorothy followed her through many of the beautiful rooms in her castle.
+>
+> The Witch bade her clean the pots and kettles and sweep the floor and keep the fire fed with wood.
+
+```md
+> Dorothy followed her through many of the beautiful rooms in her castle.
+>
+> The Witch bade her clean the pots and kettles and sweep the floor and keep the fire fed with wood.
+```
+
+### LaTeX
+
+Mintlify supports [LaTeX](https://www.latex-project.org) through the Latex component.
+
+<Latex>8 x (vk x H1 - H2) = (0,1)</Latex>
+
+```md
+<Latex>8 x (vk x H1 - H2) = (0,1)</Latex>
+```
diff --git a/essentials/navigation.mdx b/essentials/navigation.mdx
new file mode 100644
index 00000000..60adeff2
--- /dev/null
+++ b/essentials/navigation.mdx
@@ -0,0 +1,87 @@
+---
+title: 'Navigation'
+description: 'The navigation field in docs.json defines the pages that go in the navigation menu'
+icon: 'map'
+---
+
+The navigation menu is the list of links on every website.
+
+You will likely update `docs.json` every time you add a new page. Pages do not show up automatically.
+
+## Navigation syntax
+
+Our navigation syntax is recursive which means you can make nested navigation groups. You don't need to include `.mdx` in page names.
+
+<CodeGroup>
+
+```json Regular Navigation
+"navigation": {
+ "tabs": [
+ {
+ "tab": "Docs",
+ "groups": [
+ {
+ "group": "Getting Started",
+ "pages": ["quickstart"]
+ }
+ ]
+ }
+ ]
+}
+```
+
+```json Nested Navigation
+"navigation": {
+ "tabs": [
+ {
+ "tab": "Docs",
+ "groups": [
+ {
+ "group": "Getting Started",
+ "pages": [
+ "quickstart",
+ {
+ "group": "Nested Reference Pages",
+ "pages": ["nested-reference-page"]
+ }
+ ]
+ }
+ ]
+ }
+ ]
+}
+```
+
+</CodeGroup>
+
+## Folders
+
+Simply put your MDX files in folders and update the paths in `docs.json`.
+
+For example, to have a page at `https://yoursite.com/your-folder/your-page` you would make a folder called `your-folder` containing an MDX file called `your-page.mdx`.
+
+<Warning>
+
+You cannot use `api` for the name of a folder unless you nest it inside another folder. Mintlify uses Next.js which reserves the top-level `api` folder for internal server calls. A folder name such as `api-reference` would be accepted.
+
+</Warning>
+
+```json Navigation With Folder
+"navigation": {
+ "tabs": [
+ {
+ "tab": "Docs",
+ "groups": [
+ {
+ "group": "Group Name",
+ "pages": ["your-folder/your-page"]
+ }
+ ]
+ }
+ ]
+}
+```
+
+## Hidden pages
+
+MDX files not included in `docs.json` will not show up in the sidebar but are accessible through the search bar and by linking directly to them.
diff --git a/essentials/reusable-snippets.mdx b/essentials/reusable-snippets.mdx
new file mode 100644
index 00000000..376e27bd
--- /dev/null
+++ b/essentials/reusable-snippets.mdx
@@ -0,0 +1,110 @@
+---
+title: "Reusable snippets"
+description: "Reusable, custom snippets to keep content in sync"
+icon: "recycle"
+---
+
+import SnippetIntro from '/snippets/snippet-intro.mdx';
+
+<SnippetIntro />
+
+## Creating a custom snippet
+
+**Pre-condition**: You must create your snippet file in the `snippets` directory.
+
+<Note>
+ Any page in the `snippets` directory will be treated as a snippet and will not
+ be rendered into a standalone page. If you want to create a standalone page
+ from the snippet, import the snippet into another file and call it as a
+ component.
+</Note>
+
+### Default export
+
+1. Add content to your snippet file that you want to re-use across multiple
+ locations. Optionally, you can add variables that can be filled in via props
+ when you import the snippet.
+
+```mdx snippets/my-snippet.mdx
+Hello world! This is my content I want to reuse across pages. My keyword of the
+day is {word}.
+```
+
+<Warning>
+ The content that you want to reuse must be inside the `snippets` directory in
+ order for the import to work.
+</Warning>
+
+2. Import the snippet into your destination file.
+
+```mdx destination-file.mdx
+---
+title: My title
+description: My Description
+---
+
+import MySnippet from '/snippets/path/to/my-snippet.mdx';
+
+## Header
+
+Lorem impsum dolor sit amet.
+
+<MySnippet word="bananas" />
+```
+
+### Reusable variables
+
+1. Export a variable from your snippet file:
+
+```mdx snippets/path/to/custom-variables.mdx
+export const myName = 'my name';
+
+export const myObject = { fruit: 'strawberries' };
+```
+
+2. Import the snippet from your destination file and use the variable:
+
+```mdx destination-file.mdx
+---
+title: My title
+description: My Description
+---
+
+import { myName, myObject } from '/snippets/path/to/custom-variables.mdx';
+
+Hello, my name is {myName} and I like {myObject.fruit}.
+```
+
+### Reusable components
+
+1. Inside your snippet file, create a component that takes in props by exporting
+ your component in the form of an arrow function.
+
+```mdx snippets/custom-component.mdx
+export const MyComponent = ({ title }) => (
+ <div>
+ <h1>{title}</h1>
+ <p>... snippet content ...</p>
+ </div>
+);
+```
+
+<Warning>
+ MDX does not compile inside the body of an arrow function. Stick to HTML
+ syntax when you can or use a default export if you need to use MDX.
+</Warning>
+
+2. Import the snippet into your destination file and pass in the props
+
+```mdx destination-file.mdx
+---
+title: My title
+description: My Description
+---
+
+import { MyComponent } from '/snippets/custom-component.mdx';
+
+Lorem ipsum dolor sit amet.
+
+<MyComponent title={'Custom title'} />
+```
diff --git a/essentials/settings.mdx b/essentials/settings.mdx
new file mode 100644
index 00000000..884de13a
--- /dev/null
+++ b/essentials/settings.mdx
@@ -0,0 +1,318 @@
+---
+title: 'Global Settings'
+description: 'Mintlify gives you complete control over the look and feel of your documentation using the docs.json file'
+icon: 'gear'
+---
+
+Every Mintlify site needs a `docs.json` file with the core configuration settings. Learn more about the [properties](#properties) below.
+
+## Properties
+
+<ResponseField name="name" type="string" required>
+Name of your project. Used for the global title.
+
+Example: `mintlify`
+
+</ResponseField>
+
+<ResponseField name="navigation" type="Navigation[]" required>
+ An array of groups with all the pages within that group
+ <Expandable title="Navigation">
+ <ResponseField name="group" type="string">
+ The name of the group.
+
+ Example: `Settings`
+
+ </ResponseField>
+ <ResponseField name="pages" type="string[]">
+ The relative paths to the markdown files that will serve as pages.
+
+ Example: `["customization", "page"]`
+
+ </ResponseField>
+
+ </Expandable>
+</ResponseField>
+
+<ResponseField name="logo" type="string or object">
+ Path to logo image or object with path to "light" and "dark" mode logo images
+ <Expandable title="Logo">
+ <ResponseField name="light" type="string">
+ Path to the logo in light mode
+ </ResponseField>
+ <ResponseField name="dark" type="string">
+ Path to the logo in dark mode
+ </ResponseField>
+ <ResponseField name="href" type="string" default="/">
+ Where clicking on the logo links you to
+ </ResponseField>
+ </Expandable>
+</ResponseField>
+
+<ResponseField name="favicon" type="string">
+ Path to the favicon image
+</ResponseField>
+
+<ResponseField name="colors" type="Colors">
+ Hex color codes for your global theme
+ <Expandable title="Colors">
+ <ResponseField name="primary" type="string" required>
+ The primary color. Used for most often for highlighted content, section
+ headers, accents, in light mode
+ </ResponseField>
+ <ResponseField name="light" type="string">
+ The primary color for dark mode. Used for most often for highlighted
+ content, section headers, accents, in dark mode
+ </ResponseField>
+ <ResponseField name="dark" type="string">
+ The primary color for important buttons
+ </ResponseField>
+ <ResponseField name="background" type="object">
+ The color of the background in both light and dark mode
+ <Expandable title="Object">
+ <ResponseField name="light" type="string" required>
+ The hex color code of the background in light mode
+ </ResponseField>
+ <ResponseField name="dark" type="string" required>
+ The hex color code of the background in dark mode
+ </ResponseField>
+ </Expandable>
+ </ResponseField>
+ </Expandable>
+</ResponseField>
+
+<ResponseField name="topbarLinks" type="TopbarLink[]">
+ Array of `name`s and `url`s of links you want to include in the topbar
+ <Expandable title="TopbarLink">
+ <ResponseField name="name" type="string">
+ The name of the button.
+
+ Example: `Contact us`
+ </ResponseField>
+ <ResponseField name="url" type="string">
+ The url once you click on the button. Example: `https://mintlify.com/docs`
+ </ResponseField>
+
+ </Expandable>
+</ResponseField>
+
+<ResponseField name="topbarCtaButton" type="Call to Action">
+ <Expandable title="Topbar Call to Action">
+ <ResponseField name="type" type={'"link" or "github"'} default="link">
+ Link shows a button. GitHub shows the repo information at the url provided including the number of GitHub stars.
+ </ResponseField>
+ <ResponseField name="url" type="string">
+ If `link`: What the button links to.
+
+ If `github`: Link to the repository to load GitHub information from.
+ </ResponseField>
+ <ResponseField name="name" type="string">
+ Text inside the button. Only required if `type` is a `link`.
+ </ResponseField>
+
+ </Expandable>
+</ResponseField>
+
+<ResponseField name="versions" type="string[]">
+ Array of version names. Only use this if you want to show different versions
+ of docs with a dropdown in the navigation bar.
+</ResponseField>
+
+<ResponseField name="anchors" type="Anchor[]">
+ An array of the anchors, includes the `icon`, `color`, and `url`.
+ <Expandable title="Anchor">
+ <ResponseField name="icon" type="string">
+ The [Font Awesome](https://fontawesome.com/search?q=heart) icon used to feature the anchor.
+
+ Example: `comments`
+ </ResponseField>
+ <ResponseField name="name" type="string">
+ The name of the anchor label.
+
+ Example: `Community`
+ </ResponseField>
+ <ResponseField name="url" type="string">
+ The start of the URL that marks what pages go in the anchor. Generally, this is the name of the folder you put your pages in.
+ </ResponseField>
+ <ResponseField name="color" type="string">
+ The hex color of the anchor icon background. Can also be a gradient if you pass an object with the properties `from` and `to` that are each a hex color.
+ </ResponseField>
+ <ResponseField name="version" type="string">
+ Used if you want to hide an anchor until the correct docs version is selected.
+ </ResponseField>
+ <ResponseField name="isDefaultHidden" type="boolean" default="false">
+ Pass `true` if you want to hide the anchor until you directly link someone to docs inside it.
+ </ResponseField>
+ <ResponseField name="iconType" default="duotone" type="string">
+ One of: "brands", "duotone", "light", "sharp-solid", "solid", or "thin"
+ </ResponseField>
+
+ </Expandable>
+</ResponseField>
+
+<ResponseField name="topAnchor" type="Object">
+ Override the default configurations for the top-most anchor.
+ <Expandable title="Object">
+ <ResponseField name="name" default="Documentation" type="string">
+ The name of the top-most anchor
+ </ResponseField>
+ <ResponseField name="icon" default="book-open" type="string">
+ Font Awesome icon.
+ </ResponseField>
+ <ResponseField name="iconType" default="duotone" type="string">
+ One of: "brands", "duotone", "light", "sharp-solid", "solid", or "thin"
+ </ResponseField>
+ </Expandable>
+</ResponseField>
+
+<ResponseField name="tabs" type="Tabs[]">
+ An array of navigational tabs.
+ <Expandable title="Tabs">
+ <ResponseField name="name" type="string">
+ The name of the tab label.
+ </ResponseField>
+ <ResponseField name="url" type="string">
+ The start of the URL that marks what pages go in the tab. Generally, this
+ is the name of the folder you put your pages in.
+ </ResponseField>
+ </Expandable>
+</ResponseField>
+
+<ResponseField name="api" type="API">
+ Configuration for API settings. Learn more about API pages at [API Components](/api-playground/demo).
+ <Expandable title="API">
+ <ResponseField name="baseUrl" type="string">
+ The base url for all API endpoints. If `baseUrl` is an array, it will enable for multiple base url
+ options that the user can toggle.
+ </ResponseField>
+
+ <ResponseField name="auth" type="Auth">
+ <Expandable title="Auth">
+ <ResponseField name="method" type='"bearer" | "basic" | "key"'>
+ The authentication strategy used for all API endpoints.
+ </ResponseField>
+ <ResponseField name="name" type="string">
+ The name of the authentication parameter used in the API playground.
+
+ If method is `basic`, the format should be `[usernameName]:[passwordName]`
+ </ResponseField>
+ <ResponseField name="inputPrefix" type="string">
+ The default value that's designed to be a prefix for the authentication input field.
+
+ E.g. If an `inputPrefix` of `AuthKey` would inherit the default input result of the authentication field as `AuthKey`.
+ </ResponseField>
+ </Expandable>
+ </ResponseField>
+
+ <ResponseField name="playground" type="Playground">
+ Configurations for the API playground
+
+ <Expandable title="Playground">
+ <ResponseField name="mode" default="show" type='"show" | "simple" | "hide"'>
+ Whether the playground is showing, hidden, or only displaying the endpoint with no added user interactivity `simple`
+
+ Learn more at the [playground guides](/api-playground/demo)
+ </ResponseField>
+ </Expandable>
+ </ResponseField>
+
+ <ResponseField name="maintainOrder" type="boolean">
+ Enabling this flag ensures that key ordering in OpenAPI pages matches the key ordering defined in the OpenAPI file.
+
+ <Warning>This behavior will soon be enabled by default, at which point this field will be deprecated.</Warning>
+ </ResponseField>
+
+ </Expandable>
+</ResponseField>
+
+<ResponseField name="openapi" type="string | string[]">
+ A string or an array of strings of URL(s) or relative path(s) pointing to your
+ OpenAPI file.
+
+ Examples:
+ <CodeGroup>
+ ```json Absolute
+ "openapi": "https://example.com/openapi.json"
+ ```
+ ```json Relative
+ "openapi": "/openapi.json"
+ ```
+ ```json Multiple
+ "openapi": ["https://example.com/openapi1.json", "/openapi2.json", "/openapi3.json"]
+ ```
+ </CodeGroup>
+
+</ResponseField>
+
+<ResponseField name="footerSocials" type="FooterSocials">
+ An object of social media accounts where the key:property pair represents the social media platform and the account url.
+
+ Example:
+ ```json
+ {
+ "x": "https://x.com/mintlify",
+ "website": "https://mintlify.com"
+ }
+ ```
+ <Expandable title="FooterSocials">
+ <ResponseField name="[key]" type="string">
+ One of the following values `website`, `facebook`, `x`, `discord`, `slack`, `github`, `linkedin`, `instagram`, `hacker-news`
+
+ Example: `x`
+ </ResponseField>
+ <ResponseField name="property" type="string">
+ The URL to the social platform.
+
+ Example: `https://x.com/mintlify`
+ </ResponseField>
+ </Expandable>
+</ResponseField>
+
+<ResponseField name="feedback" type="Feedback">
+ Configurations to enable feedback buttons
+
+ <Expandable title="Feedback">
+ <ResponseField name="suggestEdit" type="boolean" default="false">
+ Enables a button to allow users to suggest edits via pull requests
+ </ResponseField>
+ <ResponseField name="raiseIssue" type="boolean" default="false">
+ Enables a button to allow users to raise an issue about the documentation
+ </ResponseField>
+ </Expandable>
+</ResponseField>
+
+<ResponseField name="modeToggle" type="ModeToggle">
+ Customize the dark mode toggle.
+ <Expandable title="ModeToggle">
+ <ResponseField name="default" type={'"light" or "dark"'}>
+ Set if you always want to show light or dark mode for new users. When not
+ set, we default to the same mode as the user's operating system.
+ </ResponseField>
+ <ResponseField name="isHidden" type="boolean" default="false">
+ Set to true to hide the dark/light mode toggle. You can combine `isHidden` with `default` to force your docs to only use light or dark mode. For example:
+
+ <CodeGroup>
+ ```json Only Dark Mode
+ "modeToggle": {
+ "default": "dark",
+ "isHidden": true
+ }
+ ```
+
+ ```json Only Light Mode
+ "modeToggle": {
+ "default": "light",
+ "isHidden": true
+ }
+ ```
+ </CodeGroup>
+
+ </ResponseField>
+
+ </Expandable>
+</ResponseField>
+
+<ResponseField name="backgroundImage" type="string">
+ A background image to be displayed behind every page. See example with
+ [Infisical](https://infisical.com/docs) and [FRPC](https://frpc.io).
+</ResponseField>
diff --git a/favicon.svg b/favicon.svg
new file mode 100644
index 00000000..b785c738
--- /dev/null
+++ b/favicon.svg
@@ -0,0 +1,19 @@
+<svg width="24" height="24" viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg">
+<path d="M9.06145 23.1079C5.26816 22.3769 -3.39077 20.6274 1.4173 5.06384C9.6344 6.09939 16.9728 14.0644 9.06145 23.1079Z" fill="url(#paint0_linear_17557_2021)"/>
+<path d="M8.91928 23.0939C5.27642 21.2223 0.78371 4.20891 17.0071 0C20.7569 7.19341 19.6212 16.5452 8.91928 23.0939Z" fill="url(#paint1_linear_17557_2021)"/>
+<path d="M8.91388 23.0788C8.73534 19.8817 10.1585 9.08525 23.5699 13.1107C23.1812 20.1229 18.984 26.4182 8.91388 23.0788Z" fill="url(#paint2_linear_17557_2021)"/>
+<defs>
+<linearGradient id="paint0_linear_17557_2021" x1="3.77557" y1="5.91571" x2="5.23185" y2="21.5589" gradientUnits="userSpaceOnUse">
+<stop stop-color="#18E299"/>
+<stop offset="1" stop-color="#15803D"/>
+</linearGradient>
+<linearGradient id="paint1_linear_17557_2021" x1="12.1711" y1="-0.718425" x2="10.1897" y2="22.9832" gradientUnits="userSpaceOnUse">
+<stop stop-color="#16A34A"/>
+<stop offset="1" stop-color="#4ADE80"/>
+</linearGradient>
+<linearGradient id="paint2_linear_17557_2021" x1="23.1327" y1="15.353" x2="9.33841" y2="18.5196" gradientUnits="userSpaceOnUse">
+<stop stop-color="#4ADE80"/>
+<stop offset="1" stop-color="#0D9373"/>
+</linearGradient>
+</defs>
+</svg>
diff --git a/images/checks-passed.png b/images/checks-passed.png
new file mode 100644
index 00000000..3303c773
Binary files /dev/null and b/images/checks-passed.png differ
diff --git a/images/hero-dark.png b/images/hero-dark.png
new file mode 100644
index 00000000..a61cbb12
Binary files /dev/null and b/images/hero-dark.png differ
diff --git a/images/hero-light.png b/images/hero-light.png
new file mode 100644
index 00000000..68c712d6
Binary files /dev/null and b/images/hero-light.png differ
diff --git a/index.mdx b/index.mdx
new file mode 100644
index 00000000..335c786f
--- /dev/null
+++ b/index.mdx
@@ -0,0 +1,236 @@
+---
+title: "Welcome to Aqua Protocol"
+description: "Account & verify data in seconds using cryptographic proof"
+icon: "door-open"
+---
+
+
+
+**Aqua Protocol** is an open, private, and decentralized solution for data accountability and governance. Built with modern cryptographic standards, Aqua enables you to verify data integrity and provenance without relying on centralized authorities.
+
+<Note>
+**Powered by Cryptography, Not Blockchain**
+
+Aqua Protocol is made possible by crypto—as in _cryptography_! While it can use Ethereum for timestamping, the protocol itself neither is nor requires blockchain technology. It's a privacy-preserving, open-source protocol built on modern cryptographic methods.
+
+<Badge icon="circle-check" color="green">
+ Account & Verify Data in Seconds
+</Badge>
+</Note>
+
+
+
+## What is Aqua Protocol?
+
+The Aqua Protocol is a foundational framework for building distributed trust networks. By leveraging hash-chains, cryptographic signatures, and optional blockchain timestamping, Aqua enables scalable, trustless verification of data integrity and provenance. It empowers developers and innovators to create applications that certify, attest, and secure data in an open and decentralized way.
+
+<Card
+ title="Core Idea"
+ icon="rocket"
+ href="/quickstart"
+ horizontal
+>
+ Building trust through cryptographic proof and verifiable data structures.
+</Card>
+
+Trust can be built by relying on hashing and encryption mechanisms or by delegating to a mutually trusted party. Aqua Protocol handles both scenarios, giving you flexibility in how you establish and verify trust.
+
+
+
+## How It Works
+
+At its core, Aqua creates portable hash-chains—called **AquaTrees**—that record a gapless history of data revisions. These trees can be timestamped on Ethereum for immutability, exchanged across services, and verified automatically. Whether securing documents, systems, or identities, Aqua liberates the certification process from institutional gatekeepers, making trust accessible through open cryptographic standards.
+
+### Key Features
+
+- **Tamper-Proof Records**: Cryptographic hashes ensure any modification is immediately detectable
+- **Multi-Party Signatures**: Collect signatures from multiple parties for authentication and non-repudiation
+- **Blockchain Timestamping**: Optional anchoring to Ethereum, Nostr, or TSA for provable timestamps
+- **Portable Verification**: AquaTrees can be exchanged, stored, and verified anywhere
+- **Privacy-Preserving**: Only hashes are stored on-chain, keeping your data private
+
+## Try Aquafier
+
+Want to see Aqua Protocol in action? Try **Aquafier**, our reference implementation that lets you upload, verify, and notarize any file:
+
+<CardGroup cols={2}>
+ <Card
+ title="Aquafier (Production)"
+ icon="globe"
+ href="https://aquafier.inblock.io"
+ >
+ Try the live demo - upload and notarize files instantly
+ </Card>
+
+ <Card
+ title="Aquafier (Testing)"
+ icon="flask"
+ href="https://dev.inblock.io"
+ >
+ Experiment in the development environment
+ </Card>
+</CardGroup>
+
+## Getting Started
+
+<Tip>New to Aqua Protocol? Here are the best places to start:</Tip>
+
+<CardGroup cols={2}>
+ <Card
+ title="Quick Start Guide"
+ icon="rocket"
+ href="/quickstart"
+ >
+ Get up and running with Aqua Protocol in minutes
+ </Card>
+
+ <Card
+ title="Understand the Schema"
+ icon="brain"
+ href="/schema_reference/introduction"
+ >
+ Learn about the components that make up the protocol
+ </Card>
+
+ <Card
+ title="Explore Examples"
+ icon="code"
+ href="https://github.com/inblockio/aqua-examples"
+ >
+ Browse curated examples in different programming languages
+ </Card>
+
+ <Card
+ title="Developer Tools"
+ icon="wrench"
+ href="/dev_tools/aqua_sdk"
+ >
+ Get started with our SDK, CLI, and development tools
+ </Card>
+
+ <Card
+ title="Use Cases"
+ icon="lightbulb"
+ href="/use_cases/introduction"
+ >
+ Discover real-world applications and implementation patterns
+ </Card>
+
+ <Card
+ title="View the Code"
+ icon="github"
+ href="https://github.com/inblockio"
+ >
+ Dive into the source code and contribute
+ </Card>
+</CardGroup>
+
+## The Vision of Aqua
+
+Aqua Protocol is still evolving, and we're discovering the full scope of its potential. Here's what Aqua represents:
+
+<CardGroup cols={2}>
+ <Card
+ title="An Open Framework"
+ icon="book-open"
+ >
+ Enabling private, decentralized solutions for general data notarization and verification
+ </Card>
+
+ <Card
+ title="A Verifiable Data Structure"
+ icon="shield-check"
+ >
+ Linking and certifying data with cryptographic precision through AquaTrees
+ </Card>
+
+ <Card
+ title="A Protocol for Provenance"
+ icon="fingerprint"
+ >
+ Ensuring clear attribution and integrity of data origins across systems
+ </Card>
+
+ <Card
+ title="A Foundation for Trust"
+ icon="handshake"
+ >
+ Powering distributed networks where trust is built-in, not assumed
+ </Card>
+</CardGroup>
+
+## Current Version
+
+**Aqua Protocol v4** (Beta) - Built with Rust, featuring:
+- Template system with JSON Schema validation
+- Enhanced revision types and canonicalization
+- Cross-platform support via WASM
+- Improved scalability and flexibility
+
+**Aqua Protocol v3** (Stable) - Production-ready JavaScript/TypeScript SDK
+
+<Note>
+We're excited to see where this journey takes us and invite you to explore, build, and contribute to the future of decentralized trust with Aqua Protocol!
+</Note>
+
+## Community & Contributions
+
+Aqua Protocol is open source and community-driven. We welcome:
+
+- **Feedback**: Share your thoughts and suggestions
+- **Bug Reports**: Help us improve by reporting issues
+- **Code Contributions**: Submit pull requests and improvements
+- **Documentation**: Help make Aqua more accessible
+
+<CardGroup cols={2}>
+ <Card
+ title="GitHub Repositories"
+ icon="github"
+ href="https://github.com/inblockio"
+ >
+ Browse our open-source code and contribute
+ </Card>
+
+ <Card
+ title="Example Projects"
+ icon="code-branch"
+ href="https://github.com/inblockio/aqua-examples"
+ >
+ Explore complete examples and implementation patterns
+ </Card>
+
+ <Card
+ title="Follow Updates"
+ icon="twitter"
+ href="https://x.com/inblockio"
+ >
+ Stay updated with announcements and progress
+ </Card>
+
+ <Card
+ title="Get Support"
+ icon="envelope"
+ href="mailto:info@inblock.io"
+ >
+ Need help? Reach out to our team
+ </Card>
+</CardGroup>
+
+## Next Steps
+
+Ready to dive deeper?
+
+1. **Start Building**: Follow the [Quick Start Guide](/quickstart) to create your first Aqua chain
+2. **Understand the Protocol**: Read the [Schema Reference](/schema_reference/introduction) for technical details
+3. **Explore Use Cases**: See how others are using Aqua in [real-world applications](/use_cases/introduction)
+4. **Join the Community**: Connect with developers on [GitHub](https://github.com/inblockio)
+
+---
+
+<Note>
+**Need Help?**
+
+Email us at [info@inblock.io](mailto:info@inblock.io) to talk to our team, or open an issue on GitHub for technical questions.
+</Note>
+
+
diff --git a/static/favicons/android-192x192.png b/logo/aqua-logo.png
similarity index 100%
rename from static/favicons/android-192x192.png
rename to logo/aqua-logo.png
diff --git a/logo/dark.svg b/logo/dark.svg
new file mode 100644
index 00000000..8b343cd6
--- /dev/null
+++ b/logo/dark.svg
@@ -0,0 +1,21 @@
+<svg width="177" height="24" viewBox="0 0 177 24" fill="none" xmlns="http://www.w3.org/2000/svg">
+<path d="M9.06145 23.1079C5.26816 22.3769 -3.39077 20.6274 1.4173 5.06384C9.6344 6.09939 16.9728 14.0644 9.06145 23.1079Z" fill="url(#paint0_linear_17557_2145)"/>
+<path d="M8.91928 23.0939C5.27642 21.2223 0.78371 4.20891 17.0071 0C20.7569 7.19341 19.6212 16.5452 8.91928 23.0939Z" fill="url(#paint1_linear_17557_2145)"/>
+<path d="M8.91388 23.0788C8.73534 19.8817 10.1585 9.08525 23.5699 13.1107C23.1812 20.1229 18.984 26.4182 8.91388 23.0788Z" fill="url(#paint2_linear_17557_2145)"/>
+<path d="M32.3008 19.3922V3.89432H37.9383L39.925 9.94786C40.0359 10.3154 40.1642 10.7869 40.3098 11.3624C40.4624 11.938 40.6114 12.5516 40.7571 13.2035C40.9096 13.8553 41.0483 14.4828 41.1731 15.0861C41.3049 15.6824 41.4123 16.1921 41.4955 16.6151H40.6946C40.7709 16.1921 40.8715 15.6824 40.9963 15.0861C41.128 14.4897 41.2667 13.8657 41.4123 13.2139C41.5649 12.562 41.714 11.9484 41.8596 11.3728C42.0052 10.7904 42.1335 10.3154 42.2444 9.94786L44.1999 3.89432H49.8478V19.3922H46.1657V12.7042C46.1657 12.3575 46.1726 11.9172 46.1865 11.3832C46.2004 10.8493 46.2143 10.2703 46.2281 9.64623C46.2489 9.02215 46.2663 8.39114 46.2801 7.75319C46.3009 7.11525 46.3113 6.51891 46.3113 5.96418H46.6234C46.4847 6.56052 46.3321 7.18112 46.1657 7.826C45.9993 8.47088 45.8329 9.10189 45.6665 9.71903C45.507 10.3362 45.3509 10.9013 45.1984 11.4144C45.0528 11.9276 44.928 12.3575 44.824 12.7042L42.6085 19.3922H39.5609L37.3142 12.7042C37.2033 12.3575 37.0715 11.9276 36.919 11.4144C36.7734 10.9013 36.6139 10.3396 36.4405 9.72944C36.2741 9.11229 36.1042 8.48128 35.9309 7.8364C35.7644 7.19153 35.6084 6.56745 35.4628 5.96418H35.8269C35.8338 6.51198 35.8442 7.10485 35.8581 7.74279C35.8719 8.3738 35.8858 9.00481 35.8997 9.63582C35.9205 10.2599 35.9378 10.8389 35.9517 11.3728C35.9655 11.9068 35.9725 12.3506 35.9725 12.7042V19.3922H32.3008ZM51.6684 19.3922V8.02363H55.288V19.3922H51.6684ZM53.4678 6.78588C52.927 6.78588 52.4728 6.61599 52.1053 6.27621C51.7377 5.92951 51.554 5.50652 51.554 5.00726C51.554 4.508 51.7377 4.08848 52.1053 3.74871C52.4728 3.40893 52.927 3.23904 53.4678 3.23904C54.0087 3.23904 54.4629 3.40893 54.8304 3.74871C55.1979 4.08155 55.3817 4.50107 55.3817 5.00726C55.3817 5.50652 55.1979 5.92951 54.8304 6.27621C54.4629 6.61599 54.0087 6.78588 53.4678 6.78588ZM60.7075 13.0266V19.3922H57.0879V8.02363H60.5515L60.5931 10.9672H60.2811C60.5931 10.0241 61.0612 9.26831 61.6852 8.69971C62.3093 8.12417 63.1379 7.8364 64.1711 7.8364C64.9755 7.8364 65.6724 8.01669 66.2618 8.37727C66.8512 8.73091 67.3019 9.23364 67.614 9.88545C67.9329 10.5373 68.0924 11.307 68.0924 12.1945V19.3922H64.4832V12.9122C64.4832 12.2604 64.3202 11.7542 63.9943 11.3936C63.6753 11.0331 63.2212 10.8528 62.6318 10.8528C62.2504 10.8528 61.9141 10.936 61.6228 11.1024C61.3316 11.2688 61.1062 11.515 60.9467 11.8409C60.7873 12.1599 60.7075 12.5551 60.7075 13.0266ZM76.4555 8.02363V10.7488H69.0081V8.02363H76.4555ZM70.6828 5.16328H74.292V15.783C74.292 16.1019 74.3613 16.3342 74.5 16.4799C74.6456 16.6255 74.8987 16.6983 75.2593 16.6983C75.4049 16.6983 75.5956 16.6879 75.8314 16.6671C76.0741 16.6463 76.2509 16.6289 76.3618 16.6151L76.6323 19.309C76.3133 19.3783 75.9631 19.4269 75.5817 19.4546C75.2073 19.4824 74.8363 19.4962 74.4688 19.4962C73.1999 19.4962 72.2499 19.2223 71.6189 18.6745C70.9948 18.1267 70.6828 17.3085 70.6828 16.2198V5.16328Z" fill="#FAFAFA"/>
+<path d="M88.6674 19.6522C87.5232 19.6522 86.5282 19.4581 85.6822 19.0698C84.8432 18.6815 84.1879 18.1371 83.7164 17.4368C83.2448 16.7364 82.9917 15.9078 82.9571 14.9509H84.9333C84.968 15.5957 85.1483 16.1401 85.4742 16.5839C85.8001 17.0207 86.2404 17.3536 86.7951 17.5824C87.3499 17.8043 87.974 17.9152 88.6674 17.9152C89.3885 17.9152 90.0265 17.8008 90.5812 17.572C91.1429 17.3432 91.5832 17.0242 91.9022 16.6151C92.2281 16.199 92.391 15.7171 92.391 15.1693C92.391 14.6978 92.2662 14.306 92.0166 13.994C91.7669 13.675 91.4133 13.408 90.9556 13.1931C90.498 12.9781 89.9537 12.7874 89.3227 12.621L87.5024 12.1321C86.1225 11.7646 85.0824 11.255 84.382 10.6031C83.6886 9.94439 83.3419 9.09496 83.3419 8.05483C83.3419 7.17419 83.5708 6.4045 84.0284 5.74575C84.4861 5.087 85.1171 4.57734 85.9214 4.21676C86.7258 3.84925 87.6446 3.6655 88.6778 3.6655C89.7179 3.6655 90.6297 3.85272 91.4133 4.22717C92.2038 4.60161 92.8244 5.12167 93.2751 5.78736C93.7259 6.4461 93.9651 7.20886 93.9928 8.07563H92.0894C92.0131 7.22966 91.656 6.57438 91.0181 6.10979C90.387 5.63827 89.5861 5.40251 88.6154 5.40251C87.9497 5.40251 87.3603 5.51346 86.8471 5.73535C86.341 5.95724 85.9457 6.26235 85.6614 6.65066C85.3771 7.03204 85.235 7.46889 85.235 7.96122C85.235 8.44661 85.3771 8.84879 85.6614 9.16777C85.9457 9.4798 86.3167 9.73984 86.7743 9.94786C87.232 10.149 87.7243 10.3188 88.2513 10.4575L89.8843 10.884C90.4391 11.0227 90.9765 11.2064 91.4965 11.4352C92.0235 11.6571 92.495 11.9345 92.9111 12.2673C93.3341 12.5933 93.6704 12.9954 93.92 13.4739C94.1696 13.9454 94.2945 14.5036 94.2945 15.1485C94.2945 16.0153 94.0656 16.7884 93.608 17.468C93.1573 18.1475 92.5124 18.6815 91.6733 19.0698C90.8343 19.4581 89.8323 19.6522 88.6674 19.6522ZM101.097 8.02363V9.59422H95.1062V8.02363H101.097ZM96.9368 5.16328H98.7674V16.5215C98.7674 16.9999 98.8645 17.3466 99.0587 17.5616C99.2597 17.7696 99.5995 17.8736 100.078 17.8736C100.21 17.8736 100.366 17.8667 100.546 17.8528C100.733 17.832 100.903 17.8147 101.056 17.8008L101.285 19.3506C101.097 19.3922 100.886 19.4234 100.65 19.4442C100.414 19.465 100.189 19.4754 99.974 19.4754C98.9962 19.4754 98.2439 19.2362 97.7169 18.7577C97.1968 18.2723 96.9368 17.5789 96.9368 16.6775V5.16328ZM106.33 19.621C105.595 19.621 104.932 19.4893 104.343 19.2258C103.754 18.9554 103.285 18.5636 102.939 18.0504C102.592 17.5304 102.419 16.8959 102.419 16.147C102.419 15.4952 102.547 14.9647 102.804 14.5556C103.06 14.1465 103.403 13.8275 103.833 13.5987C104.263 13.3629 104.742 13.1861 105.269 13.0682C105.796 12.9504 106.333 12.8567 106.881 12.7874C107.574 12.6903 108.132 12.6175 108.555 12.569C108.978 12.5204 109.287 12.4407 109.481 12.3298C109.675 12.2119 109.772 12.0142 109.772 11.7369V11.6537C109.772 11.2029 109.679 10.8146 109.492 10.4887C109.311 10.1628 109.041 9.90972 108.68 9.72944C108.32 9.54915 107.872 9.459 107.338 9.459C106.805 9.459 106.34 9.54568 105.945 9.71903C105.556 9.89239 105.241 10.1177 104.998 10.3951C104.755 10.6655 104.593 10.9533 104.509 11.2584L102.71 10.9152C102.897 10.2218 103.22 9.64969 103.677 9.19897C104.135 8.74825 104.679 8.41194 105.31 8.19005C105.941 7.96815 106.607 7.85721 107.307 7.85721C107.8 7.85721 108.295 7.91961 108.795 8.04443C109.301 8.16925 109.765 8.38074 110.188 8.67891C110.611 8.97014 110.951 9.36886 111.208 9.87505C111.464 10.3743 111.593 11.0053 111.593 11.7681V19.3922H109.793V17.8216H109.7C109.568 18.0851 109.363 18.359 109.086 18.6433C108.809 18.9207 108.444 19.153 107.994 19.3402C107.543 19.5274 106.988 19.621 106.33 19.621ZM106.621 17.9984C107.321 17.9984 107.904 17.8667 108.368 17.6032C108.84 17.3328 109.19 16.9861 109.419 16.5631C109.654 16.1331 109.772 15.6824 109.772 15.2109V13.6923C109.703 13.7686 109.554 13.8414 109.325 13.9107C109.096 13.9732 108.829 14.0321 108.524 14.0876C108.226 14.143 107.921 14.1916 107.609 14.2332C107.304 14.2748 107.033 14.3095 106.798 14.3372C106.354 14.3927 105.938 14.4897 105.549 14.6284C105.168 14.7602 104.86 14.9543 104.624 15.2109C104.388 15.4675 104.27 15.8107 104.27 16.2406C104.27 16.6151 104.367 16.934 104.561 17.1975C104.762 17.461 105.04 17.6621 105.393 17.8008C105.747 17.9326 106.156 17.9984 106.621 17.9984ZM114.193 19.3922V8.02363H115.951V9.79184H116.045C116.253 9.20937 116.61 8.74131 117.116 8.38767C117.622 8.03403 118.219 7.85721 118.905 7.85721C119.058 7.85721 119.217 7.86414 119.384 7.87801C119.55 7.88494 119.682 7.89188 119.779 7.89881V9.73984C119.716 9.71903 119.578 9.69476 119.363 9.66703C119.155 9.63929 118.922 9.62542 118.666 9.62542C118.174 9.62542 117.726 9.7329 117.324 9.94786C116.922 10.1628 116.603 10.4714 116.367 10.8736C116.138 11.2758 116.024 11.7577 116.024 12.3194V19.3922H114.193ZM126.322 8.02363V9.59422H120.33V8.02363H126.322ZM122.161 5.16328H123.992V16.5215C123.992 16.9999 124.089 17.3466 124.283 17.5616C124.484 17.7696 124.824 17.8736 125.302 17.8736C125.434 17.8736 125.59 17.8667 125.77 17.8528C125.958 17.832 126.127 17.8147 126.28 17.8008L126.509 19.3506C126.322 19.3922 126.11 19.4234 125.874 19.4442C125.639 19.465 125.413 19.4754 125.198 19.4754C124.221 19.4754 123.468 19.2362 122.941 18.7577C122.421 18.2723 122.161 17.5789 122.161 16.6775V5.16328ZM132.604 19.6418C131.502 19.6418 130.555 19.3957 129.765 18.9034C128.974 18.4041 128.364 17.7141 127.934 16.8335C127.511 15.9459 127.3 14.9266 127.3 13.7755C127.3 12.6106 127.511 11.5843 127.934 10.6968C128.364 9.80224 128.964 9.10189 129.734 8.5957C130.51 8.0895 131.408 7.8364 132.428 7.8364C133.1 7.8364 133.738 7.95429 134.341 8.19005C134.952 8.42581 135.489 8.78292 135.954 9.26138C136.425 9.73984 136.793 10.3431 137.056 11.0712C137.327 11.7924 137.462 12.6453 137.462 13.6299V14.2956H128.433V12.7354H136.463L135.631 13.2971C135.631 12.5412 135.506 11.8756 135.257 11.3C135.007 10.7245 134.643 10.2772 134.165 9.95826C133.686 9.63236 133.107 9.4694 132.428 9.4694C131.748 9.4694 131.162 9.63236 130.67 9.95826C130.177 10.2842 129.796 10.7245 129.526 11.2792C129.262 11.827 129.13 12.4407 129.13 13.1202V14.046C129.13 14.8642 129.273 15.5715 129.557 16.1678C129.841 16.7572 130.243 17.2114 130.763 17.5304C131.283 17.8424 131.901 17.9984 132.615 17.9984C133.093 17.9984 133.523 17.9291 133.905 17.7904C134.293 17.6448 134.619 17.4333 134.882 17.1559C135.153 16.8786 135.354 16.5457 135.486 16.1574L137.275 16.4487C137.108 17.0797 136.81 17.6344 136.38 18.1129C135.95 18.5913 135.413 18.9658 134.768 19.2362C134.123 19.5066 133.402 19.6418 132.604 19.6418ZM139.459 19.3922V8.02363H141.217V9.79184H141.311C141.519 9.20937 141.876 8.74131 142.382 8.38767C142.888 8.03403 143.485 7.85721 144.171 7.85721C144.324 7.85721 144.483 7.86414 144.649 7.87801C144.816 7.88494 144.948 7.89188 145.045 7.89881V9.73984C144.982 9.71903 144.844 9.69476 144.629 9.66703C144.421 9.63929 144.188 9.62542 143.932 9.62542C143.439 9.62542 142.992 9.7329 142.59 9.94786C142.188 10.1628 141.869 10.4714 141.633 10.8736C141.404 11.2758 141.29 11.7577 141.29 12.3194V19.3922H139.459ZM153.429 14.9613V12.7146C153.783 12.2569 154.136 11.8201 154.49 11.404C154.844 10.9811 155.204 10.565 155.572 10.1559C155.939 9.73984 156.314 9.32725 156.695 8.91814L161.355 3.89432H163.893L157.277 10.9672H157.184L153.429 14.9613ZM152.108 19.3922V3.89432H154.043V9.24058L154.022 12.5586L154.043 13.5051V19.3922H152.108ZM161.615 19.3922L155.967 11.4768L157.173 9.96866L163.903 19.3922H161.615ZM165.661 19.3922V8.02363H167.492V19.3922H165.661ZM166.587 6.02658C166.24 6.02658 165.942 5.9087 165.692 5.67294C165.443 5.43025 165.318 5.13901 165.318 4.79923C165.318 4.45946 165.443 4.17169 165.692 3.93593C165.942 3.69323 166.24 3.57189 166.587 3.57189C166.934 3.57189 167.232 3.69323 167.482 3.93593C167.731 4.17169 167.856 4.45946 167.856 4.79923C167.856 5.13901 167.731 5.43025 167.482 5.67294C167.232 5.9087 166.934 6.02658 166.587 6.02658ZM174.836 8.02363V9.59422H168.844V8.02363H174.836ZM170.675 5.16328H172.506V16.5215C172.506 16.9999 172.603 17.3466 172.797 17.5616C172.998 17.7696 173.338 17.8736 173.816 17.8736C173.948 17.8736 174.104 17.8667 174.284 17.8528C174.472 17.832 174.641 17.8147 174.794 17.8008L175.023 19.3506C174.836 19.3922 174.624 19.4234 174.388 19.4442C174.153 19.465 173.927 19.4754 173.712 19.4754C172.735 19.4754 171.982 19.2362 171.455 18.7577C170.935 18.2723 170.675 17.5789 170.675 16.6775V5.16328Z" fill="#9F9FA9"/>
+<defs>
+<linearGradient id="paint0_linear_17557_2145" x1="3.77557" y1="5.91571" x2="5.23185" y2="21.5589" gradientUnits="userSpaceOnUse">
+<stop stop-color="#18E299"/>
+<stop offset="1" stop-color="#15803D"/>
+</linearGradient>
+<linearGradient id="paint1_linear_17557_2145" x1="12.1711" y1="-0.718425" x2="10.1897" y2="22.9832" gradientUnits="userSpaceOnUse">
+<stop stop-color="#16A34A"/>
+<stop offset="1" stop-color="#4ADE80"/>
+</linearGradient>
+<linearGradient id="paint2_linear_17557_2145" x1="23.1327" y1="15.353" x2="9.33841" y2="18.5196" gradientUnits="userSpaceOnUse">
+<stop stop-color="#4ADE80"/>
+<stop offset="1" stop-color="#0D9373"/>
+</linearGradient>
+</defs>
+</svg>
diff --git a/logo/light.svg b/logo/light.svg
new file mode 100644
index 00000000..03e62bf1
--- /dev/null
+++ b/logo/light.svg
@@ -0,0 +1,21 @@
+<svg width="177" height="24" viewBox="0 0 177 24" fill="none" xmlns="http://www.w3.org/2000/svg">
+<path d="M9.06145 23.1079C5.26816 22.3769 -3.39077 20.6274 1.4173 5.06384C9.6344 6.09939 16.9728 14.0644 9.06145 23.1079Z" fill="url(#paint0_linear_17557_2020)"/>
+<path d="M8.91928 23.0939C5.27642 21.2223 0.78371 4.20891 17.0071 0C20.7569 7.19341 19.6212 16.5452 8.91928 23.0939Z" fill="url(#paint1_linear_17557_2020)"/>
+<path d="M8.91388 23.0788C8.73534 19.8817 10.1585 9.08525 23.5699 13.1107C23.1812 20.1229 18.984 26.4182 8.91388 23.0788Z" fill="url(#paint2_linear_17557_2020)"/>
+<path d="M32.3008 19.3922V3.89432H37.9383L39.925 9.94786C40.0359 10.3154 40.1642 10.7869 40.3098 11.3624C40.4624 11.938 40.6114 12.5516 40.7571 13.2035C40.9096 13.8553 41.0483 14.4828 41.1731 15.0861C41.3049 15.6824 41.4123 16.1921 41.4955 16.6151H40.6946C40.7709 16.1921 40.8715 15.6824 40.9963 15.0861C41.128 14.4897 41.2667 13.8657 41.4123 13.2139C41.5649 12.562 41.714 11.9484 41.8596 11.3728C42.0052 10.7904 42.1335 10.3154 42.2444 9.94786L44.1999 3.89432H49.8478V19.3922H46.1657V12.7042C46.1657 12.3575 46.1726 11.9172 46.1865 11.3832C46.2004 10.8493 46.2143 10.2703 46.2281 9.64623C46.2489 9.02215 46.2663 8.39114 46.2801 7.75319C46.3009 7.11525 46.3113 6.51891 46.3113 5.96418H46.6234C46.4847 6.56052 46.3321 7.18112 46.1657 7.826C45.9993 8.47088 45.8329 9.10189 45.6665 9.71903C45.507 10.3362 45.3509 10.9013 45.1984 11.4144C45.0528 11.9276 44.928 12.3575 44.824 12.7042L42.6085 19.3922H39.5609L37.3142 12.7042C37.2033 12.3575 37.0715 11.9276 36.919 11.4144C36.7734 10.9013 36.6139 10.3396 36.4405 9.72944C36.2741 9.11229 36.1042 8.48128 35.9309 7.8364C35.7644 7.19153 35.6084 6.56745 35.4628 5.96418H35.8269C35.8338 6.51198 35.8442 7.10485 35.8581 7.74279C35.8719 8.3738 35.8858 9.00481 35.8997 9.63582C35.9205 10.2599 35.9378 10.8389 35.9517 11.3728C35.9655 11.9068 35.9725 12.3506 35.9725 12.7042V19.3922H32.3008ZM51.6684 19.3922V8.02363H55.288V19.3922H51.6684ZM53.4678 6.78588C52.927 6.78588 52.4728 6.61599 52.1053 6.27621C51.7377 5.92951 51.554 5.50652 51.554 5.00726C51.554 4.508 51.7377 4.08848 52.1053 3.74871C52.4728 3.40893 52.927 3.23904 53.4678 3.23904C54.0087 3.23904 54.4629 3.40893 54.8304 3.74871C55.1979 4.08155 55.3817 4.50107 55.3817 5.00726C55.3817 5.50652 55.1979 5.92951 54.8304 6.27621C54.4629 6.61599 54.0087 6.78588 53.4678 6.78588ZM60.7075 13.0266V19.3922H57.0879V8.02363H60.5515L60.5931 10.9672H60.2811C60.5931 10.0241 61.0612 9.26831 61.6852 8.69971C62.3093 8.12417 63.1379 7.8364 64.1711 7.8364C64.9755 7.8364 65.6724 8.01669 66.2618 8.37727C66.8512 8.73091 67.3019 9.23364 67.614 9.88545C67.9329 10.5373 68.0924 11.307 68.0924 12.1945V19.3922H64.4832V12.9122C64.4832 12.2604 64.3202 11.7542 63.9943 11.3936C63.6753 11.0331 63.2212 10.8528 62.6318 10.8528C62.2504 10.8528 61.9141 10.936 61.6228 11.1024C61.3316 11.2688 61.1062 11.515 60.9467 11.8409C60.7873 12.1599 60.7075 12.5551 60.7075 13.0266ZM76.4555 8.02363V10.7488H69.0081V8.02363H76.4555ZM70.6828 5.16328H74.292V15.783C74.292 16.1019 74.3613 16.3342 74.5 16.4799C74.6456 16.6255 74.8987 16.6983 75.2593 16.6983C75.4049 16.6983 75.5956 16.6879 75.8314 16.6671C76.0741 16.6463 76.2509 16.6289 76.3618 16.6151L76.6323 19.309C76.3133 19.3783 75.9631 19.4269 75.5817 19.4546C75.2073 19.4824 74.8363 19.4962 74.4688 19.4962C73.1999 19.4962 72.2499 19.2223 71.6189 18.6745C70.9948 18.1267 70.6828 17.3085 70.6828 16.2198V5.16328Z" fill="#09090B"/>
+<path d="M88.6674 19.6522C87.5232 19.6522 86.5282 19.4581 85.6822 19.0698C84.8432 18.6815 84.1879 18.1371 83.7164 17.4368C83.2448 16.7364 82.9917 15.9078 82.9571 14.9509H84.9333C84.968 15.5957 85.1483 16.1401 85.4742 16.5839C85.8001 17.0207 86.2404 17.3536 86.7951 17.5824C87.3499 17.8043 87.974 17.9152 88.6674 17.9152C89.3885 17.9152 90.0265 17.8008 90.5812 17.572C91.1429 17.3432 91.5832 17.0242 91.9022 16.6151C92.2281 16.199 92.391 15.7171 92.391 15.1693C92.391 14.6978 92.2662 14.306 92.0166 13.994C91.7669 13.675 91.4133 13.408 90.9556 13.1931C90.498 12.9781 89.9537 12.7874 89.3227 12.621L87.5024 12.1321C86.1225 11.7646 85.0824 11.255 84.382 10.6031C83.6886 9.94439 83.3419 9.09496 83.3419 8.05483C83.3419 7.17419 83.5708 6.4045 84.0284 5.74575C84.4861 5.087 85.1171 4.57734 85.9214 4.21676C86.7258 3.84925 87.6446 3.6655 88.6778 3.6655C89.7179 3.6655 90.6297 3.85272 91.4133 4.22717C92.2038 4.60161 92.8244 5.12167 93.2751 5.78736C93.7259 6.4461 93.9651 7.20886 93.9928 8.07563H92.0894C92.0131 7.22966 91.656 6.57438 91.0181 6.10979C90.387 5.63827 89.5861 5.40251 88.6154 5.40251C87.9497 5.40251 87.3603 5.51346 86.8471 5.73535C86.341 5.95724 85.9457 6.26235 85.6614 6.65066C85.3771 7.03204 85.235 7.46889 85.235 7.96122C85.235 8.44661 85.3771 8.84879 85.6614 9.16777C85.9457 9.4798 86.3167 9.73984 86.7743 9.94786C87.232 10.149 87.7243 10.3188 88.2513 10.4575L89.8843 10.884C90.4391 11.0227 90.9765 11.2064 91.4965 11.4352C92.0235 11.6571 92.495 11.9345 92.9111 12.2673C93.3341 12.5933 93.6704 12.9954 93.92 13.4739C94.1696 13.9454 94.2945 14.5036 94.2945 15.1485C94.2945 16.0153 94.0656 16.7884 93.608 17.468C93.1573 18.1475 92.5124 18.6815 91.6733 19.0698C90.8343 19.4581 89.8323 19.6522 88.6674 19.6522ZM101.097 8.02363V9.59422H95.1062V8.02363H101.097ZM96.9368 5.16328H98.7674V16.5215C98.7674 16.9999 98.8645 17.3466 99.0587 17.5616C99.2597 17.7696 99.5995 17.8736 100.078 17.8736C100.21 17.8736 100.366 17.8667 100.546 17.8528C100.733 17.832 100.903 17.8147 101.056 17.8008L101.285 19.3506C101.097 19.3922 100.886 19.4234 100.65 19.4442C100.414 19.465 100.189 19.4754 99.974 19.4754C98.9962 19.4754 98.2439 19.2362 97.7169 18.7577C97.1968 18.2723 96.9368 17.5789 96.9368 16.6775V5.16328ZM106.33 19.621C105.595 19.621 104.932 19.4893 104.343 19.2258C103.754 18.9554 103.285 18.5636 102.939 18.0504C102.592 17.5304 102.419 16.8959 102.419 16.147C102.419 15.4952 102.547 14.9647 102.804 14.5556C103.06 14.1465 103.403 13.8275 103.833 13.5987C104.263 13.3629 104.742 13.1861 105.269 13.0682C105.796 12.9504 106.333 12.8567 106.881 12.7874C107.574 12.6903 108.132 12.6175 108.555 12.569C108.978 12.5204 109.287 12.4407 109.481 12.3298C109.675 12.2119 109.772 12.0142 109.772 11.7369V11.6537C109.772 11.2029 109.679 10.8146 109.492 10.4887C109.311 10.1628 109.041 9.90972 108.68 9.72944C108.32 9.54915 107.872 9.459 107.338 9.459C106.805 9.459 106.34 9.54568 105.945 9.71903C105.556 9.89239 105.241 10.1177 104.998 10.3951C104.755 10.6655 104.593 10.9533 104.509 11.2584L102.71 10.9152C102.897 10.2218 103.22 9.64969 103.677 9.19897C104.135 8.74825 104.679 8.41194 105.31 8.19005C105.941 7.96815 106.607 7.85721 107.307 7.85721C107.8 7.85721 108.295 7.91961 108.795 8.04443C109.301 8.16925 109.765 8.38074 110.188 8.67891C110.611 8.97014 110.951 9.36886 111.208 9.87505C111.464 10.3743 111.593 11.0053 111.593 11.7681V19.3922H109.793V17.8216H109.7C109.568 18.0851 109.363 18.359 109.086 18.6433C108.809 18.9207 108.444 19.153 107.994 19.3402C107.543 19.5274 106.988 19.621 106.33 19.621ZM106.621 17.9984C107.321 17.9984 107.904 17.8667 108.368 17.6032C108.84 17.3328 109.19 16.9861 109.419 16.5631C109.654 16.1331 109.772 15.6824 109.772 15.2109V13.6923C109.703 13.7686 109.554 13.8414 109.325 13.9107C109.096 13.9732 108.829 14.0321 108.524 14.0876C108.226 14.143 107.921 14.1916 107.609 14.2332C107.304 14.2748 107.033 14.3095 106.798 14.3372C106.354 14.3927 105.938 14.4897 105.549 14.6284C105.168 14.7602 104.86 14.9543 104.624 15.2109C104.388 15.4675 104.27 15.8107 104.27 16.2406C104.27 16.6151 104.367 16.934 104.561 17.1975C104.762 17.461 105.04 17.6621 105.393 17.8008C105.747 17.9326 106.156 17.9984 106.621 17.9984ZM114.193 19.3922V8.02363H115.951V9.79184H116.045C116.253 9.20937 116.61 8.74131 117.116 8.38767C117.622 8.03403 118.219 7.85721 118.905 7.85721C119.058 7.85721 119.217 7.86414 119.384 7.87801C119.55 7.88494 119.682 7.89188 119.779 7.89881V9.73984C119.716 9.71903 119.578 9.69476 119.363 9.66703C119.155 9.63929 118.922 9.62542 118.666 9.62542C118.174 9.62542 117.726 9.7329 117.324 9.94786C116.922 10.1628 116.603 10.4714 116.367 10.8736C116.138 11.2758 116.024 11.7577 116.024 12.3194V19.3922H114.193ZM126.322 8.02363V9.59422H120.33V8.02363H126.322ZM122.161 5.16328H123.992V16.5215C123.992 16.9999 124.089 17.3466 124.283 17.5616C124.484 17.7696 124.824 17.8736 125.302 17.8736C125.434 17.8736 125.59 17.8667 125.77 17.8528C125.958 17.832 126.127 17.8147 126.28 17.8008L126.509 19.3506C126.322 19.3922 126.11 19.4234 125.874 19.4442C125.639 19.465 125.413 19.4754 125.198 19.4754C124.221 19.4754 123.468 19.2362 122.941 18.7577C122.421 18.2723 122.161 17.5789 122.161 16.6775V5.16328ZM132.604 19.6418C131.502 19.6418 130.555 19.3957 129.765 18.9034C128.974 18.4041 128.364 17.7141 127.934 16.8335C127.511 15.9459 127.3 14.9266 127.3 13.7755C127.3 12.6106 127.511 11.5843 127.934 10.6968C128.364 9.80224 128.964 9.10189 129.734 8.5957C130.51 8.0895 131.408 7.8364 132.428 7.8364C133.1 7.8364 133.738 7.95429 134.341 8.19005C134.952 8.42581 135.489 8.78292 135.954 9.26138C136.425 9.73984 136.793 10.3431 137.056 11.0712C137.327 11.7924 137.462 12.6453 137.462 13.6299V14.2956H128.433V12.7354H136.463L135.631 13.2971C135.631 12.5412 135.506 11.8756 135.257 11.3C135.007 10.7245 134.643 10.2772 134.165 9.95826C133.686 9.63236 133.107 9.4694 132.428 9.4694C131.748 9.4694 131.162 9.63236 130.67 9.95826C130.177 10.2842 129.796 10.7245 129.526 11.2792C129.262 11.827 129.13 12.4407 129.13 13.1202V14.046C129.13 14.8642 129.273 15.5715 129.557 16.1678C129.841 16.7572 130.243 17.2114 130.763 17.5304C131.283 17.8424 131.901 17.9984 132.615 17.9984C133.093 17.9984 133.523 17.9291 133.905 17.7904C134.293 17.6448 134.619 17.4333 134.882 17.1559C135.153 16.8786 135.354 16.5457 135.486 16.1574L137.275 16.4487C137.108 17.0797 136.81 17.6344 136.38 18.1129C135.95 18.5913 135.413 18.9658 134.768 19.2362C134.123 19.5066 133.402 19.6418 132.604 19.6418ZM139.459 19.3922V8.02363H141.217V9.79184H141.311C141.519 9.20937 141.876 8.74131 142.382 8.38767C142.888 8.03403 143.485 7.85721 144.171 7.85721C144.324 7.85721 144.483 7.86414 144.649 7.87801C144.816 7.88494 144.948 7.89188 145.045 7.89881V9.73984C144.982 9.71903 144.844 9.69476 144.629 9.66703C144.421 9.63929 144.188 9.62542 143.932 9.62542C143.439 9.62542 142.992 9.7329 142.59 9.94786C142.188 10.1628 141.869 10.4714 141.633 10.8736C141.404 11.2758 141.29 11.7577 141.29 12.3194V19.3922H139.459ZM153.429 14.9613V12.7146C153.783 12.2569 154.136 11.8201 154.49 11.404C154.844 10.9811 155.204 10.565 155.572 10.1559C155.939 9.73984 156.314 9.32725 156.695 8.91814L161.355 3.89432H163.893L157.277 10.9672H157.184L153.429 14.9613ZM152.108 19.3922V3.89432H154.043V9.24058L154.022 12.5586L154.043 13.5051V19.3922H152.108ZM161.615 19.3922L155.967 11.4768L157.173 9.96866L163.903 19.3922H161.615ZM165.661 19.3922V8.02363H167.492V19.3922H165.661ZM166.587 6.02658C166.24 6.02658 165.942 5.9087 165.692 5.67294C165.443 5.43025 165.318 5.13901 165.318 4.79923C165.318 4.45946 165.443 4.17169 165.692 3.93593C165.942 3.69323 166.24 3.57189 166.587 3.57189C166.934 3.57189 167.232 3.69323 167.482 3.93593C167.731 4.17169 167.856 4.45946 167.856 4.79923C167.856 5.13901 167.731 5.43025 167.482 5.67294C167.232 5.9087 166.934 6.02658 166.587 6.02658ZM174.836 8.02363V9.59422H168.844V8.02363H174.836ZM170.675 5.16328H172.506V16.5215C172.506 16.9999 172.603 17.3466 172.797 17.5616C172.998 17.7696 173.338 17.8736 173.816 17.8736C173.948 17.8736 174.104 17.8667 174.284 17.8528C174.472 17.832 174.641 17.8147 174.794 17.8008L175.023 19.3506C174.836 19.3922 174.624 19.4234 174.388 19.4442C174.153 19.465 173.927 19.4754 173.712 19.4754C172.735 19.4754 171.982 19.2362 171.455 18.7577C170.935 18.2723 170.675 17.5789 170.675 16.6775V5.16328Z" fill="#52525C"/>
+<defs>
+<linearGradient id="paint0_linear_17557_2020" x1="3.77557" y1="5.91571" x2="5.23185" y2="21.5589" gradientUnits="userSpaceOnUse">
+<stop stop-color="#18E299"/>
+<stop offset="1" stop-color="#15803D"/>
+</linearGradient>
+<linearGradient id="paint1_linear_17557_2020" x1="12.1711" y1="-0.718425" x2="10.1897" y2="22.9832" gradientUnits="userSpaceOnUse">
+<stop stop-color="#16A34A"/>
+<stop offset="1" stop-color="#4ADE80"/>
+</linearGradient>
+<linearGradient id="paint2_linear_17557_2020" x1="23.1327" y1="15.353" x2="9.33841" y2="18.5196" gradientUnits="userSpaceOnUse">
+<stop stop-color="#4ADE80"/>
+<stop offset="1" stop-color="#0D9373"/>
+</linearGradient>
+</defs>
+</svg>
diff --git a/package.json b/package.json
deleted file mode 100644
index 4e4af2c0..00000000
--- a/package.json
+++ /dev/null
@@ -1,48 +0,0 @@
-{
- "name": "aqua-docs-v-2",
- "version": "0.0.0",
- "private": true,
- "scripts": {
- "docusaurus": "docusaurus",
- "start": "docusaurus start",
- "build": "docusaurus build",
- "swizzle": "docusaurus swizzle",
- "deploy": "docusaurus deploy",
- "clear": "docusaurus clear",
- "serve": "docusaurus serve",
- "write-translations": "docusaurus write-translations",
- "write-heading-ids": "docusaurus write-heading-ids",
- "typecheck": "tsc"
- },
- "dependencies": {
- "@docusaurus/core": "3.6.3",
- "@docusaurus/preset-classic": "3.6.3",
- "@mdx-js/react": "^3.0.0",
- "clsx": "^2.0.0",
- "prism-react-renderer": "^2.3.0",
- "react": "^18.0.0",
- "react-dom": "^18.0.0",
- "react-icons": "^5.3.0"
- },
- "devDependencies": {
- "@docusaurus/module-type-aliases": "3.6.3",
- "@docusaurus/tsconfig": "3.6.3",
- "@docusaurus/types": "3.6.3",
- "typescript": "~5.6.2"
- },
- "browserslist": {
- "production": [
- ">0.5%",
- "not dead",
- "not op_mini all"
- ],
- "development": [
- "last 3 chrome version",
- "last 3 firefox version",
- "last 5 safari version"
- ]
- },
- "engines": {
- "node": ">=18.0"
- }
-}
diff --git a/docs/protocol/assurance-levels-aal.md b/previous_versions/version_1/assurance_levels.mdx
similarity index 98%
rename from docs/protocol/assurance-levels-aal.md
rename to previous_versions/version_1/assurance_levels.mdx
index 2fe5506c..8cde2f4b 100644
--- a/docs/protocol/assurance-levels-aal.md
+++ b/previous_versions/version_1/assurance_levels.mdx
@@ -1,8 +1,6 @@
---
title: "Assurance Levels (AAL)"
linkTitle: "Assurance Levels"
-weight: 4
-sidebar_position: 5
description: >
Highlights the levels of assurances you can receive by using technology provided in the Aqua reference implementation.
---
diff --git a/docs/implementations/reference-architecture.md b/previous_versions/version_1/concepts.mdx
similarity index 98%
rename from docs/implementations/reference-architecture.md
rename to previous_versions/version_1/concepts.mdx
index aa22dd20..60d300f0 100644
--- a/docs/implementations/reference-architecture.md
+++ b/previous_versions/version_1/concepts.mdx
@@ -1,9 +1,6 @@
---
-title: "Reference Implementation"
-linkTitle: "Reference Implementation"
-weight: 1
-description: >
- Explains the technologies selected for the reference implementation and why we selected them.
+title: 'Concepts '
+description: Explains the technologies selected for the reference implementation and why we selected them.
---
Implementation specific architecture documentation for the Aqua Data
@@ -25,6 +22,9 @@ the linked-list for the documentation of the components we use here:
- [Nginx](https://nginx.org/en/docs/)
- [Let's Encrypt](https://letsencrypt.org/docs/)
+
+
+
All software components selected are open source licenses. They each
have active developer communities behind them to secure future support
and further development.
@@ -54,12 +54,12 @@ and levels of assurance.
- Large User-Base 10 Million +
-<!-- -->
+
- Hardware Wallet Support (E.g. Ledger)
- Large User-base 5 Million +
-<!-- -->
+
- All related source code is open source, lot's of money behind it
(future proof)
@@ -136,7 +136,7 @@ Security Practices:
spawn containers for multiple accounts which trust each other to
work together on shared data
-<!-- -->
+
- If you use a hosted PKC instance, assume the provider has access to
your data as we don't use homomorphic encryption nor do we have
@@ -145,7 +145,7 @@ Security Practices:
Accounting) to improve test coverage to increase stability and
security of our application
-<!-- -->
+
- To securely exchange data between PKC's, we implement a separate
security software called Guardian. The Guardian protects the PKC and
@@ -154,7 +154,7 @@ Security Practices:
highest scrutiny and attention to ensure a minimal attack surface
while allowing trust between Guardians so data can be exchanged.
-<!-- -->
+
- The Apache WebServer present in the MediaWiki container has a
technological dependency and needs regular updates as Apache was
@@ -308,7 +308,7 @@ authentication challenges.
Cryptography Group 2015, See differences
P9](https://www.secg.org/sec2-v2.pdf)
-<!-- -->
+
- Supported by BSI secp256r1 but secp256k1 is not
mentioned.https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03116/BSI-TR-03116-4.pdf?__blob=publicationFile&v=7
@@ -316,7 +316,7 @@ authentication challenges.
2021 by Tim Bansemer. Answer of the BSI: Currently the BSI has no
assessment or recommendation for secp256k1.
-<!-- -->
+
- For authentication with Metamask Ethereum wallets we currently use
[https://github.com/pelith/node-eauth-server](https://github.com/pelith/node-eauth-server). We are signing a
diff --git a/versioned_docs/version-1.1.0/Protocol/data-accounting.md b/previous_versions/version_1/data_accounting.mdx
similarity index 100%
rename from versioned_docs/version-1.1.0/Protocol/data-accounting.md
rename to previous_versions/version_1/data_accounting.mdx
diff --git a/versioned_docs/version-1.1.0/Protocol/data-governance.md b/previous_versions/version_1/data_governance.mdx
similarity index 100%
rename from versioned_docs/version-1.1.0/Protocol/data-governance.md
rename to previous_versions/version_1/data_governance.mdx
diff --git a/versioned_docs/version-1.1.0/Protocol/delegated-witnessing.md b/previous_versions/version_1/delegated_witnessing.mdx
similarity index 100%
rename from versioned_docs/version-1.1.0/Protocol/delegated-witnessing.md
rename to previous_versions/version_1/delegated_witnessing.mdx
diff --git a/versioned_docs/version-1.1.0/Protocol/design-principles.md b/previous_versions/version_1/design_principles.mdx
similarity index 100%
rename from versioned_docs/version-1.1.0/Protocol/design-principles.md
rename to previous_versions/version_1/design_principles.mdx
diff --git a/versioned_docs/version-1.1.0/Protocol/guardian.md b/previous_versions/version_1/guardian.mdx
similarity index 100%
rename from versioned_docs/version-1.1.0/Protocol/guardian.md
rename to previous_versions/version_1/guardian.mdx
diff --git a/docs/protocol/aqua-identity-protocol.md b/previous_versions/version_1/idenity_protocol.mdx
similarity index 99%
rename from docs/protocol/aqua-identity-protocol.md
rename to previous_versions/version_1/idenity_protocol.mdx
index 3d46bba6..799596ac 100644
--- a/docs/protocol/aqua-identity-protocol.md
+++ b/previous_versions/version_1/idenity_protocol.mdx
@@ -1,8 +1,5 @@
---
title: "Identity Protocol"
-linkTitle: "Identity Protocol"
-weight: 2
-sidebar_position: 3
description: >
The following text has the goal to highlight the possibility to build identity protocol functionality on top of the core verifiction protocol.
This part of the project is in early stages and not mature.
@@ -297,7 +294,7 @@ are account bound.
- 0 - valid
- 1 - revoked
-<!-- -->
+
- **`<valid until>`** \[type: date DDMMYYYY\]: if current date past
expiration date, the claim is considered expired and is not accepted
diff --git a/versioned_docs/version-1.1.0/Protocol/immutable-hyperlinks.md b/previous_versions/version_1/immutable_hyperlinks.mdx
similarity index 100%
rename from versioned_docs/version-1.1.0/Protocol/immutable-hyperlinks.md
rename to previous_versions/version_1/immutable_hyperlinks.mdx
diff --git a/versioned_docs/version-1.1.0/intro.md b/previous_versions/version_1/introduction.mdx
similarity index 98%
rename from versioned_docs/version-1.1.0/intro.md
rename to previous_versions/version_1/introduction.mdx
index fd5ba3aa..4901c435 100644
--- a/versioned_docs/version-1.1.0/intro.md
+++ b/previous_versions/version_1/introduction.mdx
@@ -1,12 +1,11 @@
---
-title: "Overview"
-linkTitle: "Overview"
-weight: 1
-sidebar_position: 1
-description: >
-
+title: 'Aqua Protocol Version 1'
+description: 'An overview of verision 1 of the Aqua protocol'
---
+
+
+
We develop the AQUA-Protocol to increase trust and digital sovereignty for individuals and organizations.
We believe that this is an effective way to redefine collaboration and strengthen democracy to be more inclusive and participatory by providing accountability for data. We do this in a context where it is critical to address challenges and threats which come with the advancement of technologies (e.g. deep fake, manipulation of data, digital surveillance, monopolization).
diff --git a/docs/protocol/aqua-name-resolution.md b/previous_versions/version_1/name_resolution.mdx
similarity index 75%
rename from docs/protocol/aqua-name-resolution.md
rename to previous_versions/version_1/name_resolution.mdx
index 87ca9863..bc65da84 100644
--- a/docs/protocol/aqua-name-resolution.md
+++ b/previous_versions/version_1/name_resolution.mdx
@@ -1,10 +1,6 @@
---
title: "Aqua Name Resolution (ANS)"
-linkTitle: "Name Resolution"
-weight: 3
-sidebar_position: 4
-description: >
- ANS is used to hashes of various types to human readable names
+description: ANS is used to hashes of various types to human readable names
---
ANS is used to resolve hashes of various types to human readable names.
diff --git a/versioned_docs/version-1.1.0/Protocol/whitepaper.md b/previous_versions/version_1/whitepaper.mdx
similarity index 99%
rename from versioned_docs/version-1.1.0/Protocol/whitepaper.md
rename to previous_versions/version_1/whitepaper.mdx
index 718443d9..4189150a 100644
--- a/versioned_docs/version-1.1.0/Protocol/whitepaper.md
+++ b/previous_versions/version_1/whitepaper.mdx
@@ -1,10 +1,7 @@
---
title: Whitepaper
linkTitle: "Whitepaper"
-weight: 1
-sidebar_position: 1
-description: >
- High level outline of Aqua Protocol (AQP) specification
+description: High level outline of Aqua Protocol (AQP) specification
---
diff --git a/versioned_docs/version-1.2.0/references.md b/previous_versions/version_2/concepts.mdx
similarity index 68%
rename from versioned_docs/version-1.2.0/references.md
rename to previous_versions/version_2/concepts.mdx
index 61060e1b..234265bf 100644
--- a/versioned_docs/version-1.2.0/references.md
+++ b/previous_versions/version_2/concepts.mdx
@@ -1,9 +1,76 @@
---
-title: "References"
-
+title: "Concepts"
+description: 'An of the terms used in version 2 of the protocol'
---
-## Signature
+
+
+## Data Structure:
+This are the basics to get you started but for a thorough understanding one done with the sections below have a look at references section to get a thorough understanding for example what is a witness, wtness network and how are witness hash created.
+
+The aqua chain structure can be broken into a the following components :
+
+
+### Revision
+
+A revision is the smallest portable entity within the AQP. Multiple revisions
+form a single portable hash chain which is serialized in JSON format.
+They have existed before in unsecured systems where multiple revisions form a
+file which can be displayed as a page. The AQP adds the cryptographic harness
+to secure it. With presenting a portable hash chain, it is possible to track
+all incremental changes stored in each revision to understand the history of a
+page and how it came to be. This allows us to have version control on digital
+assets being able to restore earlier states and to relate to them. This allows
+us to have historical evidence of digital assets.
+<br/>
+
+Every revision is represented by a merkle-root hash representing a list of alphabetically ordered key-value pairs which are hashed (implementation example SHA3-512). This allows us to dynamically change the data structure without the need to introduce breaking protocol changes.
+
+ * The input data MUST NOT have dublicated keys as this would lead to non-deterministic ordering.
+
+Aqua-Chain: Is a portable hash-chain. This provides immutability for the history of the file, once signed and/or witnessed with the respective security guarantees.
+Aqua-revisions form a portable Aqua-Chain.
+
+There are 4 Types of Revisions:
+ * Content Revision: Contains the data object(the data/file encoded to base 64).This is used to secure the data integrity and reference the data object for provenance purposes.
+ * Signature Revision: Is used to cryptographically sign, we are currently supporting Ethereum signatures.
+ * Witness Revision: Used to witness the Hash to prove its existence. We are supporting Ethereum by default.
+ * Metadata Revision: used to ensure content revision is valid.
+
+
+
+### Page
+
+A page is a visible representation of a file containing multiple or a single
+revision attributed to a shared origin. A page view could also be used to
+create a new revision by a used service which interfaces with the file for
+manipulation. In AQP all revisions share a global URI hash to
+attribute them together called a genesis hash.
+
+
+
+### Witness
+
+We define witnessing as the process of observing an event. A witness is judged
+by their capability to recollect and share an observed event. In other words,
+witnessing is the process of storing input data for later playback to provide
+data symmetry around an event.
+
+### Witness Network
+
+The digital service in a distributed ledger or similar infrastructure which
+provides transaction security and data symmetry for shared data within the
+network. An example of a witness network would be Ethereum.
+
+E.g. Ethereum can be used to store a digital fingerprint of a domain snapshot
+of a data vault. A domain snapshot is the Merklized state of all witnessed hash
+chains being present in the data vault. It is required to pay the witness
+network for its service. In the case of Ethereum, this is done using 'Ether'.
+This in return allows the account owner to create an 'undeniable' proof that a
+specific revision and the previous revisions within a hash chain has existed.
+
+
+### Signature
A signature in AQP is a cryptographic signature generated by public-private key pair. The protocol should be abstract, where it will support ‘Method’ in later iterations. This will allow us to use different types of implementations such as: `PGP signatures`, `Ethereum`, or `Bitcoin wallet ’s` signatures.
@@ -22,7 +89,7 @@ I sign the following page verification_hash:" +[0x0x9dab72<revision_verification
```
-## Wallet
+### Wallet
A wallet is a software for protecting and managing private cryptographic keys
(of private-public key pairs) which are used to govern digital assets. This is
done by authorization of transactions via digital signatures or by initiating
@@ -93,7 +160,7 @@ Service](design-principles.md#separation-of-account-and-service)
-## Metadata
+### Metadata
```
metadata_hash = calculate_hash_sum(
@@ -113,7 +180,7 @@ Description:
-## Witness
+### Witness
Witnessing allows one to undeniably prove the existence of a dataset
(represented as a portable hash chain). To complete the witnessing process, a
@@ -143,14 +210,14 @@ witness_hash = calculate_hash_sum(
We are using the Ethereum Network as an optional Witness Network for
cryptographic time-stamping.
-## Encryption
+### Encryption
according to wikipedia
```
In cryptography, encryption (more specifically, encoding) is the process of transforming information in a way that, ideally, only authorized parties can decode. This process converts the original representation of the information, known as plaintext, into an alternative form known as ciphertext. Despite its goal, encryption does not itself prevent interference but denies the intelligible content to a would-be interceptor.
```
-## Hash
+### Hash
according to investopedia
```
diff --git a/versioned_docs/version-1.2.0/prologue.md b/previous_versions/version_2/introduction.mdx
similarity index 100%
rename from versioned_docs/version-1.2.0/prologue.md
rename to previous_versions/version_2/introduction.mdx
diff --git a/previous_versions/version_2/tooling.mdx b/previous_versions/version_2/tooling.mdx
new file mode 100644
index 00000000..8df0c0ef
--- /dev/null
+++ b/previous_versions/version_2/tooling.mdx
@@ -0,0 +1,167 @@
+---
+title: "Aqua Protocol Tooling & Components"
+description: "Overview of Aqua Protocol v1.2 tools and components"
+---
+
+# Aqua Protocol Tooling & Components
+
+This document provides a comprehensive overview of all the tools and components available in the Aqua Protocol ecosystem version 1.2.
+
+## Aqua CLI
+
+Aqua CLI is a command line utility that enables you to create, verify, witness, and sign aqua chains. There are two implementations available:
+
+### Rust Implementation (Recommended)
+
+The Rust CLI is the stable implementation and the recommended choice for getting started with the Aqua protocol.
+
+**Installation:**
+- Via cargo: `cargo install aqua-cli`
+- Building from source:
+ ```bash
+ git clone git@github.com:inblockio/aqua-cli-rs.git
+ cargo build --release
+ cd target/release/ && cp aqua-cli /usr/bin
+ ```
+
+**Repository:** https://github.com/inblockio/aqua-cli-rs
+
+**Key Features:**
+- Verify aqua chain JSON files
+- Generate aqua chains
+- Generate validation reports
+- Sign and witness aqua chains
+
+**Available Commands:**
+- `-a` or `--authenticate`: Verify an aqua JSON file
+- `-s` or `--sign`: Sign an aqua JSON file
+- `-w` or `--witness`: Witness an aqua JSON file
+- `-f` or `--file`: Generate an aqua JSON file
+- `-v` or `--verbose`: Provide logs about the process
+- `-o` or `--output`: Save output to file (JSON, HTML, or PDF)
+- `-l` or `--level`: Define validation strictness (1 or 2)
+- `-d` or `--delete`: Remove revision from an aqua JSON file
+- `-c` or `--count`: Specify number of revisions to remove
+
+**Environment Variables:**
+- `aqua_domain`: Random alphanumeric value
+- `aqua_network`: "sepolia", "holesky", or "mainnet"
+- `verification_platform`: "alchemy", "infura", or "none" (default: "none")
+- `aqua_alchemy_look_up`: true or false
+
+**Example Usage:**
+```bash
+aqua-cli -a chain.json
+aqua-cli -s chain.json --output report.json
+aqua-cli -w chain.json --output report.json
+aqua-cli -f document.pdf
+aqua-cli --file image.png --verbose
+```
+
+### JavaScript Implementation
+
+The JavaScript implementation is used to quickly prototype ideas.
+
+**Repository:** https://github.com/inblockio/aqua-verifier-js
+
+:::warning
+If you are just getting started, use the Rust CLI. The JS version is primarily used to prototype ideas.
+:::
+
+**Environment Setup:**
+1. Install Node.js (latest version)
+2. Ensure you have Yarn or npm installed
+
+**Installation:**
+```bash
+git clone git@github.com:inblockio/aqua-cli-js.git
+cd aqua-cli-js && npm i && npm build
+```
+
+**Configuration:**
+Create a `credentials.json` file with the following structure:
+```json
+{
+ "mnemonic": "sample sample sample sample sample sample sample sample sample sample sample author matter",
+ "nostr_sk": "xxxxxxxxxxxxxxxx",
+ "did:key": "xxxxxxxxxxxxxx"
+}
+```
+
+**Usage Commands:**
+
+**Notarize:**
+```bash
+./notarize.js [OPTIONS] <filename>
+```
+Options:
+- `--sign [cli|metamask|did]`: Sign with Ethereum seed phrase, MetaMask, or DID key
+- `--witness-eth`: Witness to Ethereum on-chain with MetaMask
+- `--witness-nostr`: Witness to Nostr network
+- `--witness-tsa`: Witness to TSA DigiCert
+- `--link <filename.aqua.json>`: Add a link to an AQUA chain as a dependency
+
+**Verify:**
+```bash
+./verify.js [OPTIONS] <page title>
+# or
+./verify.js [OPTIONS] --file <offline file.json or file.xml>
+```
+Options:
+- `-v`: Verbose
+- `--server`: The URL of the server (e.g., https://pkc.inblock.io)
+- `--ignore-merkle-proof`: Ignore verifying the witness merkle proof
+- `--file`: The file to read from for the data
+
+## Aqua Container (Aquafier)
+
+Aqua Container is a Rust web application with a React frontend that implements the Aqua protocol. It enables data to be signed, witnessed, and verified through a web browser interface.
+
+**Try it online:** https://aquafire.aqua-protocol.org/
+
+**Technical Details:**
+- Backend: Axum web server in Rust
+- Frontend: React (TypeScript)
+- Database: SQLite with Diesel ORM
+- Communication: HTTP protocol
+- File size limit: 20 MB maximum
+- Docker container available for quick deployment
+
+**Repository:** https://github.com/inblockio/aqua-verifier-rs
+
+The container is built using the same libraries as the CLI, providing all CLI capabilities with a graphical interface.
+
+## Aqua Verifier (Chrome Extension)
+
+The Aqua Verifier is a Chrome extension that can be used to verify aqua chains directly in your browser. This is the easiest and fastest way to get started with the Aqua protocol.
+
+**Installation:** Available on the [Chrome Web Store](https://chromewebstore.google.com/detail/verifypage/gadnjidhhadchnegnpadkibmjlgihiaj)
+
+## Personal Knowledge Container (PKC)
+
+The Personal Knowledge Container was a prototype implementation of Aqua protocol v1.1.
+
+:::note
+For information about PKC, please refer to version 1.1 documentation.
+:::
+
+## Aqua Guardian
+
+Aqua Guardian is a security gateway designed to exchange Aqua-Chains and enforce policies of Aqua-Contracts. It provides secure connectivity between Guardians and verifies the integrity of Aqua storage containers.
+
+:::warning
+The Aqua Guardian still uses Aqua protocol version 1.1, making it incompatible with protocol 1.2 and all tools that use protocol 1.2 (such as Aqua Container and Aqua CLI).
+:::
+
+## Why Two CLI Implementations?
+
+The JavaScript implementation enables rapid prototyping of new ideas, while the Rust implementation provides stability and production-ready features. This dual approach allows the team to experiment quickly while maintaining a reliable tool for end users.
+
+## Getting Started
+
+For most users, we recommend starting with either:
+1. **Aqua Verifier Chrome Extension** - For the quickest and easiest start
+2. **Aqua CLI (Rust)** - For command-line users who want full control
+3. **Aqua Container Sandbox** - For a web-based graphical interface
+
+All tools support the core Aqua protocol operations: creating, signing, witnessing, and verifying aqua chains to ensure data integrity.
diff --git a/previous_versions/version_3/concepts.mdx b/previous_versions/version_3/concepts.mdx
new file mode 100644
index 00000000..6843e25d
--- /dev/null
+++ b/previous_versions/version_3/concepts.mdx
@@ -0,0 +1,611 @@
+---
+title: "Concepts"
+description: "Core concepts and terminology for Aqua Protocol v3"
+---
+
+# Aqua Protocol v3 Concepts
+
+Understanding the core concepts of Aqua Protocol v3 is essential for effectively using the SDK and building applications. This guide covers the fundamental ideas, terminology, and patterns used throughout the protocol.
+
+## AquaTree
+
+The **AquaTree** is the primary data structure in v3. It represents a complete, self-contained collection of revisions with their relationships and metadata.
+
+### Structure
+
+```typescript
+interface AquaTree {
+ revisions: Revisions // All revisions indexed by hash
+ file_index: FileIndex // Maps file hashes to filenames
+ tree?: RevisionTree // Tree structure of revisions
+ treeMapping?: TreeMapping // Path mappings for navigation
+}
+```
+
+### Components
+
+#### 1. Revisions
+A flat map of all revisions, keyed by their verification hash:
+
+```typescript
+{
+ "0xabc123...": {
+ previous_verification_hash: "0xdef456...",
+ local_timestamp: "2024-01-01T12:00:00",
+ revision_type: "file",
+ // ... other fields
+ },
+ "0xdef456...": {
+ // ... another revision
+ }
+}
+```
+
+#### 2. File Index
+Maps file content hashes to filenames for reference:
+
+```typescript
+{
+ "0xfile_hash_1": "document.pdf",
+ "0xfile_hash_2": "image.png"
+}
+```
+
+#### 3. Tree Structure (Optional)
+Hierarchical representation showing parent-child relationships:
+
+```typescript
+{
+ hash: "0xabc123...", // Root revision
+ children: [
+ {
+ hash: "0xdef456...",
+ children: [...]
+ }
+ ]
+}
+```
+
+#### 4. Tree Mapping (Optional)
+Path information for each revision:
+
+```typescript
+{
+ paths: {
+ "0xabc123": ["0xroot", "0xabc123"],
+ "0xdef456": ["0xroot", "0xabc123", "0xdef456"]
+ },
+ latestHash: "0xdef456..." // Most recent revision
+}
+```
+
+## Revisions
+
+A **Revision** is a single entry in the AquaTree representing an operation or state change.
+
+### Common Fields
+
+All revisions share these base fields:
+
+| Field | Type | Description |
+|-------|------|-------------|
+| `previous_verification_hash` | string | Hash linking to previous revision (empty string for genesis) |
+| `local_timestamp` | string | ISO 8601 timestamp when revision was created |
+| `revision_type` | string | One of: `"file"`, `"form"`, `"signature"`, `"witness"`, `"link"` |
+| `version` | string | Protocol version with method: `https://aqua-protocol.org/docs/v3/schema_2 \| SHA256 \| Method: scalar/tree` |
+
+### Genesis Revision
+
+The **genesis revision** is the first revision in a chain:
+- `previous_verification_hash` is an empty string `""`
+- Typically a file or form revision
+- Establishes the initial state
+
+### Verification Hash
+
+Each revision has a unique **verification hash** computed from its canonical form:
+
+```typescript
+hash = SHA256(canonicalized_revision_data)
+```
+
+This hash serves as:
+- Unique identifier for the revision
+- Key in the revisions map
+- Reference in `previous_verification_hash` fields
+
+## Revision Types
+
+### 1. File Revision
+
+Stores file metadata and optionally content.
+
+**Purpose**: Document file presence and content integrity
+
+**Fields**:
+- `file_hash`: SHA256 hash of file content
+- `file_nonce`: Random nonce for uniqueness
+- `content`: Optional file content (text or binary)
+- `leaves`: Array of hashes (tree mode only)
+
+**Example**:
+```json
+{
+ "previous_verification_hash": "",
+ "local_timestamp": "2024-01-01T12:00:00",
+ "revision_type": "file",
+ "version": "https://aqua-protocol.org/docs/v3/schema_2 | SHA256 | Method: scalar",
+ "file_hash": "0x9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08",
+ "file_nonce": "0x3fa8b1c2d3e4f5a67b8c9d0e1f2a3b4c"
+}
+```
+
+### 2. Form Revision
+
+Stores structured key-value data.
+
+**Purpose**: Capture form submissions, structured data, or metadata
+
+**Fields**:
+- `file_hash`: Hash of form data
+- `file_nonce`: Random nonce
+- `content`: Form data as key-value object
+- `leaves`: Array of hashes (tree mode only)
+
+**Example**:
+```json
+{
+ "previous_verification_hash": "",
+ "local_timestamp": "2024-01-01T12:00:00",
+ "revision_type": "form",
+ "version": "https://aqua-protocol.org/docs/v3/schema_2 | SHA256 | Method: tree",
+ "file_hash": "0xabc123...",
+ "file_nonce": "0x123abc...",
+ "content": {
+ "name": "John Doe",
+ "email": "john@example.com",
+ "status": "approved"
+ },
+ "leaves": ["0x...", "0x...", "0x..."]
+}
+```
+
+### 3. Signature Revision
+
+Adds cryptographic signature to prove authenticity.
+
+**Purpose**: Authenticate revisions and establish authorship
+
+**Fields**:
+- `signature`: Signature value (format depends on type)
+- `signature_type`: One of `"cli"`, `"metamask"`, `"did"`, `"p12"`, `"inline"`
+- `signature_wallet_address`: Ethereum address (for cli/metamask)
+- `signature_public_key`: Public key (for p12)
+
+**Example (MetaMask)**:
+```json
+{
+ "previous_verification_hash": "0xabc123...",
+ "local_timestamp": "2024-01-01T12:01:00",
+ "revision_type": "signature",
+ "version": "https://aqua-protocol.org/docs/v3/schema_2 | SHA256 | Method: scalar",
+ "signature_type": "metamask",
+ "signature": "0x8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f...",
+ "signature_wallet_address": "0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb8"
+}
+```
+
+**Example (DID)**:
+```json
+{
+ "previous_verification_hash": "0xabc123...",
+ "local_timestamp": "2024-01-01T12:01:00",
+ "revision_type": "signature",
+ "version": "https://aqua-protocol.org/docs/v3/schema_2 | SHA256 | Method: scalar",
+ "signature_type": "did",
+ "signature": {
+ "payload": "eyJhbGciOi...",
+ "signatures": [{
+ "protected": "eyJhbGci...",
+ "signature": "..."
+ }]
+ }
+}
+```
+
+### 4. Witness Revision
+
+Anchors revision to external timestamping service.
+
+**Purpose**: Prove existence at specific time via blockchain or TSA
+
+**Fields**:
+- `witness_merkle_root`: Root hash of Merkle tree
+- `witness_timestamp`: Unix timestamp from witness service
+- `witness_network`: Network used (`"mainnet"`, `"sepolia"`, `"holesky"`, `"tsa"`, `"nostr"`)
+- `witness_smart_contract_address`: Contract address (Ethereum)
+- `witness_transaction_hash`: Transaction hash
+- `witness_sender_account_address`: Account that witnessed
+- `witness_merkle_proof`: Merkle proof array
+
+**Example (Ethereum)**:
+```json
+{
+ "previous_verification_hash": "0xabc123...",
+ "local_timestamp": "2024-01-01T12:02:00",
+ "revision_type": "witness",
+ "version": "https://aqua-protocol.org/docs/v3/schema_2 | SHA256 | Method: scalar",
+ "witness_merkle_root": "0xdef456...",
+ "witness_timestamp": 1704110520,
+ "witness_network": "sepolia",
+ "witness_smart_contract_address": "0x5FbDB2315678afecb367f032d93F642f64180aa3",
+ "witness_transaction_hash": "0x9f86d081...",
+ "witness_sender_account_address": "0x742d35Cc...",
+ "witness_merkle_proof": []
+}
+```
+
+### 5. Link Revision
+
+Connects to other AquaTree chains.
+
+**Purpose**: Establish relationships between separate chains
+
+**Fields**:
+- `link_type`: Type of link relationship (application-specific)
+- `link_verification_hashes`: Array of hashes from other chains
+- `link_file_hashes`: Array of corresponding file hashes
+
+**Example**:
+```json
+{
+ "previous_verification_hash": "0xabc123...",
+ "local_timestamp": "2024-01-01T12:03:00",
+ "revision_type": "link",
+ "version": "https://aqua-protocol.org/docs/v3/schema_2 | SHA256 | Method: scalar",
+ "link_type": "dependency",
+ "link_verification_hashes": [
+ "0x111...",
+ "0x222...",
+ "0x333..."
+ ],
+ "link_file_hashes": [
+ "0xaaa...",
+ "0xbbb...",
+ "0xccc..."
+ ]
+}
+```
+
+## Methods: Scalar vs Tree
+
+V3 supports two canonicalization methods, specified in the version string.
+
+### Scalar Method
+
+**Format**: `Method: scalar`
+
+**How it works**:
+- Revision is serialized as-is
+- Hash computed directly from canonical JSON
+- Simple, straightforward
+
+**When to use**:
+- Small revisions
+- Simple file/form data
+- Quick operations
+
+**Example**:
+```typescript
+version: "https://aqua-protocol.org/docs/v3/schema_2 | SHA256 | Method: scalar"
+// No leaves field
+```
+
+### Tree Method
+
+**Format**: `Method: tree`
+
+**How it works**:
+- Content broken into key-value leaves
+- Each leaf hashed individually
+- Merkle tree constructed from leaves
+- Root becomes the verification hash
+
+**When to use**:
+- Large files or forms
+- Selective disclosure needed
+- Proof of specific fields
+
+**Example**:
+```typescript
+version: "https://aqua-protocol.org/docs/v3/schema_2 | SHA256 | Method: tree"
+leaves: [
+ "0xhash_of_key_value_1",
+ "0xhash_of_key_value_2",
+ "0xhash_of_key_value_3"
+]
+```
+
+**Leaf Generation**:
+```typescript
+// For form data: { "name": "John", "email": "john@example.com" }
+leaves = [
+ SHA256("name:John"),
+ SHA256("email:john@example.com")
+]
+```
+
+## Chains and Trees
+
+### Linear Chain
+
+Simple sequence of revisions:
+
+```
+Genesis Signature Witness Update Signature Witness
+```
+
+Each revision references the previous one.
+
+### Branching Tree
+
+Multiple paths from a common ancestor:
+
+```
+ Genesis
+
+ Signature
+ / \
+ Branch A Branch B
+
+ Update 1 Update 2
+```
+
+V3 supports branching, allowing parallel development paths.
+
+### Path Mapping
+
+The `treeMapping` provides paths to each revision:
+
+```typescript
+{
+ paths: {
+ "genesis_hash": ["genesis_hash"],
+ "sig_hash": ["genesis_hash", "sig_hash"],
+ "branch_a_hash": ["genesis_hash", "sig_hash", "branch_a_hash"],
+ "branch_b_hash": ["genesis_hash", "sig_hash", "branch_b_hash"]
+ },
+ latestHash: "branch_a_hash" // Longest path
+}
+```
+
+## File Object
+
+Input format for creating revisions:
+
+```typescript
+interface FileObject {
+ fileName: string // Display name
+ fileContent: string | // Text content
+ AquaTree | // Linked tree
+ Uint8Array | // Binary data
+ Record<string, string> | // Form data
+ object // Structured data
+ path: string // File path
+ fileSize?: number // Size in bytes
+}
+```
+
+### Content Types
+
+**Text**: Plain text, HTML, JSON
+```typescript
+{
+ fileName: "doc.txt",
+ fileContent: "Hello World",
+ path: "/docs/doc.txt"
+}
+```
+
+**Binary**: Images, PDFs, any binary file
+```typescript
+{
+ fileName: "image.png",
+ fileContent: new Uint8Array([...]),
+ path: "/images/image.png"
+}
+```
+
+**Form**: Key-value structured data
+```typescript
+{
+ fileName: "form.json",
+ fileContent: {
+ "field1": "value1",
+ "field2": "value2"
+ },
+ path: "/forms/form.json"
+}
+```
+
+**Link**: Reference to another AquaTree
+```typescript
+{
+ fileName: "linked.json",
+ fileContent: anotherAquaTree,
+ path: "/links/linked.json"
+}
+```
+
+## Verification Graph
+
+Result of verification includes a graph structure:
+
+```typescript
+interface VerificationGraphData {
+ hash: string
+ previous_verification_hash: string
+ timestamp: string
+ isValidationSuccessful: boolean
+ revisionType: RevisionType
+ info: RevisionGraphInfo // Type-specific details
+ verificationGraphData: VerificationGraphData[] // Children
+ linkVerificationGraphData: VerificationGraphData[] // Links
+}
+```
+
+### Traversing the Graph
+
+```typescript
+function printVerification(graph: VerificationGraphData, depth = 0) {
+ const indent = " ".repeat(depth);
+ const status = graph.isValidationSuccessful ? "" : "";
+ console.log(`${indent}${status} ${graph.revisionType} (${graph.hash.slice(0, 10)}...)`);
+
+ // Traverse children
+ graph.verificationGraphData.forEach(child => {
+ printVerification(child, depth + 1);
+ });
+
+ // Traverse links
+ graph.linkVerificationGraphData.forEach(link => {
+ console.log(`${indent} Linked:`);
+ printVerification(link, depth + 2);
+ });
+}
+```
+
+## Credentials
+
+Configuration for signing and witnessing:
+
+```typescript
+interface CredentialsData {
+ mnemonic: string // BIP39 mnemonic for CLI signing
+ nostr_sk: string // Nostr secret key
+ did_key: string // DID key for DID signing
+ alchemy_key: string // Alchemy API key for verification
+ witness_eth_network: string // "mainnet", "sepolia", "holesky"
+ witness_method: string // "cli" or "metamask"
+ p12_password?: string // P12 certificate password
+ p12_content?: string // P12 certificate content
+}
+```
+
+## Logging
+
+V3 uses typed logging throughout:
+
+```typescript
+enum LogType {
+ SUCCESS = "success",
+ INFO = "info",
+ ERROR = "error",
+ WARNING = "warning",
+ HINT = "hint",
+ DEBUGDATA = "debug_data",
+ // ... revision types with emojis
+ FILE = "file", // =
+ LINK = "link", // =
+ SIGNATURE = "signature", // =
+ WITNESS = "witness", // =@
+ FORM = "form" // =
+}
+```
+
+Each operation returns logs for debugging and user feedback.
+
+## Best Practices
+
+### 1. Genesis Patterns
+
+**Single File**:
+```
+File Genesis Sign Witness
+```
+
+**Form Data**:
+```
+Form Genesis Sign Witness
+```
+
+### 2. Update Patterns
+
+**Content Update**:
+```
+... New File Revision Sign Witness
+```
+
+**Multi-Party**:
+```
+... Sign (Party 1) Sign (Party 2) Witness
+```
+
+### 3. Linking Patterns
+
+**Dependencies**:
+```
+Main Document Link (to dependencies) Sign Witness
+```
+
+**Aggregation**:
+```
+Component 1
+Component 2 Aggregation Link Sign Witness
+Component 3
+```
+
+### 4. Verification Patterns
+
+**Full Chain**:
+```typescript
+const result = await aquafier.verifyRevisionChain(aquaTree);
+```
+
+**Specific Revision**:
+```typescript
+const revision = aquaTree.revisions[specificHash];
+// Manually verify hash computation
+```
+
+### 5. Storage Patterns
+
+**Database**: Store serialized AquaTree JSON
+```typescript
+const json = JSON.stringify(aquaTree);
+db.save(documentId, json);
+```
+
+**File System**: Save as .aqua.json file
+```typescript
+fs.writeFileSync('document.aqua.json', JSON.stringify(aquaTree, null, 2));
+```
+
+## Common Patterns
+
+### Document Lifecycle
+
+```
+1. Create File Genesis
+2. Review Sign (Reviewer)
+3. Approve Sign (Approver)
+4. Timestamp Witness (Ethereum)
+5. Archive Store AquaTree
+6. Verify Check entire chain
+```
+
+### Multi-Document Project
+
+```
+1. Create each document Individual AquaTrees
+2. Link together Link Revision in main tree
+3. Sign project Sign main tree
+4. Witness Witness main tree
+5. All documents timestamped through link
+```
+
+## See Also
+
+- [Introduction](/previous_versions/version_3/introduction) - Overview and quick start
+- [Tooling](/previous_versions/version_3/tooling) - SDK API reference
+- [Schema Reference](/previous_versions/version_3/schema) - Detailed specifications
diff --git a/previous_versions/version_3/introduction.mdx b/previous_versions/version_3/introduction.mdx
new file mode 100644
index 00000000..bebbb6d6
--- /dev/null
+++ b/previous_versions/version_3/introduction.mdx
@@ -0,0 +1,302 @@
+---
+title: "Aqua Protocol v3"
+description: "Introduction to Aqua Protocol version 3 with JavaScript/TypeScript SDK"
+---
+
+# Aqua Protocol v3
+
+Aqua Protocol v3 is a mature version of the protocol with a comprehensive JavaScript/TypeScript SDK. It provides a robust framework for creating verifiable revision chains with support for files, forms, signatures, witnesses, and links.
+
+## Overview
+
+Version 3 represents a stable, production-ready implementation of the Aqua Protocol specifically designed for JavaScript/TypeScript environments. It offers:
+
+- **Cross-Platform Support**: Node.js, Web browsers, and React Native
+- **Type Safety**: Full TypeScript support with comprehensive type definitions
+- **Flexible Revision Types**: File, Form, Signature, Witness, and Link revisions
+- **Multiple Signing Methods**: CLI, MetaMask, DID, and P12 certificate signing
+- **Multi-Network Witnessing**: Ethereum (mainnet, Sepolia, Holesky), Nostr, and TSA
+- **Tree Structure**: Native support for revision trees and path mapping
+
+## Version Identifier
+
+```
+https://aqua-protocol.org/docs/v3/schema_2 | SHA256 | Method: scalar/tree
+```
+
+## Core Components
+
+### AquaTree Structure
+
+The AquaTree is the core data structure in v3:
+
+```typescript
+interface AquaTree {
+ revisions: Revisions // Map of revision hash to revision data
+ file_index: FileIndex // Map of file hash to filename
+ tree?: RevisionTree // Tree structure representation
+ treeMapping?: TreeMapping // Path mappings for navigation
+}
+```
+
+### Revision Types
+
+V3 supports five types of revisions:
+
+1. **File Revision** - Store file metadata and content hashes
+2. **Form Revision** - Store structured form data with key-value pairs
+3. **Signature Revision** - Add cryptographic signatures
+4. **Witness Revision** - Timestamp via blockchain or TSA
+5. **Link Revision** - Connect to other AquaTree chains
+
+## Key Features
+
+### 1. Dual Mode Support
+
+**Scalar Mode**: Direct hash computation
+```typescript
+version: "https://aqua-protocol.org/docs/v3/schema_2 | SHA256 | Method: scalar"
+```
+
+**Tree Mode**: Merkle tree-based with leaves
+```typescript
+version: "https://aqua-protocol.org/docs/v3/schema_2 | SHA256 | Method: tree"
+leaves: ["hash1", "hash2", "hash3", ...]
+```
+
+### 2. Platform Flexibility
+
+```typescript
+// Node.js
+import Aquafier from 'aqua-js-sdk';
+
+// Web Browser
+import Aquafier from 'aqua-js-sdk/web';
+
+// React Native
+import Aquafier from 'aqua-js-sdk/react-native';
+```
+
+### 3. Comprehensive Signing
+
+- **CLI Signing**: Uses mnemonic phrase
+- **MetaMask**: Browser extension integration
+- **DID**: Decentralized identifiers with JWS
+- **P12**: Certificate-based signing
+- **Inline**: Pre-computed signatures
+
+### 4. Multi-Network Witnessing
+
+- **Ethereum**: Mainnet, Sepolia, Holesky testnets
+- **Nostr**: Decentralized social network
+- **TSA**: RFC 3161 timestamp authorities
+
+### 5. Content Flexibility
+
+File content can be:
+- **Text**: HTML, plain text, JSON
+- **Binary**: Images, PDFs, any file type (as Uint8Array)
+- **Forms**: Key-value structured data
+- **Links**: References to other AquaTrees
+
+## Quick Start Example
+
+```typescript
+import Aquafier, { FileObject } from 'aqua-js-sdk';
+
+// Initialize Aquafier
+const aquafier = new Aquafier();
+
+// Create file object
+const fileObject: FileObject = {
+ fileName: "document.txt",
+ fileContent: "Important document content",
+ path: "/documents/document.txt"
+};
+
+// Create genesis revision
+const result = await aquafier.createGenesisRevision(fileObject);
+
+if (result.isErr) {
+ console.error("Error creating revision");
+ result.logs.forEach(log => console.log(log));
+ return;
+}
+
+// Access the AquaTree
+const aquaTree = result.data.aquaTree;
+
+// Sign the revision
+const signResult = await aquafier.signRevision(
+ aquaTree,
+ "cli", // or "metamask", "did", "p12"
+ credentials
+);
+
+// Witness to blockchain
+const witnessResult = await aquafier.witnessRevision(
+ signResult.data.aquaTree,
+ "eth", // or "nostr", "tsa"
+ witnessConfig
+);
+
+// Save aquaTree JSON for storage/transmission
+const json = JSON.stringify(witnessResult.data.aquaTree);
+```
+
+## Architecture
+
+### Revision Chain Structure
+
+```
+Genesis Revision (File/Form)
+ ↓ previous_verification_hash
+Signature Revision
+ ↓ previous_verification_hash
+Witness Revision
+ ↓ previous_verification_hash
+New Content Revision
+ ↓ previous_verification_hash
+...
+```
+
+### Tree Branching
+
+V3 supports tree structures for branching revisions:
+
+```
+ Genesis
+ ↓
+ Signature
+ / \
+ Branch A Branch B
+ ↓ ↓
+ Update 1 Update 2
+```
+
+## Common Fields
+
+All revisions share these core fields:
+
+| Field | Type | Description |
+|-------|------|-------------|
+| `previous_verification_hash` | string | Hash of previous revision (empty for genesis) |
+| `local_timestamp` | string | ISO 8601 timestamp |
+| `revision_type` | string | Type: `"file"`, `"form"`, `"signature"`, `"witness"`, `"link"` |
+| `version` | string | Protocol version and method identifier |
+
+## Installation
+
+```bash
+npm install aqua-js-sdk
+```
+
+### Requirements
+
+- Node.js v20.9.0 or later
+- TypeScript 5.3+ (optional, for type checking)
+
+### Peer Dependencies
+
+- `ethers` ^6.7.1 (for Ethereum operations)
+- `react-native-fs` (optional, for React Native)
+- `@react-native-async-storage/async-storage` (optional, for React Native)
+
+## Use Cases
+
+### Document Notarization
+```
+Document → Sign (Author) → Witness (Ethereum) → Verifiable Proof
+```
+
+### Form Data Accountability
+```
+Form Submission → Sign (User) → Witness → Audit Trail
+```
+
+### Multi-Party Approval
+```
+Document → Sign (Party 1) → Sign (Party 2) → Witness → Approved
+```
+
+### Supply Chain Tracking
+```
+Event 1 → Link to Event 2 → Link to Event 3 → Complete Chain
+```
+
+### Content Versioning
+```
+Version 1 → Update → Version 2 → Update → Version 3 → History
+```
+
+## Verification
+
+V3 includes comprehensive verification capabilities:
+
+```typescript
+// Verify entire chain
+const verification = await aquafier.verifyRevisionChain(aquaTree);
+
+// Check results
+verification.verificationGraphData.forEach(node => {
+ console.log(`${node.revisionType}: ${node.isValidationSuccessful ? '✓' : '✗'}`);
+});
+```
+
+## Key Differences from v4
+
+| Feature | v3 | v4 |
+|---------|----|----|
+| Language | JavaScript/TypeScript | Rust (with WASM support) |
+| Template System | No formal templates | Template revisions with JSON Schema |
+| Signature Types | 4 types (CLI, MetaMask, DID, P12) | 3 types (RSA, EIP-191, DID:JWS) |
+| Version Format | URL with embedded method | URL only, method as field |
+| Form Support | Native form revision type | Forms as object revisions with templates |
+| Platform Focus | Web/Node.js/React Native | Cross-platform with WASM |
+
+## Migration Considerations
+
+### From v3 to v4
+
+- **Breaking Changes**: Schema structure differs significantly
+- **No Direct Migration**: v3 and v4 chains are not directly compatible
+- **Use Case**: Continue using v3 for JavaScript-first projects
+- **Future**: v4 offers more structure and cross-platform consistency
+
+### When to Use v3
+
+- Existing JavaScript/TypeScript projects
+- React Native applications
+- Need for form revision type
+- Mature, stable implementation required
+- Quick prototyping and development
+
+### When to Use v4
+
+- New projects requiring maximum interoperability
+- Need for formal schema validation
+- Rust or multi-language environments
+- WASM compilation for web
+- Template-based data structures
+
+## Community and Support
+
+- **GitHub**: [aqua-verifier-js-lib](https://github.com/inblockio/aqua-verifier-js-lib)
+- **Issues**: Report bugs and request features on GitHub
+- **Documentation**: Examples in `/examples` directory
+
+## Next Steps
+
+- [Concepts](/previous_versions/version_3/concepts) - Core concepts and terminology
+- [Tooling](/previous_versions/version_3/tooling) - SDK usage and API reference
+- [Schema Reference](/previous_versions/version_3/schema) - Detailed revision specifications
+- [Examples](https://github.com/inblockio/aqua-verifier-js-lib/tree/main/examples) - Code examples
+
+## Version History
+
+- **3.2.1**: Current stable release
+- **3.2.0**: React Native support added
+- **3.1.x**: Performance improvements
+- **3.0.0**: Major release with TypeScript rewrite
+
+For detailed changelog, see the [GitHub releases](https://github.com/inblockio/aqua-verifier-js-lib/releases).
diff --git a/previous_versions/version_3/schema.mdx b/previous_versions/version_3/schema.mdx
new file mode 100644
index 00000000..9dec9e34
--- /dev/null
+++ b/previous_versions/version_3/schema.mdx
@@ -0,0 +1,577 @@
+---
+title: "Schema Reference"
+description: "Detailed schema specifications for Aqua Protocol v3 revisions"
+---
+
+# Aqua Protocol v3 - Schema Reference
+
+This document provides comprehensive technical specifications for all revision types in Aqua Protocol v3. Each revision type has specific fields and validation rules.
+
+## Version String Format
+
+```
+https://aqua-protocol.org/docs/v3/schema_2 | SHA256 | Method: {scalar|tree}
+```
+
+**Components:**
+- Protocol URL: `https://aqua-protocol.org/docs/v3/schema_2`
+- Hash Algorithm: `SHA256`
+- Canonicalization Method: `scalar` or `tree`
+
+## Common Fields
+
+All revisions share these mandatory fields:
+
+| Field | Type | Description | Validation |
+|-------|------|-------------|------------|
+| `previous_verification_hash` | string | Hash of previous revision | Empty string for genesis, otherwise 64-char hex with `0x` prefix |
+| `local_timestamp` | string | ISO 8601 timestamp | Valid ISO 8601 format: `YYYY-MM-DDTHH:mm:ss` |
+| `revision_type` | string | Type of revision | One of: `"file"`, `"form"`, `"signature"`, `"witness"`, `"link"` |
+| `version` | string | Protocol version and method | Must match format above |
+
+---
+
+## File Revision
+
+Represents a file with metadata and optional content.
+
+### Fields
+
+| Field | Type | Required | Description |
+|-------|------|----------|-------------|
+| `previous_verification_hash` | string | Yes | Previous revision hash (empty for genesis) |
+| `local_timestamp` | string | Yes | ISO 8601 timestamp |
+| `revision_type` | string | Yes | Must be `"file"` |
+| `version` | string | Yes | Protocol version string |
+| `file_hash` | string | Yes | SHA256 hash of file content (hex with `0x`) |
+| `file_nonce` | string | Yes | Random 16-byte nonce (hex with `0x`) |
+| `content` | string/Uint8Array | No | Optional file content |
+| `leaves` | string[] | Conditional | Required if `Method: tree`, array of leaf hashes |
+
+### Genesis File Revision (Scalar)
+
+```json
+{
+ "previous_verification_hash": "",
+ "local_timestamp": "2024-01-01T12:00:00",
+ "revision_type": "file",
+ "version": "https://aqua-protocol.org/docs/v3/schema_2 | SHA256 | Method: scalar",
+ "file_hash": "0x9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08",
+ "file_nonce": "0x3fa8b1c2d3e4f5a67b8c9d0e1f2a3b4c"
+}
+```
+
+### Genesis File Revision (Tree)
+
+```json
+{
+ "previous_verification_hash": "",
+ "local_timestamp": "2024-01-01T12:00:00",
+ "revision_type": "file",
+ "version": "https://aqua-protocol.org/docs/v3/schema_2 | SHA256 | Method: tree",
+ "file_hash": "0x9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08",
+ "file_nonce": "0x3fa8b1c2d3e4f5a67b8c9d0e1f2a3b4c",
+ "leaves": [
+ "0x1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef",
+ "0xabcdef1234567890abcdef1234567890abcdef1234567890abcdef1234567890"
+ ]
+}
+```
+
+### With Content
+
+```json
+{
+ "previous_verification_hash": "",
+ "local_timestamp": "2024-01-01T12:00:00",
+ "revision_type": "file",
+ "version": "https://aqua-protocol.org/docs/v3/schema_2 | SHA256 | Method: scalar",
+ "file_hash": "0x9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08",
+ "file_nonce": "0x3fa8b1c2d3e4f5a67b8c9d0e1f2a3b4c",
+ "content": "This is the file content as a string"
+}
+```
+
+### Validation Rules
+
+1. `file_hash` must match SHA256 of file content
+2. `file_nonce` must be exactly 16 bytes (32 hex chars + `0x`)
+3. If `Method: tree`, `leaves` array must be present
+4. If `Method: scalar`, `leaves` must be absent
+5. `content` is optional but if present, hash must match `file_hash`
+
+---
+
+## Form Revision
+
+Stores structured key-value data.
+
+### Fields
+
+| Field | Type | Required | Description |
+|-------|------|----------|-------------|
+| `previous_verification_hash` | string | Yes | Previous revision hash (empty for genesis) |
+| `local_timestamp` | string | Yes | ISO 8601 timestamp |
+| `revision_type` | string | Yes | Must be `"form"` |
+| `version` | string | Yes | Protocol version string |
+| `file_hash` | string | Yes | SHA256 hash of form data |
+| `file_nonce` | string | Yes | Random 16-byte nonce |
+| `content` | object | Yes | Form data as key-value pairs |
+| `leaves` | string[] | Conditional | Required if `Method: tree` |
+
+### Example (Scalar)
+
+```json
+{
+ "previous_verification_hash": "",
+ "local_timestamp": "2024-01-01T12:00:00",
+ "revision_type": "form",
+ "version": "https://aqua-protocol.org/docs/v3/schema_2 | SHA256 | Method: scalar",
+ "file_hash": "0xabc123def456...",
+ "file_nonce": "0x7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f",
+ "content": {
+ "name": "John Doe",
+ "email": "john@example.com",
+ "organization": "Example Corp",
+ "role": "Developer"
+ }
+}
+```
+
+### Example (Tree)
+
+```json
+{
+ "previous_verification_hash": "",
+ "local_timestamp": "2024-01-01T12:00:00",
+ "revision_type": "form",
+ "version": "https://aqua-protocol.org/docs/v3/schema_2 | SHA256 | Method: tree",
+ "file_hash": "0xabc123def456...",
+ "file_nonce": "0x7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f",
+ "content": {
+ "name": "John Doe",
+ "email": "john@example.com",
+ "organization": "Example Corp",
+ "role": "Developer"
+ },
+ "leaves": [
+ "0x...", // SHA256("name:John Doe")
+ "0x...", // SHA256("email:john@example.com")
+ "0x...", // SHA256("organization:Example Corp")
+ "0x..." // SHA256("role:Developer")
+ ]
+}
+```
+
+### Leaf Computation (Tree Mode)
+
+For each key-value pair in `content`:
+```typescript
+leaf_hash = SHA256(`${key}:${value}`)
+```
+
+### Validation Rules
+
+1. `content` must be a valid JSON object
+2. All values in `content` must be strings
+3. `file_hash` must match hash of canonicalized content
+4. If `Method: tree`, number of leaves must match number of keys in content
+
+---
+
+## Signature Revision
+
+Adds cryptographic signature to verify authenticity.
+
+### Common Fields
+
+| Field | Type | Required | Description |
+|-------|------|----------|-------------|
+| `previous_verification_hash` | string | Yes | Hash of revision being signed |
+| `local_timestamp` | string | Yes | ISO 8601 timestamp |
+| `revision_type` | string | Yes | Must be `"signature"` |
+| `version` | string | Yes | Protocol version string |
+| `signature_type` | string | Yes | Type: `"cli"`, `"metamask"`, `"did"`, `"p12"`, `"inline"` |
+
+### CLI / MetaMask Signature
+
+**Additional Fields:**
+| Field | Type | Required | Description |
+|-------|------|----------|-------------|
+| `signature` | string | Yes | Hex-encoded signature (65 bytes for ECDSA) |
+| `signature_wallet_address` | string | Yes | Ethereum address (EIP-55 checksummed) |
+
+**Example:**
+```json
+{
+ "previous_verification_hash": "0xabc123...",
+ "local_timestamp": "2024-01-01T12:01:00",
+ "revision_type": "signature",
+ "version": "https://aqua-protocol.org/docs/v3/schema_2 | SHA256 | Method: scalar",
+ "signature_type": "cli",
+ "signature": "0x8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d1c",
+ "signature_wallet_address": "0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb8"
+}
+```
+
+### DID Signature
+
+**Additional Fields:**
+| Field | Type | Required | Description |
+|-------|------|----------|-------------|
+| `signature` | object | Yes | JWS (JSON Web Signature) object |
+
+**Signature Object Structure:**
+```typescript
+{
+ payload: string; // Base64url-encoded payload
+ signatures: [{
+ protected: string; // Base64url-encoded protected header
+ signature: string; // Base64url-encoded signature
+ }]
+}
+```
+
+**Example:**
+```json
+{
+ "previous_verification_hash": "0xabc123...",
+ "local_timestamp": "2024-01-01T12:01:00",
+ "revision_type": "signature",
+ "version": "https://aqua-protocol.org/docs/v3/schema_2 | SHA256 | Method: scalar",
+ "signature_type": "did",
+ "signature": {
+ "payload": "eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19",
+ "signatures": [{
+ "protected": "eyJhbGciOiJFZERTQSJ9",
+ "signature": "kKvXJ_qjJRtGQFLpRvQlCdXMFD8sSE4DTlbMmLqg0BJ9FQKLHvX7y_z5Pr8u0xT8D2vCj9qL1KzN4rP2MzKfBQ"
+ }]
+ }
+}
+```
+
+### P12 Certificate Signature
+
+**Additional Fields:**
+| Field | Type | Required | Description |
+|-------|------|----------|-------------|
+| `signature` | string | Yes | Hex-encoded signature |
+| `signature_public_key` | string | Yes | Hex-encoded DER public key |
+
+**Example:**
+```json
+{
+ "previous_verification_hash": "0xabc123...",
+ "local_timestamp": "2024-01-01T12:01:00",
+ "revision_type": "signature",
+ "version": "https://aqua-protocol.org/docs/v3/schema_2 | SHA256 | Method: scalar",
+ "signature_type": "p12",
+ "signature": "0x...",
+ "signature_public_key": "0x308201a2300d06092a864886f70d01010105000382018f..."
+}
+```
+
+### Inline Signature
+
+Same as CLI/MetaMask but with pre-computed signature.
+
+### Validation Rules
+
+1. Signature must be verifiable using provided credentials
+2. For CLI/MetaMask: Address must be recoverable from signature
+3. For DID: JWS must be valid and verifiable
+4. For P12: Signature must verify with public key
+5. Signature must be computed over `previous_verification_hash`
+
+---
+
+## Witness Revision
+
+Anchors revision to blockchain or timestamping service.
+
+### Fields
+
+| Field | Type | Required | Description |
+|-------|------|----------|-------------|
+| `previous_verification_hash` | string | Yes | Hash being witnessed |
+| `local_timestamp` | string | Yes | ISO 8601 timestamp |
+| `revision_type` | string | Yes | Must be `"witness"` |
+| `version` | string | Yes | Protocol version string |
+| `witness_merkle_root` | string | Yes | Root hash of Merkle tree |
+| `witness_timestamp` | number | Yes | Unix timestamp from witness service |
+| `witness_network` | string | Yes | Network: `"mainnet"`, `"sepolia"`, `"holesky"`, `"tsa"`, `"nostr"` |
+| `witness_smart_contract_address` | string | Conditional | Required for Ethereum |
+| `witness_transaction_hash` | string | Yes | Transaction or event hash |
+| `witness_sender_account_address` | string | Conditional | Required for Ethereum |
+| `witness_merkle_proof` | string[] | Yes | Merkle proof (empty for single witness) |
+
+### Ethereum Witness Example
+
+```json
+{
+ "previous_verification_hash": "0xabc123...",
+ "local_timestamp": "2024-01-01T12:02:00",
+ "revision_type": "witness",
+ "version": "https://aqua-protocol.org/docs/v3/schema_2 | SHA256 | Method: scalar",
+ "witness_merkle_root": "0xdef456...",
+ "witness_timestamp": 1704110520,
+ "witness_network": "sepolia",
+ "witness_smart_contract_address": "0x5FbDB2315678afecb367f032d93F642f64180aa3",
+ "witness_transaction_hash": "0x9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08",
+ "witness_sender_account_address": "0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb8",
+ "witness_merkle_proof": []
+}
+```
+
+### Batched Witness Example
+
+Multiple revisions witnessed in single transaction:
+
+```json
+{
+ "previous_verification_hash": "0xabc123...",
+ "local_timestamp": "2024-01-01T12:02:00",
+ "revision_type": "witness",
+ "version": "https://aqua-protocol.org/docs/v3/schema_2 | SHA256 | Method: scalar",
+ "witness_merkle_root": "0xroot...",
+ "witness_timestamp": 1704110520,
+ "witness_network": "mainnet",
+ "witness_smart_contract_address": "0x5FbDB2315678afecb367f032d93F642f64180aa3",
+ "witness_transaction_hash": "0x9f86d081...",
+ "witness_sender_account_address": "0x742d35Cc...",
+ "witness_merkle_proof": [
+ "0xsibling_hash_1",
+ "0xsibling_hash_2",
+ "0xsibling_hash_3"
+ ]
+}
+```
+
+### Nostr Witness Example
+
+```json
+{
+ "previous_verification_hash": "0xabc123...",
+ "local_timestamp": "2024-01-01T12:02:00",
+ "revision_type": "witness",
+ "version": "https://aqua-protocol.org/docs/v3/schema_2 | SHA256 | Method: scalar",
+ "witness_merkle_root": "0xabc123...",
+ "witness_timestamp": 1704110520,
+ "witness_network": "nostr",
+ "witness_smart_contract_address": "",
+ "witness_transaction_hash": "nevent1qqsw...",
+ "witness_sender_account_address": "npub1...",
+ "witness_merkle_proof": []
+}
+```
+
+### TSA Witness Example
+
+```json
+{
+ "previous_verification_hash": "0xabc123...",
+ "local_timestamp": "2024-01-01T12:02:00",
+ "revision_type": "witness",
+ "version": "https://aqua-protocol.org/docs/v3/schema_2 | SHA256 | Method: scalar",
+ "witness_merkle_root": "0xabc123...",
+ "witness_timestamp": 1704110520,
+ "witness_network": "tsa",
+ "witness_smart_contract_address": "https://timestamp.digicert.com",
+ "witness_transaction_hash": "base64_tsa_response",
+ "witness_sender_account_address": "",
+ "witness_merkle_proof": []
+}
+```
+
+### Validation Rules
+
+1. For single witness: `witness_merkle_proof` must be empty array
+2. For single witness: `witness_merkle_root` equals `previous_verification_hash`
+3. For batched: Merkle proof must verify back to `witness_merkle_root`
+4. Transaction must exist and be confirmed on specified network
+5. `witness_timestamp` should match blockchain/service timestamp
+6. For Ethereum: Contract address and sender address required
+
+---
+
+## Link Revision
+
+Connects to other AquaTree chains.
+
+### Fields
+
+| Field | Type | Required | Description |
+|-------|------|----------|-------------|
+| `previous_verification_hash` | string | Yes | Previous revision in this chain |
+| `local_timestamp` | string | Yes | ISO 8601 timestamp |
+| `revision_type` | string | Yes | Must be `"link"` |
+| `version` | string | Yes | Protocol version string |
+| `link_type` | string | No | Application-specific link type |
+| `link_verification_hashes` | string[] | Yes | Array of hashes from other chains |
+| `link_file_hashes` | string[] | No | Corresponding file hashes |
+
+### Example
+
+```json
+{
+ "previous_verification_hash": "0xabc123...",
+ "local_timestamp": "2024-01-01T12:03:00",
+ "revision_type": "link",
+ "version": "https://aqua-protocol.org/docs/v3/schema_2 | SHA256 | Method: scalar",
+ "link_type": "dependencies",
+ "link_verification_hashes": [
+ "0x111222333444555666777888999000aaabbbcccdddeeefff000111222333444",
+ "0x222333444555666777888999000aaabbbcccdddeeefff000111222333444555",
+ "0x333444555666777888999000aaabbbcccdddeeefff000111222333444555666"
+ ],
+ "link_file_hashes": [
+ "0xfileHash1...",
+ "0xfileHash2...",
+ "0xfileHash3..."
+ ]
+}
+```
+
+### Validation Rules
+
+1. `link_verification_hashes` must be non-empty array
+2. Each hash in array must be valid revision hash
+3. If `link_file_hashes` present, must have same length as `link_verification_hashes`
+4. Referenced revisions should exist (optional strict validation)
+
+---
+
+## Hash Computation
+
+### Scalar Method
+
+1. Serialize revision as canonical JSON (sorted keys)
+2. Compute SHA256 hash of serialized string
+3. Prefix with `0x`
+
+```typescript
+const canonical = JSON.stringify(sortKeys(revision));
+const hash = "0x" + sha256(canonical).toString('hex');
+```
+
+### Tree Method
+
+1. Extract leaves array from revision
+2. Build Merkle tree from leaves
+3. Root hash becomes verification hash
+
+```typescript
+const leaves = revision.leaves;
+const tree = new MerkleTree(leaves, sha256);
+const hash = "0x" + tree.getRoot().toString('hex');
+```
+
+---
+
+## AquaTree Storage Format
+
+Complete AquaTree structure for storage/transmission:
+
+```json
+{
+ "revisions": {
+ "0xgenesis_hash": {
+ "previous_verification_hash": "",
+ "local_timestamp": "2024-01-01T12:00:00",
+ "revision_type": "file",
+ "version": "https://aqua-protocol.org/docs/v3/schema_2 | SHA256 | Method: scalar",
+ "file_hash": "0x...",
+ "file_nonce": "0x..."
+ },
+ "0xsignature_hash": {
+ "previous_verification_hash": "0xgenesis_hash",
+ "local_timestamp": "2024-01-01T12:01:00",
+ "revision_type": "signature",
+ "version": "https://aqua-protocol.org/docs/v3/schema_2 | SHA256 | Method: scalar",
+ "signature_type": "cli",
+ "signature": "0x...",
+ "signature_wallet_address": "0x..."
+ },
+ "0xwitness_hash": {
+ "previous_verification_hash": "0xsignature_hash",
+ "local_timestamp": "2024-01-01T12:02:00",
+ "revision_type": "witness",
+ "version": "https://aqua-protocol.org/docs/v3/schema_2 | SHA256 | Method: scalar",
+ "witness_merkle_root": "0x...",
+ "witness_timestamp": 1704110520,
+ "witness_network": "sepolia",
+ "witness_smart_contract_address": "0x...",
+ "witness_transaction_hash": "0x...",
+ "witness_sender_account_address": "0x...",
+ "witness_merkle_proof": []
+ }
+ },
+ "file_index": {
+ "0xfile_hash": "document.pdf"
+ },
+ "tree": {
+ "hash": "0xgenesis_hash",
+ "children": [
+ {
+ "hash": "0xsignature_hash",
+ "children": [
+ {
+ "hash": "0xwitness_hash",
+ "children": []
+ }
+ ]
+ }
+ ]
+ },
+ "treeMapping": {
+ "paths": {
+ "0xgenesis_hash": ["0xgenesis_hash"],
+ "0xsignature_hash": ["0xgenesis_hash", "0xsignature_hash"],
+ "0xwitness_hash": ["0xgenesis_hash", "0xsignature_hash", "0xwitness_hash"]
+ },
+ "latestHash": "0xwitness_hash"
+ }
+}
+```
+
+---
+
+## Field Constraints
+
+### Hashes
+- Format: Lowercase hexadecimal with `0x` prefix
+- Length: 64 characters (32 bytes) + 2-char prefix = 66 total
+- Example: `0x9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08`
+
+### Timestamps
+- Format: ISO 8601
+- Pattern: `YYYY-MM-DDTHH:mm:ss`
+- Example: `2024-01-01T12:00:00`
+
+### Ethereum Addresses
+- Format: EIP-55 checksummed
+- Length: 42 characters (20 bytes + 0x)
+- Mixed case for checksum
+- Example: `0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb8`
+
+### Nonces
+- Length: Exactly 16 bytes (32 hex chars + 0x)
+- Format: Lowercase hexadecimal with `0x` prefix
+- Example: `0x3fa8b1c2d3e4f5a67b8c9d0e1f2a3b4c`
+
+---
+
+## Version Compatibility
+
+- **v3.2.x**: Current version, fully compatible
+- **v3.1.x**: Compatible, minor improvements
+- **v3.0.x**: Compatible, initial TypeScript release
+- **v2.x**: Not compatible, different schema
+
+---
+
+## See Also
+
+- [Introduction](/previous_versions/version_3/introduction) - Getting started
+- [Concepts](/previous_versions/version_3/concepts) - Core concepts
+- [Tooling](/previous_versions/version_3/tooling) - SDK API reference
diff --git a/previous_versions/version_3/tooling.mdx b/previous_versions/version_3/tooling.mdx
new file mode 100644
index 00000000..f3005170
--- /dev/null
+++ b/previous_versions/version_3/tooling.mdx
@@ -0,0 +1,784 @@
+---
+title: "Tooling & SDK"
+description: "Aqua JS SDK API reference and usage guide"
+---
+
+# Aqua Protocol v3 - Tooling & SDK
+
+The Aqua JS SDK (aqua-js-sdk) is a comprehensive TypeScript library for working with Aqua Protocol v3. It provides a complete API for creating, signing, witnessing, and verifying revision chains across multiple platforms.
+
+## Installation
+
+```bash
+npm install aqua-js-sdk
+```
+
+### Platform-Specific Imports
+
+```typescript
+// Node.js (default)
+import Aquafier from 'aqua-js-sdk';
+
+// Web Browser
+import Aquafier from 'aqua-js-sdk/web';
+
+// React Native
+import Aquafier from 'aqua-js-sdk/react-native';
+```
+
+## Core API
+
+### Aquafier Class
+
+The main class providing all Aqua Protocol operations.
+
+#### Constructor
+
+```typescript
+const aquafier = new Aquafier();
+```
+
+No configuration needed for initialization.
+
+---
+
+### Creating Revisions
+
+#### createGenesisRevision()
+
+Creates the first revision in a new AquaTree.
+
+**Signature:**
+```typescript
+async createGenesisRevision(
+ fileObject: FileObject,
+ isForm?: boolean,
+ enableContent?: boolean,
+ enableScalar?: boolean
+): Promise<Result<AquaOperationData, LogData[]>>
+```
+
+**Parameters:**
+- `fileObject`: File data to create revision from
+- `isForm`: If true, creates form revision (default: false)
+- `enableContent`: Include file content in revision (default: false)
+- `enableScalar`: Use scalar method instead of tree (default: true)
+
+**Returns:**
+- Success: `AquaOperationData` with new AquaTree
+- Failure: Array of error logs
+
+**Example:**
+```typescript
+const fileObject: FileObject = {
+ fileName: "contract.pdf",
+ fileContent: pdfBuffer, // Uint8Array or string
+ path: "/documents/contract.pdf"
+};
+
+const result = await aquafier.createGenesisRevision(fileObject);
+
+if (result.isErr) {
+ result.data.logData.forEach(log => console.error(log));
+ return;
+}
+
+const aquaTree = result.data.aquaTree;
+```
+
+#### createNewRevision()
+
+Adds a new file/form revision to an existing AquaTree.
+
+**Signature:**
+```typescript
+async createNewRevision(
+ aquaTree: AquaTree,
+ fileObject: FileObject,
+ isForm?: boolean,
+ enableContent?: boolean,
+ enableScalar?: boolean
+): Promise<Result<AquaOperationData, LogData[]>>
+```
+
+**Example:**
+```typescript
+const result = await aquafier.createNewRevision(
+ existingAquaTree,
+ updatedFileObject,
+ false, // not a form
+ false, // don't embed content
+ true // use scalar method
+);
+```
+
+---
+
+### Signing Revisions
+
+#### signRevision()
+
+Signs the latest revision in an AquaTree.
+
+**Signature:**
+```typescript
+async signRevision(
+ aquaTree: AquaTree,
+ signType: SignType,
+ credentials?: CredentialsData,
+ inlineOptions?: InlineSignerOptions
+): Promise<Result<AquaOperationData, LogData[]>>
+```
+
+**Parameters:**
+- `signType`: One of `"cli"`, `"metamask"`, `"did"`, `"p12"`, `"inline"`
+- `credentials`: Credentials for CLI, DID, or P12 signing
+- `inlineOptions`: Pre-computed signature for inline mode
+
+**Sign Types:**
+
+##### CLI Signing
+Uses BIP39 mnemonic to derive wallet and sign.
+
+```typescript
+const credentials: CredentialsData = {
+ mnemonic: "abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about",
+ // ... other fields
+};
+
+const result = await aquafier.signRevision(
+ aquaTree,
+ "cli",
+ credentials
+);
+```
+
+##### MetaMask Signing
+Opens MetaMask for user to sign (browser only).
+
+```typescript
+const result = await aquafier.signRevision(
+ aquaTree,
+ "metamask"
+);
+```
+
+**React Native MetaMask:**
+```typescript
+const result = await aquafier.signRevision(
+ aquaTree,
+ "metamask",
+ undefined,
+ {
+ deepLinkUrl: "metamask://",
+ callbackUrl: "myapp://metamask-callback",
+ onDeepLinkReady: (url) => {
+ // Open MetaMask app
+ Linking.openURL(url);
+ }
+ }
+);
+```
+
+##### DID Signing
+Signs with Decentralized Identifier.
+
+```typescript
+const credentials: CredentialsData = {
+ did_key: "your-did-key-here",
+ // ... other fields
+};
+
+const result = await aquafier.signRevision(
+ aquaTree,
+ "did",
+ credentials
+);
+```
+
+##### P12 Certificate Signing
+Signs with P12 certificate.
+
+```typescript
+const credentials: CredentialsData = {
+ p12_password: "certificate-password",
+ p12_content: "base64-encoded-p12-content",
+ // ... other fields
+};
+
+const result = await aquafier.signRevision(
+ aquaTree,
+ "p12",
+ credentials
+);
+```
+
+##### Inline Signing
+Use pre-computed signature.
+
+```typescript
+const inlineOptions: InlineSignerOptions = {
+ walletAddress: "0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb8",
+ signature: "0x8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f..."
+};
+
+const result = await aquafier.signRevision(
+ aquaTree,
+ "inline",
+ undefined,
+ inlineOptions
+);
+```
+
+---
+
+### Witnessing Revisions
+
+#### witnessRevision()
+
+Timestamps a revision via blockchain or TSA.
+
+**Signature:**
+```typescript
+async witnessRevision(
+ aquaTree: AquaTree,
+ witnessType: WitnessType,
+ witnessConfig: WitnessConfig,
+ credentials?: CredentialsData,
+ witnessPlatform?: WitnessPlatformType,
+ inlineOptions?: InlineWitnessOptions
+): Promise<Result<AquaOperationData, LogData[]>>
+```
+
+**Parameters:**
+- `witnessType`: `"eth"`, `"nostr"`, or `"tsa"`
+- `witnessConfig`: Network and contract configuration
+- `credentials`: Credentials for signing transaction
+- `witnessPlatform`: `"cli"` or `"metamask"` (Ethereum only)
+- `inlineOptions`: Pre-computed transaction (inline mode)
+
+#### Ethereum Witnessing
+
+**Configuration:**
+```typescript
+const witnessConfig: WitnessConfig = {
+ witnessEventVerificationHash: latestRevisionHash,
+ witnessNetwork: "sepolia", // or "mainnet", "holesky"
+ smartContractAddress: "0x5FbDB2315678afecb367f032d93F642f64180aa3"
+};
+
+const credentials: CredentialsData = {
+ mnemonic: "your mnemonic here",
+ // ...
+};
+```
+
+**CLI Method** (uses mnemonic):
+```typescript
+const result = await aquafier.witnessRevision(
+ aquaTree,
+ "eth",
+ witnessConfig,
+ credentials,
+ "cli"
+);
+```
+
+**MetaMask Method** (prompts user):
+```typescript
+const result = await aquafier.witnessRevision(
+ aquaTree,
+ "eth",
+ witnessConfig,
+ undefined,
+ "metamask"
+);
+```
+
+#### Nostr Witnessing
+
+```typescript
+const witnessConfig: WitnessConfig = {
+ witnessEventVerificationHash: latestRevisionHash,
+ witnessNetwork: "sepolia", // not used for Nostr
+ smartContractAddress: "" // not used for Nostr
+};
+
+const credentials: CredentialsData = {
+ nostr_sk: "your-nostr-secret-key",
+ // ...
+};
+
+const result = await aquafier.witnessRevision(
+ aquaTree,
+ "nostr",
+ witnessConfig,
+ credentials
+);
+```
+
+#### TSA Witnessing
+
+```typescript
+const result = await aquafier.witnessRevision(
+ aquaTree,
+ "tsa",
+ witnessConfig
+);
+```
+
+---
+
+### Linking Revisions
+
+#### linkRevision()
+
+Creates a link revision connecting to other AquaTrees.
+
+**Signature:**
+```typescript
+async linkRevision(
+ aquaTree: AquaTree,
+ linkedAquaTrees: AquaTree[],
+ linkType?: string
+): Promise<Result<AquaOperationData, LogData[]>>
+```
+
+**Example:**
+```typescript
+const result = await aquafier.linkRevision(
+ mainAquaTree,
+ [dependency1Tree, dependency2Tree, dependency3Tree],
+ "dependencies"
+);
+```
+
+---
+
+### Verification
+
+#### verifyRevisionChain()
+
+Verifies an entire AquaTree chain.
+
+**Signature:**
+```typescript
+async verifyRevisionChain(
+ aquaTree: AquaTree,
+ credentials?: CredentialsData
+): Promise<VerificationGraphData>
+```
+
+**Parameters:**
+- `aquaTree`: Tree to verify
+- `credentials`: Optional, for Ethereum witness lookup
+
+**Returns:**
+- `VerificationGraphData`: Graph structure with verification results
+
+**Example:**
+```typescript
+const verificationResult = await aquafier.verifyRevisionChain(aquaTree, credentials);
+
+// Check overall success
+if (verificationResult.isValidationSuccessful) {
+ console.log("✓ Chain is valid");
+} else {
+ console.log("✗ Chain validation failed");
+}
+
+// Traverse verification graph
+function printResults(node: VerificationGraphData, depth = 0) {
+ const indent = " ".repeat(depth);
+ const status = node.isValidationSuccessful ? "✓" : "✗";
+ console.log(`${indent}${status} ${node.revisionType}`);
+
+ node.verificationGraphData.forEach(child => printResults(child, depth + 1));
+}
+
+printResults(verificationResult);
+```
+
+#### verifyFormRevision()
+
+Verifies form-specific data.
+
+**Signature:**
+```typescript
+async verifyFormRevision(
+ aquaTree: AquaTree,
+ formData: FormData
+): Promise<FormVerificationResponseData>
+```
+
+---
+
+### Utility Methods
+
+#### removeLastRevision()
+
+Removes the most recent revision from an AquaTree.
+
+**Signature:**
+```typescript
+removeLastRevision(
+ aquaTree: AquaTree
+): Result<AquaOperationData, LogData[]>
+```
+
+**Example:**
+```typescript
+const result = aquafier.removeLastRevision(aquaTree);
+
+if (result.isOk) {
+ const updatedTree = result.data.aquaTree;
+ console.log("Revision removed successfully");
+}
+```
+
+#### checkIfFileAlreadyNotarized()
+
+Checks if a file has already been notarized.
+
+**Signature:**
+```typescript
+checkIfFileAlreadyNotarized(
+ aquaTree: AquaTree,
+ fileObject: FileObject
+): boolean
+```
+
+#### fetchFilesToBeRead()
+
+Gets list of files that need content loaded.
+
+**Signature:**
+```typescript
+fetchFilesToBeRead(aquaTree: AquaTree): string[]
+```
+
+---
+
+## Type Reference
+
+### Core Types
+
+```typescript
+interface FileObject {
+ fileName: string
+ fileContent: string | AquaTree | Uint8Array | Record<string, string> | object
+ path: string
+ fileSize?: number
+}
+
+interface AquaTree {
+ revisions: Revisions
+ file_index: FileIndex
+ tree?: RevisionTree
+ treeMapping?: TreeMapping
+}
+
+interface Revision {
+ previous_verification_hash: string
+ local_timestamp: string
+ revision_type: RevisionType
+ version: string
+ // ... type-specific fields
+}
+
+type RevisionType = "file" | "witness" | "signature" | "form" | "link"
+type SignType = "metamask" | "cli" | "did" | "p12" | "inline"
+type WitnessType = "tsa" | "eth" | "nostr"
+type WitnessNetwork = "sepolia" | "mainnet" | "holesky"
+```
+
+### Result Type
+
+```typescript
+type Result<T, E> =
+ | { isOk: true; isErr: false; data: T }
+ | { isOk: false; isErr: true; data: E }
+```
+
+### Configuration Types
+
+```typescript
+interface CredentialsData {
+ mnemonic: string
+ nostr_sk: string
+ did_key: string
+ alchemy_key: string
+ witness_eth_network: string
+ witness_method: string
+ p12_password?: string
+ p12_content?: string
+}
+
+interface WitnessConfig {
+ witnessEventVerificationHash: string
+ witnessNetwork: WitnessNetwork
+ smartContractAddress: string
+}
+```
+
+---
+
+## Platform-Specific Notes
+
+### Node.js
+
+Full functionality available:
+- All signing methods
+- All witnessing methods
+- File system access
+- HTTP server for MetaMask callback
+
+```typescript
+import Aquafier from 'aqua-js-sdk';
+import fs from 'fs';
+
+const aquafier = new Aquafier();
+
+// Read file from disk
+const fileContent = fs.readFileSync('document.pdf');
+
+const fileObject = {
+ fileName: 'document.pdf',
+ fileContent: fileContent,
+ path: './document.pdf'
+};
+```
+
+### Web Browser
+
+Most functionality available:
+- MetaMask signing (primary method)
+- DID signing
+- Ethereum witnessing via MetaMask
+- Nostr, TSA witnessing
+
+**Limitations:**
+- No P12 signing (requires file system)
+- No CLI signing with mnemonic (security risk in browser)
+
+```typescript
+import Aquafier from 'aqua-js-sdk/web';
+
+const aquafier = new Aquafier();
+
+// File from input element
+const file = document.getElementById('fileInput').files[0];
+const arrayBuffer = await file.arrayBuffer();
+
+const fileObject = {
+ fileName: file.name,
+ fileContent: new Uint8Array(arrayBuffer),
+ path: file.name
+};
+```
+
+### React Native
+
+Most functionality with platform adaptations:
+- MetaMask via deep linking
+- DID signing
+- Limited witnessing
+
+**Limitations:**
+- No local HTTP server
+- MetaMask requires custom deep linking
+- File system needs react-native-fs
+
+```typescript
+import Aquafier from 'aqua-js-sdk/react-native';
+import RNFS from 'react-native-fs';
+
+const aquafier = new Aquafier();
+
+// Read file
+const fileContent = await RNFS.readFile(filePath, 'base64');
+
+const fileObject = {
+ fileName: 'document.pdf',
+ fileContent: Buffer.from(fileContent, 'base64'),
+ path: filePath
+};
+```
+
+---
+
+## Complete Workflow Examples
+
+### Document Notarization
+
+```typescript
+// 1. Create genesis
+const fileObject: FileObject = {
+ fileName: "contract.pdf",
+ fileContent: pdfBuffer,
+ path: "/contracts/contract.pdf"
+};
+
+let result = await aquafier.createGenesisRevision(fileObject);
+let aquaTree = result.data.aquaTree;
+
+// 2. Sign with CLI
+const credentials: CredentialsData = {
+ mnemonic: process.env.MNEMONIC,
+ // ... other fields
+};
+
+result = await aquafier.signRevision(aquaTree, "cli", credentials);
+aquaTree = result.data.aquaTree;
+
+// 3. Witness to Ethereum
+const witnessConfig: WitnessConfig = {
+ witnessEventVerificationHash: Object.keys(aquaTree.revisions)[Object.keys(aquaTree.revisions).length - 1],
+ witnessNetwork: "sepolia",
+ smartContractAddress: "0x5FbDB2315678afecb367f032d93F642f64180aa3"
+};
+
+result = await aquafier.witnessRevision(
+ aquaTree,
+ "eth",
+ witnessConfig,
+ credentials,
+ "cli"
+);
+aquaTree = result.data.aquaTree;
+
+// 4. Save
+fs.writeFileSync('contract.aqua.json', JSON.stringify(aquaTree, null, 2));
+```
+
+### Multi-Party Approval
+
+```typescript
+// Party 1: Create and sign
+let result = await aquafier.createGenesisRevision(fileObject);
+let aquaTree = result.data.aquaTree;
+
+result = await aquafier.signRevision(aquaTree, "cli", party1Credentials);
+aquaTree = result.data.aquaTree;
+
+// Send aquaTree to Party 2
+
+// Party 2: Add signature
+result = await aquafier.signRevision(aquaTree, "metamask");
+aquaTree = result.data.aquaTree;
+
+// Send back to Party 1
+
+// Party 1: Witness
+result = await aquafier.witnessRevision(
+ aquaTree,
+ "eth",
+ witnessConfig,
+ party1Credentials,
+ "cli"
+);
+aquaTree = result.data.aquaTree;
+```
+
+### Form Submission with Verification
+
+```typescript
+// 1. Create form genesis
+const formData = {
+ name: "John Doe",
+ email: "john@example.com",
+ status: "pending"
+};
+
+const fileObject: FileObject = {
+ fileName: "application.json",
+ fileContent: formData,
+ path: "/forms/application.json"
+};
+
+let result = await aquafier.createGenesisRevision(fileObject, true); // isForm=true
+let aquaTree = result.data.aquaTree;
+
+// 2. Sign
+result = await aquafier.signRevision(aquaTree, "did", credentials);
+aquaTree = result.data.aquaTree;
+
+// 3. Witness
+result = await aquafier.witnessRevision(aquaTree, "nostr", witnessConfig, credentials);
+aquaTree = result.data.aquaTree;
+
+// 4. Verify form
+const verifyResult = await aquafier.verifyFormRevision(aquaTree, formData);
+console.log("Form valid:", verifyResult.isOk);
+```
+
+---
+
+## Error Handling
+
+All methods return `Result<T, E>` type. Always check for errors:
+
+```typescript
+const result = await aquafier.createGenesisRevision(fileObject);
+
+if (result.isErr) {
+ // Handle error
+ console.error("Failed to create genesis:");
+ result.data.forEach(log => {
+ console.error(`[${log.logType}] ${log.log}`);
+ });
+ return;
+}
+
+// Success
+const aquaTree = result.data.aquaTree;
+```
+
+---
+
+## Best Practices
+
+1. **Always verify results**: Check `isErr` before using data
+2. **Store credentials securely**: Never commit mnemonic/keys
+3. **Use environment variables**: Store sensitive data in `.env`
+4. **Validate inputs**: Check file sizes and formats before processing
+5. **Handle logs**: Display or log all LogData for debugging
+6. **Test on testnets**: Use Sepolia/Holesky before mainnet
+7. **Save AquaTrees**: Persist JSON after each operation
+8. **Verify chains**: Run verification after receiving AquaTrees
+
+---
+
+## Testing
+
+Create `credentials.json` for testing:
+
+```json
+{
+ "mnemonic": "your test mnemonic",
+ "nostr_sk": "your nostr secret key",
+ "did_key": "your did key",
+ "alchemy_key": "your alchemy api key",
+ "witness_eth_network": "sepolia",
+ "witness_method": "cli"
+}
+```
+
+Run tests:
+```bash
+npm test
+```
+
+Run specific test file:
+```bash
+npm test -- ./tests/aquafier.test.ts
+```
+
+---
+
+## See Also
+
+- [Introduction](/previous_versions/version_3/introduction) - Getting started
+- [Concepts](/previous_versions/version_3/concepts) - Core concepts
+- [Schema Reference](/previous_versions/version_3/schema) - Revision specifications
+- [GitHub Repository](https://github.com/inblockio/aqua-verifier-js-lib) - Source code and examples
diff --git a/previous_versions/version_4/version_4.mdx b/previous_versions/version_4/version_4.mdx
new file mode 100644
index 00000000..f02e0432
--- /dev/null
+++ b/previous_versions/version_4/version_4.mdx
@@ -0,0 +1,133 @@
+---
+title: "Version v4 (beta)"
+description: 'Concepts, protocol structure, and getting started with Aqua Protocol v4'
+---
+
+# Aqua Protocol v4
+
+Aqua Protocol v4 is the latest version of the protocol, introducing significant improvements in structure, flexibility, and capabilities. This version is currently in beta.
+
+## Overview
+
+Aqua Protocol v4 provides a robust framework for creating cryptographically verifiable chains of revisions. Each revision in a chain can represent different types of operations, from storing data to signing, witnessing, and linking to other chains.
+
+## Core Concepts
+
+### Revisions
+
+A revision is the fundamental unit in Aqua Protocol. There are five types of revisions in v4:
+
+1. **Object Revision** - Stores data with an associated template
+2. **Template Revision** - Defines the schema for object revisions
+3. **Signature Revision** - Adds cryptographic signatures to verify authenticity
+4. **Witness Revision** - Provides timestamped proof of existence via blockchain
+5. **Link Revision** - Creates verifiable connections to other revision chains
+
+### Revision Chains
+
+Revisions form chains by referencing previous revisions through cryptographic hashes. The first revision in a chain is called the "genesis revision" and has no previous revision reference.
+
+### Methods
+
+Aqua Protocol v4 supports two canonicalization methods:
+
+- **scalar**: Direct JSON canonicalization (default for most use cases)
+- **tree**: Merkle tree-based canonicalization for large datasets
+
+### Hash Types
+
+Currently, v4 supports:
+- **FIPS_202-SHA3-256**: SHA-3 256-bit hashing algorithm
+
+## Common Fields
+
+All revision types share these common fields:
+
+| Field | Type | Description |
+|-------|------|-------------|
+| `version` | string | Protocol version URL: `https://aqua-protocol.org/docs/v4/schema` |
+| `revision_type` | string/RevisionLink | Type identifier for the revision |
+| `nonce` | string | Random 16-byte hex string (prefixed with `0x`) for uniqueness |
+| `local_timestamp` | number | Unix timestamp when the revision was created |
+| `method` | string | Canonicalization method: `"scalar"` or `"tree"` |
+| `hash_type` | string | Hashing algorithm: `"FIPS_202-SHA3-256"` |
+| `previous_revision` | string | Hash reference to the previous revision (optional for genesis) |
+
+## Schema Structure
+
+The v4 schema is designed to be:
+
+- **Extensible**: New revision types can be added without breaking existing chains
+- **Verifiable**: Every revision can be independently verified through hash computation
+- **Composable**: Chains can link to other chains, creating complex data structures
+- **Flexible**: Templates allow custom data structures while maintaining validation
+
+## Key Improvements from Previous Versions
+
+### 1. Unified Revision Structure
+All revision types follow a consistent structure with common fields, making implementation and validation simpler.
+
+### 2. Template-Based Validation
+Object revisions reference templates via hash, ensuring data conformity to predefined schemas.
+
+### 3. Multiple Signature Types
+Support for RSA, Ethereum (EIP-191), and DID-based signatures provides flexibility for different use cases.
+
+### 4. Enhanced Witnessing
+Improved witness structure with detailed transaction information and merkle proof support.
+
+### 5. Explicit Linking
+Link revisions create verifiable connections between separate revision chains.
+
+## Getting Started
+
+To understand the v4 schema in detail, visit the [Schema Reference](/schema_reference/introduction) section, where each revision type is documented with examples and field specifications.
+
+## Tooling
+
+### Aqua RS SDK
+
+The official Rust SDK for Aqua Protocol v4 provides:
+- Type-safe revision creation and validation
+- Cryptographic operations (signing, hashing)
+- Witnessing capabilities (Ethereum, Nostr, TSA)
+- WASM compilation for web applications
+
+**Repository**: [github.com/inblockio/aqua-rs-sdk](https://github.com/inblockio/aqua-rs-sdk)
+
+**Installation:**
+```bash
+# For Rust projects
+cargo add aqua-rs-sdk
+
+# For WASM builds
+wasm-pack build --target web --no-default-features --features wasm
+```
+
+### CLI Tools
+
+Command-line utilities built on the v4 SDK enable:
+- Creating and validating revision chains
+- Signing revisions with various methods
+- Witnessing to blockchain networks
+- Verifying complete chains
+
+## Use Cases
+
+Aqua Protocol v4 is designed for:
+
+- **Document Integrity**: Verifiable audit trails for documents and data
+- **Supply Chain**: Tracking provenance and authenticity
+- **Digital Identity**: Self-sovereign identity with verifiable credentials
+- **Notarization**: Timestamped proof of existence
+- **Data Provenance**: Complete history tracking with cryptographic guarantees
+- **Decentralized Attestations**: Peer-to-peer verification without central authorities
+
+## Next Steps
+
+- Explore the [Schema Reference](/schema_reference/introduction) to understand each revision type
+- Review example revision chains in the SDK repository
+- Try the CLI tools to create your first revision chain
+- Read about specific use cases and implementation patterns
+
+For questions or feedback about v4, please visit the [Aqua Protocol GitHub repository](https://github.com/inblockio).
diff --git a/quickstart.mdx b/quickstart.mdx
new file mode 100644
index 00000000..e4897a9c
--- /dev/null
+++ b/quickstart.mdx
@@ -0,0 +1,446 @@
+---
+title: "Quick Start"
+description: "Get started with Aqua Protocol in minutes"
+icon: "rocket"
+---
+
+
+
+This guide will get you up and running with Aqua Protocol quickly. You'll create your first Aqua chain, sign it, and optionally witness it on a blockchain.
+
+## Choose Your SDK
+
+<Tabs>
+ <Tab title="JavaScript/TypeScript (v3)">
+ **Stable** - Production-ready SDK for Node.js, Web, and React Native
+
+ Best for: Web applications, existing JavaScript projects
+ </Tab>
+
+ <Tab title="Rust (v4)">
+ **Beta** - Template system, WASM support, cross-platform
+
+ Best for: New projects, performance-critical applications
+ </Tab>
+
+
+</Tabs>
+
+---
+
+## JavaScript/TypeScript Quick Start (v3)
+
+<Info>
+**Prerequisites**:
+- Node.js version 19 or higher
+- npm, yarn, or pnpm package manager
+</Info>
+
+<Note>
+We recommend using TypeScript to enjoy type definitions and better development experience.
+</Note>
+
+<Steps>
+ <Step title="Install the SDK">
+ Create a new project or add to an existing one:
+
+ ```bash
+ # Create new project (optional)
+ mkdir my-aqua-project
+ cd my-aqua-project
+ npm init -y
+
+ # Install Aqua SDK
+ npm install aqua-js-sdk
+
+ # For TypeScript projects, also install type support
+ npm install --save-dev typescript @types/node
+ ```
+ </Step>
+
+ <Step title="Create Your First Aqua Chain">
+ Create a file called `index.ts` (or `index.js`):
+
+ ```typescript
+ import Aquafier, { FileObject } from 'aqua-js-sdk';
+
+ async function main() {
+ // Initialize Aquafier
+ const aquafier = new Aquafier();
+
+ // Create a file object to notarize
+ const fileObject: FileObject = {
+ fileName: "hello.txt",
+ fileContent: "Hello, Aqua Protocol!",
+ path: "./hello.txt"
+ };
+
+ // Create genesis revision (notarize the file)
+ console.log("Creating Aqua chain...");
+ const result = await aquafier.createGenesisRevision(fileObject);
+
+ if (result.isOk()) {
+ console.log("✓ Success! Aqua chain created.");
+ console.log("Aqua Tree:", JSON.stringify(result.data.aquaTree, null, 2));
+
+ // The aquaTree contains your notarized file
+ const aquaTree = result.data.aquaTree;
+ console.log("\nYou can now:");
+ console.log("- Sign this chain");
+ console.log("- Witness it on blockchain");
+ console.log("- Verify it anytime");
+ } else {
+ console.error("✗ Error:", result.error);
+ }
+ }
+
+ main().catch(console.error);
+ ```
+ </Step>
+
+ <Step title="Run Your Code">
+ ```bash
+ # For TypeScript
+ npx tsx index.ts
+
+ # Or compile and run
+ npx tsc index.ts
+ node index.js
+
+ # For plain JavaScript
+ node index.js
+ ```
+
+ You should see output showing your Aqua chain was created successfully!
+ </Step>
+
+ <Step title="Next: Add a Signature (Optional)">
+ Extend your code to add a cryptographic signature:
+
+ ```typescript
+ // ... after creating genesis ...
+
+ if (result.isOk()) {
+ const aquaTree = result.data.aquaTree;
+
+ // Sign with MetaMask (will prompt in browser)
+ const wrapper = {
+ aquaTree: aquaTree,
+ fileObject: fileObject,
+ revision: ""
+ };
+
+ console.log("\nAdding signature...");
+ const signedResult = await aquafier.signAquaTree(
+ wrapper,
+ "metamask", // or "cli", "did", "p12"
+ {}, // credentials
+ true // auto-increment
+ );
+
+ if (signedResult.isOk()) {
+ console.log("✓ Signature added!");
+ }
+ }
+ ```
+ </Step>
+</Steps>
+
+---
+
+## Rust Quick Start (v4)
+
+<Info>
+**Prerequisites**:
+- Rust 1.70 or higher
+- Cargo package manager
+</Info>
+
+<Steps>
+ <Step title="Create a New Project">
+ ```bash
+ # Create a new Rust binary project
+ cargo new my-aqua-project
+ cd my-aqua-project
+
+ # Or for a library
+ cargo new --lib my-aqua-lib
+ ```
+ </Step>
+
+ <Step title="Add Aqua SDK Dependency">
+ Add the Aqua SDK to your `Cargo.toml`:
+
+ ```toml
+ [dependencies]
+ aqua-rs-sdk = { git = "https://github.com/inblockio/aqua-verifier-rs" }
+ tokio = { version = "1", features = ["full"] }
+ serde_json = "1.0"
+ ```
+ </Step>
+
+ <Step title="Create Your First Aqua Chain">
+ Update `src/main.rs`:
+
+ ```rust
+ use aqua_rs_sdk::primitives::Method;
+ use aqua_rs_sdk::schema::file_data::FileData;
+ use aqua_rs_sdk::Aquafier;
+ use std::path::PathBuf;
+
+ #[tokio::main]
+ async fn main() -> Result<(), Box<dyn std::error::Error>> {
+ println!("Creating Aqua chain...");
+
+ // Read file content
+ let filename = "test.txt".to_string();
+ let file_content = tokio::fs::read(&filename).await?;
+
+ // Create file data
+ let file_data = FileData::new(
+ filename.clone(),
+ file_content,
+ PathBuf::from(format!("./{}", filename)),
+ );
+
+ // Initialize Aquafier
+ let aquafier = Aquafier::new(None, None);
+
+ // Create genesis revision (notarize the file)
+ let result = aquafier.create_genesis_revision(file_data, Method::Scalar);
+
+ match result {
+ Ok(tree) => {
+ println!("✓ Aqua chain created successfully!");
+ println!("{}", serde_json::to_string_pretty(&tree)?);
+
+ println!("\nYou can now:");
+ println!("- Add a signature revision");
+ println!("- Witness on blockchain");
+ println!("- Verify the chain");
+ }
+ Err(e) => {
+ eprintln!("Error: {:#?}", e);
+ }
+ }
+
+ Ok(())
+ }
+ ```
+ </Step>
+
+ <Step title="Build and Run">
+ ```bash
+ cargo build
+ cargo run
+ ```
+
+ You should see confirmation that your object revision was created!
+ </Step>
+</Steps>
+
+---
+
+## CLI Tool Quick Start
+
+<Info>
+**Prerequisites**:
+- Rust and Cargo installed
+</Info>
+
+<Steps>
+ <Step title="Install the CLI">
+ ```bash
+ # Clone and build
+ git clone https://github.com/inblockio/aqua-cli-rs
+ cd aqua-cli-rs
+ cargo build --release
+
+ # The binary will be at target/release/aqua-cli
+ ```
+ </Step>
+
+ <Step title="Verify an Aqua Chain">
+ ```bash
+ ./target/release/aqua-cli verify --file chain.aqua.json
+ ```
+ </Step>
+
+ <Step title="Get Help">
+ ```bash
+ ./target/release/aqua-cli --help
+ ```
+ </Step>
+</Steps>
+
+See the [CLI documentation](/dev_tools/aqua_cli) for more commands.
+
+---
+
+## Troubleshooting
+
+<AccordionGroup>
+ <Accordion title="Node.js: Module not found error">
+ **Issue**: `Cannot find module 'aqua-js-sdk'`
+
+ **Solutions**:
+ 1. Ensure you ran `npm install aqua-js-sdk`
+ 2. Check you're in the correct directory with `package.json`
+ 3. Try deleting `node_modules` and `package-lock.json`, then run `npm install` again
+ 4. For TypeScript, ensure you have `@types/node` installed
+ </Accordion>
+
+ <Accordion title="TypeScript: Type errors">
+ **Issue**: TypeScript compilation errors
+
+ **Solutions**:
+ 1. Ensure you have TypeScript installed: `npm install --save-dev typescript`
+ 2. Create or update `tsconfig.json`:
+ ```json
+ {
+ "compilerOptions": {
+ "target": "ES2020",
+ "module": "commonjs",
+ "esModuleInterop": true,
+ "strict": true
+ }
+ }
+ ```
+ 3. Use `tsx` for direct TypeScript execution: `npm install --save-dev tsx`
+ </Accordion>
+
+ <Accordion title="Rust: Compilation errors">
+ **Issue**: Build fails with dependency errors
+
+ **Solutions**:
+ 1. Update Rust: `rustup update`
+ 2. Clean and rebuild: `cargo clean && cargo build`
+ 3. Check you're using Rust 1.70 or higher: `rustc --version`
+ 4. Ensure your `Cargo.toml` has the correct repository URL
+ </Accordion>
+
+ <Accordion title="MetaMask: Not detecting in Node.js">
+ **Issue**: MetaMask signing doesn't work
+
+ **Solution**: MetaMask works in browser environments only. For Node.js:
+ - Use CLI signing with mnemonic in `credentials.json`
+ - Or use DID or P12 signing methods
+ - See [Development Guide](/development) for details
+ </Accordion>
+
+ <Accordion title="Witnessing: Network errors">
+ **Issue**: Ethereum witness fails
+
+ **Solutions**:
+ 1. Ensure you have ETH in your wallet (testnet ETH for Sepolia/Holesky)
+ 2. Get testnet ETH from faucets:
+ - Sepolia: [sepoliafaucet.com](https://sepoliafaucet.com)
+ - Holesky: [holesky-faucet.pk910.de](https://holesky-faucet.pk910.de)
+ 3. Check network connectivity
+ 4. Verify your Alchemy API key is correct
+ </Accordion>
+</AccordionGroup>
+
+
+---
+
+## What You've Learned
+
+Congratulations! You've created your first Aqua chain. Here's what you accomplished:
+
+✅ Installed an Aqua SDK (JavaScript or Rust)<br/>
+✅ Created a genesis revision (notarized data)<br/>
+✅ Understood the basic Aqua workflow<br/>
+✅ Ready to add signatures and witnesses<br/>
+
+## Next Steps
+
+Now that you have the basics, dive deeper into Aqua Protocol's features:
+
+<CardGroup cols={2}>
+ <Card title="Signing Revisions" icon="signature" href="/schema_reference/signing_revision">
+ Add cryptographic signatures with RSA, Ethereum, or DID methods
+ </Card>
+
+ <Card title="Witnessing" icon="clock" href="/schema_reference/witness_revision">
+ Anchor your chains to Ethereum, TSA, or Nostr for timestamps
+ </Card>
+
+ <Card title="Linking Chains" icon="link" href="/schema_reference/link_revision">
+ Connect multiple Aqua Trees to build complex provenance graphs
+ </Card>
+
+ <Card title="Using Templates" icon="table" href="/schema_reference/template_revision">
+ Define data schemas with JSON Schema validation (v4 only)
+ </Card>
+
+ <Card title="Development Guide" icon="code" href="/development">
+ Complete guide for signing methods, witnessing, and advanced usage
+ </Card>
+
+ <Card title="Schema Reference" icon="book" href="/schema_reference/introduction">
+ Detailed technical specifications for all revision types
+ </Card>
+
+ <Card title="Use Cases" icon="lightbulb" href="/use_cases/introduction">
+ Explore real-world applications and implementation patterns
+ </Card>
+
+ <Card title="Examples" icon="github" href="https://github.com/inblockio/aqua-examples">
+ Browse complete working examples in multiple languages
+ </Card>
+</CardGroup>
+
+## Complete Workflow Example
+
+Want to see the full workflow including signing and witnessing?
+
+<Tabs>
+ <Tab title="JavaScript">
+ Check out the [complete JavaScript example](https://github.com/inblockio/aqua-js-sdk/tree/master/examples) in the SDK repository.
+ </Tab>
+
+ <Tab title="Rust">
+ Check out the [Rust SDK documentation](/dev_tools/aqua_sdk) for complete examples.
+ </Tab>
+</Tabs>
+
+## Try Aquafier
+
+Not ready to code yet? Try our web-based demo:
+
+<CardGroup cols={2}>
+ <Card title="Aquafier Demo" icon="globe" href="https://aquafier.inblock.io">
+ Upload and notarize files through a web interface
+ </Card>
+
+ <Card title="Test Environment" icon="flask" href="https://dev.inblock.io">
+ Experiment safely in the development environment
+ </Card>
+</CardGroup>
+
+## Get Help
+
+<CardGroup cols={2}>
+ <Card title="GitHub Issues" icon="github" href="https://github.com/inblockio">
+ Report bugs or ask questions on GitHub
+ </Card>
+
+ <Card title="Email Support" icon="envelope" href="mailto:info@inblock.io">
+ Contact our team for assistance
+ </Card>
+
+ <Card title="Documentation" icon="book" href="/">
+ Browse comprehensive guides and references
+ </Card>
+
+ <Card title="Community" icon="users" href="https://github.com/inblockio/aqua-examples/discussions">
+ Join discussions with other developers
+ </Card>
+</CardGroup>
+
+---
+
+<Note>
+**Ready to build?** Start with the [Development Guide](/development) for detailed instructions on signing, witnessing, and advanced features.
+</Note>
diff --git a/schema_reference/aqua_tree.mdx b/schema_reference/aqua_tree.mdx
new file mode 100644
index 00000000..aed1641f
--- /dev/null
+++ b/schema_reference/aqua_tree.mdx
@@ -0,0 +1,259 @@
+---
+title: "Aqua Tree"
+description: "The root data structure containing revisions and metadata"
+---
+
+
+The **Aqua Tree** is the primary data structure in Aqua Protocol. It serves as the container for all revisions, their relationships, and associated metadata. An Aqua Tree represents a complete, self-contained unit that can be stored, transmitted, and verified independently.
+
+## Why "Tree" and Not "Chain"?
+
+The term "tree" is intentional. While revisions form chains through their `previous_hash` references, the structure supports **branching** where a single revision can have multiple children. This creates a tree topology rather than a simple linear chain.
+
+```
+Genesis Revision
+ |
+ Revision A
+ / \
+Rev B Rev C ← Branching creates a tree
+ | |
+Rev D Rev E
+```
+
+## Structure
+
+An Aqua Tree consists of two primary components:
+
+### Core Fields
+
+| Field | Type | Required | Description |
+|-------|------|----------|-------------|
+| `revisions` | Object | Yes | Map of revision hashes to revision objects |
+| `file_index` | Object | Yes | Map of content hashes to filenames |
+
+### Complete Structure
+
+```json
+{
+ "revisions": {
+ "0xabc123...": {
+ "revision_type": "0x742b74c87ccd7bfc76eaec416027a0bc039b59b9c2d452ea55a5c0e9b0e3f08e",
+ "nonce": "0x3fa8b1c2d3e4f5a67b8c9d0e1f2a3b4c",
+ "local_timestamp": 1704067200,
+ "version": "https://aqua-protocol.org/docs/v4/schema",
+ // ... revision-specific fields
+ },
+ "0xdef456...": {
+ // ... another revision
+ }
+ },
+ "file_index": {
+ "0xe1bcaa92b0ea2f0eb1f046ca4fc877f26726e5bec8b1a5cf25504a29bc4e0f28": "document.pdf",
+ "0x9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08": "contract.txt"
+ }
+}
+```
+
+## Revisions Map
+
+The `revisions` field is an object where:
+- **Keys**: Verification hashes of revisions (hex strings prefixed with `0x`)
+- **Values**: Complete revision objects
+
+Each revision is indexed by its verification hash, which is computed from the revision's canonical form. This allows O(1) lookup of any revision by its hash.
+
+### Revision Hash as Key
+
+```json
+{
+ "revisions": {
+ "0xabc123...": { /* revision object */ },
+ "0xdef456...": { /* revision object */ }
+ }
+}
+```
+
+The hash serves as:
+- Unique identifier for the revision
+- Key for efficient lookups
+- Reference in `previous_hash` fields to build the chain
+
+## File Index
+
+The `file_index` maps content hashes to human-readable filenames. This provides context about what content each hash represents.
+
+See the [File Index documentation](/schema_reference/file_index) for detailed information.
+
+## Complete Example
+
+Here's a minimal Aqua Tree with a genesis object revision and a signature:
+
+```json
+{
+ "revisions": {
+ "0x742b74c87ccd7bfc76eaec416027a0bc039b59b9c2d452ea55a5c0e9b0e3f08e": {
+ "revision_type": "0x742b74c87ccd7bfc76eaec416027a0bc039b59b9c2d452ea55a5c0e9b0e3f08e",
+ "nonce": "0x3fa8b1c2d3e4f5a67b8c9d0e1f2a3b4c",
+ "local_timestamp": 1704067200,
+ "version": "https://aqua-protocol.org/docs/v4/schema",
+ "method": "scalar",
+ "hash_type": "FIPS_202-SHA3-256",
+ "payload": {
+ "payload_type": "text/plain",
+ "hash": "0x9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08",
+ "hash_type": "FIPS_202-SHA3-256",
+ "descriptor": "Initial Document"
+ }
+ },
+ "0xsig123...": {
+ "revision_type": "0x8e5b2f9c4d3a1e7b6c8f9d0e2a5b3c4d1e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b",
+ "nonce": "0x1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d",
+ "local_timestamp": 1704067260,
+ "version": "https://aqua-protocol.org/docs/v4/schema",
+ "method": "scalar",
+ "hash_type": "FIPS_202-SHA3-256",
+ "previous_hash": "0x742b74c87ccd7bfc76eaec416027a0bc039b59b9c2d452ea55a5c0e9b0e3f08e",
+ "signature_type": "eip191",
+ "signature": "0x8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c901",
+ "wallet_address": "0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb8"
+ }
+ },
+ "file_index": {
+ "0x9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08": "document.txt"
+ }
+}
+```
+
+## Navigating the Tree
+
+### Finding the Genesis Revision
+
+The genesis revision has no `previous_hash` field or has `previous_hash: null`. To find it:
+
+```typescript
+const genesis = Object.values(aquaTree.revisions).find(
+ rev => !rev.previous_hash
+);
+```
+
+### Following the Chain
+
+To traverse from genesis to latest:
+
+```typescript
+function getChain(aquaTree, startHash) {
+ const chain = [];
+ let current = aquaTree.revisions[startHash];
+
+ while (current) {
+ chain.push(current);
+
+ // Find child (revision that references this one)
+ const childHash = Object.keys(aquaTree.revisions).find(hash =>
+ aquaTree.revisions[hash].previous_hash === currentHash
+ );
+
+ current = childHash ? aquaTree.revisions[childHash] : null;
+ }
+
+ return chain;
+}
+```
+
+### Finding All Branches
+
+For trees with branches:
+
+```typescript
+function findChildren(aquaTree, parentHash) {
+ return Object.entries(aquaTree.revisions)
+ .filter(([_, rev]) => rev.previous_hash === parentHash)
+ .map(([hash, rev]) => ({ hash, revision: rev }));
+}
+```
+
+## Storage and Transmission
+
+### File Storage
+
+Aqua Trees are typically stored as JSON files with `.aqua.json` extension:
+
+```bash
+document.aqua.json
+contract-2024-01-01.aqua.json
+```
+
+### Size Considerations
+
+- Each revision: ~200-500 bytes (depending on type and content)
+- Typical Aqua Tree: 1-10 KB for simple documents
+- Large trees with many revisions: Up to several MB
+
+### Compression
+
+For large trees, consider gzip compression:
+
+```bash
+gzip document.aqua.json
+# Results in document.aqua.json.gz
+```
+
+## Validation
+
+An Aqua Tree is valid if:
+
+1. **All revisions have valid hashes**: Each revision's hash matches its computed verification hash
+2. **Previous hashes reference existing revisions**: All `previous_hash` values point to revisions in the tree (except genesis)
+3. **No circular references**: Following `previous_hash` links eventually reaches genesis
+4. **Signatures are valid**: All signature revisions have valid cryptographic signatures
+5. **File index matches**: All hashes in file_index correspond to content referenced in revisions
+
+## Use Cases
+
+### Document Management
+
+Store a document's complete revision history:
+- Genesis: Initial document creation
+- Updates: Each modification as new object revision
+- Signatures: Approvals from stakeholders
+- Witnesses: Blockchain timestamps for legal proof
+
+### Multi-Document Projects
+
+Use link revisions to connect related Aqua Trees:
+- Main project tree links to component trees
+- Each component has its own revision history
+- Verification cascades through linked trees
+
+### Credential Issuance
+
+Issue verifiable credentials:
+- Genesis: Credential data (degree, certificate, license)
+- Signature: Issuing authority signs
+- Witness: Blockchain timestamp for verification
+- File index: Maps credential hash to recipient identifier
+
+## Performance Considerations
+
+### Lookup Performance
+
+- Hash-based lookup: O(1)
+- Finding children: O(n) where n is number of revisions
+- Full chain traversal: O(m) where m is chain length
+
+### Optimization Strategies
+
+For large trees:
+1. **Index children separately**: Maintain a `children` map for each revision
+2. **Cache traversals**: Store pre-computed chain paths
+3. **Lazy loading**: Load only needed revisions for verification
+4. **Prune old revisions**: Archive historical revisions separately
+
+## Related Documentation
+
+- [Revision Types](/schema_reference/revision) - Overview of all revision types
+- [Object Revision](/schema_reference/object_revision) - Genesis and data revisions
+- [Signature Revision](/schema_reference/signing_revision) - Cryptographic signatures
+- [Witness Revision](/schema_reference/witness_revision) - Blockchain anchoring
+- [Link Revision](/schema_reference/link_revision) - Connecting trees
+- [File Index](/schema_reference/file_index) - Content hash mapping
\ No newline at end of file
diff --git a/schema_reference/file_index.mdx b/schema_reference/file_index.mdx
new file mode 100644
index 00000000..0b2ec90b
--- /dev/null
+++ b/schema_reference/file_index.mdx
@@ -0,0 +1,383 @@
+---
+title: "File Index"
+description: "Mapping content hashes to human-readable filenames"
+---
+
+# File Index
+
+The **File Index** is a component of the Aqua Tree that maps content hashes to human-readable filenames. It provides context about what each hash represents, making Aqua Trees more understandable and navigable.
+
+## Purpose
+
+When content is hashed (documents, images, data files), the resulting hash is a cryptographic string that provides no information about the original content. The file index solves this by maintaining a mapping between:
+
+- **Content hashes**: SHA3-256 hashes of file content
+- **Filenames**: Human-readable names that describe the content
+
+This enables users and applications to understand what content each hash represents without needing to store or transmit the actual content.
+
+## Structure
+
+The file index is a simple key-value object:
+
+```json
+{
+ "file_index": {
+ "0xe1bcaa92b0ea2f0eb1f046ca4fc877f26726e5bec8b1a5cf25504a29bc4e0f28": "document.pdf",
+ "0x9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08": "test.txt",
+ "0x3b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9": "image.png"
+ }
+}
+```
+
+### Field Format
+
+| Component | Description | Format |
+|-----------|-------------|--------|
+| **Key** | Content hash | Hex string prefixed with `0x`, typically 64 characters (SHA3-256) |
+| **Value** | Filename | String, typically includes file extension |
+
+## Hash Sources
+
+File index entries can reference hashes from several sources:
+
+### 1. Object Revision Payloads
+
+When an object revision contains content:
+
+```json
+{
+ "revisions": {
+ "0xrev_hash...": {
+ "payload": {
+ "hash": "0xe1bcaa92b0ea2f0eb1f046ca4fc877f26726e5bec8b1a5cf25504a29bc4e0f28",
+ "payload_type": "application/pdf",
+ "descriptor": "Contract Document"
+ }
+ }
+ },
+ "file_index": {
+ "0xe1bcaa92b0ea2f0eb1f046ca4fc877f26726e5bec8b1a5cf25504a29bc4e0f28": "contract.pdf"
+ }
+}
+```
+
+### 2. Linked External Trees
+
+When link revisions reference other Aqua Trees:
+
+```json
+{
+ "revisions": {
+ "0xlink_hash...": {
+ "revision_type": "0x1c3e5a7b9d2f4e6a8c0b1d3f5e7a9c2b4d6e8f0a1c3e5a7b9d2f4e6a8c0b1d3f",
+ "links": [
+ {
+ "verification_hash": "0xexternal_tree_hash...",
+ "content_hash": "0x3b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9"
+ }
+ ]
+ }
+ },
+ "file_index": {
+ "0x3b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9": "component_tree.aqua.json"
+ }
+}
+```
+
+### 3. Template Content
+
+When template revisions define schemas:
+
+```json
+{
+ "file_index": {
+ "0xtemplate_hash...": "user_credential_schema.json"
+ }
+}
+```
+
+## Complete Example
+
+Here's a complete Aqua Tree showing how file_index integrates:
+
+```json
+{
+ "revisions": {
+ "0x742b74c87ccd7bfc76eaec416027a0bc039b59b9c2d452ea55a5c0e9b0e3f08e": {
+ "revision_type": "0x742b74c87ccd7bfc76eaec416027a0bc039b59b9c2d452ea55a5c0e9b0e3f08e",
+ "nonce": "0x3fa8b1c2d3e4f5a67b8c9d0e1f2a3b4c",
+ "local_timestamp": 1704067200,
+ "version": "https://aqua-protocol.org/docs/v4/schema",
+ "method": "scalar",
+ "hash_type": "FIPS_202-SHA3-256",
+ "payload": {
+ "payload_type": "application/pdf",
+ "hash": "0x9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08",
+ "hash_type": "FIPS_202-SHA3-256",
+ "descriptor": "Sales Contract"
+ }
+ },
+ "0xsig_hash...": {
+ "revision_type": "0x8e5b2f9c4d3a1e7b6c8f9d0e2a5b3c4d1e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b",
+ "previous_hash": "0x742b74c87ccd7bfc76eaec416027a0bc039b59b9c2d452ea55a5c0e9b0e3f08e",
+ "signature_type": "eip191",
+ "signature": "0x...",
+ "wallet_address": "0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb8"
+ }
+ },
+ "file_index": {
+ "0x9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08": "sales_contract_2024.pdf"
+ }
+}
+```
+
+## Benefits
+
+### 1. Human Readability
+
+Users can understand what content is in the tree without decoding hashes:
+
+```json
+"file_index": {
+ "0xabc...": "proposal.docx",
+ "0xdef...": "budget.xlsx",
+ "0x123...": "diagram.png"
+}
+```
+
+Instead of just seeing cryptographic hashes, users see meaningful filenames.
+
+### 2. Content Discovery
+
+Applications can list available content:
+
+```typescript
+const filenames = Object.values(aquaTree.file_index);
+console.log("Available files:", filenames);
+// Output: ["proposal.docx", "budget.xlsx", "diagram.png"]
+```
+
+### 3. Reverse Lookup
+
+Find the hash for a known filename:
+
+```typescript
+function findHashByFilename(aquaTree, filename) {
+ return Object.entries(aquaTree.file_index)
+ .find(([_, name]) => name === filename)?.[0];
+}
+
+const hash = findHashByFilename(tree, "contract.pdf");
+```
+
+### 4. Linked Tree Context
+
+When trees link to external trees, the file index identifies them:
+
+```json
+"file_index": {
+ "0xhash1...": "main_document.pdf",
+ "0xhash2...": "appendix_a.aqua.json", // External tree
+ "0xhash3...": "appendix_b.aqua.json" // External tree
+}
+```
+
+## Best Practices
+
+### Descriptive Filenames
+
+Use clear, descriptive names with appropriate extensions:
+
+```json
+// Good
+"file_index": {
+ "0xabc...": "employment_contract_john_doe_2024.pdf",
+ "0xdef...": "diploma_computer_science_2024.pdf"
+}
+
+// Avoid
+"file_index": {
+ "0xabc...": "file1.dat",
+ "0xdef...": "doc.bin"
+}
+```
+
+### Include Extensions
+
+Always include file extensions to indicate content type:
+
+```json
+"file_index": {
+ "0xabc...": "document.pdf", // PDF document
+ "0xdef...": "image.png", // PNG image
+ "0x123...": "data.json", // JSON data
+ "0x456...": "archive.zip", // Compressed archive
+ "0x789...": "video.mp4" // Video file
+}
+```
+
+### Unique Names
+
+Ensure filenames are unique within a tree to avoid ambiguity:
+
+```json
+// Good - unique names
+"file_index": {
+ "0xabc...": "contract_v1.pdf",
+ "0xdef...": "contract_v2.pdf"
+}
+
+// Avoid - duplicate names
+"file_index": {
+ "0xabc...": "contract.pdf",
+ "0xdef...": "contract.pdf" // Ambiguous!
+}
+```
+
+### External Tree Naming
+
+For linked external trees, use the `.aqua.json` extension:
+
+```json
+"file_index": {
+ "0xhash...": "component_a.aqua.json",
+ "0xhash...": "dependency_b.aqua.json"
+}
+```
+
+## Optional Nature
+
+While the file index is a standard component of Aqua Trees, entries are **optional**:
+
+- Not all hashes need file index entries
+- The tree remains valid without file_index
+- Applications can function using hashes alone
+
+However, including file index entries significantly improves usability.
+
+## Validation
+
+The file index should be validated for:
+
+### 1. Hash Format
+
+All keys must be valid hex strings:
+
+```typescript
+function isValidHash(hash: string): boolean {
+ return /^0x[0-9a-fA-F]{64}$/.test(hash);
+}
+```
+
+### 2. Referenced Hashes
+
+Hashes in file_index should appear in revisions:
+
+```typescript
+function validateFileIndex(aquaTree) {
+ const referencedHashes = new Set();
+
+ // Collect all content hashes from revisions
+ Object.values(aquaTree.revisions).forEach(rev => {
+ if (rev.payload?.hash) {
+ referencedHashes.add(rev.payload.hash);
+ }
+ if (rev.links) {
+ rev.links.forEach(link => referencedHashes.add(link.content_hash));
+ }
+ });
+
+ // Check file_index entries
+ for (const hash of Object.keys(aquaTree.file_index)) {
+ if (!referencedHashes.has(hash)) {
+ console.warn(`Orphaned file_index entry: ${hash}`);
+ }
+ }
+}
+```
+
+### 3. Filename Validity
+
+Filenames should not contain invalid characters:
+
+```typescript
+function isValidFilename(filename: string): boolean {
+ // Avoid: null bytes, path separators, control characters
+ return !/[\x00\/\\]/.test(filename);
+}
+```
+
+## Use Cases
+
+### Document Management Systems
+
+Track document names across revisions:
+
+```json
+"file_index": {
+ "0xv1...": "proposal_draft_v1.docx",
+ "0xv2...": "proposal_draft_v2.docx",
+ "0xfinal...": "proposal_final.docx"
+}
+```
+
+### Multi-File Projects
+
+Reference multiple files in a project:
+
+```json
+"file_index": {
+ "0xreadme...": "README.md",
+ "0xcode...": "main.rs",
+ "0xconfig...": "config.toml",
+ "0xdocs...": "documentation.pdf"
+}
+```
+
+### Supply Chain Tracking
+
+Identify product-related documents:
+
+```json
+"file_index": {
+ "0xcert...": "organic_certification.pdf",
+ "0xinspect...": "quality_inspection_report.pdf",
+ "0xship...": "shipping_manifest.pdf"
+}
+```
+
+### Credential Systems
+
+Map credential hashes to recipient identifiers:
+
+```json
+"file_index": {
+ "0xdiploma...": "diploma_john_doe_2024.pdf",
+ "0xtranscript...": "transcript_john_doe_2024.pdf"
+}
+```
+
+## Storage Considerations
+
+### Size Impact
+
+Each file index entry adds approximately 100-150 bytes:
+- 64-character hash: ~66 bytes
+- Filename: 20-50 bytes typical
+- JSON overhead: ~20 bytes
+
+For large trees, this is minimal compared to revision data.
+
+### Compression
+
+File index compresses well with gzip due to repetitive patterns:
+- Hash prefixes (`0x`)
+- Common file extensions (`.pdf`, `.json`)
+
+## Related Documentation
+
+- [Aqua Tree](/schema_reference/aqua_tree) - Complete tree structure
+- [Object Revision](/schema_reference/object_revision) - Revisions containing content hashes
+- [Link Revision](/schema_reference/link_revision) - Linking to external trees
+- [Template Revision](/schema_reference/template_revision) - Schema definitions
diff --git a/schema_reference/introduction.mdx b/schema_reference/introduction.mdx
new file mode 100644
index 00000000..809b7805
--- /dev/null
+++ b/schema_reference/introduction.mdx
@@ -0,0 +1,415 @@
+---
+title: "Aqua Protocol Schema Reference "
+description: "Complete technical reference for Aqua Protocol v4"
+---
+
+
+This section provides the complete technical specification for Aqua Protocol v4. Here you'll find detailed documentation on data structures, revision types, validation rules, and implementation requirements.
+
+## What is Aqua Protocol?
+
+Aqua Protocol is a cryptographic protocol for creating verifiable, timestamped chains of revisions with signatures and blockchain anchoring. It enables:
+
+- **Tamper-Proof Records**: Cryptographic hashes ensure any modification is detectable
+- **Multi-Party Signatures**: Multiple parties can sign revisions for authentication
+- **Blockchain Timestamping**: Anchor revisions to Ethereum, Nostr, or TSA for provable timestamps
+- **Provenance Tracking**: Link revisions to track data flow and transformations
+- **Template Validation**: Enforce data schemas with JSON Schema
+
+## Core Data Structure
+
+When you notarize content with Aqua Protocol, the output is a JSON file called an **Aqua Tree**.
+
+### Aqua Tree Structure
+
+```json
+{
+ "revisions": {
+ "0xhash1...": { /* revision object */ },
+ "0xhash2...": { /* revision object */ }
+ },
+ "file_index": {
+ "0xcontenthash1...": "document.pdf",
+ "0xcontenthash2...": "image.png"
+ }
+}
+```
+
+The Aqua Tree contains two primary components:
+
+- **[Revisions](/schema_reference/revision)**: Map of verification hashes to revision objects
+- **[File Index](/schema_reference/file_index)**: Map of content hashes to filenames
+
+See the [Aqua Tree documentation](/schema_reference/aqua_tree) for complete details.
+
+## Revision Types
+
+Aqua Protocol v4 defines five revision types, each serving a specific purpose:
+
+### 1. Object Revision
+**Purpose**: Store data content (documents, files, structured data)
+
+**Use for**:
+- Genesis revisions (first revision in a chain)
+- Document updates and modifications
+- Data snapshots
+
+**Learn more**: [Object Revision Reference](/schema_reference/object_revision)
+
+### 2. Template Revision
+**Purpose**: Define data schemas and validation rules
+
+**Use for**:
+- Enforcing data structure with JSON Schema
+- Creating reusable data models
+- Validating object revision content
+
+**Learn more**: [Template Revision Reference](/schema_reference/template_revision)
+
+### 3. Signature Revision
+**Purpose**: Add cryptographic signatures for authentication
+
+**Use for**:
+- Proving authorship and authorization
+- Multi-party approval workflows
+- Non-repudiation
+
+**Signature Types**:
+- **RSA**: Traditional RSA signatures
+- **EIP-191**: Ethereum-style signatures
+- **DID:JWS**: Decentralized identifier signatures
+
+**Learn more**: [Signature Revision Reference](/schema_reference/signing_revision)
+
+### 4. Witness Revision
+**Purpose**: Anchor revisions to blockchain for timestamping
+
+**Use for**:
+- Proving existence at specific time
+- Creating tamper-proof timestamps
+- Regulatory compliance
+
+**Networks Supported**:
+- Ethereum (mainnet, Sepolia, Holesky)
+- Nostr
+- TSA (RFC 3161 Timestamping Authorities)
+
+**Learn more**: [Witness Revision Reference](/schema_reference/witness_revision)
+
+### 5. Link Revision
+**Purpose**: Connect to other Aqua Trees
+
+**Use for**:
+- Referencing dependencies
+- Building composite documents
+- Creating provenance graphs
+
+**Learn more**: [Link Revision Reference](/schema_reference/link_revision)
+
+## Common Revision Fields
+
+All revision types share these common fields:
+
+| Field | Type | Required | Description |
+|-------|------|----------|-------------|
+| `revision_type` | string | Yes | Hash identifying the revision type |
+| `nonce` | string | Yes | Random 16-byte hex string for uniqueness |
+| `local_timestamp` | number | Yes | Unix timestamp when revision was created |
+| `version` | string | Yes | Protocol version: `https://aqua-protocol.org/docs/v4/schema` |
+| `method` | string | Yes | Canonicalization method: `"scalar"` or `"tree"` |
+| `hash_type` | string | Yes | Hash algorithm: `"FIPS_202-SHA3-256"` |
+| `previous_hash` | string | No | Hash of previous revision (absent in genesis) |
+
+Additional fields depend on the specific revision type.
+
+## Canonicalization Methods
+
+Aqua Protocol v4 supports two methods for computing revision hashes:
+
+### Scalar Method
+**Best for**: Simple, straightforward hashing
+
+```json
+{
+ "method": "scalar",
+ // Content hashed as-is
+}
+```
+
+The entire revision is serialized and hashed directly.
+
+### Tree Method
+**Best for**: Selective disclosure, large content
+
+```json
+{
+ "method": "tree",
+ "leaves": [
+ "0xleaf1hash...",
+ "0xleaf2hash..."
+ ]
+}
+```
+
+Content is broken into leaves, each hashed separately, then combined in a Merkle tree.
+
+## Verification Hash
+
+Each revision has a **verification hash** computed from its canonical form using SHA3-256:
+
+```
+verification_hash = SHA3-256(canonical_revision_json)
+```
+
+This hash serves as:
+- Unique identifier for the revision
+- Key in the revisions map
+- Reference in `previous_hash` fields
+- Proof of integrity
+
+## Revision Chains
+
+Revisions form chains through `previous_hash` references:
+
+```
+Genesis (no previous_hash)
+ ↓
+Revision A (previous_hash → Genesis)
+ ↓
+Signature B (previous_hash → Revision A)
+ ↓
+Witness C (previous_hash → Signature B)
+```
+
+### Genesis Revision
+
+The first revision in a chain:
+- Has no `previous_hash` field (or `previous_hash: null`)
+- Typically an object or template revision
+- Establishes the chain's starting point
+
+### Subsequent Revisions
+
+All revisions after genesis:
+- Must have `previous_hash` pointing to an existing revision
+- Build upon the chain's history
+- Can be any revision type
+
+## Example: Complete Aqua Tree
+
+Here's a minimal example showing a document with signature and witness:
+
+```json
+{
+ "revisions": {
+ "0x742b74c87ccd7bfc76eaec416027a0bc039b59b9c2d452ea55a5c0e9b0e3f08e": {
+ "revision_type": "0x742b74c87ccd7bfc76eaec416027a0bc039b59b9c2d452ea55a5c0e9b0e3f08e",
+ "nonce": "0x3fa8b1c2d3e4f5a67b8c9d0e1f2a3b4c",
+ "local_timestamp": 1704067200,
+ "version": "https://aqua-protocol.org/docs/v4/schema",
+ "method": "scalar",
+ "hash_type": "FIPS_202-SHA3-256",
+ "payload": {
+ "payload_type": "application/pdf",
+ "hash": "0x9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08",
+ "hash_type": "FIPS_202-SHA3-256",
+ "descriptor": "Contract Document"
+ }
+ },
+ "0x8e5b2f9c4d3a1e7b6c8f9d0e2a5b3c4d1e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b": {
+ "revision_type": "0x8e5b2f9c4d3a1e7b6c8f9d0e2a5b3c4d1e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b",
+ "nonce": "0x1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d",
+ "local_timestamp": 1704067260,
+ "version": "https://aqua-protocol.org/docs/v4/schema",
+ "method": "scalar",
+ "hash_type": "FIPS_202-SHA3-256",
+ "previous_hash": "0x742b74c87ccd7bfc76eaec416027a0bc039b59b9c2d452ea55a5c0e9b0e3f08e",
+ "signature_type": "eip191",
+ "signature": "0x8c9d0e1f...",
+ "wallet_address": "0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb8"
+ },
+ "0x1c3e5a7b9d2f4e6a8c0b1d3f5e7a9c2b4d6e8f0a1c3e5a7b9d2f4e6a8c0b1d3f": {
+ "revision_type": "0x1c3e5a7b9d2f4e6a8c0b1d3f5e7a9c2b4d6e8f0a1c3e5a7b9d2f4e6a8c0b1d3f",
+ "nonce": "0x2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e",
+ "local_timestamp": 1704067320,
+ "version": "https://aqua-protocol.org/docs/v4/schema",
+ "method": "scalar",
+ "hash_type": "FIPS_202-SHA3-256",
+ "previous_hash": "0x8e5b2f9c4d3a1e7b6c8f9d0e2a5b3c4d1e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b",
+ "merkle_root": "0x9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08",
+ "timestamp": 1704067320,
+ "network": "sepolia",
+ "smart_contract_address": "0x5FbDB2315678afecb367f032d93F642f64180aa3",
+ "transaction_hash": "0x3b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9",
+ "sender_account_address": "0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb8",
+ "merkle_proof": []
+ }
+ },
+ "file_index": {
+ "0x9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08": "contract.pdf"
+ }
+}
+```
+
+This tree contains:
+1. **Object Revision** (genesis): Document content hash
+2. **Signature Revision**: EIP-191 signature from wallet
+3. **Witness Revision**: Ethereum Sepolia timestamp
+
+## Built-in Templates
+
+Aqua Protocol v4 includes several built-in templates:
+
+| Template | Purpose | Hash |
+|----------|---------|------|
+| **Object** | Generic object revision | `0x742b74c87ccd7bfc...` |
+| **Template** | Template definition | `0x9c2f4e6a8c0b1d3f...` |
+| **Signature** | Signature revision | `0x8e5b2f9c4d3a1e7b...` |
+| **Witness** | Witness revision | `0x1c3e5a7b9d2f4e6a...` |
+| **Link** | Link revision | `0x4a6c8e0b2d4f6a8c...` |
+| **File** | File content | `0x5b7d9f1a3c5e7b9d...` |
+| **Domain** | Domain name | `0x6c8e0b2d4f6a8c0b...` |
+| **Email** | Email address | `0x7d9f1a3c5e7b9d2f...` |
+
+Each built-in template has a specific hash that serves as its `revision_type` identifier.
+
+## Hash Format
+
+All hashes in Aqua Protocol v4 use consistent formatting:
+
+- **Algorithm**: SHA3-256 (FIPS 202)
+- **Format**: Hex string prefixed with `0x`
+- **Length**: 66 characters (`0x` + 64 hex digits)
+- **Example**: `0x9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08`
+
+## Timestamp Format
+
+Timestamps use Unix epoch format:
+
+- **Type**: Integer (seconds since January 1, 1970 UTC)
+- **Example**: `1704067200` = January 1, 2024 00:00:00 UTC
+
+## Validation Rules
+
+An Aqua Tree is valid if:
+
+1. **All revisions have valid hashes**: Computed hash matches the key
+2. **Previous hashes exist**: All `previous_hash` values reference existing revisions (except genesis)
+3. **No cycles**: Following `previous_hash` eventually reaches genesis
+4. **Signatures verify**: All signature revisions have valid cryptographic signatures
+5. **Templates validate**: Object revisions with templates match their schema
+6. **Witnesses exist**: Witness revisions reference valid blockchain transactions
+
+## Schema Version
+
+All revisions in Aqua Protocol v4 use:
+
+```json
+{
+ "version": "https://aqua-protocol.org/docs/v4/schema"
+}
+```
+
+This identifies the protocol version and schema specification.
+
+## Implementation Guidelines
+
+### Creating Revisions
+
+1. **Generate nonce**: Create random 16-byte hex string
+2. **Set timestamp**: Use current Unix timestamp
+3. **Add content**: Include revision-specific fields
+4. **Set previous_hash**: Reference prior revision (if not genesis)
+5. **Compute hash**: Canonicalize and hash the revision
+6. **Use hash as key**: Store in revisions map with hash as key
+
+### Verifying Chains
+
+1. **Find genesis**: Locate revision with no `previous_hash`
+2. **Traverse chain**: Follow `previous_hash` references
+3. **Verify hashes**: Recompute and compare each verification hash
+4. **Check signatures**: Validate all cryptographic signatures
+5. **Verify witnesses**: Check blockchain transactions
+6. **Validate templates**: Ensure object data matches schemas
+
+## File Storage
+
+Aqua Trees are typically stored as JSON files:
+
+```bash
+document.aqua.json
+contract-2024-01-01.aqua.json
+```
+
+The `.aqua.json` extension identifies Aqua Protocol files.
+
+## Use Cases
+
+Aqua Protocol v4 schema supports diverse applications:
+
+- **Document Notarization**: Legal documents, contracts, agreements
+- **Supply Chain**: Product tracking, provenance verification
+- **Credentials**: Diplomas, certificates, licenses
+- **Data Integrity**: Scientific data, audit logs, compliance records
+- **Multi-Party Workflows**: Approvals, reviews, collaborative editing
+
+## Navigation
+
+Explore the detailed specifications for each component:
+
+<CardGroup cols={2}>
+ <Card title="Aqua Tree" icon="tree" href="/schema_reference/aqua_tree">
+ Root data structure containing revisions and file index
+ </Card>
+
+ <Card title="File Index" icon="folder" href="/schema_reference/file_index">
+ Mapping content hashes to filenames
+ </Card>
+
+ <Card title="Revision Types" icon="code-branch" href="/schema_reference/revision">
+ Overview of all revision types
+ </Card>
+
+ <Card title="Object Revision" icon="file" href="/schema_reference/object_revision">
+ Store document and data content
+ </Card>
+
+ <Card title="Template Revision" icon="table" href="/schema_reference/template_revision">
+ Define schemas with JSON Schema
+ </Card>
+
+ <Card title="Signature Revision" icon="signature" href="/schema_reference/signing_revision">
+ Add cryptographic signatures
+ </Card>
+
+ <Card title="Witness Revision" icon="clock" href="/schema_reference/witness_revision">
+ Blockchain timestamping
+ </Card>
+
+ <Card title="Link Revision" icon="link" href="/schema_reference/link_revision">
+ Connect to other Aqua Trees
+ </Card>
+</CardGroup>
+
+## Additional Resources
+
+- [Quick Start Guide](/quickstart) - Get started with Aqua Protocol
+- [Version 4 Introduction](/previous_versions/version_4/version_4) - Overview of v4 features
+- [Use Cases](/use_cases/introduction) - Real-world applications
+- [Aqua SDK](/dev_tools/aqua_sdk) - Rust SDK for implementation
+- [Aqua CLI](/dev_tools/aqua_cli) - Command-line tool
+
+## Version History
+
+**Current Version**: 4.0.0 (Beta)
+
+Aqua Protocol v4 introduces:
+- Template system with JSON Schema validation
+- Enhanced revision type system
+- Improved canonicalization methods
+- Better support for complex data structures
+
+For previous versions, see:
+- [Version 3 Documentation](/previous_versions/version_3/introduction) - JavaScript SDK (Stable)
+- [Version 2 Documentation](/previous_versions/version_2/introduction) - Legacy
+- [Version 1 Documentation](/previous_versions/version_1/introduction) - Legacy
diff --git a/schema_reference/link_revision.mdx b/schema_reference/link_revision.mdx
new file mode 100644
index 00000000..9116aff4
Binary files /dev/null and b/schema_reference/link_revision.mdx differ
diff --git a/schema_reference/object_revision.mdx b/schema_reference/object_revision.mdx
new file mode 100644
index 00000000..dc07915e
--- /dev/null
+++ b/schema_reference/object_revision.mdx
@@ -0,0 +1,247 @@
+---
+title: "Object Revision"
+description: "Schema specification for Object Revisions in Aqua Protocol v4"
+---
+
+# Object Revision
+
+An Object Revision is the primary data-carrying revision type in Aqua Protocol v4. It stores arbitrary structured data that conforms to a template schema. Object revisions are typically the first revision in a chain (genesis) or follow other object revisions.
+
+## Overview
+
+Object revisions serve as containers for application data. Each object revision:
+- References a template (via `revision_type` field) that defines its schema
+- Contains a `payload` with the actual data
+- Can be the genesis revision (no `previous_revision`) or link to a previous revision
+- Must conform to the validation rules defined by its template
+
+## Schema Structure
+
+### Fields
+
+| Field | Type | Required | Description |
+|-------|------|----------|-------------|
+| `previous_revision` | string | Conditional | Hash reference to the previous revision. **Optional for genesis revisions**, **Required for subsequent revisions** |
+| `revision_type` | string | Yes | Hash reference to the template that defines the payload schema |
+| `nonce` | string | Yes | Random 16-byte hex string (e.g., `0x2ba6a8b9b987cf8c3567f72871812ae9`) for uniqueness |
+| `local_timestamp` | number | Yes | Unix timestamp (seconds since epoch) when the revision was created |
+| `version` | string | Yes | Protocol version: `"https://aqua-protocol.org/docs/v4/schema"` |
+| `method` | string | Yes | Canonicalization method: `"scalar"` or `"tree"` |
+| `hash_type` | string | Yes | Hash algorithm: `"FIPS_202-SHA3-256"` |
+| `payload` | object | Yes | The actual data, must conform to the referenced template schema |
+
+### Field Details
+
+#### previous_revision
+- **Format**: Lowercase hex string prefixed with `0x` (e.g., `0x3f8a...`)
+- **Length**: Variable (typically 64 characters for SHA3-256 hashes)
+- **Omitted**: Only in genesis revisions (the first revision in a chain)
+- **Purpose**: Creates the chain linkage and ensures revision ordering
+
+#### revision_type
+- **Format**: Hash reference pointing to a Template Revision
+- **Purpose**: Identifies which template validates this object's payload
+- **Example**: `0x1234abcd...` (hash of a template revision)
+- **Validation**: The template's schema must validate the payload
+
+#### payload
+- **Type**: JSON object
+- **Validation**: Must conform to the JSON Schema defined in the referenced template
+- **Flexibility**: Can contain any structured data as long as it matches the template
+- **Size**: Depends on the method:
+ - `scalar`: Entire payload is hashed directly
+ - `tree`: Payload is broken into leaves for merkle tree construction
+
+## Methods
+
+### Scalar Method
+
+The `scalar` method treats the entire object as a single unit. The payload is serialized, canonicalized, and hashed as one block.
+
+**Best for:**
+- Small to medium-sized objects
+- When you need to verify the entire object at once
+- Simple use cases
+
+### Tree Method
+
+The `tree` method breaks the payload into leaves using JSON pointers, creating a merkle tree structure.
+
+**Best for:**
+- Large objects where partial verification is needed
+- When you want to prove specific fields without revealing the entire object
+- Advanced use cases requiring selective disclosure
+
+## Examples
+
+### Example 1: Genesis Object Revision (File)
+
+This is a genesis revision (first in chain) using the File template:
+
+```json
+{
+ "revision_type": "0x742b74c87ccd7bfc76eaec416027a0bc039b59b9c2d452ea55a5c0e9b0e3f08e",
+ "nonce": "0x3fa8b1c2d3e4f5a67b8c9d0e1f2a3b4c",
+ "local_timestamp": 1704067200,
+ "version": "https://aqua-protocol.org/docs/v4/schema",
+ "method": "scalar",
+ "hash_type": "FIPS_202-SHA3-256",
+ "payload": {
+ "payload_type": "application/pdf",
+ "hash": "0x9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08",
+ "hash_type": "FIPS_202-SHA3-256",
+ "descriptor": "Important Contract Document"
+ }
+}
+```
+
+**Note**: No `previous_revision` field because this is a genesis revision.
+
+### Example 2: Subsequent Object Revision (Domain Claim)
+
+This revision follows another revision in the chain:
+
+```json
+{
+ "previous_revision": "0x3f8a7b2c9d1e4f5a6b8c0d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a",
+ "revision_type": "0x8b3e4c7d9f1a2b5c6e8f0a3b4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3",
+ "nonce": "0x7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f",
+ "local_timestamp": 1704070800,
+ "version": "https://aqua-protocol.org/docs/v4/schema",
+ "method": "scalar",
+ "hash_type": "FIPS_202-SHA3-256",
+ "payload": {
+ "domain": "example.com",
+ "wallet_address": "0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb8"
+ }
+}
+```
+
+### Example 3: Object with Tree Method
+
+Using the tree method for a larger object:
+
+```json
+{
+ "previous_revision": "0x1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b",
+ "revision_type": "0x4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a",
+ "nonce": "0x9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b",
+ "local_timestamp": 1704074400,
+ "version": "https://aqua-protocol.org/docs/v4/schema",
+ "method": "tree",
+ "hash_type": "FIPS_202-SHA3-256",
+ "payload": {
+ "name": "John Doe",
+ "email": "john@example.com",
+ "phone": "+1234567890",
+ "address": {
+ "street": "123 Main St",
+ "city": "Anytown",
+ "country": "USA"
+ },
+ "metadata": {
+ "created": "2024-01-01",
+ "verified": true
+ }
+ }
+}
+```
+
+**With tree method**: Each field (using JSON pointers like `/name`, `/email`, `/address/city`) becomes a leaf in the merkle tree.
+
+## Validation Rules
+
+An Object Revision is valid if:
+
+1. **Structure**: Contains all required fields with correct types
+2. **Version**: The `version` field matches `"https://aqua-protocol.org/docs/v4/schema"`
+3. **Method**: The `method` is either `"scalar"` or `"tree"`
+4. **Hash Type**: The `hash_type` is a recognized algorithm (e.g., `"FIPS_202-SHA3-256"`)
+5. **Nonce**: Is a valid 16-byte hex string prefixed with `0x`
+6. **Timestamp**: Is a valid Unix timestamp
+7. **Previous Revision**:
+ - Must be absent for genesis revisions
+ - Must be present and valid for non-genesis revisions
+ - Must reference an existing revision
+8. **Revision Type**: Must reference a valid template revision
+9. **Payload**: Must conform to the JSON Schema defined in the referenced template
+10. **Hash Verification**: The computed hash matches what's expected
+
+## Common Use Cases
+
+### Document Storage
+Store file metadata with hash references:
+```json
+{
+ "payload": {
+ "payload_type": "application/pdf",
+ "hash": "0x...",
+ "hash_type": "FIPS_202-SHA3-256",
+ "descriptor": "Legal Agreement 2024"
+ }
+}
+```
+
+### Identity Claims
+Store verifiable claims about entities:
+```json
+{
+ "payload": {
+ "domain": "company.com",
+ "wallet_address": "0x742d35Cc..."
+ }
+}
+```
+
+### Credential Data
+Store structured credential information:
+```json
+{
+ "payload": {
+ "credential_type": "EmailVerification",
+ "subject": "user@example.com",
+ "issuer": "0x...",
+ "issued_at": 1704067200
+ }
+}
+```
+
+## Relationship with Other Revisions
+
+After creating an Object Revision, you typically:
+
+1. **Sign it** - Add a Signature Revision to prove authenticity
+2. **Witness it** - Add a Witness Revision for timestamped proof
+3. **Update it** - Create a new Object Revision that references this one
+4. **Link it** - Create a Link Revision to connect to other chains
+
+## Implementation Notes
+
+### Creating an Object Revision
+
+When implementing object revision creation:
+
+1. Validate payload against the template schema first
+2. Generate a random 16-byte nonce
+3. Capture the current timestamp
+4. Include `previous_revision` only if not genesis
+5. Serialize according to the chosen method
+6. Compute the hash for verification
+
+### Verifying an Object Revision
+
+To verify an object revision:
+
+1. Check all required fields are present
+2. Validate field types and formats
+3. Verify the referenced template exists
+4. Validate payload against template schema
+5. Recompute the hash and compare
+6. If not genesis, verify `previous_revision` exists and is valid
+
+## See Also
+
+- [Template Revision](/schema_reference/template_revision) - Defines the schema for object payloads
+- [Signature Revision](/schema_reference/signing_revision) - Sign object revisions
+- [Witness Revision](/schema_reference/witness_revision) - Add timestamped proof
+- [Link Revision](/schema_reference/link_revision) - Connect to other chains
diff --git a/schema_reference/revision.mdx b/schema_reference/revision.mdx
new file mode 100644
index 00000000..7e4e3317
--- /dev/null
+++ b/schema_reference/revision.mdx
@@ -0,0 +1,105 @@
+---
+title: "Aqua Protocol Revisions"
+description: "What is a revision , what maked up a revision ?"
+---
+
+Revisions are content-identifiable envelops in Aqua-Protocol. They are atomic and form a graph structure in a hash-tree. It represents the evolutionary, iterative, and historical essence of the atomic objects in the Aqua Protocol.
+
+
+- Revision Chaining: Revisions form chains via optional previous_revision (a SHA3-256 hash), marking genesis if absent.
+- Type Identification: revision_type specifies the revision's purpose—either a reference to a [template](https://www.notion.so/V4-Protocol-Draft-27ae695c0eec801c95fff40830e4c0e4?pvs=21) (32-hex hash) (for [Object](https://www.notion.so/V4-Protocol-Draft-27ae695c0eec801c95fff40830e4c0e4?pvs=21) revisions) or built-in types like "[template](https://www.notion.so/V4-Protocol-Draft-27ae695c0eec801c95fff40830e4c0e4?pvs=21)", "[signature](https://www.notion.so/V4-Protocol-Draft-27ae695c0eec801c95fff40830e4c0e4?pvs=21)", or "[link](https://www.notion.so/V4-Protocol-Draft-27ae695c0eec801c95fff40830e4c0e4?pvs=21)".
+- Timing and Entropy: Includes a Unix timestamp (local_timestamp, unsigned 64-bit) and a random nonce (128-bit hex) for ordering and anti-collision.
+- Versioning: version points to a protocol schema URL or a hash/custom string (up to 128 chars) for compatibility.
+- Canonicalisation Method: method chooses between "scalar" (simple object hash for efficiency) or "tree" (Merkle tree for granular proofs, e.g., selective disclosure).
+- Hash Type: identifier of the hashing function to generate the hash ID of the revision
+- Schema Integration: Optional schema embeds a full JSON Schema (Draft 2020-12) for validating custom data in templates.
+
+
+```JSON
+{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "$id": "https://aqua-protocol.org/docs/v4/metaschema",
+ "title": "Aqua Protocol Metaschema",
+ "description": "Schema for metadata in Aqua Protocol revisions",
+ "type": "object",
+ "properties": {
+ "previous_revision": {
+ "description": "SHA3-256 hash of the previous revision. If not present, this is a genesis revision.",
+ "type": "string",
+ "pattern": "^[0-9a-fA-F]{64}$"
+ },
+ "revision_type": {
+ "description": "Non-traversable reference to a template or one of the specified types.",
+ "oneOf": [
+ {
+ "type": "string",
+ "pattern": "^[0-9a-fA-F]{32}$"
+ "description": "Non-traversable reference to a template revision hash."
+ },
+ {
+ "type": "string",
+ "enum": ["template", "signature", "link"]
+ "description": "Fundamental revision types within Aqua Protocol"
+ }
+ ]
+ },
+ "local_timestamp": {
+ "description": "Unsigned 64-bit integer Unix timestamp.",
+ "type": "integer",
+ "minimum": 0,
+ "maximum": 18446744073709551615
+ },
+ "nonce": {
+ "description": "128-bit random bytes for entropy, hex-encoded.",
+ "type": "string",
+ "pattern": "^[0-9a-fA-F]{32}$"
+ },
+ "version": {
+ "description": "Version identifier: either a specific URL or a SHA256 hash.",
+ "oneOf": [
+ {
+ "type": "string",
+ "const": "https://aqua-protocol.org/docs/v4/schema | FIPS_202-SHA3-256"
+ },
+ {
+ "type": "string",
+ "pattern": "^{32}"
+ "maxLength": 128,
+ }
+ ]
+ },
+ "hash_type": {
+ "description": "Hash function identifier: either FIPS_202-SHA3-256 or a custom hashing type.",
+ "oneOf": [
+ {
+ "type": "string",
+ "const": "FIPS_202-SHA3-256"
+ },
+ {
+ "type": "string",
+ "pattern": "^{32}"
+ "maxLength": 128,
+ }
+ ]
+ }
+ "method": {
+ "description": "Method type.",
+ "type": "string",
+ "enum": ["tree", "scalar"]
+ "description": "Scalar: Is a simple hash of the stringified revision object. This is the default method for performance reasons. Tree: Creates a merkle tree of all the values. This allows a more granular verification. This is used for e.g. selective disclosure",
+ }
+ "schema": {
+ "description": "Schema definition found in template revisions",
+ "type": "object",
+ "$ref": "https://json-schema.org/draft/2020-12/schema"
+ }
+ },
+ "required": ["revision_type", "local_timestamp", "nonce", "version", "hash_type", "method"],
+ // This is to allow other revision types like link revision and signature revision
+ // Its the responsibility of the implementation to be more or less permissive
+ "additionalFields": true
+}
+
+
+
+```
\ No newline at end of file
diff --git a/schema_reference/signing_revision.mdx b/schema_reference/signing_revision.mdx
new file mode 100644
index 00000000..efbed73a
--- /dev/null
+++ b/schema_reference/signing_revision.mdx
@@ -0,0 +1,352 @@
+---
+title: "Signature Revision"
+description: "Schema specification for Signature Revisions in Aqua Protocol v4"
+---
+
+# Signature Revision
+
+A Signature Revision adds cryptographic proof of authenticity and authorship to a revision chain. It references a previous revision and includes a digital signature that can be verified using the associated public key or address. Aqua Protocol v4 supports three signature types: RSA, Ethereum (EIP-191), and DID-based signatures.
+
+## Overview
+
+Signature revisions provide:
+- **Authentication**: Proof that a specific entity created or approved the previous revision
+- **Integrity**: Assurance that the signed revision hasn't been tampered with
+- **Non-repudiation**: The signer cannot deny having signed the revision
+- **Flexibility**: Support for multiple cryptographic signature schemes
+
+## Schema Structure
+
+### Common Fields
+
+| Field | Type | Required | Description |
+|-------|------|----------|-------------|
+| `previous_revision` | string | Yes | Hash reference to the revision being signed |
+| `revision_type` | string | Yes | Always `"signature"` for signature revisions |
+| `nonce` | string | Yes | Random 16-byte hex string for uniqueness |
+| `local_timestamp` | number | Yes | Unix timestamp when the signature was created |
+| `version` | string | Yes | Protocol version: `"https://aqua-protocol.org/docs/v4/schema"` |
+| `method` | string | Yes | Canonicalization method: `"scalar"` (typical) or `"tree"` |
+| `hash_type` | string | Yes | Hash algorithm: `"FIPS_202-SHA3-256"` |
+| `signature` | object | Yes | Signature value object (varies by signature type) |
+
+### Signature Value Object
+
+The `signature` field is an object with different structures depending on the signature type.
+
+## Signature Types
+
+### 1. RSA Signature
+
+Uses RSA public-key cryptography with PKCS#1 v1.5 padding.
+
+#### Structure
+```json
+{
+ "signature_type": "rsa",
+ "signature": "0x...",
+ "public_key": "0x..."
+}
+```
+
+#### Fields
+
+| Field | Type | Description |
+|-------|------|-------------|
+| `signature_type` | string | Must be `"rsa"` |
+| `signature` | string | Hex-encoded RSA signature (256 bytes for RSA-2048, 512 bytes for RSA-4096) |
+| `public_key` | string | Hex-encoded DER-encoded RSA public key (200-600 bytes) |
+
+#### Validation Rules
+- Signature must be 256 bytes (RSA-2048) or 512 bytes (RSA-4096)
+- Public key must be DER-encoded and between 200-600 bytes
+- Both fields must be lowercase hex strings prefixed with `0x`
+
+#### Example
+```json
+{
+ "previous_revision": "0x3f8a7b2c9d1e4f5a6b8c0d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a",
+ "revision_type": "signature",
+ "nonce": "0x9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b",
+ "local_timestamp": 1704067200,
+ "version": "https://aqua-protocol.org/docs/v4/schema",
+ "method": "scalar",
+ "hash_type": "FIPS_202-SHA3-256",
+ "signature": {
+ "signature_type": "rsa",
+ "signature": "0x8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d",
+ "public_key": "0x308201a2300d06092a864886f70d01010105000382018f003082018a0282018100c9c4d8e3f7a1b5c9d0e4f8a2b6c0d4e8f2a6b0c4d8e2f6a0b4c8d2e6f0a4b8c2d6e0f4a8b2c6d0e4f8a2b6c0d4e8f2a6b0c4d8e2f6a0b4c8d2e6f0a4b8c2d6e0f4a8b2c6d0e4f8a2b6c0d4e8f2a6b0c4d8e2f6a0b4c8d2e6f0a4b8c2d6e0f4a8b2c6d0e4f8a2b6c0d4e8f2a6b0c4d8e2f6a0b4c8d2e6f0a4b8c2d6e0f4a8b2c6d0e4f8a2b6c0d4e8f2a6b0c4d8e2f6a0b4c8d2e6f0a4b8c2d6e0f4a8b2c6d0e4f8a2b6c0d4e8f2a6b0c4d8e2f6a0b4c8d2e6f0a4b8c2d6e0f4a8b2c6d0e4f8a2b6c0d4e8f2a6b0c4d8e2f6a0b4c8d2e6f0a4b8c2d6e0f4a8b2c6d0e4f8a2b6c0d4e8f2a6b0c4d8e2f6a0b4c8d2e6f0a4b8c2d6e0f4a8b2c6d0e4f8a2b6c0d4e8f2a6b0c4d8e2f6a0b4c8d2e6f0a4b8c2d6e00203010001"
+ }
+}
+```
+
+---
+
+### 2. Ethereum (EIP-191) Signature
+
+Uses Ethereum's personal sign method (EIP-191) with ECDSA on the secp256k1 curve.
+
+#### Structure
+```json
+{
+ "signature_type": "ethereum:eip-191",
+ "signature": "0x...",
+ "signature_wallet_address": "0x..."
+}
+```
+
+#### Fields
+
+| Field | Type | Description |
+|-------|------|-------------|
+| `signature_type` | string | Must be `"ethereum:eip-191"` |
+| `signature` | string | Hex-encoded ECDSA signature (65 bytes: r=32, s=32, v=1) |
+| `signature_wallet_address` | string | EIP-55 checksummed Ethereum address (20 bytes) |
+
+#### Validation Rules
+- Signature must be exactly 65 bytes
+- Wallet address must be a valid EIP-55 checksummed address
+- Both fields must be hex strings prefixed with `0x`
+- Address checksum must be validated
+
+#### Example
+```json
+{
+ "previous_revision": "0x3f8a7b2c9d1e4f5a6b8c0d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a",
+ "revision_type": "signature",
+ "nonce": "0x1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e",
+ "local_timestamp": 1704070800,
+ "version": "https://aqua-protocol.org/docs/v4/schema",
+ "method": "scalar",
+ "hash_type": "FIPS_202-SHA3-256",
+ "signature": {
+ "signature_type": "ethereum:eip-191",
+ "signature": "0x8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d1c",
+ "signature_wallet_address": "0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb8"
+ }
+}
+```
+
+**Note**: The `signature_wallet_address` must use proper EIP-55 checksumming (mixed case).
+
+---
+
+### 3. DID JWS Signature
+
+Uses Decentralized Identifiers (DIDs) with JSON Web Signatures (JWS).
+
+#### Structure
+```json
+{
+ "signature_type": "did:jws",
+ "jws": "eyJ...",
+ "did": "did:key:..."
+}
+```
+
+#### Fields
+
+| Field | Type | Description |
+|-------|------|-------------|
+| `signature_type` | string | Must be `"did:jws"` |
+| `jws` | string | Compact JWS (JSON Web Signature) |
+| `did` | string | Decentralized Identifier of the signer |
+
+#### Validation Rules
+- JWS must be in compact serialization format (three base64url-encoded parts separated by dots)
+- DID must be a valid DID string (e.g., `did:key:z6Mk...`, `did:web:example.com`)
+- The DID document must be resolvable to verify the signature
+
+#### Example
+```json
+{
+ "previous_revision": "0x3f8a7b2c9d1e4f5a6b8c0d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a",
+ "revision_type": "signature",
+ "nonce": "0x5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a",
+ "local_timestamp": 1704074400,
+ "version": "https://aqua-protocol.org/docs/v4/schema",
+ "method": "scalar",
+ "hash_type": "FIPS_202-SHA3-256",
+ "signature": {
+ "signature_type": "did:jws",
+ "jws": "eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..kKvXJ_qjJRtGQFLpRvQlCdXMFD8sSE4DTlbMmLqg0BJ9FQKLHvX7y_z5Pr8u0xT8D2vCj9qL1KzN4rP2MzKfBQ",
+ "did": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK"
+ }
+}
+```
+
+---
+
+## What Gets Signed
+
+The signature is computed over the **hash of the previous revision**, not the revision itself.
+
+### Signing Process
+
+1. Compute the hash of the `previous_revision`
+2. For Ethereum: Add EIP-191 prefix (`\x19Ethereum Signed Message:\n32`)
+3. Sign the hash using the appropriate method
+4. Create the signature revision with the signature value
+5. Compute the hash of the signature revision
+
+### Example Signing Flow
+
+```
+Object Revision => Compute Hash => Sign Hash => Signature Revision
+ |
+0x3f8a7b2c... (previous_revision in signature)
+```
+
+## Validation Rules
+
+A Signature Revision is valid if:
+
+1. **Structure**: Contains all required fields with correct types
+2. **Revision Type**: The `revision_type` is exactly `"signature"`
+3. **Previous Revision**: References a valid existing revision
+4. **Signature Type**: One of `"rsa"`, `"ethereum:eip-191"`, or `"did:jws"`
+5. **Signature Format**: Matches the requirements for the specific signature type
+6. **No Unknown Fields**: The signature object contains only recognized fields
+7. **Signature Verification**: The signature can be cryptographically verified
+ - For RSA: Verify using the provided public key
+ - For EIP-191: Recover address from signature and compare to `signature_wallet_address`
+ - For DID:JWS: Resolve DID and verify JWS signature
+
+## Multiple Signatures
+
+To add multiple signatures to the same revision:
+
+```
+Object Revision
+ |
+Signature 1 (Alice signs object)
+ |
+Signature 2 (Bob signs Signature 1)
+ |
+Signature 3 (Carol signs Signature 2)
+```
+
+Each signature revision signs the previous revision, creating a chain of signatures.
+
+### Multi-Party Signing
+
+For independent multi-party signing (all signing the same object):
+
+```
+ Object Revision
+ | | |
+Signature A Signature B Signature C
+ | | |
+ Link Revision
+```
+
+Use a Link Revision to combine multiple independent signature branches.
+
+## Common Use Cases
+
+### 1. Document Signing
+Sign file object revisions to prove authorship:
+```
+File Object => Signature (Author) => Witness (Timestamp)
+```
+
+### 2. Approval Workflows
+Multiple parties sign in sequence:
+```
+Document => Sign (Creator) => Sign (Reviewer) => Sign (Approver)
+```
+
+### 3. Notarization
+Professional notary signs an object:
+```
+Object => Signature (Notary's RSA key) => Witness (Blockchain)
+```
+
+### 4. Smart Contract Interaction
+Ethereum wallet signs for on-chain verification:
+```
+Claim => Signature (EIP-191) => Submit to Smart Contract
+```
+
+### 5. Decentralized Identity
+DID-based signatures for verifiable credentials:
+```
+Credential => Signature (Issuer's DID) => Holder stores
+```
+
+## Implementation Notes
+
+### Creating a Signature Revision
+
+1. Identify the revision to sign
+2. Compute its hash (the `previous_revision` value)
+3. Prepare the message to sign (hash, with any required prefixes)
+4. Generate the signature using chosen method
+5. Construct the signature revision object
+6. Validate the signature can be verified
+7. Compute and store the signature revision hash
+
+### Verifying a Signature Revision
+
+#### RSA Verification
+```
+1. Extract public_key from signature object
+2. Extract signature bytes
+3. Reconstruct signed message (hash of previous_revision)
+4. Verify signature using RSA public key
+```
+
+#### EIP-191 Verification
+```
+1. Reconstruct EIP-191 message: "\x19Ethereum Signed Message:\n32" + hash
+2. Recover address from signature
+3. Compare recovered address to signature_wallet_address
+```
+
+#### DID:JWS Verification
+```
+1. Resolve DID to get DID document
+2. Extract verification method (public key)
+3. Verify JWS signature using verification method
+4. Validate JWS payload matches revision data
+```
+
+## Security Considerations
+
+### 1. Key Management
+- RSA: Protect private key files, use strong key sizes (e2048 bits)
+- EIP-191: Secure wallet seed phrases/private keys
+- DID: Maintain DID document security and key rotation policies
+
+### 2. Signature Reuse
+- Each signature should sign a unique revision
+- Nonces prevent replay attacks
+
+### 3. Timestamp Validation
+- Check `local_timestamp` is reasonable (not far future/past)
+- Compare with witness timestamps for consistency
+
+### 4. Address Validation
+- For EIP-191: Always validate EIP-55 checksum
+- Reject non-checksummed addresses
+
+### 5. DID Resolution
+- Ensure DID resolver is trustworthy
+- Cache DID documents appropriately
+- Handle resolution failures gracefully
+
+## Relationship with Other Revisions
+
+- **Object Revisions**: Typically what gets signed first
+- **Witness Revisions**: Often follow signatures to add timestamping
+- **Link Revisions**: Can combine multiple signature branches
+- **Template Revisions**: Can also be signed, though less common
+
+## See Also
+
+- [Object Revision](/schema_reference/object_revision) - What typically gets signed
+- [Witness Revision](/schema_reference/witness_revision) - Add timestamps after signing
+- [Link Revision](/schema_reference/link_revision) - Combine signature branches
+- [EIP-191 Specification](https://eips.ethereum.org/EIPS/eip-191) - Ethereum signing standard
+- [DID Core Specification](https://www.w3.org/TR/did-core/) - Decentralized Identifiers
+- [JWS Specification](https://www.rfc-editor.org/rfc/rfc7515) - JSON Web Signatures
diff --git a/schema_reference/template_revision.mdx b/schema_reference/template_revision.mdx
new file mode 100644
index 00000000..ac1d9c0f
--- /dev/null
+++ b/schema_reference/template_revision.mdx
@@ -0,0 +1,441 @@
+---
+title: "Template Revision"
+description: "Schema specification for Template Revisions in Aqua Protocol v4"
+---
+
+# Template Revision
+
+A Template Revision defines the structure and validation rules for Object Revisions. Templates use JSON Schema to specify what data fields are required, their types, formats, and constraints. Template revisions are standalone (they don't have a `previous_revision` field) and are referenced by object revisions via their hash.
+
+## Overview
+
+Template revisions serve as the "type system" for Aqua Protocol. They:
+- Define schemas using JSON Schema (Draft 2020-12)
+- Are immutable once created (identified by their hash)
+- Can be reused by multiple object revisions
+- Optionally reference code implementations
+- Enable validation and type safety
+
+## Schema Structure
+
+### Fields
+
+| Field | Type | Required | Description |
+|-------|------|----------|-------------|
+| `revision_type` | string | Yes | Always `"template"` for template revisions |
+| `nonce` | string | Yes | Random 16-byte hex string for uniqueness |
+| `local_timestamp` | number | Yes | Unix timestamp when the template was created |
+| `version` | string | Yes | Protocol version: `"https://aqua-protocol.org/docs/v4/schema"` |
+| `method` | string | Yes | Canonicalization method: `"scalar"` or `"tree"` (typically `"scalar"`) |
+| `hash_type` | string | Yes | Hash algorithm: `"FIPS_202-SHA3-256"` |
+| `schema` | object | Yes | JSON Schema (Draft 2020-12) that validates object payloads |
+| `code_revision_ref` | string | No | Optional hash reference to code that implements this template |
+
+### Field Details
+
+#### revision_type
+- **Value**: Always `"template"`
+- **Purpose**: Identifies this as a template revision
+- **Note**: Unlike object revisions, this is a string constant, not a hash reference
+
+#### schema
+- **Format**: Valid JSON Schema (Draft 2020-12 specification)
+- **Purpose**: Defines validation rules for object revision payloads
+- **Required fields in schema**:
+ - `$schema`: Should be `"https://json-schema.org/draft/2020-12/schema"`
+ - `type`: Typically `"object"`
+ - `properties`: Defines the payload structure
+ - `required`: Lists mandatory fields
+ - `additionalProperties`: Usually `false` for strict validation
+
+#### code_revision_ref
+- **Format**: Hex string reference to another revision (optional)
+- **Purpose**: Links to executable code or scripts that work with this template
+- **Use case**: For templates that need associated processing logic
+- **Example**: Reference to smart contract code, validation scripts, or transformation functions
+
+## Examples
+
+### Example 1: File Template
+
+A template for storing file metadata:
+
+```json
+{
+ "revision_type": "template",
+ "nonce": "0x2ba6a8b9b987cf8c3567f72871812ae9",
+ "local_timestamp": 1762266013,
+ "version": "https://aqua-protocol.org/docs/v4/schema",
+ "method": "scalar",
+ "hash_type": "FIPS_202-SHA3-256",
+ "schema": {
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "type": "object",
+ "properties": {
+ "payload_type": {
+ "type": "string",
+ "maxLength": 128
+ },
+ "hash": {
+ "type": "string",
+ "pattern": "^0x[0-9a-f]{64,128}$"
+ },
+ "hash_type": {
+ "description": "Hash function identifier",
+ "anyOf": [
+ {
+ "type": "string",
+ "const": "FIPS_202-SHA3-256"
+ },
+ {
+ "type": "string",
+ "minLength": 1,
+ "maxLength": 128
+ }
+ ]
+ },
+ "descriptor": {
+ "type": "string",
+ "maxLength": 140
+ }
+ },
+ "required": [
+ "payload_type",
+ "hash",
+ "hash_type",
+ "descriptor"
+ ],
+ "additionalProperties": false
+ }
+}
+```
+
+**Hash of this template**: `0x742b74c87ccd7bfc76eaec416027a0bc039b59b9c2d452ea55a5c0e9b0e3f08e`
+
+This hash is what object revisions use in their `revision_type` field to reference this template.
+
+### Example 2: Domain Claim Template
+
+A template for domain ownership claims:
+
+```json
+{
+ "revision_type": "template",
+ "nonce": "0x0da37dc1685f4d78a87c9462b0e87685",
+ "local_timestamp": 1762817552,
+ "version": "https://aqua-protocol.org/docs/v4/schema",
+ "method": "scalar",
+ "hash_type": "FIPS_202-SHA3-256",
+ "schema": {
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "type": "object",
+ "properties": {
+ "domain": {
+ "type": "string",
+ "format": "idn-hostname"
+ },
+ "wallet_address": {
+ "type": "string",
+ "pattern": "^0x[0-9a-fA-F]{40}$"
+ }
+ },
+ "required": [
+ "domain",
+ "wallet_address"
+ ],
+ "additionalProperties": false
+ }
+}
+```
+
+### Example 3: Email Claim Template
+
+A template for email verification claims:
+
+```json
+{
+ "revision_type": "template",
+ "nonce": "0x5c8f9a1b2d3e4f5a6b7c8d9e0f1a2b3c",
+ "local_timestamp": 1762820000,
+ "version": "https://aqua-protocol.org/docs/v4/schema",
+ "method": "scalar",
+ "hash_type": "FIPS_202-SHA3-256",
+ "schema": {
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "type": "object",
+ "properties": {
+ "email": {
+ "type": "string",
+ "format": "email"
+ },
+ "wallet_address": {
+ "type": "string",
+ "pattern": "^0x[0-9a-fA-F]{40}$"
+ },
+ "verified_at": {
+ "type": "integer",
+ "description": "Unix timestamp of verification"
+ }
+ },
+ "required": [
+ "email",
+ "wallet_address"
+ ],
+ "additionalProperties": false
+ }
+}
+```
+
+### Example 4: Template with Code Reference
+
+A template that references associated code:
+
+```json
+{
+ "revision_type": "template",
+ "nonce": "0x7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a",
+ "local_timestamp": 1762825000,
+ "version": "https://aqua-protocol.org/docs/v4/schema",
+ "method": "scalar",
+ "hash_type": "FIPS_202-SHA3-256",
+ "schema": {
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "type": "object",
+ "properties": {
+ "calculation_type": {
+ "type": "string",
+ "enum": ["sum", "average", "weighted"]
+ },
+ "values": {
+ "type": "array",
+ "items": {
+ "type": "number"
+ }
+ }
+ },
+ "required": ["calculation_type", "values"],
+ "additionalProperties": false
+ },
+ "code_revision_ref": "0x3f8a7b2c9d1e4f5a6b8c0d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a"
+}
+```
+
+## Built-in Templates
+
+The Aqua RS SDK provides several built-in templates with pre-computed hashes:
+
+| Template | Purpose | Hash Reference |
+|----------|---------|----------------|
+| File | File metadata storage | `0x742b74c87ccd7bfc76eaec416027a0bc039b59b9c2d452ea55a5c0e9b0e3f08e` |
+| Domain | Domain ownership claims | (computed at runtime) |
+| Email | Email verification | (computed at runtime) |
+| Name | Name claims | (computed at runtime) |
+| Phone | Phone verification | (computed at runtime) |
+| Attestation | General attestations | (computed at runtime) |
+
+These templates are defined in the SDK at `src/schema/templates/` and can be used directly without creating new template revisions.
+
+## JSON Schema Features
+
+Template schemas support all JSON Schema Draft 2020-12 features:
+
+### Type Validation
+```json
+{
+ "type": "string" // or "number", "integer", "boolean", "array", "object", "null"
+}
+```
+
+### Format Validation
+```json
+{
+ "type": "string",
+ "format": "email" // or "date", "date-time", "uri", "hostname", etc.
+}
+```
+
+### Pattern Matching
+```json
+{
+ "type": "string",
+ "pattern": "^0x[0-9a-f]{40}$"
+}
+```
+
+### Length Constraints
+```json
+{
+ "type": "string",
+ "minLength": 1,
+ "maxLength": 100
+}
+```
+
+### Numeric Constraints
+```json
+{
+ "type": "number",
+ "minimum": 0,
+ "maximum": 100,
+ "multipleOf": 0.01
+}
+```
+
+### Array Constraints
+```json
+{
+ "type": "array",
+ "items": { "type": "string" },
+ "minItems": 1,
+ "maxItems": 10,
+ "uniqueItems": true
+}
+```
+
+### Enumerations
+```json
+{
+ "type": "string",
+ "enum": ["option1", "option2", "option3"]
+}
+```
+
+### Conditional Schemas
+```json
+{
+ "anyOf": [
+ { "type": "string", "const": "FIPS_202-SHA3-256" },
+ { "type": "string", "minLength": 1 }
+ ]
+}
+```
+
+## Validation Rules
+
+A Template Revision is valid if:
+
+1. **Structure**: Contains all required fields with correct types
+2. **Revision Type**: The `revision_type` field is exactly `"template"`
+3. **Version**: Matches `"https://aqua-protocol.org/docs/v4/schema"`
+4. **Schema**: Is a valid JSON Schema (Draft 2020-12)
+5. **Schema Root**: The schema should define an object type at the root level
+6. **No Previous Revision**: Templates never have a `previous_revision` field
+7. **Code Reference**: If present, `code_revision_ref` must be a valid hash reference
+8. **Hash Verification**: The computed hash can be verified
+
+## Template Lifecycle
+
+### 1. Creation
+```
+Create JSON Schema Generate Template Revision Compute Hash
+```
+
+### 2. Publication
+```
+Template Hash Used by Object Revisions Enables Validation
+```
+
+### 3. Reuse
+```
+Multiple Objects Reference Same Template Consistent Validation
+```
+
+## Best Practices
+
+### 1. Use Descriptive Property Names
+```json
+{
+ "properties": {
+ "email_address": { "type": "string", "format": "email" },
+ "verified_at_timestamp": { "type": "integer" }
+ }
+}
+```
+
+### 2. Always Set additionalProperties
+```json
+{
+ "additionalProperties": false // Strict validation
+}
+```
+
+### 3. Include Descriptions
+```json
+{
+ "properties": {
+ "status": {
+ "type": "string",
+ "description": "Current verification status: pending, verified, or rejected"
+ }
+ }
+}
+```
+
+### 4. Use Appropriate Constraints
+```json
+{
+ "email": {
+ "type": "string",
+ "format": "email",
+ "maxLength": 254 // RFC 5321 limit
+ }
+}
+```
+
+### 5. Plan for Forward Compatibility
+- Avoid overly restrictive patterns
+- Use `anyOf` for accepting multiple formats
+- Consider optional fields for future extensions
+
+## Relationship with Other Revisions
+
+- **Object Revisions**: Reference templates via their `revision_type` field
+- **Code Revisions**: Can be referenced via `code_revision_ref` (optional)
+- **No Chaining**: Templates don't form chains; they're standalone definitions
+
+## Implementation Notes
+
+### Creating a Template
+
+1. Design your JSON Schema based on your data requirements
+2. Validate the schema itself is valid JSON Schema
+3. Create the template revision structure
+4. Generate a random nonce
+5. Compute the template hash
+6. Store the hash for use in object revisions
+
+### Using a Template
+
+1. Reference the template hash in the object's `revision_type`
+2. Ensure payload conforms to the template schema
+3. Validate payload against schema before creating object revision
+
+### Template Validation
+
+When validating an object against a template:
+
+```
+1. Retrieve template by hash
+2. Extract JSON Schema from template
+3. Validate object payload against schema
+4. Check validation result
+```
+
+## Common Use Cases
+
+### Document Templates
+Define structure for document metadata, file hashes, and descriptors.
+
+### Credential Templates
+Specify required fields for verifiable credentials (email, domain, phone, etc.).
+
+### Data Exchange Templates
+Standardize data formats for interoperability between systems.
+
+### Smart Contract Templates
+Link templates to on-chain contract code for decentralized validation.
+
+## See Also
+
+- [Object Revision](/schema_reference/object_revision) - Use templates to validate objects
+- [JSON Schema Specification](https://json-schema.org/draft/2020-12/json-schema-core.html) - Full JSON Schema documentation
diff --git a/schema_reference/witness_revision.mdx b/schema_reference/witness_revision.mdx
new file mode 100644
index 00000000..b56ce9cb
--- /dev/null
+++ b/schema_reference/witness_revision.mdx
@@ -0,0 +1,417 @@
+---
+title: "Witness Revision"
+description: "Schema specification for Witness Revisions in Aqua Protocol v4"
+---
+
+# Witness Revision
+
+A Witness Revision provides cryptographic proof that a revision existed at a specific point in time. It anchors revision hashes to external systems like blockchains (Ethereum), decentralized networks (Nostr), or Trusted Timestamping Authorities (TSA). This creates an immutable, verifiable timestamp that cannot be backdated.
+
+## Overview
+
+Witness revisions provide:
+- **Timestamping**: Cryptographic proof of when a revision existed
+- **Immutability**: Blockchain or TSA anchoring prevents backdating
+- **Verifiability**: Anyone can verify the witness independently
+- **Batch Efficiency**: Multiple revisions can be witnessed in a single transaction via Merkle trees
+- **Decentralization**: Uses public blockchains or decentralized networks
+
+## Schema Structure
+
+### Common Fields
+
+| Field | Type | Required | Description |
+|-------|------|----------|-------------|
+| `previous_revision` | string | Yes | Hash reference to the revision being witnessed |
+| `revision_type` | string | Yes | Always `"witness"` for witness revisions |
+| `nonce` | string | Yes | Random 16-byte hex string for uniqueness |
+| `local_timestamp` | number | Yes | Unix timestamp when the witness was created locally |
+| `version` | string | Yes | Protocol version: `"https://aqua-protocol.org/docs/v4/schema"` |
+| `method` | string | Yes | Canonicalization method: `"scalar"` (typical) or `"tree"` |
+| `hash_type` | string | Yes | Hash algorithm: `"FIPS_202-SHA3-256"` |
+| `witness` | object | Yes | Witness value object containing proof details |
+
+### Witness Value Object
+
+The `witness` field contains details about the witnessing transaction:
+
+| Field | Type | Required | Description |
+|-------|------|----------|-------------|
+| `merkle_proof` | array | Yes | Array of hex strings forming the Merkle proof path |
+| `sender_account_address` | string | Yes | Address that submitted the witness transaction |
+| `transaction_hash` | string | Yes | Transaction hash on the blockchain or network |
+| `smart_contract_address` | string | Yes | Address of the witness contract (or endpoint URL) |
+| `network` | string | Yes | Network identifier: `"mainnet"`, `"sepolia"`, `"holesky"`, `"tsa"`, or `"nostr"` |
+| `merkle_root` | string | Yes | Root hash of the Merkle tree stored on-chain |
+| `timestamp` | number | Yes | Unix timestamp from the blockchain/network |
+
+## Network Types
+
+### 1. Ethereum Networks
+
+#### Mainnet
+- **Network**: `"mainnet"`
+- **Purpose**: Production witnessing on Ethereum mainnet
+- **Cost**: Higher gas fees
+- **Security**: Maximum security and permanence
+
+#### Sepolia (Testnet)
+- **Network**: `"sepolia"`
+- **Purpose**: Testing and development
+- **Cost**: Free testnet ETH
+- **Security**: Testnet only, subject to resets
+
+#### Holesky (Testnet)
+- **Network**: `"holesky"`
+- **Purpose**: Testing and development
+- **Cost**: Free testnet ETH
+- **Security**: Testnet only, newer Ethereum testnet
+
+### 2. Trusted Timestamping Authority (TSA)
+
+- **Network**: `"tsa"`
+- **Purpose**: RFC 3161 compliant timestamping
+- **Provider**: DigiCert or other TSA services
+- **Verification**: Via TSA public certificates
+
+### 3. Nostr
+
+- **Network**: `"nostr"`
+- **Purpose**: Decentralized social network timestamping
+- **Verification**: Via Nostr relays and events
+- **Cost**: Typically free
+
+## Example
+
+### Ethereum Witness (Sepolia)
+
+```json
+{
+ "previous_revision": "0x3f8a7b2c9d1e4f5a6b8c0d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a",
+ "revision_type": "witness",
+ "nonce": "0x7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f",
+ "local_timestamp": 1704067200,
+ "version": "https://aqua-protocol.org/docs/v4/schema",
+ "method": "scalar",
+ "hash_type": "FIPS_202-SHA3-256",
+ "witness": {
+ "merkle_proof": [
+ "0x1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef",
+ "0xabcdef1234567890abcdef1234567890abcdef1234567890abcdef1234567890",
+ "0x567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef1234"
+ ],
+ "sender_account_address": "0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb8",
+ "transaction_hash": "0x9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08",
+ "smart_contract_address": "0x5FbDB2315678afecb367f032d93F642f64180aa3",
+ "network": "sepolia",
+ "merkle_root": "0xa3bf4f1b2b0b822cd15d6c15b0f00a089f86d081884c7d659a2feaa0c55ad015",
+ "timestamp": 1704067250
+ }
+}
+```
+
+### Single Revision Witness
+
+When witnessing a single revision (no batching), the Merkle proof is empty:
+
+```json
+{
+ "previous_revision": "0x3f8a7b2c9d1e4f5a6b8c0d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a",
+ "revision_type": "witness",
+ "nonce": "0x9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b",
+ "local_timestamp": 1704070800,
+ "version": "https://aqua-protocol.org/docs/v4/schema",
+ "method": "scalar",
+ "hash_type": "FIPS_202-SHA3-256",
+ "witness": {
+ "merkle_proof": [],
+ "sender_account_address": "0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb8",
+ "transaction_hash": "0x8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d",
+ "smart_contract_address": "0x5FbDB2315678afecb367f032d93F642f64180aa3",
+ "network": "mainnet",
+ "merkle_root": "0x3f8a7b2c9d1e4f5a6b8c0d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a",
+ "timestamp": 1704070850
+ }
+}
+```
+
+**Note**: When `merkle_proof` is empty, `merkle_root` equals `previous_revision`.
+
+## Merkle Tree Batching
+
+To reduce costs, multiple revisions can be witnessed in a single transaction using Merkle trees.
+
+### Process
+
+1. **Collect Revisions**: Gather multiple revision hashes to witness
+2. **Build Merkle Tree**: Create a Merkle tree from the revision hashes
+3. **Submit Root**: Submit only the Merkle root to the blockchain
+4. **Generate Proofs**: For each revision, generate its Merkle proof
+5. **Create Witnesses**: Create witness revisions with proofs
+
+### Example: Witnessing 4 Revisions
+
+```
+Revision Hashes:
+- Rev1: 0xaaaa...
+- Rev2: 0xbbbb...
+- Rev3: 0xcccc...
+- Rev4: 0xdddd...
+
+Merkle Tree:
+ Root
+ / \
+ H12 H34
+ / \ / \
+ Rev1 Rev2 Rev3 Rev4
+
+Submit to blockchain: Root hash only
+
+Witness for Rev1:
+ merkle_proof: [H12's sibling (Rev2), H12's parent's sibling (H34)]
+ merkle_root: Root
+```
+
+### Proof Verification
+
+To verify a revision was witnessed:
+
+1. Start with revision hash
+2. Apply Merkle proof hashes (sibling hashes)
+3. Compute up the tree to get root
+4. Verify computed root matches `merkle_root`
+5. Verify `merkle_root` is on blockchain at `transaction_hash`
+
+## Validation Rules
+
+A Witness Revision is valid if:
+
+1. **Structure**: Contains all required fields with correct types
+2. **Revision Type**: The `revision_type` is exactly `"witness"`
+3. **Previous Revision**: References a valid existing revision
+4. **Network**: One of the supported network values
+5. **Timestamp Consistency**:
+ - `witness.timestamp` should be close to `local_timestamp`
+ - Both should be reasonable (not far in future)
+6. **Merkle Proof**: If present, must be valid array of hex strings
+7. **Transaction Verification**: The `transaction_hash` exists on the specified `network`
+8. **Merkle Root Verification**: If batched, Merkle proof must lead to merkle_root
+9. **On-Chain Verification**: The `merkle_root` is stored at the `smart_contract_address` in the transaction
+10. **Address Format**: All addresses must be valid hex strings
+
+## Witness Smart Contract
+
+### Ethereum Contract Interface
+
+The witness contract typically has a method like:
+
+```solidity
+function witness(bytes32 merkleRoot) public returns (bool)
+```
+
+### Verification Process
+
+1. Query blockchain for transaction at `transaction_hash`
+2. Verify transaction called the `smart_contract_address`
+3. Extract the witnessed value (merkle_root) from transaction data
+4. Verify it matches the `merkle_root` in the witness revision
+5. Check transaction timestamp matches `timestamp` field
+
+## Common Use Cases
+
+### 1. Document Notarization
+
+```
+Document Object → Signature → Witness (Ethereum)
+```
+
+Proves the document existed and was signed at a specific time.
+
+### 2. Batch Processing
+
+```
+100 Documents → Compute Hashes → Build Merkle Tree → Single Witness Transaction
+```
+
+Economical witnessing of many documents at once.
+
+### 3. Legal Evidence
+
+```
+Evidence Object → Signature (Parties) → Witness (Mainnet)
+```
+
+Creates tamper-proof timestamp for legal proceedings.
+
+### 4. Supply Chain
+
+```
+Shipment Event → Witness (Every checkpoint) → Audit Trail
+```
+
+Immutable record of supply chain events.
+
+### 5. Credential Issuance
+
+```
+VC Issuance → Signature (Issuer) → Witness (Public verification)
+```
+
+Publicly verifiable credential issuance timestamps.
+
+## Timestamp Interpretation
+
+### local_timestamp
+- Created by client when preparing witness revision
+- Not trusted (can be manipulated)
+- Used for user display and rough ordering
+
+### witness.timestamp
+- Provided by blockchain/TSA
+- Trusted (immutable on-chain)
+- Authoritative time proof
+- Should be used for verification and legal purposes
+
+**Best Practice**: Always use `witness.timestamp` for critical timestamp verification.
+
+## Cost Considerations
+
+### Ethereum
+
+| Network | Cost | When to Use |
+|---------|------|-------------|
+| Mainnet | ~$5-50 per transaction | Production, legal, high-value |
+| Sepolia | Free (testnet) | Development, testing |
+| Holesky | Free (testnet) | Development, testing |
+
+**Gas Optimization**: Batch multiple witnesses into one transaction using Merkle trees.
+
+### TSA
+- Typically $0.10-1.00 per timestamp
+- Good for compliance requirements
+- RFC 3161 standard
+
+### Nostr
+- Free (decentralized network)
+- Lower trust than blockchain
+- Good for social proof
+
+## Implementation Notes
+
+### Creating a Witness Revision
+
+1. Identify the revision(s) to witness
+2. Choose network (mainnet, sepolia, etc.)
+3. If batching, build Merkle tree
+4. Submit transaction to blockchain
+5. Wait for transaction confirmation
+6. Extract transaction details
+7. Generate Merkle proofs (if batched)
+8. Create witness revision(s)
+
+### Verifying a Witness Revision
+
+#### Single Revision (No Batching)
+```
+1. Verify merkle_proof is empty
+2. Verify merkle_root equals previous_revision
+3. Query blockchain for transaction_hash
+4. Verify transaction exists and is confirmed
+5. Extract witnessed value from transaction
+6. Verify it matches merkle_root
+7. Check transaction timestamp
+```
+
+#### Batched Revision
+```
+1. Verify merkle_proof is non-empty
+2. Compute Merkle root using proof and previous_revision
+3. Verify computed root matches merkle_root
+4. Query blockchain for transaction_hash
+5. Verify merkle_root is stored on-chain
+6. Validate transaction timestamp
+```
+
+### Error Handling
+
+Common issues and solutions:
+
+| Issue | Solution |
+|-------|----------|
+| Transaction not found | Wait longer (may not be confirmed yet) |
+| Wrong network | Check transaction on correct network |
+| Merkle proof invalid | Regenerate proof from original tree |
+| Timestamp mismatch | Check blockchain time vs local time |
+| Gas estimation failed | Check wallet balance and gas price |
+
+## Security Considerations
+
+### 1. Network Selection
+- Use mainnet for production/legal purposes
+- Use testnets only for development
+- Consider compliance requirements
+
+### 2. Confirmation Depth
+- Wait for sufficient confirmations (6+ for mainnet)
+- More confirmations = higher security
+- Balance security vs speed requirements
+
+### 3. Merkle Proof Storage
+- Store proofs securely
+- Without proof, batched witness can't be verified
+- Consider proof backup strategies
+
+### 4. Timestamp Trust
+- Trust blockchain timestamp over local_timestamp
+- Account for block time variability
+- Consider block reorganizations
+
+### 5. Cost Management
+- Batch witnesses to reduce costs
+- Monitor gas prices
+- Use appropriate network for use case
+
+## Advanced Topics
+
+### Multi-Network Witnessing
+
+Witness the same revision on multiple networks for redundancy:
+
+```
+Object → Signature → Witness (Ethereum) → Witness (Nostr) → Witness (TSA)
+```
+
+Each witness provides independent proof.
+
+### Periodic Re-Witnessing
+
+For long-term preservation, periodically re-witness important revisions:
+
+```
+2024: Object → Witness (Mainnet)
+2025: Link to Object → Witness (Mainnet)
+2026: Link to 2025 → Witness (Mainnet)
+```
+
+### Cross-Chain Verification
+
+Witness on multiple blockchains for increased trust:
+
+```
+Object → Witness (Ethereum Mainnet) → Witness (Polygon) → Witness (Arbitrum)
+```
+
+## Relationship with Other Revisions
+
+- **Object Revisions**: Primary target for witnessing
+- **Signature Revisions**: Often witnessed after signing
+- **Link Revisions**: Can be witnessed to prove connection timestamp
+- **Template Revisions**: Rarely witnessed (they're standalone)
+
+## See Also
+
+- [Object Revision](/schema_reference/object_revision) - What typically gets witnessed
+- [Signature Revision](/schema_reference/signing_revision) - Often combined with witnessing
+- [RFC 3161 - Timestamping](https://www.rfc-editor.org/rfc/rfc3161) - TSA standard
+- [Ethereum Smart Contracts](https://ethereum.org/en/developers/docs/smart-contracts/) - On-chain witnessing
+- [Merkle Trees](https://en.wikipedia.org/wiki/Merkle_tree) - Batch witnessing structure
diff --git a/sidebars.ts b/sidebars.ts
deleted file mode 100644
index 28971397..00000000
--- a/sidebars.ts
+++ /dev/null
@@ -1,33 +0,0 @@
-import type {SidebarsConfig} from '@docusaurus/plugin-content-docs';
-
-// This runs in Node.js - Don't use client-side code here (browser APIs, JSX...)
-
-/**
- * Creating a sidebar enables you to:
- - create an ordered group of docs
- - render a sidebar for each doc of that group
- - provide next/previous navigation
-
- The sidebars can be generated from the filesystem, or explicitly defined here.
-
- Create as many sidebars as you want.
- */
-const sidebars: SidebarsConfig = {
- // By default, Docusaurus generates a sidebar from the docs folder structure
- tutorialSidebar: [{type: 'autogenerated', dirName: '.'}],
-
- // But you can create a sidebar manually
- /*
- tutorialSidebar: [
- 'intro',
- 'hello',
- {
- type: 'category',
- label: 'Tutorial',
- items: ['tutorial-basics/create-a-document'],
- },
- ],
- */
-};
-
-export default sidebars;
diff --git a/snippets/snippet-intro.mdx b/snippets/snippet-intro.mdx
new file mode 100644
index 00000000..e20fbb6f
--- /dev/null
+++ b/snippets/snippet-intro.mdx
@@ -0,0 +1,4 @@
+One of the core principles of software development is DRY (Don't Repeat
+Yourself). This is a principle that applies to documentation as
+well. If you find yourself repeating the same content in multiple places, you
+should consider creating a custom snippet to keep your content in sync.
diff --git a/src/components/HomepageFeatures/index.tsx b/src/components/HomepageFeatures/index.tsx
deleted file mode 100644
index 366877b1..00000000
--- a/src/components/HomepageFeatures/index.tsx
+++ /dev/null
@@ -1,81 +0,0 @@
-import clsx from 'clsx';
-import Heading from '@theme/Heading';
-import styles from './styles.module.css';
-import { ReactNode } from 'react';
-import { FaAppStoreIos, FaGithub } from 'react-icons/fa';
-import { FaX, FaXTwitter } from 'react-icons/fa6';
-
-type FeatureItem = {
- title: string;
- icon: ReactNode;
- description: JSX.Element;
- link: string;
- linkLabel: string;
-};
-
-const FeatureList: FeatureItem[] = [
- {
- title: 'Aquafier Demo',
- icon: <FaAppStoreIos size={'40px'} />,
- description: (
- <>
- Aquafier is a reference implementation of AQUA Protocol. Upload, verify and notarize any file.
- </>
- ),
- link: "https://aquafier.inblock.io/",
- linkLabel: "Try Aquafier now",
- },
- {
- title: 'Contributions welcome!',
- icon: <FaGithub size={'40px'} />,
- description: (
- <>
- We welcome feedback, bug reports, ideas, or contributions code and documentation alike.
- </>
- ),
- link: "https://github.com/inblockio",
- linkLabel: "Our Github",
- },
- {
- title: 'Follow us on X',
- icon: <FaXTwitter size={'40px'} />,
- description: (
- <>
- For announcements and updates about our progress on the AQUA Protocol
- </>
- ),
- link: "https://twitter.com/inblockio",
- linkLabel: "Follow Us",
- },
-];
-
-function Feature({ title, icon, description, link, linkLabel }: FeatureItem) {
- return (
- <div className={clsx('col col--4')}>
- <div className="text--center">
- {icon}
- </div>
- <div className="text--center padding-horiz--md">
- <Heading as="h3">{title}</Heading>
- <p>{description}</p>
- </div>
- <div className={clsx("text--center padding-horiz--md", styles.action_link)}>
- <a href={link}>{linkLabel}</a>
- </div>
- </div>
- );
-}
-
-export default function HomepageFeatures(): JSX.Element {
- return (
- <section className={styles.features}>
- <div className="container">
- <div className="row">
- {FeatureList.map((props, idx) => (
- <Feature key={idx} {...props} />
- ))}
- </div>
- </div>
- </section>
- );
-}
diff --git a/src/components/HomepageFeatures/styles.module.css b/src/components/HomepageFeatures/styles.module.css
deleted file mode 100644
index 76591c09..00000000
--- a/src/components/HomepageFeatures/styles.module.css
+++ /dev/null
@@ -1,22 +0,0 @@
-.features {
- display: flex;
- align-items: center;
- padding: 4rem 0;
- width: 100%;
-}
-
-.featureSvg {
- height: 200px;
- width: 200px;
-}
-
-
-.action_link a{
- color: #72a1e5;
- text-decoration: none;
- background-color: transparent;
-}
-
-.action_link a:hover{
- color: #3176d9;
-}
\ No newline at end of file
diff --git a/src/css/custom.css b/src/css/custom.css
deleted file mode 100644
index a1aee073..00000000
--- a/src/css/custom.css
+++ /dev/null
@@ -1,56 +0,0 @@
-/**
- * Any CSS included here will be global. The classic template
- * bundles Infima by default. Infima is a CSS framework designed to
- * work well for content-centric websites.
- */
-
-/* You can override the default Infima variables here. */
-/* :root {
- --ifm-color-primary: #2e8555;
- --ifm-color-primary-dark: #29784c;
- --ifm-color-primary-darker: #277148;
- --ifm-color-primary-darkest: #205d3b;
- --ifm-color-primary-light: #33925d;
- --ifm-color-primary-lighter: #359962;
- --ifm-color-primary-lightest: #3cad6e;
- --ifm-code-font-size: 95%;
- --docusaurus-highlighted-code-line-bg: rgba(0, 0, 0, 0.1);
-} */
-
-/* For readability concerns, you should choose a lighter palette in dark mode. */
-/* [data-theme='dark'] {
- --ifm-color-primary: #25c2a0;
- --ifm-color-primary-dark: #21af90;
- --ifm-color-primary-darker: #1fa588;
- --ifm-color-primary-darkest: #1a8870;
- --ifm-color-primary-light: #29d5b0;
- --ifm-color-primary-lighter: #32d8b4;
- --ifm-color-primary-lightest: #4fddbf;
- --docusaurus-highlighted-code-line-bg: rgba(0, 0, 0, 0.3);
-} */
-
-
-:root {
- --ifm-color-primary: #1600bd;
- --ifm-color-primary-dark: #1400aa;
- --ifm-color-primary-darker: #1300a1;
- --ifm-color-primary-darkest: #0f0084;
- --ifm-color-primary-light: #1800d0;
- --ifm-color-primary-lighter: #1900d9;
- --ifm-color-primary-lightest: #1d00f6;
-
- --ifm-code-font-size: 95%;
- --docusaurus-highlighted-code-line-bg: rgba(0, 0, 0, 0.1);
-}
-
-
-[data-theme='dark'] {
- --ifm-color-primary: #86b4fe;
- --ifm-color-primary-dark: #609cfe;
- --ifm-color-primary-darker: #4c90fe;
- --ifm-color-primary-darkest: #136cfd;
- --ifm-color-primary-light: #acccfe;
- --ifm-color-primary-lighter: #c0d8fe;
- --ifm-color-primary-lightest: #f9fcff;
- --ifm-background-color: #00010a;
-}
diff --git a/src/pages/community.tsx b/src/pages/community.tsx
deleted file mode 100644
index 33c733f3..00000000
--- a/src/pages/community.tsx
+++ /dev/null
@@ -1,98 +0,0 @@
-import clsx from 'clsx';
-import useDocusaurusContext from '@docusaurus/useDocusaurusContext';
-import Layout from '@theme/Layout';
-
-import styles from './index.module.css';
-import communityStyles from './coummunity.module.css';
-import { ReactNode } from 'react';
-import { MdEmail, MdMerge } from 'react-icons/md';
-import { BsGithub, BsStackOverflow, BsTwitterX } from 'react-icons/bs';
-import { BiMessage } from 'react-icons/bi';
-
-const ListItem = ({ icon, title, link, description }: { icon: ReactNode, title: string, link: string, description: string }) => {
-
- return (
- <a href={link}>
- <div className={communityStyles.gridItem}>
- <div className='icon'>
- {icon}
- </div>
- <h3 className='title'>{title}</h3>
- <p className={clsx(communityStyles.threeLines, 'description')}>
- {description}
- </p>
- </div>
- </a>
- )
-}
-
-export default function Community() {
- const { siteConfig } = useDocusaurusContext();
- return (
- <Layout
- title={`${siteConfig.title}`}
- description="A peer to peer trust protocol to govern data.">
- <div className={clsx(styles.quote)}>
- <h1>Join the AQUA Protocol community</h1>
- </div>
- <div className={clsx(styles.quote_2)}>
- <p>
- AQUA Protocol is an open source project that anyone in the community can use, improve, and enjoy. We'd love you to join us! Here's a few ways to find out what's happening and get involved.
- </p>
- </div>
- <div className={communityStyles.container}>
- {/* <div className={clsx(communityStyles.column, communityStyles.learnConnect)}>
- <h2 className={communityStyles.title}>Learn and Connect</h2>
- <p className={communityStyles.twoLines}>
- Using or want to use AQUA Protocol? Find out more here:
- </p>
-
- <div className={communityStyles.grid}>
- <ListItem
- icon={<MdEmail size={"40px"} />}
- title={'Mailing List'}
- link={'info@inblock.io'}
- description={'Discussion and help from your fellow users'}
- />
- <ListItem
- icon={<BsTwitterX size={"40px"} />}
- title={'Twitter'}
- link={'https://twitter.com/inblockio'}
- description={'Follow inblock.io on Twitter for latest news!'}
- />
- <ListItem
- icon={<BiMessage size={"40px"} />}
- title={'Matrix'}
- link={'https://matrix.to/#/#aqua-community:matrix.jembawan.com'}
- description={'Chat with other project developers on Matrix'}
- />
- </div>
- </div> */}
- <div className={clsx(communityStyles.column, communityStyles.developContribute)}>
- <h2 className={communityStyles.title}>Develop and Contribute</h2>
- <p className={communityStyles.twoLines}>If you want to get more involved by contributing to AQUA Protocol, join us here:</p>
- <div className={communityStyles.grid}>
- <ListItem
- icon={<BsGithub size={"40px"} />}
- title={'Github'}
- link={'https://github.com/inblockio'}
- description={'AQUA development takes place here!'}
- />
- {/* <ListItem
- icon={<BsStackOverflow size={"40px"} />}
- title={'Stack Overflow'}
- link={'https://stackoverflow.com/questions/tagged/aqua'}
- description={'Questions and curated answers by developers working with AQUA'}
- />
- <ListItem
- icon={<MdMerge size={"40px"} />}
- title={'Contribution Guidelines'}
- link={'/docs/v2/contribution-guidelines'}
- description={'You can find out how to contribute here '}
- /> */}
- </div>
- </div>
- </div>
- </Layout>
- );
-}
diff --git a/src/pages/coummunity.module.css b/src/pages/coummunity.module.css
deleted file mode 100644
index 8e5bfd5f..00000000
--- a/src/pages/coummunity.module.css
+++ /dev/null
@@ -1,68 +0,0 @@
-.container {
- /* max-width: 1400px; */
- margin: auto;
- display: flex;
- flex-direction: column;
- gap: 2rem;
- padding: 1rem;
-}
-
-.column {
- flex: 1;
- padding: 40px 0;
-}
-
-.title {
- font-size: 1.5rem;
- font-weight: bold;
- margin-bottom: 1rem;
-}
-
-.grid {
- display: grid;
- grid-template-columns: repeat(auto-fit, minmax(250px, 1fr));
- gap: 20px;
- margin-top: 20px;
-}
-
-.twoLines {
- height: calc(1.3rem * 2.5);
-}
-
-
-.threeLines {
- height: calc(1.3rem * 3);
- font-size: 14px;
-}
-
-.gridItem {
- padding: 10px;
- display: flex;
- flex-direction: column;
- justify-content: center;
- align-items: center;
- text-align: center;
- row-gap: 10px;
- border: 1px solid rgba(90, 90, 90, 0.589);
- border-radius: 10px;
-}
-
-.gridItem .icon {
- display: flex;
- justify-content: center;
-}
-
-.gridItem .title,
-.gridItem .description {
- text-align: center;
-}
-
-.link:hover {
- text-decoration: underline;
-}
-
-@media (min-width: 768px) {
- .container {
- flex-direction: row;
- }
-}
\ No newline at end of file
diff --git a/src/pages/index.module.css b/src/pages/index.module.css
deleted file mode 100644
index 385c0b57..00000000
--- a/src/pages/index.module.css
+++ /dev/null
@@ -1,129 +0,0 @@
-/**
- * CSS files with the .module.css suffix will be treated as CSS modules
- * and scoped locally.
- */
-
-.heroBanner {
- padding: 20rem 0;
- text-align: center;
- position: relative;
- overflow: hidden;
- background: url("/static/featured-background.png"), linear-gradient(#30638e, #30638e);
- background-size: cover;
- background-position: center;
- color: white !important;
-}
-
-@media screen and (max-width: 996px) {
- .heroBanner {
- padding: 2rem;
- }
-}
-
-.buttons {
- display: flex;
- align-items: center;
- justify-content: center;
- gap: 20px;
- flex-wrap: wrap;
-}
-
-
-.btn {
- display: inline-block;
- font-size: 1.25rem;
- padding: 0.75rem 1.5rem;
- border-radius: 0.5rem;
- font-weight: 500;
- text-decoration: none;
- display: flex;
- align-items: center;
- gap: 0.5rem;
-}
-
-.btn_lg {
- padding: .5rem 1rem;
- font-size: 1.25rem;
- line-height: 1.5;
- border-radius: 50px;
- text-decoration: none !important;
-}
-
-.btn_lg span {
- margin-right: 10px;
-}
-
-.btn_light {
- color: #222 !important;
- background: #d3f3ee linear-gradient(180deg, #daf5f1, #D3F3EE)repeat-x;
- border-color: #d3f3ee;
- box-shadow: inset 0 1px rgba(255, 255, 255, .15), 0 1px 1px rgba(0, 0, 0, .075);
-}
-
-.btn_light:hover {
- background: #005c5c !important;
- color: #ffffff !important;
-}
-
-.btn_dark {
- color: #fff !important;
- background: #403f4c linear-gradient(180deg, #5d5c67, #403F4C)repeat-x;
- border-color: #403f4c;
- box-shadow: inset 0 1px rgba(255, 255, 255, .15), 0 1px 1px rgba(0, 0, 0, .075);
-}
-
-.btn_dark:hover {
- background: #444444 !important;
-}
-
-.quote {
- padding: 80px 20px;
- /* margin: 20px auto; */
- text-align: center;
- color: #ffffff;
- background-color: #305f88;
- /* border-radius: 8px; */
-
- background: linear-gradient(180deg, #5d5c67, #305f88);
- box-shadow: 0 4px 8px rgba(0, 0, 0, 0.2);
- position: relative;
-
-}
-
-.quote p {
- margin: auto;
- font-size: 1.25rem;
- line-height: 1.5;
- font-weight: 400;
- color: #ffffff;
- max-width: 1000px;
- text-align: center;
-}
-
-.quote::after{
- content: "";
- --size: 40px;
- width: var(--size);
- height: var(--size);
- background: #305f88;
- position: absolute;
- bottom: -20px;
- left: 50%;
- transform: translateX(-50%) rotate(135deg);
-}
-
-.quote_2 {
- background-color: #d3f3ee;
- color: #222;
- padding: 80px 20px;
-
-}
-
-.quote_2 p {
- margin: auto;
- font-size: 1.25rem;
- line-height: 1.5;
- font-weight: 400;
- max-width: 800px;
- text-align: center;
-}
\ No newline at end of file
diff --git a/src/pages/index.tsx b/src/pages/index.tsx
deleted file mode 100644
index f96f7db1..00000000
--- a/src/pages/index.tsx
+++ /dev/null
@@ -1,67 +0,0 @@
-import clsx from 'clsx';
-import Link from '@docusaurus/Link';
-import useDocusaurusContext from '@docusaurus/useDocusaurusContext';
-import Layout from '@theme/Layout';
-import HomepageFeatures from '@site/src/components/HomepageFeatures';
-import Heading from '@theme/Heading';
-
-import styles from './index.module.css';
-import { FaArrowAltCircleRight, FaGithub } from 'react-icons/fa';
-import { CgCommunity } from 'react-icons/cg';
-
-export function HomepageHeader() {
- const { siteConfig } = useDocusaurusContext();
- return (
- <header className={clsx('hero hero--primary', styles.heroBanner)}>
- <div className="container">
- <Heading as="h1" className="hero__title">
- Welcome to the AQUA Protocol!
- </Heading>
- <p className="hero__subtitle">
- Account & Verify data in seconds using Aqua Protocol.
- An open, private and decentralised solution for data accountability and governance!
- </p>
- <div className={styles.buttons}>
- <a className={clsx(styles.btn, styles.btn_lg, styles.btn_light)} href="/docs/v3/intro">
- <span>Documentation</span>
- <FaArrowAltCircleRight />
- </a>
- {/* <a className={clsx(styles.btn, styles.btn_lg, styles.btn_light)} href="/community">
- <span>Community</span>
- <CgCommunity />
- </a> */}
- <a className={clsx(styles.btn, styles.btn_lg, styles.btn_dark)} href="https://github.com/inblockio">
- <span>Source Code</span>
- <FaGithub />
- </a>
- </div>
- </div>
- </header >
- );
-}
-
-export default function Home() {
- const { siteConfig } = useDocusaurusContext();
- return (
- <Layout
- title={`${siteConfig.title}`}
- description="A private peer to peer trust protocol for data governance.">
- <HomepageHeader />
- <div className={clsx(styles.quote)}>
- <p>
- The AQUA Protocol is a privacy preserving, open-source protocol for data verification which is built with modern cryptographic standards. The AQUA Protocol is not and does not require a blockchain!
- </p>
- </div>
- <div className={clsx(styles.quote_2)}>
- <p>
- AQUA Protocol is made possible by crypto,
- <br />
- as in <i>cryptography</i>!
- </p>
- </div>
- <main>
- <HomepageFeatures />
- </main>
- </Layout>
- );
-}
diff --git a/static/.nojekyll b/static/.nojekyll
deleted file mode 100644
index e69de29b..00000000
diff --git a/static/docs_pics/Cheque_Filled_Example.png b/static/docs_pics/Cheque_Filled_Example.png
deleted file mode 100644
index f6d35029..00000000
Binary files a/static/docs_pics/Cheque_Filled_Example.png and /dev/null differ
diff --git a/static/docs_pics/Escrow_Gateway_Aqua.png b/static/docs_pics/Escrow_Gateway_Aqua.png
deleted file mode 100644
index 9f520432..00000000
Binary files a/static/docs_pics/Escrow_Gateway_Aqua.png and /dev/null differ
diff --git a/static/docs_pics/Escrow_Gateway_Aqua.png:Zone.Identifier b/static/docs_pics/Escrow_Gateway_Aqua.png:Zone.Identifier
deleted file mode 100644
index 8001b8b2..00000000
--- a/static/docs_pics/Escrow_Gateway_Aqua.png:Zone.Identifier
+++ /dev/null
@@ -1,3 +0,0 @@
-[ZoneTransfer]
-ZoneId=3
-HostUrl=https://app.diagrams.net/
diff --git a/static/docs_pics/Flow_Cheque.jpg b/static/docs_pics/Flow_Cheque.jpg
deleted file mode 100644
index 8ff3a4e9..00000000
Binary files a/static/docs_pics/Flow_Cheque.jpg and /dev/null differ
diff --git a/static/docs_pics/Flow_Cheque.png b/static/docs_pics/Flow_Cheque.png
deleted file mode 100644
index 8ff3a4e9..00000000
Binary files a/static/docs_pics/Flow_Cheque.png and /dev/null differ
diff --git a/static/favicon.ico b/static/favicon.ico
deleted file mode 100644
index 487fce48..00000000
Binary files a/static/favicon.ico and /dev/null differ
diff --git a/static/favicons/android-144x144.png b/static/favicons/android-144x144.png
deleted file mode 100644
index 57ee3d35..00000000
Binary files a/static/favicons/android-144x144.png and /dev/null differ
diff --git a/static/favicons/android-36x36.png b/static/favicons/android-36x36.png
deleted file mode 100644
index 20a4fb8b..00000000
Binary files a/static/favicons/android-36x36.png and /dev/null differ
diff --git a/static/favicons/android-48x48.png b/static/favicons/android-48x48.png
deleted file mode 100644
index dc662be5..00000000
Binary files a/static/favicons/android-48x48.png and /dev/null differ
diff --git a/static/favicons/android-72x72.png b/static/favicons/android-72x72.png
deleted file mode 100644
index ca8a8828..00000000
Binary files a/static/favicons/android-72x72.png and /dev/null differ
diff --git a/static/favicons/android-96x96.png b/static/favicons/android-96x96.png
deleted file mode 100644
index 4d4105b7..00000000
Binary files a/static/favicons/android-96x96.png and /dev/null differ
diff --git a/static/favicons/apple-touch-icon-180x180.png b/static/favicons/apple-touch-icon-180x180.png
deleted file mode 100644
index ab2c4bde..00000000
Binary files a/static/favicons/apple-touch-icon-180x180.png and /dev/null differ
diff --git a/static/favicons/favicon-16x16.png b/static/favicons/favicon-16x16.png
deleted file mode 100644
index 7288cf2b..00000000
Binary files a/static/favicons/favicon-16x16.png and /dev/null differ
diff --git a/static/favicons/favicon-32x32.png b/static/favicons/favicon-32x32.png
deleted file mode 100644
index 487fce48..00000000
Binary files a/static/favicons/favicon-32x32.png and /dev/null differ
diff --git a/static/featured-background.png b/static/featured-background.png
deleted file mode 100644
index a6bb9d4f..00000000
Binary files a/static/featured-background.png and /dev/null differ
diff --git a/static/img/aqua_chrome_plugin.png b/static/img/aqua_chrome_plugin.png
deleted file mode 100644
index 7a1e83a9..00000000
Binary files a/static/img/aqua_chrome_plugin.png and /dev/null differ
diff --git a/static/img/docusaurus.png b/static/img/docusaurus.png
deleted file mode 100644
index f458149e..00000000
Binary files a/static/img/docusaurus.png and /dev/null differ
diff --git a/static/img/favicon.ico b/static/img/favicon.ico
deleted file mode 100644
index 487fce48..00000000
Binary files a/static/img/favicon.ico and /dev/null differ
diff --git a/static/img/favicon_old.ico b/static/img/favicon_old.ico
deleted file mode 100644
index c01d54bc..00000000
Binary files a/static/img/favicon_old.ico and /dev/null differ
diff --git a/static/img/logo.svg b/static/img/logo.svg
deleted file mode 100644
index 9db6d0d0..00000000
--- a/static/img/logo.svg
+++ /dev/null
@@ -1 +0,0 @@
-<svg width="200" height="200" viewBox="0 0 200 200" xmlns="http://www.w3.org/2000/svg"><g fill="none" fill-rule="evenodd"><path fill="#FFF" d="M99 52h84v34H99z"/><path d="M23 163c-7.398 0-13.843-4.027-17.303-10A19.886 19.886 0 0 0 3 163c0 11.046 8.954 20 20 20h20v-20H23z" fill="#3ECC5F"/><path d="M112.98 57.376L183 53V43c0-11.046-8.954-20-20-20H73l-2.5-4.33c-1.112-1.925-3.889-1.925-5 0L63 23l-2.5-4.33c-1.111-1.925-3.889-1.925-5 0L53 23l-2.5-4.33c-1.111-1.925-3.889-1.925-5 0L43 23c-.022 0-.042.003-.065.003l-4.142-4.141c-1.57-1.571-4.252-.853-4.828 1.294l-1.369 5.104-5.192-1.392c-2.148-.575-4.111 1.389-3.535 3.536l1.39 5.193-5.102 1.367c-2.148.576-2.867 3.259-1.296 4.83l4.142 4.142c0 .021-.003.042-.003.064l-4.33 2.5c-1.925 1.111-1.925 3.889 0 5L23 53l-4.33 2.5c-1.925 1.111-1.925 3.889 0 5L23 63l-4.33 2.5c-1.925 1.111-1.925 3.889 0 5L23 73l-4.33 2.5c-1.925 1.111-1.925 3.889 0 5L23 83l-4.33 2.5c-1.925 1.111-1.925 3.889 0 5L23 93l-4.33 2.5c-1.925 1.111-1.925 3.889 0 5L23 103l-4.33 2.5c-1.925 1.111-1.925 3.889 0 5L23 113l-4.33 2.5c-1.925 1.111-1.925 3.889 0 5L23 123l-4.33 2.5c-1.925 1.111-1.925 3.889 0 5L23 133l-4.33 2.5c-1.925 1.111-1.925 3.889 0 5L23 143l-4.33 2.5c-1.925 1.111-1.925 3.889 0 5L23 153l-4.33 2.5c-1.925 1.111-1.925 3.889 0 5L23 163c0 11.046 8.954 20 20 20h120c11.046 0 20-8.954 20-20V83l-70.02-4.376A10.645 10.645 0 0 1 103 68c0-5.621 4.37-10.273 9.98-10.624" fill="#3ECC5F"/><path fill="#3ECC5F" d="M143 183h30v-40h-30z"/><path d="M193 158c-.219 0-.428.037-.639.064-.038-.15-.074-.301-.116-.451A5 5 0 0 0 190.32 148a4.96 4.96 0 0 0-3.016 1.036 26.531 26.531 0 0 0-.335-.336 4.955 4.955 0 0 0 1.011-2.987 5 5 0 0 0-9.599-1.959c-.148-.042-.297-.077-.445-.115.027-.211.064-.42.064-.639a5 5 0 0 0-5-5 5 5 0 0 0-5 5c0 .219.037.428.064.639-.148.038-.297.073-.445.115a4.998 4.998 0 0 0-9.599 1.959c0 1.125.384 2.151 1.011 2.987-3.717 3.632-6.031 8.693-6.031 14.3 0 11.046 8.954 20 20 20 9.339 0 17.16-6.41 19.361-15.064.211.027.42.064.639.064a5 5 0 0 0 5-5 5 5 0 0 0-5-5" fill="#44D860"/><path fill="#3ECC5F" d="M153 123h30v-20h-30z"/><path d="M193 115.5a2.5 2.5 0 1 0 0-5c-.109 0-.214.019-.319.032-.02-.075-.037-.15-.058-.225a2.501 2.501 0 0 0-.963-4.807c-.569 0-1.088.197-1.508.518a6.653 6.653 0 0 0-.168-.168c.314-.417.506-.931.506-1.494a2.5 2.5 0 0 0-4.8-.979A9.987 9.987 0 0 0 183 103c-5.522 0-10 4.478-10 10s4.478 10 10 10c.934 0 1.833-.138 2.69-.377a2.5 2.5 0 0 0 4.8-.979c0-.563-.192-1.077-.506-1.494.057-.055.113-.111.168-.168.42.321.939.518 1.508.518a2.5 2.5 0 0 0 .963-4.807c.021-.074.038-.15.058-.225.105.013.21.032.319.032" fill="#44D860"/><path d="M63 55.5a2.5 2.5 0 0 1-2.5-2.5c0-4.136-3.364-7.5-7.5-7.5s-7.5 3.364-7.5 7.5a2.5 2.5 0 1 1-5 0c0-6.893 5.607-12.5 12.5-12.5S65.5 46.107 65.5 53a2.5 2.5 0 0 1-2.5 2.5" fill="#000"/><path d="M103 183h60c11.046 0 20-8.954 20-20V93h-60c-11.046 0-20 8.954-20 20v70z" fill="#FFFF50"/><path d="M168.02 124h-50.04a1 1 0 1 1 0-2h50.04a1 1 0 1 1 0 2m0 20h-50.04a1 1 0 1 1 0-2h50.04a1 1 0 1 1 0 2m0 20h-50.04a1 1 0 1 1 0-2h50.04a1 1 0 1 1 0 2m0-49.814h-50.04a1 1 0 1 1 0-2h50.04a1 1 0 1 1 0 2m0 19.814h-50.04a1 1 0 1 1 0-2h50.04a1 1 0 1 1 0 2m0 20h-50.04a1 1 0 1 1 0-2h50.04a1 1 0 1 1 0 2M183 61.611c-.012 0-.022-.006-.034-.005-3.09.105-4.552 3.196-5.842 5.923-1.346 2.85-2.387 4.703-4.093 4.647-1.889-.068-2.969-2.202-4.113-4.46-1.314-2.594-2.814-5.536-5.963-5.426-3.046.104-4.513 2.794-5.807 5.167-1.377 2.528-2.314 4.065-4.121 3.994-1.927-.07-2.951-1.805-4.136-3.813-1.321-2.236-2.848-4.75-5.936-4.664-2.994.103-4.465 2.385-5.763 4.4-1.373 2.13-2.335 3.428-4.165 3.351-1.973-.07-2.992-1.51-4.171-3.177-1.324-1.873-2.816-3.993-5.895-3.89-2.928.1-4.399 1.97-5.696 3.618-1.232 1.564-2.194 2.802-4.229 2.724a1 1 0 0 0-.072 2c3.017.101 4.545-1.8 5.872-3.487 1.177-1.496 2.193-2.787 4.193-2.855 1.926-.082 2.829 1.115 4.195 3.045 1.297 1.834 2.769 3.914 5.731 4.021 3.103.104 4.596-2.215 5.918-4.267 1.182-1.834 2.202-3.417 4.15-3.484 1.793-.067 2.769 1.35 4.145 3.681 1.297 2.197 2.766 4.686 5.787 4.796 3.125.108 4.634-2.62 5.949-5.035 1.139-2.088 2.214-4.06 4.119-4.126 1.793-.042 2.728 1.595 4.111 4.33 1.292 2.553 2.757 5.445 5.825 5.556l.169.003c3.064 0 4.518-3.075 5.805-5.794 1.139-2.41 2.217-4.68 4.067-4.773v-2z" fill="#000"/><path fill="#3ECC5F" d="M83 183h40v-40H83z"/><path d="M143 158c-.219 0-.428.037-.639.064-.038-.15-.074-.301-.116-.451A5 5 0 0 0 140.32 148a4.96 4.96 0 0 0-3.016 1.036 26.531 26.531 0 0 0-.335-.336 4.955 4.955 0 0 0 1.011-2.987 5 5 0 0 0-9.599-1.959c-.148-.042-.297-.077-.445-.115.027-.211.064-.42.064-.639a5 5 0 0 0-5-5 5 5 0 0 0-5 5c0 .219.037.428.064.639-.148.038-.297.073-.445.115a4.998 4.998 0 0 0-9.599 1.959c0 1.125.384 2.151 1.011 2.987-3.717 3.632-6.031 8.693-6.031 14.3 0 11.046 8.954 20 20 20 9.339 0 17.16-6.41 19.361-15.064.211.027.42.064.639.064a5 5 0 0 0 5-5 5 5 0 0 0-5-5" fill="#44D860"/><path fill="#3ECC5F" d="M83 123h40v-20H83z"/><path d="M133 115.5a2.5 2.5 0 1 0 0-5c-.109 0-.214.019-.319.032-.02-.075-.037-.15-.058-.225a2.501 2.501 0 0 0-.963-4.807c-.569 0-1.088.197-1.508.518a6.653 6.653 0 0 0-.168-.168c.314-.417.506-.931.506-1.494a2.5 2.5 0 0 0-4.8-.979A9.987 9.987 0 0 0 123 103c-5.522 0-10 4.478-10 10s4.478 10 10 10c.934 0 1.833-.138 2.69-.377a2.5 2.5 0 0 0 4.8-.979c0-.563-.192-1.077-.506-1.494.057-.055.113-.111.168-.168.42.321.939.518 1.508.518a2.5 2.5 0 0 0 .963-4.807c.021-.074.038-.15.058-.225.105.013.21.032.319.032" fill="#44D860"/><path d="M143 41.75c-.16 0-.33-.02-.49-.05a2.52 2.52 0 0 1-.47-.14c-.15-.06-.29-.14-.431-.23-.13-.09-.259-.2-.38-.31-.109-.12-.219-.24-.309-.38s-.17-.28-.231-.43a2.619 2.619 0 0 1-.189-.96c0-.16.02-.33.05-.49.03-.16.08-.31.139-.47.061-.15.141-.29.231-.43.09-.13.2-.26.309-.38.121-.11.25-.22.38-.31.141-.09.281-.17.431-.23.149-.06.31-.11.47-.14.32-.07.65-.07.98 0 .159.03.32.08.47.14.149.06.29.14.43.23.13.09.259.2.38.31.11.12.22.25.31.38.09.14.17.28.23.43.06.16.11.31.14.47.029.16.05.33.05.49 0 .66-.271 1.31-.73 1.77-.121.11-.25.22-.38.31-.14.09-.281.17-.43.23a2.565 2.565 0 0 1-.96.19m20-1.25c-.66 0-1.3-.27-1.771-.73a3.802 3.802 0 0 1-.309-.38c-.09-.14-.17-.28-.231-.43a2.619 2.619 0 0 1-.189-.96c0-.66.27-1.3.729-1.77.121-.11.25-.22.38-.31.141-.09.281-.17.431-.23.149-.06.31-.11.47-.14.32-.07.66-.07.98 0 .159.03.32.08.47.14.149.06.29.14.43.23.13.09.259.2.38.31.459.47.73 1.11.73 1.77 0 .16-.021.33-.05.49-.03.16-.08.32-.14.47-.07.15-.14.29-.23.43-.09.13-.2.26-.31.38-.121.11-.25.22-.38.31-.14.09-.281.17-.43.23a2.565 2.565 0 0 1-.96.19" fill="#000"/></g></svg>
\ No newline at end of file
diff --git a/static/img/undraw_docusaurus_mountain.svg b/static/img/undraw_docusaurus_mountain.svg
deleted file mode 100644
index af961c49..00000000
--- a/static/img/undraw_docusaurus_mountain.svg
+++ /dev/null
@@ -1,171 +0,0 @@
-<svg xmlns="http://www.w3.org/2000/svg" width="1088" height="687.962" viewBox="0 0 1088 687.962">
- <title>Easy to Use
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/static/img/undraw_docusaurus_react.svg b/static/img/undraw_docusaurus_react.svg
deleted file mode 100644
index 94b5cf08..00000000
--- a/static/img/undraw_docusaurus_react.svg
+++ /dev/null
@@ -1,170 +0,0 @@
-
- Powered by React
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/static/img/undraw_docusaurus_tree.svg b/static/img/undraw_docusaurus_tree.svg
deleted file mode 100644
index d9161d33..00000000
--- a/static/img/undraw_docusaurus_tree.svg
+++ /dev/null
@@ -1,40 +0,0 @@
-
- Focus on What Matters
-
diff --git a/tsconfig.json b/tsconfig.json
deleted file mode 100644
index 920d7a65..00000000
--- a/tsconfig.json
+++ /dev/null
@@ -1,8 +0,0 @@
-{
- // This file is not used in compilation. It is here just for a nice editor experience.
- "extends": "@docusaurus/tsconfig",
- "compilerOptions": {
- "baseUrl": "."
- },
- "exclude": [".docusaurus", "build"]
-}
diff --git a/use_cases/document_verification.mdx b/use_cases/document_verification.mdx
new file mode 100644
index 00000000..49422bab
--- /dev/null
+++ b/use_cases/document_verification.mdx
@@ -0,0 +1,338 @@
+---
+title: "Document Verification"
+description: "Ensure document authenticity and integrity with cryptographic verification"
+---
+
+# Document Verification
+
+Aqua Protocol provides tamper-proof verification of document integrity through cryptographic proofs, enabling organizations to authenticate documents without relying on centralized authorities. Every document modification is timestamped and permanently recorded, creating an immutable audit trail.
+
+## Core Capabilities
+
+### Tamper-Proof Verification
+Once a document is notarized in the Aqua Protocol, any modification becomes immediately detectable. The cryptographic hash of the document content is stored in the revision chain, making it mathematically impossible to alter without detection.
+
+### Timestamp Authentication
+Every document revision receives a blockchain-anchored timestamp, providing cryptographic proof of when the document was created or modified. This eliminates disputes about document timelines.
+
+### Permanent Audit Trails
+All document revisions, signatures, and witnesses are permanently recorded in an immutable chain. This creates a complete history of the document lifecycle that can be independently verified.
+
+### Decentralized Validation
+Verification happens cryptographically without requiring trust in intermediaries. Anyone with the document and its Aqua chain can independently verify authenticity and integrity.
+
+## Use Cases by Industry
+
+### Legal Documents
+
+**Contract Authenticity**
+- Prove when contracts were signed
+- Verify that contract terms haven't been altered
+- Establish non-repudiation through digital signatures
+- Maintain chain of custody for legal proceedings
+
+**Evidence Preservation**
+- Create tamper-proof records of digital evidence
+- Timestamp evidence collection
+- Maintain audit trails for admissibility
+- Prove evidence integrity in court
+
+**Notary Services**
+- Provide remote notarization with cryptographic proof
+- Replace traditional notary stamps with blockchain anchoring
+- Enable verifiable notarization across jurisdictions
+- Reduce costs while increasing security
+
+**Legal Compliance**
+- Demonstrate compliance with document retention policies
+- Prove regulatory filings were submitted on time
+- Maintain auditable records for investigations
+- Satisfy e-discovery requirements
+
+### Business Applications
+
+**Invoice Verification**
+- Authenticate invoices to prevent fraud
+- Track invoice approvals and modifications
+- Provide proof of invoice delivery and receipt
+- Enable automated payment processing with verified invoices
+
+**Purchase Orders**
+- Verify PO authenticity between trading partners
+- Track PO modifications and approvals
+- Prevent unauthorized changes
+- Create audit trails for procurement compliance
+
+**Financial Records**
+- Ensure integrity of financial statements
+- Track modifications to accounting records
+- Satisfy auditor requirements for record verification
+- Maintain SOX compliance with immutable audit logs
+
+**Regulatory Reporting**
+- Prove timely submission of regulatory reports
+- Demonstrate report integrity over time
+- Satisfy audit requirements
+- Reduce compliance costs
+
+### Educational Credentials
+
+**Diploma Authentication**
+- Provide instant verification of degree authenticity
+- Eliminate diploma mills and fraudulent credentials
+- Enable employers to verify qualifications
+- Reduce verification costs and time
+
+**Transcript Integrity**
+- Prevent transcript tampering
+- Allow secure sharing with third parties
+- Maintain permanent academic records
+- Enable credential portability across institutions
+
+**Certificate Validation**
+- Verify professional certifications
+- Track certificate expiration dates
+- Enable certificate revocation when needed
+- Support continuing education tracking
+
+**Academic Records**
+- Create verifiable lifetime learning records
+- Enable secure transcript sharing
+- Support credential stacking and micro-credentials
+- Facilitate credit transfers between institutions
+
+### Government Documents
+
+**Identity Documents**
+- Authenticate passports and ID cards
+- Enable remote identity verification
+- Prevent identity fraud
+- Support digital identity systems
+
+**License Verification**
+- Verify professional licenses instantly
+- Track license renewals and expirations
+- Enable license portability across jurisdictions
+- Support automated compliance checking
+
+**Permits and Certifications**
+- Authenticate building permits
+- Verify safety certifications
+- Track permit modifications
+- Enable instant permit validation by inspectors
+
+**Official Records**
+- Ensure integrity of government records
+- Enable citizen verification of official documents
+- Maintain transparent government operations
+- Prevent records tampering
+
+## Key Benefits
+
+### Eliminate Single Points of Failure
+Traditional document verification systems rely on centralized databases that can fail, be hacked, or become unavailable. Aqua Protocol's decentralized approach distributes verification capability, ensuring documents can always be verified even if specific systems are offline.
+
+### Maintain Document Provenance
+Every document modification is recorded with cryptographic proof of who made the change, when it occurred, and what was changed. This complete provenance trail answers questions about document history definitively.
+
+### Cryptographic Verification
+Verification relies on mathematical certainty rather than trust. Hashes, signatures, and blockchain anchors provide proof that can't be forged, even by system administrators.
+
+### No Trusted Intermediaries Required
+Unlike traditional notary or verification services, Aqua Protocol enables anyone to verify document authenticity independently. This reduces costs and increases accessibility.
+
+### Regulatory Compliance
+Industries requiring regulatory compliance benefit from maintained audit trails:
+- **Legal firms**: Demonstrate evidence integrity and chain of custody
+- **Financial institutions**: Satisfy SOX, GDPR, and financial regulations
+- **Healthcare providers**: Maintain HIPAA-compliant document trails
+- **Educational institutions**: Provide verifiable credentials that meet accreditation standards
+
+### Cost Reduction
+Automated verification reduces manual processes, eliminates middlemen, speeds up verification times, and prevents fraud losses.
+
+## How It Works
+
+### 1. Document Notarization
+When a document is first notarized:
+- The document content is hashed using SHA3-256
+- A genesis revision is created with the document hash
+- The revision is signed by the document creator
+- The signature is witnessed on a blockchain
+- All data is stored in an immutable Aqua chain
+
+### 2. Document Updates
+When a document is modified:
+- A new revision is created referencing the previous revision
+- The new content hash is recorded
+- The update is signed by authorized parties
+- The signature is witnessed for timestamp proof
+- The revision chain grows, maintaining complete history
+
+### 3. Multi-Party Signing
+For documents requiring multiple signatures:
+- Each party adds their signature as a new revision
+- Signatures reference the document revision being signed
+- Order of signing is preserved in the chain
+- All signatures receive blockchain timestamps
+- Final witness anchors the complete signing process
+
+### 4. Verification
+Anyone can verify a document by:
+- Computing the hash of the document content
+- Comparing it to the hash in the revision chain
+- Verifying all signatures cryptographically
+- Checking blockchain witness timestamps
+- Validating the entire revision chain integrity
+
+## Real-World Scenarios
+
+### Scenario 1: Legal Contract Management
+
+**Challenge**: A law firm needs to manage contracts with guaranteed integrity and provable signing timestamps for multiple parties.
+
+**Solution**:
+- Contract is notarized when drafted, creating the genesis revision
+- Each party reviews and signs, adding signature revisions
+- Final contract is witnessed on Ethereum mainnet
+- All parties receive the complete Aqua chain
+- Years later, if disputed, the contract's integrity and signing timeline can be cryptographically proven
+
+**Benefits**: Non-repudiation, tamper-proof records, defensible timestamps, reduced notary costs
+
+### Scenario 2: Academic Credential Verification
+
+**Challenge**: Universities issue thousands of diplomas, and employers need to verify credentials quickly without calling the registrar.
+
+**Solution**:
+- University notarizes each diploma as it's issued
+- Diploma includes an Aqua chain with the university's signature
+- University witnesses the batch of diplomas on blockchain
+- Employers scan QR code or receive Aqua chain from candidate
+- Verification happens instantly using Aqua verification tools
+
+**Benefits**: Instant verification, eliminated fraud, reduced administrative burden, improved candidate experience
+
+### Scenario 3: Financial Audit Trail
+
+**Challenge**: A public company must maintain auditable financial records that prove compliance with regulations.
+
+**Solution**:
+- Financial statements are notarized each quarter
+- CFO signs the statement, adding signature revision
+- External auditor witnesses the statement on blockchain
+- Audit trail is preserved permanently
+- Regulators can verify statement integrity independently
+
+**Benefits**: Regulatory compliance, reduced audit costs, defensible records, fraud prevention
+
+### Scenario 4: Government Permit Issuance
+
+**Challenge**: Building department issues permits that need to be verified by inspectors, contractors, and the public.
+
+**Solution**:
+- Permit applications are notarized when submitted
+- Permit approvals are signed by authorized officials
+- Approved permits are witnessed on blockchain
+- QR codes on physical permits link to Aqua chains
+- Anyone can verify permit authenticity and status
+
+**Benefits**: Fraud prevention, instant verification, public transparency, reduced administrative overhead
+
+## Integration Patterns
+
+### Document Management Systems
+Integrate Aqua Protocol into existing DMS platforms to automatically notarize important documents. When documents are finalized, trigger Aqua notarization via SDK.
+
+### E-Signature Platforms
+Enhance e-signature solutions with blockchain-anchored timestamps and cryptographic verification. Each signature becomes a verifiable revision in the Aqua chain.
+
+### CRM and Business Systems
+Add document verification to CRM, ERP, or custom business applications. Automatically notarize quotes, proposals, contracts, and invoices as they're generated.
+
+### Educational Systems
+Integrate with student information systems to automatically notarize transcripts, diplomas, and certificates as they're issued.
+
+### Government Systems
+Add Aqua Protocol to permit, license, and registration systems to provide instant verification capability to citizens and businesses.
+
+## Best Practices
+
+### Initial Notarization
+- Notarize documents as early as possible in their lifecycle
+- Include relevant metadata (document type, parties, purpose)
+- Use appropriate method (scalar for small docs, tree for large)
+- Sign immediately after creation to establish authorship
+
+### Multi-Party Documents
+- Establish signing order and communicate to all parties
+- Each party should verify previous signatures before adding theirs
+- Witness after all signatures are collected
+- Distribute complete Aqua chain to all parties
+
+### Long-Term Storage
+- Store Aqua chains separately from documents
+- Back up chains to multiple locations
+- Include Aqua chain with document when transmitting
+- Test verification periodically
+
+### Verification
+- Always verify documents received from third parties
+- Check entire revision chain, not just the latest revision
+- Verify blockchain witnesses for important documents
+- Validate signatures match expected signers
+
+### Privacy Considerations
+- Aqua chains don't contain document content by default
+- Share chains carefully as they prove document existence
+- Use private blockchains if public witnessing is problematic
+- Consider what metadata is included in revisions
+
+## Technical Advantages
+
+### Cryptographic Security
+- SHA3-256 hashing provides computational infeasibility of collision attacks
+- ECDSA signatures (65 bytes) provide 128-bit security level
+- Blockchain anchoring makes backdating mathematically impossible
+
+### Scalability
+- Document verification is O(n) where n is number of revisions
+- Merkle tree mode enables selective disclosure of large documents
+- Batch witnessing reduces blockchain transaction costs
+- Verification can happen offline after initial chain retrieval
+
+### Interoperability
+- JSON-based format enables easy integration
+- Multiple SDK options (Rust, JavaScript/TypeScript)
+- Platform-agnostic verification
+- Standard cryptographic primitives
+
+### Future-Proof
+- Protocol versioning supports evolution
+- Blockchain-agnostic witness mechanism
+- Multiple signature algorithm support
+- Extensible revision types
+
+## Common Questions
+
+**Q: What if the blockchain network goes offline?**
+A: Verification of existing documents still works using cryptographic verification of signatures and hashes. Only new witnessing requires blockchain access. Historical witnesses remain provable through transaction records.
+
+**Q: How long are documents stored?**
+A: Aqua Protocol stores only hashes and metadata, not document content. Document storage is separate and managed by users. Aqua chains are small (kilobytes) and can be stored indefinitely.
+
+**Q: Can witnesses be trusted?**
+A: Blockchain witnesses provide cryptographic proof of timestamp. As long as the blockchain network is secure and decentralized, witnesses cannot be backdated or falsified.
+
+**Q: What about privacy?**
+A: By default, only document hashes are stored on-chain, not content. The document itself remains private. Share Aqua chains carefully as they prove document existence at specific times.
+
+**Q: How do I revoke a document?**
+A: Add a revocation revision to the chain. The document history remains (for audit purposes), but new revisions can indicate revoked status.
+
+## See Also
+
+- [Supply Chain Tracking](/use_cases/supply-chain) - Apply similar verification to supply chain events
+- [Identity Attestation](/use_cases/identity-attestation) - Verify identity credentials
+- [Quick Start](/quick-start) - Get started with document verification
+- [Schema Reference](/schema_reference/introduction) - Technical specifications
diff --git a/use_cases/identity_attestation.mdx b/use_cases/identity_attestation.mdx
new file mode 100644
index 00000000..9319e731
--- /dev/null
+++ b/use_cases/identity_attestation.mdx
@@ -0,0 +1,125 @@
+---
+title: "Identity Attestation"
+description: "Establish trust with verifiable self-sovereign identity claims and attestations"
+---
+
+# Identity Attestation
+
+The Aqua Protocol enables a robust **Self-Sovereign Identity (SSI)** framework where individuals and organizations can issue, attest, and verify identity claims without relying on centralized identity providers. By leveraging cryptographic proofs and decentralized trust chains, Aqua allows users to own their data while enabling third parties to verify specific attributes with certainty.
+
+## Core Capabilities
+
+### Self-Sovereign Identity (SSI)
+Users have full control over their identities. Identity claims are **self-issued** first, proving account ownership, and then enriched by **attestations** from trusted authorities. This ensures that the user is always the central point of their identity graph.
+
+### Verifiable Attestations
+Third parties (Trust Authorities) can sign attestations that validate a user's specific claims (e.g., "Over 18", "Accredited Investor", "University Graduate"). These attestations are cryptographically linked to the user's identity chain and the authority's trust chain.
+
+### Trust Chains
+Trust is transitive and transparent. A verifier doesn't just trust a claim; they verify the entire chain of authority. For example, a diploma is trusted because it's signed by a University, which is accredited by an Education Ministry, which is recognized by the Government.
+
+### Selective Disclosure & Privacy
+Users can share specific attestations (e.g., "I am over 21") without revealing their entire identity or unrelated personal data. Data Vaults protect sensitive claims, ensuring they are only decrypted for authorized verifiers.
+
+## Use Cases by Industry
+
+### Education & Academia
+
+**Digital Diplomas & Transcripts**
+- Universities issue tamper-proof degree certificates.
+- Students can instantly prove graduation to employers.
+- Prevents credential fraud and "diploma mills".
+- Enables portable academic records across institutions.
+
+**Professional Certifications**
+- Licensing boards attest to professional status (e.g., Medical License, Bar Association).
+- Real-time verification of valid/active status.
+- Automated expiry and renewal tracking.
+
+### Government & Legal
+
+**Digital ID & Passports**
+- Governments issue digital complements to physical IDs.
+- Citizens use digital wallets to prove citizenship or residency.
+- Streamlined visa and border entry processes.
+
+**Notary & Witnessing**
+- Notaries attest to the identity of a signer on a document.
+- Creates a cryptographic link between the person, the document, and the notary.
+- Replaces physical stamps with digital signatures.
+
+### Financial Services
+
+**KYC/AML Compliance**
+- Banks perform "Know Your Customer" checks once and issue a reusable attestation.
+- Users share this attestation with other services to onboard instantly without re-submitting documents.
+- Reduces compliance costs and friction.
+
+**Accredited Investor Status**
+- Financial institutions attest that a user meets investment criteria.
+- Allows participation in regulated private equity or tokens.
+
+### Digital Services & Web3
+
+**Sybil Resistance**
+- Verify that an account belongs to a unique human without collecting personal data.
+- "Proof of Humanity" or "Social Login" attestations.
+- Prevents bot spam and manipulation in DAOs and communities.
+
+**Reputation & Social Proof**
+- Platforms attest to a user's reputation score or history.
+- Enables portable reputation across different marketplaces and communities.
+
+## Key Benefits
+
+### User Privacy & Control
+Users store their own data in encrypted Data Vaults. They grant access only when necessary and can revoke it at any time. No centralized "honey pot" of user data to hack.
+
+### Fraud Reduction
+Cryptographic signatures make it impossible to forge attestations.
+
+### Interoperability
+Built on standard cryptographic primitives, allowing identity claims to be used across different platforms, wallets, and services that support the Aqua Protocol.
+
+### Reduced Friction
+"Verify once, use everywhere." Users don't need to repeatedly upload passport photos or utility bills. One verified attestation can be reused across multiple services.
+
+## How It Works
+
+### 1. Claim Creation (Self-Issuance)
+The user creates a **Self-Issued Identity Claim**.
+- Example: "I claim my name is Alice."
+- This claim is signed by Alice's private key, establishing ownership of the claim.
+- It serves as the "subject" for future attestations.
+
+### 2. Attestation
+A **Trust Authority** (e.g., a University) verifies the claim off-chain (by checking real documents) and then issues an **Attestation**.
+- The Authority signs a statement referencing Alice's self-issued claim hash.
+- "I, University X, attest that the claim [Hash] by Alice is true."
+- This attestation is recorded in the Authority's Aqua chain.
+
+### 3. Verification & Trust Chains
+A relying party (e.g., an Employer) verifies the diploma.
+- They check Alice's claim.
+- They verify the University's signature on the attestation.
+- They verify the University's authority (e.g., by checking a "Ministry of Education" attestation on the University's identity).
+- If the chain of trust is valid, the diploma is accepted.
+
+
+## Real-World Scenario: The "Trust Chain"
+
+Consider verifying a **University Degree**:
+
+1. **The Graduate (Alice)**: Creates a self-issued claim for her degree.
+2. **The Professor**: Signs an attestation for Alice's grade/completion.
+3. **The Department Head**: Attests to the Professor's employment.
+4. **The University**: Attests to the Department Head's role.
+5. **The Ministry of Education**: Attests to the University's accreditation.
+
+When an employer verifies Alice's degree, they trace this path back to a root of trust they recognize (e.g., the Ministry of Education), ensuring the credential is legitimate without needing to call the university.
+
+## See Also
+
+- [Document Verification](/use_cases/document-verification) - Verify the integrity of files and contracts.
+- [Supply Chain Tracking](/use_cases/supply-chain) - Trace provenance of physical goods.
+- [Aqua CLI](/dev_tools/aqua_cli) - Tools for issuing and verifying claims.
diff --git a/use_cases/introduction.mdx b/use_cases/introduction.mdx
new file mode 100644
index 00000000..a3b5e0d7
--- /dev/null
+++ b/use_cases/introduction.mdx
@@ -0,0 +1,220 @@
+---
+title: 'Use Cases & Examples'
+description: 'How can Aqua protocol be used in your project'
+---
+
+# Aqua Protocol Use Cases
+
+Aqua Protocol provides cryptographic verification and provenance tracking for data across diverse industries and applications. By creating immutable chains of revisions with signatures and blockchain anchoring, Aqua enables trust without centralized authorities.
+
+## Why Aqua Protocol?
+
+Traditional systems for tracking data provenance, verifying authenticity, and maintaining audit trails rely on centralized databases and trusted intermediaries. These approaches introduce:
+
+- **Single points of failure**: Centralized systems can be compromised, taken offline, or manipulated
+- **Trust requirements**: Users must trust the intermediary to maintain integrity
+- **Limited verification**: Third parties cannot independently verify authenticity
+- **Vendor lock-in**: Data is trapped in proprietary systems
+- **High costs**: Intermediaries charge fees for verification services
+
+Aqua Protocol solves these problems through:
+
+- **Decentralized verification**: Anyone can verify data integrity cryptographically
+- **Mathematical certainty**: Cryptographic proofs replace trust requirements
+- **Immutable history**: Complete audit trails that cannot be altered
+- **Open standards**: Platform-agnostic verification using standard algorithms
+- **Cost efficiency**: Reduced reliance on intermediaries and manual processes
+
+## Core Capabilities
+
+### Tamper-Proof Records
+Once data is recorded in an Aqua chain, modifications become immediately detectable. Cryptographic hashes ensure that any change to content, timestamps, or signatures invalidates the chain, providing mathematical proof of tampering.
+
+### Blockchain Timestamping
+Every critical revision can be anchored to Ethereum, Nostr, or TSA timestamping services. This provides cryptographic proof of when data existed, eliminating disputes about timing and preventing backdating.
+
+### Multi-Party Signatures
+Multiple parties can cryptographically sign revisions, establishing non-repudiation and accountability. Each signature is independently verifiable, proving who authorized what and when.
+
+### Provenance Tracking
+Link revisions create relationships between chains, enabling complex provenance graphs. Track how data flows through systems, who touched it, and what transformations occurred.
+
+### Template-Based Validation
+Version 4's template system enforces data schemas with JSON Schema validation, ensuring consistent structure across revisions while maintaining cryptographic integrity.
+
+## Application Domains
+
+### Legal and Compliance
+Legal documents, contracts, evidence, regulatory filings, and compliance records require guaranteed integrity and provable timestamps. Aqua Protocol provides:
+- Non-repudiation through cryptographic signatures
+- Defensible timestamps via blockchain anchoring
+- Complete audit trails for investigations
+- Chain of custody for evidence
+- Regulatory compliance documentation
+
+### Supply Chain and Logistics
+Products moving through complex supply chains need provenance tracking from origin to destination. Aqua Protocol enables:
+- End-to-end traceability from raw materials to consumer
+- Multi-party coordination across manufacturers, distributors, and retailers
+- Authenticity verification to prevent counterfeits
+- Regulatory compliance for food, pharmaceuticals, and other regulated goods
+- Efficient recalls with precise product tracking
+
+### Identity and Credentials
+Educational institutions, professional organizations, and governments issue credentials that need verification. Aqua Protocol provides:
+- Instant verification of diplomas, certificates, and licenses
+- Revocation capability when credentials expire or are withdrawn
+- Portable credentials that individuals control
+- Elimination of credential fraud
+- Reduced verification costs and time
+
+### Financial Services
+Financial institutions require immutable audit trails for transactions, statements, and regulatory reports. Aqua Protocol offers:
+- Tamper-proof financial records
+- Provable submission timing for regulatory filings
+- Multi-party approval workflows for transactions
+- Audit-ready documentation for compliance
+- Fraud prevention through verification
+
+### Healthcare
+Patient records, clinical trial data, and medical device tracking demand integrity and privacy. Aqua Protocol enables:
+- Verifiable medical records that patients control
+- Clinical trial data integrity for regulatory approval
+- Medical device tracking and recall management
+- HIPAA-compliant audit trails
+- Secure sharing between healthcare providers
+
+### Intellectual Property
+Patents, copyrights, trade secrets, and creative works benefit from provable timestamps. Aqua Protocol provides:
+- Proof of creation date for prior art disputes
+- Version tracking for creative works
+- Licensing and royalty audit trails
+- Collaborative creation with attribution
+- Protection against IP theft
+
+## Industry-Specific Solutions
+
+### Manufacturing
+- Bill of materials with cryptographic proof
+- Quality control inspection records
+- Product genealogy from components to finished goods
+- Supplier certification verification
+- Warranty claim documentation
+
+### Real Estate
+- Property title chains with verified transfers
+- Lease agreements with multi-party signatures
+- Inspection reports with tamper-proof timestamps
+- Escrow milestone documentation
+- Regulatory compliance for transactions
+
+### Energy and Utilities
+- Renewable energy certificate tracking
+- Carbon credit provenance verification
+- Utility meter reading audit trails
+- Regulatory compliance documentation
+- Asset maintenance history
+
+### Government and Public Sector
+- Passport and identity document verification
+- Professional license tracking
+- Permit and certification issuance
+- Public records integrity
+- Voting and election audit trails
+
+## Technical Flexibility
+
+Aqua Protocol adapts to diverse requirements through:
+
+- **Multiple revision types**: Objects, templates, signatures, witnesses, and links
+- **Flexible signing methods**: RSA, Ethereum EIP-191, DID:JWS, and more
+- **Choice of witnesses**: Ethereum (mainnet, testnets), Nostr, TSA
+- **Scalar or tree methods**: Optimize for simplicity or selective disclosure
+- **Cross-platform SDKs**: Rust with WASM, JavaScript/TypeScript for any environment
+- **Template customization**: Define domain-specific schemas with JSON Schema
+
+## Getting Started
+
+Explore the detailed use cases below to understand how Aqua Protocol applies to your specific domain:
+
+
+
+ Ensure document authenticity and integrity with cryptographic verification. Learn how legal firms, businesses, educational institutions, and government agencies use Aqua Protocol for tamper-proof document management.
+
+
+
+ Track products through the supply chain with end-to-end transparency. Discover how food, pharmaceutical, manufacturing, and logistics companies implement provenance verification.
+
+
+
+ Implement secure identity verification and credential attestation. Explore how credentials, certifications, and identity documents gain instant verifiability.
+
+
+
+ Practical examples and step-by-step tutorials for building with Aqua Protocol. Get hands-on experience implementing real-world use cases.
+
+
+
+## Common Patterns
+
+Regardless of industry, Aqua Protocol implementations typically follow these patterns:
+
+### 1. Genesis Creation
+Start by creating the initial revision with core data:
+- Document content, product information, or credential details
+- Relevant metadata (timestamps, identifiers, classifications)
+- Template reference for structured data validation
+
+### 2. Multi-Party Signatures
+Collect signatures from relevant parties:
+- Creator signs to establish authenticity
+- Reviewers sign to indicate approval
+- Authorities sign for official endorsement
+- Each signature adds non-repudiation
+
+### 3. Blockchain Witnessing
+Anchor critical revisions to blockchain:
+- Provides tamper-proof timestamps
+- Prevents backdating of revisions
+- Enables independent verification
+- Satisfies regulatory requirements
+
+### 4. Provenance Linking
+Connect related chains:
+- Link components to assemblies
+- Reference supporting documents
+- Establish dependencies between datasets
+- Create complex verification graphs
+
+### 5. Long-Term Verification
+Maintain verifiability over time:
+- Store Aqua chains separately from content
+- Distribute chains to all stakeholders
+- Periodically verify chain integrity
+- Update verification tools as needed
+
+## Benefits Across All Use Cases
+
+### Trust Without Intermediaries
+Cryptographic verification replaces trust in centralized authorities. Anyone can independently verify authenticity, reducing costs and increasing accessibility.
+
+### Regulatory Compliance
+Immutable audit trails satisfy regulators across industries. From SOX compliance in finance to HIPAA in healthcare, Aqua Protocol provides defensible documentation.
+
+### Cost Reduction
+Automated verification eliminates manual processes, reduces fraud losses, speeds up operations, and removes intermediary fees.
+
+### Enhanced Security
+Cryptographic primitives (SHA3-256, ECDSA) provide security that cannot be achieved with traditional databases. Even system administrators cannot forge valid chains.
+
+### Future-Proof Design
+Protocol versioning, extensible revision types, and blockchain-agnostic witnessing ensure Aqua chains remain verifiable as technology evolves.
+
+## Next Steps
+
+Ready to implement Aqua Protocol for your use case?
+
+- Review the detailed use case documentation above
+- Check out the [Quick Start Guide](/quick-start) for hands-on implementation
+- Explore the [Schema Reference](/schema_reference/introduction) for technical specifications
+- Choose your SDK: [Rust (v4)](/previous_versions/version_4/introduction) or [JavaScript (v3)](/previous_versions/version_3/introduction)
diff --git a/use_cases/supply_chain.mdx b/use_cases/supply_chain.mdx
new file mode 100644
index 00000000..1471bdf5
--- /dev/null
+++ b/use_cases/supply_chain.mdx
@@ -0,0 +1,388 @@
+---
+title: "Supply Chain Tracking"
+description: "End-to-end traceability and provenance verification for supply chain operations"
+---
+
+# Supply Chain Tracking
+
+Aqua Protocol provides cryptographic provenance tracking for supply chain operations, enabling end-to-end traceability from raw materials to finished products. Each step in the supply chain is recorded with immutable timestamps, creating a verifiable chain of custody that proves authenticity and tracks movement across multiple parties.
+
+## Core Capabilities
+
+### End-to-End Traceability
+Track products from origin to destination with cryptographic proof at each step. Every transfer, transformation, and quality check is recorded in an immutable chain, creating a complete product history that can be independently verified.
+
+### Multi-Party Coordination
+Supply chains involve manufacturers, distributors, retailers, regulators, and consumers. Aqua Protocol enables all parties to contribute to the chain while maintaining data integrity, without requiring a central authority.
+
+### Provenance Verification
+Prove the origin and authenticity of products cryptographically. Consumers and businesses can verify that products are genuine, sourced ethically, and meet quality standards without trusting intermediaries.
+
+### Real-Time Transparency
+All stakeholders can verify the current state and history of products in real-time. Blockchain witnesses provide tamper-proof timestamps, ensuring accurate tracking of supply chain events as they occur.
+
+## Use Cases by Industry
+
+### Food & Agriculture
+
+**Farm-to-Table Tracking**
+- Record harvest timestamps and origin farm information
+- Track temperature and storage conditions during transport
+- Prove organic certification and farming practices
+- Enable consumers to verify food provenance via QR codes
+
+**Quality Assurance**
+- Document quality inspections at each stage
+- Track batch numbers for recall management
+- Record processing and packaging timestamps
+- Maintain cold chain compliance records
+
+**Regulatory Compliance**
+- Demonstrate compliance with food safety regulations
+- Provide audit trails for health inspectors
+- Track certifications (organic, fair trade, kosher, halal)
+- Prove country of origin for import/export
+
+**Recall Management**
+- Identify affected batches immediately
+- Trace contamination to specific sources
+- Notify all parties in distribution chain
+- Minimize recall scope with precise tracking
+
+### Pharmaceuticals
+
+**Drug Authentication**
+- Prevent counterfeit medications from entering supply chain
+- Verify pharmaceutical manufacturer and production batch
+- Track medication from factory to pharmacy
+- Enable patients to verify medication authenticity
+
+**Cold Chain Management**
+- Record temperature at every transport stage
+- Prove compliance with storage requirements
+- Alert stakeholders to temperature excursions
+- Maintain regulatory compliance documentation
+
+**Clinical Trial Management**
+- Track investigational drugs through trial phases
+- Document chain of custody for trial materials
+- Prove compliance with trial protocols
+- Maintain audit trails for regulatory submissions
+
+**Regulatory Reporting**
+- Demonstrate compliance with pharmaceutical regulations
+- Track serialization and aggregation data
+- Provide audit trails for FDA, EMA, and other authorities
+- Support Drug Supply Chain Security Act (DSCSA) compliance
+
+### Manufacturing
+
+**Component Traceability**
+- Track components from suppliers to assembly
+- Verify authenticity of critical components
+- Manage bill of materials with cryptographic proof
+- Prevent counterfeit parts from entering production
+
+**Quality Control**
+- Record inspection results at each manufacturing stage
+- Document rework and quality issues
+- Track serial numbers through production process
+- Maintain statistical process control data
+
+**Product Genealogy**
+- Build complete product history from raw materials
+- Track which components went into which products
+- Enable root cause analysis for defects
+- Support warranty claims with production records
+
+**Supplier Management**
+- Verify supplier certifications and compliance
+- Track supplier performance metrics
+- Prove ethical sourcing practices
+- Manage supplier risk with documented history
+
+### Logistics & Distribution
+
+**Shipment Tracking**
+- Record custody transfers between carriers
+- Timestamp loading and unloading events
+- Track location updates throughout journey
+- Prove on-time delivery with blockchain witnesses
+
+**Customs and Border Control**
+- Provide immutable documentation for customs
+- Prove product origin for tariff classification
+- Streamline border crossings with verified data
+- Reduce customs delays with cryptographic proof
+
+**Last-Mile Delivery**
+- Verify final delivery to customer
+- Timestamp customer receipt
+- Prove condition at delivery
+- Enable dispute resolution with documented proof
+
+**Warehouse Management**
+- Track inventory movements within facilities
+- Record picking, packing, and shipping operations
+- Maintain lot and serial number traceability
+- Integrate with ERP systems for real-time updates
+
+## Key Benefits
+
+### Eliminate Counterfeits
+Counterfeit products cost industries billions annually. Aqua Protocol makes counterfeiting economically infeasible by requiring cryptographic proof at each supply chain step. Fake products cannot produce valid Aqua chains, making them easily identifiable.
+
+### Improve Recall Efficiency
+When safety issues arise, rapid recall is critical. Aqua Protocol enables precise identification of affected products, reducing recall scope and cost. Complete provenance data shows exactly which batches are impacted and where they were distributed.
+
+### Increase Consumer Trust
+Consumers increasingly demand transparency about product origins and manufacturing. Scannable QR codes linked to Aqua chains let customers verify authenticity, ethical sourcing, and quality standards, building brand trust.
+
+### Streamline Compliance
+Regulatory compliance requires extensive documentation and audit trails. Aqua Protocol automatically creates tamper-proof records that satisfy regulators, reducing compliance costs and audit preparation time.
+
+### Enable Ethical Sourcing
+Prove that products meet ethical standards for labor practices, environmental impact, and sustainable sourcing. Immutable records prevent "ethics washing" and provide verifiable proof of responsible practices.
+
+### Reduce Liability
+Complete documentation of supply chain events reduces liability exposure. When disputes arise, cryptographic proof shows exactly what happened, when, and who was responsible.
+
+## How It Works
+
+### 1. Product Registration
+When a product enters the supply chain:
+- Genesis revision is created with product identifier
+- Initial metadata recorded (SKU, batch number, origin)
+- Manufacturer signs the genesis revision
+- Signature is witnessed on blockchain for timestamp proof
+- Product receives unique Aqua chain
+
+### 2. Supply Chain Events
+As the product moves through the supply chain:
+- Each event creates a new revision (transfer, inspection, processing)
+- Event data includes timestamp, location, responsible party
+- Each party signs their contributions to the chain
+- Critical events are witnessed for regulatory proof
+- Chain grows to include complete product history
+
+### 3. Multi-Party Signatures
+When custody transfers between parties:
+- Sending party signs transfer revision
+- Receiving party verifies and countersigns
+- Both signatures reference the same state
+- Blockchain witness timestamps the transfer
+- Prevents disputes about transfer timing or condition
+
+### 4. Verification
+At any point, stakeholders can verify:
+- Scan product QR code to retrieve Aqua chain
+- Verify all cryptographic signatures
+- Check blockchain witnesses for timestamps
+- Validate entire chain integrity
+- Confirm product authenticity and history
+
+## Real-World Scenarios
+
+### Scenario 1: Pharmaceutical Supply Chain
+
+**Challenge**: A pharmaceutical company must track medication from manufacturing through distribution to pharmacies while maintaining cold chain compliance and preventing counterfeits.
+
+**Solution**:
+- Each medication batch gets genesis revision when manufactured
+- Quality control inspections add signed revisions
+- Temperature monitors record readings as revisions
+- Each distributor transfer is signed by both parties
+- Pharmacies verify medication authenticity by scanning
+- Regulators can audit complete chain from manufacturer to patient
+
+**Benefits**: Counterfeit prevention, cold chain compliance, regulatory audit trails, patient safety, streamlined recalls
+
+### Scenario 2: Organic Food Certification
+
+**Challenge**: Consumers want to verify that "organic" products are genuinely organic from farm to store, but current systems rely on paper certificates that can be forged.
+
+**Solution**:
+- Farms create genesis revision with organic certification
+- Certification body signs the certification revision
+- Each processing step is documented and signed
+- Distributors add transport and storage revisions
+- Retailers witness final product placement
+- Consumers scan QR code to verify organic provenance
+
+**Benefits**: Verified organic claims, consumer confidence, brand differentiation, premium pricing justification
+
+### Scenario 3: Automotive Parts Traceability
+
+**Challenge**: An automotive manufacturer needs to track critical safety components through multiple supplier tiers to ensure authenticity and enable recalls if defects are discovered.
+
+**Solution**:
+- Tier 3 supplier creates genesis for raw materials
+- Tier 2 supplier adds processing revisions with quality checks
+- Tier 1 supplier integrates into assemblies with link revisions
+- OEM manufacturer links assemblies into final vehicles
+- Each VIN is linked to component Aqua chains
+- Defective component traced to exact source and all affected vehicles
+
+**Benefits**: Counterfeit prevention, rapid recall execution, root cause analysis, supplier accountability, quality improvement
+
+### Scenario 4: Coffee Supply Chain Transparency
+
+**Challenge**: Coffee roasters want to prove fair trade practices and sustainable sourcing to increasingly conscious consumers, but existing certification systems are opaque.
+
+**Solution**:
+- Coffee farmers create genesis with harvest data
+- Fair trade auditor signs certification revision
+- Exporters document transport and quality grading
+- Importers add customs and warehousing data
+- Roasters link to final packaged products
+- Consumers scan bags to see complete farm-to-cup journey
+
+**Benefits**: Verified ethical sourcing, consumer transparency, premium pricing, farmer accountability, brand storytelling
+
+## Integration Patterns
+
+### ERP Systems
+Integrate Aqua Protocol with enterprise resource planning systems to automatically create revisions for inventory movements, production events, and quality checks.
+
+**Implementation**:
+- ERP triggers Aqua revision creation on key events
+- Product master data becomes genesis revision
+- Manufacturing orders add production revisions
+- Shipping orders create transfer revisions
+- Quality inspections add signed quality revisions
+
+### IoT Sensors
+Connect IoT devices to automatically record sensor data as revisions:
+- Temperature sensors for cold chain monitoring
+- GPS trackers for location updates
+- RFID readers for automated checkpoint scanning
+- Weight scales for quantity verification
+- Quality inspection equipment for automated testing
+
+### Blockchain Oracles
+Use blockchain oracles to feed external data into supply chains:
+- Weather data for agricultural provenance
+- Customs clearance status
+- Regulatory database lookups
+- Third-party certification verification
+- Market pricing for timestamp-based valuation
+
+### Consumer Apps
+Build consumer-facing applications that verify products:
+- Mobile apps with QR code scanning
+- Web portals for product history viewing
+- Voice assistants for product authentication
+- Smart packaging with NFC chips
+- Augmented reality product storytelling
+
+### Supplier Portals
+Create portals for suppliers to contribute to chains:
+- Self-service revision creation
+- Document upload and signature
+- Certification management
+- Quality data submission
+- Real-time status visibility
+
+## Best Practices
+
+### Genesis Creation
+- Create genesis as early as possible in supply chain
+- Include comprehensive product metadata
+- Use template revisions for standardized data
+- Sign genesis immediately to establish authenticity
+- Witness genesis for high-value or regulated products
+
+### Event Granularity
+- Balance detail with practical overhead
+- Record all custody transfers
+- Document critical quality checkpoints
+- Capture regulatory compliance events
+- Skip routine events that don't add value
+
+### Multi-Party Coordination
+- Establish clear protocols for handoffs
+- Both parties must sign custody transfers
+- Verify previous signatures before adding new ones
+- Communicate chain updates to all stakeholders
+- Maintain consistent timestamp standards
+
+### Data Privacy
+- Aqua chains store hashes, not sensitive content
+- Use tree method for selective disclosure
+- Share chains only with authorized parties
+- Consider what metadata is included
+- Use private witnesses if public timestamps are problematic
+
+### Verification Strategy
+- Verify products at key checkpoints
+- Check complete chain for high-value items
+- Spot-check for routine items
+- Validate blockchain witnesses for critical events
+- Train staff on verification procedures
+
+### Batch Operations
+- Use batch witnessing to reduce costs
+- Group similar products in same witness transaction
+- Balance cost savings with timestamp precision
+- Implement automated batching in integration systems
+- Monitor batch sizes for optimization
+
+## Technical Advantages
+
+### Scalability
+- Object revisions scale to billions of products
+- Link revisions enable hierarchical organization
+- Batch witnessing reduces blockchain costs
+- Offline verification after chain retrieval
+- Distributed storage prevents bottlenecks
+
+### Interoperability
+- JSON-based format for easy integration
+- Multiple SDK options (Rust, JavaScript)
+- Standard cryptographic primitives
+- Platform-agnostic verification
+- Compatible with existing supply chain systems
+
+### Flexibility
+- Template system for industry-specific schemas
+- Custom revision types for unique requirements
+- Multiple signature methods for different parties
+- Choice of witnessing networks
+- Extensible for future needs
+
+### Security
+- SHA3-256 hashing prevents collision attacks
+- ECDSA signatures provide strong authentication
+- Blockchain anchoring prevents backdating
+- Merkle trees enable selective disclosure
+- Cryptographic proof instead of trust
+
+## Common Questions
+
+**Q: How do we handle products without digital interfaces?**
+A: Use QR codes, NFC tags, or printed Aqua chain identifiers on packaging. The Aqua chain exists independently of the physical product. Low-cost printed codes work for most products.
+
+**Q: What if a supply chain participant doesn't want to use Aqua Protocol?**
+A: The chain can continue without them, but their contribution won't have cryptographic proof. This creates accountability - participants who don't use Aqua Protocol are less trustworthy. Market pressure encourages adoption.
+
+**Q: How do we handle returns and reverse logistics?**
+A: Add revision documenting the return event, including reason and condition. The chain naturally grows to include forward and reverse movements, maintaining complete product history.
+
+**Q: Can we integrate with existing traceability systems?**
+A: Yes. Aqua Protocol can wrap existing systems, adding cryptographic proof to current tracking data. Legacy system data can be hashed and stored in revisions.
+
+**Q: What about supply chain privacy?**
+A: Aqua chains contain only hashes by default, not business-sensitive data. Share chains selectively with authorized parties. Use tree method for selective disclosure of specific fields to certain stakeholders.
+
+**Q: How do we handle lost or damaged products?**
+A: Add revision documenting loss or damage event with relevant details. The Aqua chain preserves the history up to that point, supporting insurance claims and investigations.
+
+**Q: What if blockchain networks fail?**
+A: Verification of existing chains works offline using cryptographic signatures. Only new witnessing requires blockchain access. Historical witnesses remain provable through blockchain transaction records.
+
+## See Also
+
+- [Document Verification](/use_cases/document-verification) - Apply similar techniques to documents
+- [Identity Attestation](/use_cases/identity-attestation) - Verify credentials and certifications
+- [Quick Start](/quick-start) - Get started with supply chain tracking
+- [Schema Reference](/schema_reference/introduction) - Technical specifications
diff --git a/versioned_docs/version-1.1.0/Implementations/__category__.json b/versioned_docs/version-1.1.0/Implementations/__category__.json
deleted file mode 100644
index f90f052a..00000000
--- a/versioned_docs/version-1.1.0/Implementations/__category__.json
+++ /dev/null
@@ -1,8 +0,0 @@
-{
- "label": "Implementation",
- "linkTitle": "Implementation",
- "position": 1,
- "link": {
- "type": "generated-index"
- }
-}
\ No newline at end of file
diff --git a/versioned_docs/version-1.1.0/Implementations/_index.md b/versioned_docs/version-1.1.0/Implementations/_index.md
deleted file mode 100644
index 3bbf41fd..00000000
--- a/versioned_docs/version-1.1.0/Implementations/_index.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-title: "Implementations"
-linkTitle: "Implementations"
-weight: 3
-description: >
- Details various software that is implementing the Aqua Protocol
----
-
diff --git a/versioned_docs/version-1.1.0/Implementations/reference-architecture.md b/versioned_docs/version-1.1.0/Implementations/reference-architecture.md
deleted file mode 100644
index aa22dd20..00000000
--- a/versioned_docs/version-1.1.0/Implementations/reference-architecture.md
+++ /dev/null
@@ -1,336 +0,0 @@
----
-title: "Reference Implementation"
-linkTitle: "Reference Implementation"
-weight: 1
-description: >
- Explains the technologies selected for the reference implementation and why we selected them.
----
-
-Implementation specific architecture documentation for the Aqua Data
-Vault 'Personal Knowledge Container (PKC)'. In this document you will
-find reasoning as to why certain components were chosen to build this
-prototype. We have not duplicated any vendor documentation. Please find
-the linked-list for the documentation of the components we use here:
-
-- [MetaMask](https://docs.metamask.io/guide/)
-- [Ethereum](https://ethereum.org/en/developers/docs/)
-- [Docker](https://docs.docker.com/)
-- [MediaWiki](https://www.mediawiki.org/wiki/Documentation)
-- [MediaWiki Extension: Aqua](https://github.com/inblockio/aqua-docs)
-- [MediaWiki Skin Tweeki](https://tweeki.kollabor.at/)
-- [Pelith Eauth Server](https://github.com/pelith/node-eauth-server)
-- [Nodejs](https://nodejs.org/en/docs/)
-- [GitHub](https://docs.github.com/en)
-- [Apache](https://httpd.apache.org/docs/)
-- [Nginx](https://nginx.org/en/docs/)
-- [Let's Encrypt](https://letsencrypt.org/docs/)
-
-All software components selected are open source licenses. They each
-have active developer communities behind them to secure future support
-and further development.
-
-## Wallets / Accounts
-
-Why do we use Ethereum Wallets / Accounts?
-
-An identity anchor needs to be a public, private key. This allows a
-public component which we can share (public key) and a private component
-which proves ownership over that public-key. Public keys are used in
-Ethereum as accounts to receive and send transactions. Therefore the
-Ethereum ecosystem has developed standards. These have evolved to a
-larger eco-system involving wallet-providers which have built software
-and hardware wallets to securely manage those keys. We leverage one of
-the most vibrant developer communities and utilize these wallets. In our
-case they are used mainly for offline-activities (Login, Signing) which
-do not require connectivity to the Ethereum blockchain.
-
-## Web-Application (Chrome-Extension MetaMask)
-
-Was selected as it is one of the most advanced, widely used,
-feature-rich web-wallets. Most importantly it's a browser-plugin which
-allows us to interact with browser applications. MetaMask also has the
-ability to connect to a hardware wallet allowing for increased security
-and levels of assurance.
-
-- Large User-Base 10 Million +
-
-
-
-- Hardware Wallet Support (E.g. Ledger)
- - Large User-base 5 Million +
-
-
-
-- All related source code is open source, lot's of money behind it
- (future proof)
-- SSI (Self-sovereign identity): Compatible with the DID schema
- did:ethr:``
-- Fulfills SSI principles:
- - Controlled by user, allows for creation of new accounts / wallet
- addresses
- - User can create new identity anchor independent of third party
- - Can be moved between devices by users recovery key or even to a
- hardware wallet (not recommended but possible:
- https://kryptonitelex.medium.com/how-to-transfer-your-metamask-to-a-ledger-hardware-wallet-bcece7d5567b)
-
-## Witness Network
-
-We are using the Ethereum Network as an optional Witness Network for
-cryptographic time-stamping.
-
-### Why public Blockchain?
-
-The witness event serves the purpose of being able to prove the
-existence of a document without the ability to deny it. This requires
-censorship resistance and global coverage. The security of the network,
-it's distribution, and the high economical price to attack the network,
-are all good reasons why we want to use a public blockchain to publish
-highly obfuscated hashes (fingerprints). This proves the state of the
-data in a Data Vault (PKC).
-
-The MetaMask wallet is able to publish the witness event verification
-hash to the public Ethereum blockchain. This completes our third
-important layer of integrity verification, which is to prove
-cryptographic time and existence of a document by writing it's
-fingerprint onto the ledger. This is not done directly, but through a
-process which highly obfuscates the hash. This ensures that that there
-is no plausible attack (even if the attacker owns a powerful quantum
-computer) to match the fingerprint with any personal data.
-
-## Data Vault
-
-The Data Vault named 'Personal Knowledge Container' is creatd by using a
-tool for containerization called 'Docker'. This allows us to package our
-application so it can be deployed to different operating system
-environments. Docker provides the abstraction / virtualization layer.
-
-Inside Docker we containerized multiple services:
-
-## MediaWiki for data governance
-
-MediaWiki is a data governance tool which has a legacy as a
-collaboration tool. It powers Wikipedia, the largest encyclopedia in the
-world. We step into this experience, and the benefits of a feature rich,
-battle-proven application. It's a powerful tool to both manage and
-present data.
-
-As MediaWiki has an active and established developer community, it is
-possible to tap into existing professional service companies. Supporting
-development and any required changes within the application.
-
-MediaWiki has been modified to use workflows for data processing. This
-will allow for implementing and testing workflows and business logic
-between Personal-Knowledge-Containers.
-
-We use all the benefits of MediaWiki to manage and present data in the
-browser, while we work around one of its main limitations: Security.
-MediaWiki was never developed to have advanced security and permission
-structures, as it was built for Wikipedia - a fully public website. This
-has several implications for us.
-
-Security Practices:
-
-- We assume that we can't defend against insider attacks on the same
- MediaWiki instance, therefore every user has their own instance
-- If there is a need for a collaboration space, it is possible to
- spawn containers for multiple accounts which trust each other to
- work together on shared data
-
-
-
-- If you use a hosted PKC instance, assume the provider has access to
- your data as we don't use homomorphic encryption nor do we have
- encryption implemented
-- We are using typed and tested PHP (for MediaWiki Extension Data
- Accounting) to improve test coverage to increase stability and
- security of our application
-
-
-
-- To securely exchange data between PKC's, we implement a separate
- security software called Guardian. The Guardian protects the PKC and
- manages all access according to the accounts owners set permissions.
- The Guardian is under active development. It will receive the
- highest scrutiny and attention to ensure a minimal attack surface
- while allowing trust between Guardians so data can be exchanged.
-
-
-
-- The Apache WebServer present in the MediaWiki container has a
- technological dependency and needs regular updates as Apache was
- effected by critical security issues like
- [CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228)
-- Therefore we do not expose the Apache web-server to the internet by
- default and do not recommend this to ensure that there is no
- unnecessary attack surface. If an organization decides to expose the
- web-surface of a PKC to the internet, they should expect this
- instance to be compromised and leak all it's stored data. Therefore
- we re-emphasize: If PKC / MediaWiki is exposed to the web, there
- can't be any guarantee that data can be kept private. Therefore
- assume your data can be leaked on a web-facing MediaWiki instance.
- Organizations hosting PKC's for collaboration should do so with
- restricted firewall permissions, ensuring that the web-interface is
- only reachable for the employees authorized to see the content.
-
-## MediaWiki Extension: Aqua
-
-The existing ecosystem and reference implementations around MediaWiki
-allowed us to quickly prototype our reference implementation for Aqua.
-The implementation itself allowed us to further develop the protocol.
-The downsides are currently old PHP code and MediaWiki's legacy. In
-return we benefit from a well documented project.
-
-Looking forward we want to see other client-implementations in different
-languages independent of MediaWiki to show the potential of the Aqua
-Protocol. We hope to re-use part of the PHP code base to apply it to
-other applications, like Word-Press.
-
-## MediaWiki Skin Choice
-
-Using Tweeki as a Bootstrap 4 compatible Skin for MediaWiki, we were
-able to establish contact with the chief maintainer of the extension,
-and were able to collaborate to solve various issues to improve the
-skin. We are coordinating with other parties to see how we can improve
-support for the Skin. In the future we are hoping to increase the
-maintainer base. Prospectively we want to use Tweeki as an abstraction
-layer from MediaWiki classic to Bootstrap 4, and respectively Bootstrap
-5+.
-
-## Authentication
-
-- For Authentication with Web-Wallets, we use
- [https://github.com/pelith/node-eauth-server](https://github.com/pelith/node-eauth-server) which provides us with
- an open source solution for a signature-response challenge. We then
- integrate with OAUTH2 and OIDC using existing authentication
- standards to achieve the login.
-- The Pelith server provides us with the Signature-Challenge and is
- forwarding the access token via OAUTH2 to MediaWiki. Here we check
- if the user exists. If this is the case, access is granted.
-
-## WebServer-Proxy / HTTPs
-
-- We are using NGINX Web-Server as the proxy server. NGINX is a modern
- and the most popular (#1 since 2021 by share[^1]) web-server on the
- web.
-- We are using Let's Encrypt to provide secure connections via HTTPS
- if a PKC is deployed to the web. Let's encrypt serves over 260
- million websites according to the vendor website.[^2] provides free
- TLS Certificates for secure HTTPS connections.
-- The NGINX Web-Proxy allows us to ensure that we can add additional
- services to the PKC and redirect the services according to our
- needs.
-
-## Software-Development
-
-- We use [https://github.com](https://github.com) for software development. As we started
- with very little budget, we gratefully utilised free resources to
- develop our open source software. This allowed us to focus on being
- productive.
- - Github is owned by Microsoft and is therefore subject to US
- policies and Microsofts interests.
- - This itself requires us to move away to be independent or at
- least host a mirror instance outside of Github. The deletion of
- a repository or losing access could harm our development process
- significantly.
-- We use GPL-V3 license on the majority of our repositories.
- - We maintain the rights on branding
- - We maintain more restrictive rights on deployment scripts
- (service provider technologies)
-
-## Browser Choice
-
-We are using the Chrome-Engine as our Web-Browser of choice. It's the
-most dominant web-browser on the Web, and has become the quasi standard
-with many different forks creating an ecosystem around it.
-Microsoft-Edge is actually Chrome. There are non-google chrome forks
-which deserve attention, funding and support (like
-[https://github.com/Eloston/ungoogled-chromium](https://github.com/Eloston/ungoogled-chromium)). This will provide us
-with a modern and state of the art browser architecture to work with.
-
-As Chrome is the most secure and modern base to build on, we support
--only- chrome. Therefore we use a chrome extension to verify the content
-of an Aqua file. This extension is available for download in the Google
-Chrome App Store, or can be built from scratch following the
-instructions in our repository.[^3]
-
-This allows us to provide ease of setup, as users can easily deploy the
-chrome extension without further effort by adding it from the google app
-store.
-
-We are using NPM / node.js for fast prototyping. This comes with severe
-security implications as the npm ecosystem has been prone to various
-supply-chain attacks over recent months [^4] .
-
-## Technology choices on cryptography
-
-All cryptography used in our development is based on international NIST
-standards and follows the international understanding for internet
-security. This is consistent with the perspective of the BSI in Germany,
-but for some specific details there are no insights provided by the
-ministry.
-
-### Hashing Algorithms (SHA3-512)
-
-PKC uses standard Crypto (SHA3-512) winner of the National Institute of
-Standards and Technology see
-[https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf) . We do not
-use custom encryption as this comes at the cost of unnecessary risks.
-
-This is an accepted secure and recommended standard according to [BSI -
-Technische Richtlinie – Kryptographische Algorithmen und Schlussellängen
-Seite
-42](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.pdf?__blob=publicationFile).
-
-### Merkle Tree[^5]
-
-- We use merkle trees to be able to witness the state of all pages /
- files in a single hash. Used to generate a unique fingerprint of a
- domain (a collection of verified data hash chain's within one
- domain).
-- There is a lot of future potential in ongoing research to improve
- privacy and utility of merkle trees in the [Aqua
- Protocol](https://pkc.inblock.io/index.php/Aqua_Protocol)
- - See related technologies and research like TAPROOT:
- [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki)
-
-### Public-Private-Key Signatures (secp256k1)
-
-Used in combination with Ethereum Accounts. It is used for signing and
-authentication challenges.
-
-- in ether.js
- [cryptography/secp256k1](https://github.com/ethereumjs/ethereumjs-monorepo/blob/ade4233ddffffdd146b386de701762196a8c941c/packages/util/src/signature.ts#L23-L45)
- see
- [implementation](https://github.com/ethereum/js-ethereum-cryptography/blob/b1f35053df3f0cfa132fc45d59b688ca0d62994a/src/secp256k1-compat.ts#L99-L123)
-- related documents of the 'Standards for Efficient Cryptography
- Group' [https://secg.org](https://secg.org) specific doc secp256k1 [Both variants
- of the same standardization process of the Standards for Efficient
- Cryptography Group 2015, See differences
- P9](https://www.secg.org/sec2-v2.pdf)
-
-
-
-- Supported by BSI secp256r1 but secp256k1 is not
- mentioned.https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03116/BSI-TR-03116-4.pdf?__blob=publicationFile&v=7
- Request for clarification was send via E-Mail on the 3rd of November
- 2021 by Tim Bansemer. Answer of the BSI: Currently the BSI has no
- assessment or recommendation for secp256k1.
-
-
-
-- For authentication with Metamask Ethereum wallets we currently use
- [https://github.com/pelith/node-eauth-server](https://github.com/pelith/node-eauth-server). We are signing a
- unique input value with ethereum.js using the personal sign method.
- Once the challenge is completed successfully we receive an OAUTH
- token from the Eauth identity provider of the pelith Eauth server.
-
-1. [NGINX: Most Popular Web Server](https://linuxiac.com/nginx-most-popular-web-server/)
-
-2. [Let's Encrypt](https://letsencrypt.org/)
-
-3. [Aqua Verify Page Chrome Extension - GitHub](https://github.com/inblockio/aqua-verifypage-chrome-extension)
-
-4. [NPM Supply Chain Attack](https://duckduckgo.com/?q=npm+supply+chain+attack&ia=software)
-
-5. [Merkle Tree - Wikipedia](https://en.wikipedia.org/wiki/Merkle_tree)
-
diff --git a/versioned_docs/version-1.1.0/Protocol/__category__.json b/versioned_docs/version-1.1.0/Protocol/__category__.json
deleted file mode 100644
index 0435bf70..00000000
--- a/versioned_docs/version-1.1.0/Protocol/__category__.json
+++ /dev/null
@@ -1,9 +0,0 @@
-{
- "label": "Protocol",
- "linkTitle": "Protocol",
- "position": 2,
- "sidebar_position": 2,
- "link": {
- "type": "generated-index"
- }
-}
\ No newline at end of file
diff --git a/versioned_docs/version-1.1.0/Protocol/_index.md b/versioned_docs/version-1.1.0/Protocol/_index.md
deleted file mode 100644
index e65a65e5..00000000
--- a/versioned_docs/version-1.1.0/Protocol/_index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: "Protocol"
-linkTitle: "Protocol"
-weight: 2
-description: >
- Low level reference documentation of the AQUA Protocol
----
-
-This section of documentation gets into specific details about the AQUA Protocol
-and is meant for those doing an implementation or contributing to the Protocol
-itself.
diff --git a/versioned_docs/version-1.1.0/Protocol/aqua-identity-protocol.md b/versioned_docs/version-1.1.0/Protocol/aqua-identity-protocol.md
deleted file mode 100644
index 59165a22..00000000
--- a/versioned_docs/version-1.1.0/Protocol/aqua-identity-protocol.md
+++ /dev/null
@@ -1,446 +0,0 @@
----
-title: "Identity Protocol"
-linkTitle: "Identity Protocol"
-weight: 2
-sidebar_position: 2
-description: >
- The following text has the goal to highlight the possibility to build identity protocol functionality on top of the core verifiction protocol.
- This part of the project is in early stages and not mature.
----
-
-The Aqua Identity Protocol (AIP) is an experimental application protocol
-under development for Self Sovereign Identity's (SSIs) on top of the
-Aqua Protocol. This is an active field of research which is related to
-the work of the Decentralized-Identity-Foundation (DIF)[^1] and the
-World-Wide-Web-Consortium[^2]. As this is under active development,
-anything you see is experimental and subject to change. The goal is to
-provide a Self-Sovereign-Digital Identity Protocol to protect individual
-rights, freedom and the opportunity for the individual to participate in
-the digital economy.
-
-We are building on the advancements and insights for rebooting the
-web-of-trust initiative[^3] and the definition of a
-Self-Sovereign-Identity provided by Christopher Allen in shortened form here.[^4]
-
-### Self-Sovereign-Identity-Principles
-
-1. **Existence:** users must have an independent existence.
-2. **Control:** users must control their identities.
-3. **Access:** users must have access to their own data.
-4. **Transparency:** Systems and algorithms must be transparent.
-5. **Persistence:** Identities must be long-lived.
-6. **Portability:** Information and services about identity must be transportable.
-7. **Interoperability:** Identities should be as widely usable as possible.
-8. **Consent:** users must agree to the use of their identity.
-9. **Minimization:** Disclosure of claims must be minimized.
-10. **Protection:** The rights of users must be protected.
-
-
-Those 10 stated principles are implemented within the Aqua Protocol and
-it's existing reference implementation in various degrees. They are also
-represented in the [Design Principles](design-principles.md).
-
-
-# Architecture
-
-For the Aqua Identity Protocol to be implemented in accordance with the
-above statements, SSI-Principles and critical component choices from
-outside the protocol need to be made, and required tools need to be
-provided. **Data Vault**'s will provide a space which is fully account
-controlled. Other architectural decisions enabling SSI can be found in
-the reference implementation PKC Architecture Documentation.
-
-### Usage of **Data Vaults** to protect identity claims
-
-Pages with the namespace ``: must be 'read and write able' by
-`` only by default. This is to protect the personal-identifiable
-data of the user. This data should be stored in a place where only the
-account owner has access to. This can be achieved by having the data
-stored locally on a machine the account owner has, or by using
-cryptography which requires the account's owner explicit interaction to
-decrypt it. The content should not be decrypted on the server, but
-within the web-browser or client-application to ensure that a
-potentially compromised service-provider can't leak the sensitive
-information.
-
-- Identity claims are **encrypted by default** and can only be
- decrypted by the account owner or other accounts explicitly given
- permission to do so.
-- Identity claims **must** be given access by the account owner to
- e.g. let somebody else sign them.
-
-Note: There should be an extra effort by any **Data Vault**
-implementation to protect identity claims. It is recommended to strongly
-regulate and audit the emerging solutions to ensure a high level of
-protection for citizens.
-
-### Self Issued Identity Claims
-
-These are used to make statements about an account to form an identity. Those
-claims can be partially revealed on demand to other parties. Those
-claims can also be protected by advancements in privacy technologies
-like Zero-Knowledge-Proofs and ongoing advancements in key management.
-
-Identity claims are sets of [Verified
-Data](https://pkc.inblock.io/index.php/Verified_Data) which follow a
-structured data convention to claim or attest attributes to an account.
-For example, an attribute could be the year of birth of an account
-owner, or the legal name of an account owner. Claims should always be
-atomic to allow the account owner to disclose them selectivity.
-Different claims can be combined to represent a citizen ID or a
-drivers-license. Other claims can be educational certificates, like
-school certificates.
-
-Identity claims in the [Aqua Identity
-Protocol](https://pkc.inblock.io/index.php/Aqua_Identity_Protocol) are
-**always self issues**. This means that the first signature on the claim
-needs to be from the private key which belongs to the account, i.e. the claim
-is issued for. This proves account ownership. This means:
-
-- All claims can only be issued from the account which they make a
- claim about. A claim belongs to it's origin account and can only be
- managed from it's address.
-- A claim can 'accumulate trust' by being signed by other accounts who
- support this claim.
-- Self-issuance protects accounts against spam, and the issuance of
- fraudulent claims to an account without the knowledge of the account
- owner.
-
-##### **Claim Attestation**
-
-Can be completed by a Trust Authority referring to the Identity Claim in
-collaboration with the account owner, or a referencing statement.
-
-It is possible **to attest to a claim** by referencing the claim's
-unique revision_verification hash within the attestation. This means you
-can make statements about an account or about a claim without involving
-the account owner in that process. An attestation contains a statement
-about the referenced data set, and is expected to be signed by the
-account who makes the attestation. This ensures there is clear account
-attribution. Attestations without signature should be disregarded, as
-they have no account attribution.
-
----
-
-## **Specification for the Aqua Identity Protocol**
-
-Policies for Self-Issued-Identity-Claims:
-
-- Syntax of Title: ``:``
-- Example:
- [0xa2026582b94feb9124231fbf7b052c39218954c2:Birthdate](https://pkc.inblock.io/index.php/0xa2026582b94feb9124231fbf7b052c39218954c2:Birthdate)
-
-The title is not protected against changes, but the content of the page
-is protected.**IMPORTANT:** Therefore, we **must** compare the page
-stored **``,``**. Then reassemble the title to check if
-they are consistent before proceeding with further validation of the
-identity claim.
-
-Content of the page
-
-- **Account:** ``
- - Is repeated to reassemble the title to check it.
-- **Attribute:** ``
- - Is repeated to reassemble the title to check it.
-- **Value:** Is the value of the claim. E.g. '1889' for a year of
- birth.
- - The first revision **must** be signed by the account owner to
- create a self-issued identity claim
- - Values **must** not change within a hash-chain. If a value
- changes, the claim will be marked as invalid with the revision
- of the change. If a new attribute value needs to be defined for
- an account, this is done through a new claim.
-
------
-
-**Claim issuance Process**
-
-1. Claim is created (based on template)
-2. Claim is signed by issuer (first revision)
-3. Claim is registered by issuer (optional, done via Claim Registry)
-4. Claim is verified by authority to accumulate trust (this might
- include the requirement to hold a revocation authority on a claim
- registered via a Claim Registry)
-
-Trust-Chains with Identity Claims
-
-Will build a web of trust, which can be applicable not only for public
-institutions, but also for commercial organizations and private
-entities.
-
-### A trust chain of identity claims for educational certificates (example)
-
-1. The certificate is issued as integrity verified data via the Aqua
- Protocol.
-2. The recipient of the certificate registers the certificate as an
- identity claim
-3. The certificate is signed after it was issued as an identity claim
- by a Trust Authority (e.g. the university professor) and the
- university director's office (director)
-4. The university professor holds trust claims from the university
- director
-5. The university director holds trust claims by the ministry of
- education
-6. The educational ministry of education holds trust claims by the
- minister-president
-7. The minister-president holds trust claims of a verified election
-
-The chain of trust is supplied by the party signing the statement.
-
-*IMPORTANT: **The authority who is given authority needs to prove
-where their authority originated** **when they act in the function of
-that authority.***
-
-1. E.g. the professor needs to supply the claim of the university
- entitling him
-2. E.g. the university director needs to supply the claim of the
- educational ministry
-3. E.g. the educational ministry needs to supply the claim of the
- minister-president.
-4. ... and so on.
-
-# Verification Process
-
-1. Claim is presented
-2. Claim integrity is validated
- 1. How can you trust the content of a claim: Claim content needs to
- be static. E.g. a given-name claim 'Jarred Maxim' cannot change,
- even if there are many revisions to the page. If the static
- content HAS changed, the claim is INVALID or at least only valid
- until the point where it changed. In the case of such an
- information change, a new claim needs to be issued.
-3. Claim registry is validated (root trust)
-4. Claim signatures are validated
- 1. Comparison between signature time and validity of the signing
- authority. Is the account authority still valid?
- 2. lookup of authority claims from expected root trust?
-
-### Trust in Signatures
-
-If somebody signs an identity claim, we believe they do that to
-
-1. Vouch with their account for the integrity of the presented data.
- This can be supported via an Authoritative Claim and a comment which
- gets attached to the claim itself or is issued via an Attestation.
-2. To verify the signature, we use an automated verification process.
- This is done through implementations of an Aqua-Verifier like
- [https://github.com/inblockio/aqua-verifier-js](https://github.com/inblockio/aqua-verifier-js) or
- [https://github.com/inblockio/aqua-VerifyPage-chrome-extension](https://github.com/inblockio/aqua-verifypage-chrome-extension)
- which also checks against the restrictions given by the Aqua
- Identity Protocol or/and additional defined policies.
-3. Add access rights to a claim by adding a Data Usage Agreement which
- is enforced by the Guardian. Access rights can be restricted:
- 1. to specific accounts
- 2. to specific domain id's representing an instance of a Data Vault
-4. Verification: The verification process considers which account it
- signed, and what was stated with the signature, or with the
- additional data added to the claim. To consider a claim valid, the
- relationship between the verifying party and the Trust Authority who
- signed it, is essential. Can the party be trusted? Why do I trust
- this party?
- 1. Claims can be either chained (cascaded into each other) and
- offline verified, and/or online verified against an existing
- Claim-Registry. In both cases a known trusted party account
- reference point is required for the verifying party to trust.
-
-#### **Trust Authorities**
-
-are accounts which have an elevated trusted position. They issue
-[Authoritative Trust
-Claims](https://pkc.inblock.io/index.php/Authoritative_Claim) to give
-legitimacy to a self-issued identity claim.
-
-Why do you trust a professor to issue an [Educational
-Certificate](https://pkc.inblock.io/index.php/Educational_Certificate)?
-
-Because the professor is able to provide a trust chain, represented by a
-chained [Authoritative Trust
-Claim](https://pkc.inblock.io/index.php/Authoritative_Claim), proving
-that he has authority to attest an [Educational
-Certificate](https://pkc.inblock.io/index.php/Educational_Certificate)
-with his signature. With his signature, he is increasing the trust of
-the self-issued [Identity
-Claim](https://pkc.inblock.io/index.php/Identity_Claim) to allow it to
-have practical utility.
-
-### **Claim Registries**
-
-A claim registry in the context of the Aqua Identity Protocol is a
-global registry to allow for real-time global claim revocation and
-re-instantiation of Identity Claim's. This solves the problems related
-and known to certificate revocation. The Claim Registry acts like a
-global Claim Revocation List (CRL)[^5].
-
-E.g. a driver's license can be revoked by a Trust Authority and later be
-re-instantiated after the 'Punishment for driving too fast' is over.
-Identity claims are either valid or invalid. The Claim Registry is
-managing who can revoke / re-instantiate a registered claim.
-
-There is ongoing research and optimizations on privacy concerns to
-reduce costs for on-chain Identity Claim.
-
-Implementation in Ethereum with Smart-Contracts (Solidity). All claims
-are account bound.
-
-**Claim Registration Specification - Smart Contract Structure**
-
-- **``** as root trust of the self-issued
- identity claim. A claim has to be a verified page, which is signed
- and timestamped. If all are present, the next page-verification hash
- entangles all of those properties and becomes the 'address' of the
- claim. In the receipt of the publish process for the claim, there is
- an attached receipt, and by writing the receipt into the claim,
- there is also a new revision generated. This creates the second
- revision of the claim, which entangles the signature and the witness
- event with the hash-chain to make them immutable.
-- **``** \[type:boolean\] of claim
- - 0 - valid
- - 1 - revoked
-
-
-
-- **``** \[type: date DDMMYYYY\]: if current date past
- expiration date, the claim is considered expired and is not accepted
- anymore
-- **``** \[type:address\] an account which
- updates the status of the claim, e.g. revocation or suspension of an
- account
-- **``** \[type:address\] list of
- accounts which are authorized to update status of the claim other
- than the owner. The owner has a special right to update the list of
- revocation authorities to hold new addresses.
----
-
- EXAMPLE: Claim Registration Data \[Receipt\]
-
-The presence of Claim Registration Data \[Receipt\] means that the claim
-address (verification hash) has been written to a Claim Registry on a
-Witness Network.
-
-Protocol: Aqua Identity Protocol Version 1.0
-
-Registration Event: 1
-
-- Domain ID: e9ece84189
-- Claim address (verification hash of self-signed claim):
- 1db331add502cf1b1712468d1c3e5d66a0016a6f04885c5533619ffbb43fffb6dfa452e119d4bee7628e9792af69089d38d860a5f8d0708184bbb74b8cabdaf7
-- ``
- - Merkle Root:
- 7e9782fb8a6e749ef2ba48f8cd410b05335ba48b20ba42508efeb76add38b0f39e717e91381c8de34641af4c477c39fc169eaa0908dba25e0a54e8de615fcd00
- - Claim Snapshot Verification Hash:
- 278f930a35d06d7b9d28aab37d402c147d1beffdbe53d212481c17ec686698e9469f9cf7d7d53b9a4435c4b99ca2e578b5dc5fec6c63cb802b540493fe927575
-- Witness Network: goerli
-- Claim Registry Smart Contract Address:
- 0x45f59310ADD88E6d23ca58A0Fa7A55BEE6d2a611
-- Transaction Hash:
- 0xa572e8d6ef8d4a1bb3b5087680817e70bb79a0376c3a9be9e2c6b4d92df228a1
- Sender Account Address: 0xa2026582b94feb9124231fbf7b052c39218954c2
- ___
-
-#### **Claim Revocation**
-
-**Traditional** **revocation:**
-
-- Traditional strategies for certificate revocation can be
- applied.[^6]
-- Most effective are short expiration dates where possible, due to the
- lack of effective revocation processes for certificates without
- global registries.
-
-**Using Distributed Ledgers**
-
-- Done via [Claim
- Registry](https://pkc.inblock.io/index.php/Claim_Registry)
- (indicates the global status of an identity claim to be either valid
- or invalid)
-
-**Process:**
-
-- Locally completed (within the Self-Issued Identity Claim) by
- changing the status to 'revoked' and signing by the issuer. This
- adds a receipt to the identity claim, which is displayed when
- verifying the claim. This includes the revocation transaction for
- the revocation on the
- [Identity-Registry](https://pkc.inblock.io/index.php/Identity-Registry)
-- If there is a new claim which is succeeding the previous identity
- claim[Claim
- Registry](https://pkc.inblock.io/index.php/Claim_Registry), then
- this is also noticed within the revocation receipt under
- 'Successor-Claim: ``.
-
-Bulk Claim Registration (Should be part of Claim Registry)
-
-- To reduce costs during registration of the identity claims via a
- [Claim Registry](https://pkc.inblock.io/index.php/Claim_Registry)
- they can be clustered and registered together
-- We use the
- [SmartContract:Identity-Registry](https://pkc.inblock.io/index.php/SmartContract:Identity-Registry)
- for this. To scale our efforts we utilize a variant of the
- 'Domain-Manifest-Generator / Publisher' which is very similar. The
- differences are in the selection of what can be published, and the
- data structure which is published to the Claim Registry instead of
- the witness smart contract.
-- The Claim Snapshot Generator can only include ID claims of your own
- `` namespace.
-- The Claim Snapshot Publisher is registering all selected claims
- (select them by page name (filter required) and will populate the
- target
- [SmartContract:Identity-Registry](https://pkc.inblock.io/index.php/SmartContract:Identity-Registry).
- Every claim will hold the relative merkle-proof to show the path for
- it's registration.
-
-Examples for **Identity Claims with Aqua:**
-
-- [Example Identity Documents with PKC and Data
- Accounting](https://pkc.inblock.io/index.php/User:0xa2026582b94feb9124231fbf7b052c39218954c2)
-- Reference:Example Identity Documents (Research)
-
-# FAQ
-
-1. How to find [Claim
- Registry](https://pkc.inblock.io/index.php/Claim_Registry)'s? By
- following the chain of trust of authoritative claims and validating
- them one by one.
-2. How to check if authority is still valid and how to find an
- authority registry? As before, by reading the chain of trust and
- looking up the status of the related identity claims.
-3. How to visually check authority dependencies? It is possible to
- visualize the links of links of links to represent the chain of
- trust.
-
-Important References:
-
-- [Basic intro into
- DID](https://www.youtube.com/watch?v=gWfAIYXcyH4&ab_channel=Okta)
-- [Basic intro into
- DIDComm](https://www.youtube.com/watch?v=8c7yRTENqSc&ab_channel=DecentralizedIdentityFoundation)
-- [W3C Verified Data
- Model](https://www.w3.org/TR/vc-data-model/#claims)
-- [Revocation List 2020](https://w3c-ccg.github.io/vc-status-rl-2020/)
- A privacy-preserving mechanism for revoking Verifiable Credentials
-- [DIDCOMM implementations and
- use-cases](https://github.com/decentralized-identity/didcomm-messaging)
-- [DIDkit](https://github.com/spruceid/didkit)
-
-Thought leader Christopher Allen:
-
-- [Self-Sovereign-Identity-Principles](https://github.com/WebOfTrustInfo/self-sovereign-identity/blob/master/self-sovereign-identity-principles.md)
-- [A bitcoin based SSI infrastructure
- prototype](https://github.com/BlockchainCommons/Gordian)
-
-### References
-
-See Implementation Specific Aqua Identity Protocol Implementation in MWe
-
-1. [Identity Foundation](https://identity.foundation/)
-
-2. [W3C (World Wide Web Consortium)](https://www.w3.org/)
-
-3. [Web of Trust](https://www.weboftrust.info/)
-
-4. [Self-Sovereign Identity Principles - GitHub](https://github.com/WebOfTrustInfo/self-sovereign-identity/blob/master/self-sovereign-identity-principles.md)
-
-5. [Certificate Revocation (CRL) Explained - SecureW2](https://www.securew2.com/blog/certificate-revocation-crl-explained)
-
-6. [PKI Certificate Revocation Process Explained - TechNet](https://social.technet.microsoft.com/wiki/contents/articles/34071.pki-certificate-revocation-process-explained.aspx)
-
diff --git a/versioned_docs/version-1.1.0/Protocol/aqua-name-resolution.md b/versioned_docs/version-1.1.0/Protocol/aqua-name-resolution.md
deleted file mode 100644
index ed161077..00000000
--- a/versioned_docs/version-1.1.0/Protocol/aqua-name-resolution.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-title: "Name Resolution"
-linkTitle: "Name Resolution"
-weight: 3
-sidebar_position: 3
-description: >
- ANS is used to hashes of various types to human readable names
----
-
-Aqua Name Resolution (ANS) is used to resolve hashes of various types to human readable names.
-
-The following hashes are resolved by the ANS:
-* wallet-addresses to names, organisations an aliases.
-* genesis_hashes to titles.
-* domain_ids to registered endpoints of that domain.
-
-See the [reference implementation](https://github.com/inblockio/aqua-verifier-webextension/blob/main/src/name_resolver.ts).
diff --git a/versioned_docs/version-1.1.0/Protocol/assurance-levels-aal.md b/versioned_docs/version-1.1.0/Protocol/assurance-levels-aal.md
deleted file mode 100644
index d7873531..00000000
--- a/versioned_docs/version-1.1.0/Protocol/assurance-levels-aal.md
+++ /dev/null
@@ -1,52 +0,0 @@
----
-title: "Assurance Levels (AAL)"
-linkTitle: "Assurance Levels"
-weight: 4
-sidebar_position: 4
-description: >
- Highlights the levels of assurances you can receive by using technology provided in the Aqua reference implementation.
----
-
-How safe are the wallets to used? - Current PKC Pilot - relating to the
-'Authentication assurance level's (AAL)' according to the World Bank
-standards:
-
-See short presentation [Aqua_PKC_-_Wallet-Security.pdf](https://github.com/inblockio/aqua-docs/files/7885411/Aqua_PKC_-_Wallet-Security.pdf)
-
-### Level 1
-
-The Metamask wallet alone has a low (level 1 ) level of assurance.
-MetaMask is the most common browser blockchain wallet applications on
-the web and their developer teams strive for increased security to keep
-crypto-assets of their 10 Million+ Users safe.
-
-### Level 2
-
-Metamask offers integration with Hardware-Wallets which raises the level
-of assurance by having at least 2 authentication factors (e.g., a token
-with a password or PIN) to min. level 2. The Hardware-Tokens are build
-to be temper proof.
-
-### Level 3
-
-- It is possible to integrate the different layers of security at once
-
-with Metamask (Password Protection) a hardware-token (temper proof) with
-PIN a one-time-password generator based on your mobile-phone
-(recommended is a hardened mobile phone which also uses biometrics for
-highest security) requires implementation of one-time-password
-authentication for logins after wallet-authentication see
-[https://github.com/inblockio/micro-PKC/issues/37](https://github.com/inblockio/micro-PKC/issues/37)
-
-- Other high security options allow multi-signature logins with
- smart-contracts requiring multiple parties to confirm the operation
- to be executed. This can be defined based on the smart contract to
- extreme security as each of the layers mentioned above can be added
- to each party being involved in the multi-signature event to open a
- PKC or to SIGN a verified page within the PKC or to witness a data
- set via a witness network.
-
-- The mentioned security model is not dependent on the security of
- Metamask. If Metamask is hacked it will not allow to compromise the
- model above as the security of the private key of the hardware token
- is preserved.
diff --git a/versioned_docs/version-1.2.0/Components/__category__.json b/versioned_docs/version-1.2.0/Components/__category__.json
deleted file mode 100644
index 60637293..00000000
--- a/versioned_docs/version-1.2.0/Components/__category__.json
+++ /dev/null
@@ -1,7 +0,0 @@
-{
- "label": "Components",
- "position": 3,
- "link": {
- "type": "generated-index"
- }
- }
\ No newline at end of file
diff --git a/versioned_docs/version-1.2.0/Components/containers/__category__.json b/versioned_docs/version-1.2.0/Components/containers/__category__.json
deleted file mode 100644
index f0f3957a..00000000
--- a/versioned_docs/version-1.2.0/Components/containers/__category__.json
+++ /dev/null
@@ -1,6 +0,0 @@
-{
- "label": "Containers",
- "link": {
- "type": "generated-index"
- }
- }
\ No newline at end of file
diff --git a/versioned_docs/version-1.2.0/Components/containers/aquafier.md b/versioned_docs/version-1.2.0/Components/containers/aquafier.md
deleted file mode 100644
index ea4ac97a..00000000
--- a/versioned_docs/version-1.2.0/Components/containers/aquafier.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-title: Aqua Container Rust "Aquafier"
----
-
-## Aquafier
-Aqua container is a rust with a react front ent project that implments the aqua protocol.It enables data to be signed , witnessed and verified.
-The projects shows the capability of the aqua protocol to ensure data integrity.
-
-### technical details
-- This project has an axum web server in rust.
-- The web folder conatins a react js(typescript) frontend to interact with the back end.
-- diesel is used as an ormwith sqlite backend
-- HTTP protocol is used for interaction between the front end and the back end.
-- files have a maximum size of 20 mb
-- docker container is provided to help you quickly deploy the docker container.
diff --git a/versioned_docs/version-1.2.0/Components/containers/media-wiki.md b/versioned_docs/version-1.2.0/Components/containers/media-wiki.md
deleted file mode 100644
index d4c54aa7..00000000
--- a/versioned_docs/version-1.2.0/Components/containers/media-wiki.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-title: "Personal Knowledge Container"
----
-
-The personal knowldge container is/was a prototype implementation of the aqua protocol v1.1.
-To learn more about pkc check version 1.1 docs.
\ No newline at end of file
diff --git a/versioned_docs/version-1.2.0/Components/intro.md b/versioned_docs/version-1.2.0/Components/intro.md
deleted file mode 100644
index 25b16b4f..00000000
--- a/versioned_docs/version-1.2.0/Components/intro.md
+++ /dev/null
@@ -1,48 +0,0 @@
----
-title: "Introduction"
-sidebar_position: 1
----
-
-
-### 1. Aqua cli
-Aqua cli is a command line utility.That enables you to create aqua chains, verify aqua chains, witness and sign aqua chains.
-There are two command line utilities.
-
-A rust implmentation [here](https://github.com/inblockio/aqua-verifier-rs)
-A javascript implmentation [here](https://github.com/inblockio/aqua-verifier-js)
-
-
-🤔 You would ask why have two :
- which generates filename.aqua.json
-
- Options:
- --sign [cli|metamask|did]
- Sign with either of:
- 1. the Ethereum seed phrase provided in mnemonic.txt
- 2. MetaMask
- 3. DID key
- --witness-eth Witness to Ethereum on-chain with MetaMask
- --witness-nostr Witness to Nostr network
- --witness-tsa Witness to TSA DigiCert
- --link
- Add a link to an AQUA chain as a dependency
-
- ```
- 1. `./verify.js --help`
-
- ```
- Usage:
- verify.js [OPTIONS]
- or
- verify.js [OPTIONS] --file
-
- Options:
- -v Verbose
- --server
- --ignore-merkle-proof Ignore verifying the witness merkle proof of each revision
- --file (If present) The file to read from for the data
- If the --server is not specified, it defaults to http://localhost:9352
- ```
\ No newline at end of file
diff --git a/versioned_docs/version-1.2.0/Components/verifier/aqua-cli-rust.md b/versioned_docs/version-1.2.0/Components/verifier/aqua-cli-rust.md
deleted file mode 100644
index bea080ac..00000000
--- a/versioned_docs/version-1.2.0/Components/verifier/aqua-cli-rust.md
+++ /dev/null
@@ -1,72 +0,0 @@
----
-title: Aqua CLI Rust Implementation
----
-
-Aqua cli is a command line utility.That enables you to create aqua chains, verify aqua chains, witness and sign aqua chains.
-
-Just like other aqua tooling and libraries cli 1.2 tooling the cli versioning matches the protocol supported.
-
-
-🚀 How to install it.
-1. `cargo install aqua-cli`
-2. building from source
- a. `git clone git@github.com:inblockio/aqua-cli-rs.git`
- b. `cargo build--release`
- c. `cd target/release/ && cp aqua-cli /usr/bin`
-
-
-💡 the repo location
-`https://github.com:inblockio/aqua-cli-rs`
-
-
-📝 Usage
-```
-Aqua CLI TOOL
-
-========================================================
-
-This tool validates files using a aqua protocol. It can:
- • Verify aqua chain json file
- • Generate aqua chain.
- • Generate validation reports
-
-COMMANDS:
- • -a or --authenticate to verify an aqua json file.
- • -s or --sign to sign an aqua json file.
- • -w or --witness to witness an aqua json file.
- • -f or --file to generate an aqua json file.
- • -v or --verbose to provide logs about the process when using -v,-s,-w or -f command (verbose option).
- • -o or --output to save the output to a file (json, html or pdf).
- • -l or --level define how strict the validation should be 1 or 2
- 1: Strict validation (does look up, if local wallet mnemonic fails it panic)
- 2: Standard validation (create a new mnemonic if one in keys.json faile)
- • -h or --help to show usage, about aqua-cli.
- • -i or --info to show the cli version.
- • -k or --key-file to specify the file containings (this can also be set in the env )
- • -d or --delete remove revision from an aqua json file, bydefault removes last revsion but can be used with -c or --count parameter to specifiy the number of revisions
- • -c or --count to specify the number of revisions to remove (note a genesis revision cannot be removed)
-
-EXAMPLES:
- aqua-cli -a chain.json
- aqua-cli -s chain.json --output report.json
- aqua-cli -w chain.json --output report.json
-
- aqua-cli -f document.pdf
- aqua-cli --file image.png --verbose
- aqua-cli -f document.json --output report.json
-
-
-SUMMARY
- * aquq-cli expects ateast parameter -s,-v,-w or -f.
- * in your environment set the
- 1. aqua_domain="random_alphanumeric"
- 2. aqua_network="sepolia" or "holesky" or "mainnet"
- 3. verification_platform="alchemy" or "infura" or "none" for witnessing (default "none")
- 4. aqua_alchemy_look_up= false or true
-
-For more information, visit: https://github.com/inblockio/aqua-verifier-cli"
-
-```
-
-
-
diff --git a/versioned_docs/version-1.2.0/Components/verifier/verifier.md b/versioned_docs/version-1.2.0/Components/verifier/verifier.md
deleted file mode 100644
index 5ac904df..00000000
--- a/versioned_docs/version-1.2.0/Components/verifier/verifier.md
+++ /dev/null
@@ -1,4 +0,0 @@
----
-title: "Verifier"
-sidebar_position: 1
----
\ No newline at end of file
diff --git a/versioned_docs/version-1.2.0/Components/verifier/webextension.md b/versioned_docs/version-1.2.0/Components/verifier/webextension.md
deleted file mode 100644
index 96ad8578..00000000
--- a/versioned_docs/version-1.2.0/Components/verifier/webextension.md
+++ /dev/null
@@ -1,5 +0,0 @@
----
-title: Aqua Verifier Webextension
----
-
-
\ No newline at end of file
diff --git a/versioned_docs/version-1.2.0/contribution-guidelines.md b/versioned_docs/version-1.2.0/contribution-guidelines.md
deleted file mode 100644
index 99ae04b8..00000000
--- a/versioned_docs/version-1.2.0/contribution-guidelines.md
+++ /dev/null
@@ -1,144 +0,0 @@
----
-title: "Contribution Guidelines"
-linkTitle: "Contribution"
-weight: 20
-menu:
- main:
- weight: 20
----
-
-### Contribution Guide for Rust and JavaScript/TypeScript Aqua Projects
- =
- | { success: true; value: T }
- | { success: false; error: E };
-
- function divide(a: number, b: number): Result {
- if (b === 0) {
- return {
- success: false,
- error: new Error('Division by zero')
- };
- }
- return {
- success: true,
- value: a / b
- };
- }
- ```
-5. **Performance Considerations**
- - Use `const` by default or `let`
- - Use `Map` and `Set` for efficient key-value and unique collections
- - Avoid unnecessary object creation
-
-6. Documentation
- - Use JSDoc or TypeDoc for documentation
- - Include type information in documentation
- - Provide examples in documentation comments
- ```typescript
-
- /**
- * Calculates the area of a rectangle
- * @param width - The width of the rectangle
- * @param height - The height of the rectangle
- * @returns The calculated area
- * @example
- * const area = calculateArea(5, 10);
- * console.log(area); // 50
- */
- function calculateArea(width: number, height: number): number {
- return width * height;
- }
-
- ```
-
\ No newline at end of file
diff --git a/versioned_docs/version-1.2.0/getting-started.md b/versioned_docs/version-1.2.0/getting-started.md
deleted file mode 100644
index 9d4f72e5..00000000
--- a/versioned_docs/version-1.2.0/getting-started.md
+++ /dev/null
@@ -1,70 +0,0 @@
----
-title: "Getting Started"
-sidebar_position: 2
----
-
-## Data Structure:
-This are the basics to get you started but for a thorough understanding one done with the sections below have a look at references section to get a thorough understanding for example what is a witness, wtness network and how are witness hash created.
-
-The aqua chain structure can be broken into a the following components :
-
-
-### Revision
-
-A revision is the smallest portable entity within the AQP. Multiple revisions
-form a single portable hash chain which is serialized in JSON format.
-They have existed before in unsecured systems where multiple revisions form a
-file which can be displayed as a page. The AQP adds the cryptographic harness
-to secure it. With presenting a portable hash chain, it is possible to track
-all incremental changes stored in each revision to understand the history of a
-page and how it came to be. This allows us to have version control on digital
-assets being able to restore earlier states and to relate to them. This allows
-us to have historical evidence of digital assets.
-}'
-```
-
-
----
-
-## Aqua Revisions with Signatures
-
-Aqua tracks changes and signatures in a revision tree. Below is an example of a fully signed cheque:
-
-```json
-{
- "revisions": {
- "0xd453ccae56945ce381f1adb57feef37ba77e215604fe078faa2d9527159c9c76": {
- "previous_verification_hash": "",
- "local_timestamp": "20250306172550",
- "revision_type": "form",
- "file_hash": "dd056a2c7c877716e2fd9f4f1aecfff05da6aae0158c0aa60775afa88cc1daf3",
- "forms_sender": "0xbdc64c49bf736cfe1b8233b083d3d632f26feb27",
- "forms_receiver": "",
- "forms_amount": "0.3",
- "forms_currency": "ETH",
- "version": "https://aqua-protocol.org/docs/v3/schema_2 | SHA256 | Method: tree"
- },
- "0x1ea148be50e98f45996353a8b2b1eb5b8e379c2bc02c18fe875e6c52bd1ccd08": {
- "previous_verification_hash": "0xd453ccae56945ce381f1adb57feef37ba77e215604fe078faa2d9527159c9c76",
- "revision_type": "signature",
- "signature": "0xd3984892d212c2613fbbea69ed669449e378f5d085326c6e2770f69e5420408515a1975a9308e058f8d33dee700b8018e372b622e8ea12934ebc0b1c1e9832f21b",
- "signature_wallet_address": "0xbdc64c49bf736cfe1b8233b083d3d632f26feb27",
- "signature_type": "ethereum:eip-191"
- },
- "0x6548c5d222c4c4382e430aff84432896ce64e5c1fb465c907a4a91a927ce4a9c": {
- "previous_verification_hash": "",
- "revision_type": "form",
- "file_hash": "00bf727b9503eeb95283eb315595a4340aae9db9abc15e77caab0a27ebb62f93",
- "forms_sender": "0xbdc64c49bf736cfe1b8233b083d3d632f26feb27",
- "forms_receiver": "0x4a79b0d4b8feda7af5902da2d15d73a7e5fdefd4",
- "forms_amount": "0.3",
- "forms_currency": "ETH"
- },
- "0x9c234109372fe09e1193f9637536eb555cfbe7803cdf17067dfad0d76fc52a86": {
- "previous_verification_hash": "0x6548c5d222c4c4382e430aff84432896ce64e5c1fb465c907a4a91a927ce4a9c",
- "revision_type": "signature",
- "signature": "0xabdacd337ae491914b6f2afb2e53249709983c3c98c54c66fcf07fed186a5fb751a6b29e1444bec134695ee01da8fc12b56d71b89df7801c49ce67f2068cc30d1b",
- "signature_wallet_address": "0x4a79b0d4b8feda7af5902da2d15d73a7e5fdefd4",
- "signature_type": "ethereum:eip-191"
- }
- },
- "tree": {
- "hash": "0x9c234109372fe09e1193f9637536eb555cfbe7803cdf17067dfad0d76fc52a86",
- "children": []
- }
-}
-```
-
-### Verification Rules
-- **`forms_sender`**, **`forms_amount`**, and **`forms_currency`** must match between revisions.
-- Only **`forms_receiver`** can differ (updated by the receiver).
-- Signatures must validate against the respective wallet addresses.
-
----
-
-## Additional Milestones (Aqua-Dev-Team)
-
-1. [ ] **Aqua Library**: Integrate the Rust-based Aqua API for offline verification (see [aqua-cheques](https://github.com/inblockio/aqua-cheques)).
-2. [ ] **WAVs Setup**: Deploy a WAVs instance or use an existing one. Ensure it can:
- - Accept JSON submissions.
- - Run Aqua verification.
- - Trigger the smart contract.
-3. [ ] **Smart Contract**: Deploy an escrow contract with:
- - Whitelisting for sender addresses.
- - Locking cheque amoung with revision hash and amount for possible revocation
- - A `cashout` function triggered by WAVs.
diff --git a/versioned_docs/version-1.3.2/RestAPI.md b/versioned_docs/version-1.3.2/RestAPI.md
deleted file mode 100644
index 1014ca5d..00000000
--- a/versioned_docs/version-1.3.2/RestAPI.md
+++ /dev/null
@@ -1,349 +0,0 @@
----
-title: "Rest API"
-menu:
- main:
- weight: 10
----
-
-## REST API Specification for Aqua-Protocol Version 3
-
-REST APIs are used to interact with the Aqua-Protocol in Client-Server applications.
-This includes data syncing and exchange operations between different aqua-services.
-Early versions of this API where prototypes within the PKC-Guardian project.
-
-## Base URL
-/aqua/v3/
-
-
-## Authentication
-- **Requirement**: All endpoints except `/session` (POST) require a `Bearer` JWT in the `Authorization` header.
-- **JWT Details**: Issued via SIWE-OIDC, tied to the user’s Ethereum wallet address (secp256k1-derived), configurable lifespan (default: 1 hour).
-
-## Endpoints
-
-### 1. Get Aqua Tree Latest
-- **Method**: `GET`
-- **Path**: `/trees/{genesisHash}/latest`
-- **Description**: Retrieves all latest revision hashes across all branches of the tree starting from the genesis hash.
-- **Query Params**:
- - `includeMetadata` (boolean, default: `false`): Include full revision details.
-- **Response** (minimal):
- ```json
- {
- "latest": [
- "0x4d8f16e234aee6738325cb4e4bee0a4ae83e251614bbf1620961e3af9f702554",
- "0xsomeotherhash..."
- ]
- }
-```
-
-## Authentication
-- **Requirement**: All endpoints except `/session` (POST) require a `Bearer` JWT in the `Authorization` header.
-- **JWT Details**: Issued via SIWE-OIDC, tied to the user’s Ethereum wallet address (secp256k1-derived), configurable lifespan (default: 1 hour).
-
-### 1. Get Aqua Tree Latest
-- **Method**: `GET`
-- **Path**: `/trees/:revisionHash/latest`
-- **Description**: Retrieves all latest revision hashes across all branches of the tree starting from the genesis hash.
-- **Query Params**:
- - `includeMetadata` (boolean, default: `false`): Include full revision details.
-- **Response** (minimal):
-
- ```json
- {
- "latest": [
- "0x4d8f16e234aee6738325cb4e4bee0a4ae83e251614bbf1620961e3af9f702554",
- "0xsomeotherhash..."
- ]
- }
-```
-Response (with includeMetadata=true):
- ```json
-{
- "latest": [
- {
- "verification_hash": "0x4d8f16e234aee6738325cb4e4bee0a4ae83e251614bbf1620961e3af9f702554",
- "revision_type": "link",
- "local_timestamp": "20250223204717",
- "previous_verification_hash": "0xc828a5579c69923a66db6b06e6e47c31dc08ccc8f8340d8e2b190683dc76de21"
- }
- ]
-}
-```
-Status Codes:
-- `200`: Success
-- `404`: Genesis hash not found
-- `401`: Unauthorized
-
-## Get Aqua Tree Branch
-- **Method**: `GET`
-- **Path**: `/trees/:revisionHash/branch`
-- **Description**: Retrieves the branch from the specified hash back to the genesis hash (backward traversal only).
-- **Query Params**:
- - `page` (int, optional, default: `1`): Pagination page.
- - `limit` (int, optional, default: `100`): Revisions per page.
-- **Response**:
- ```json
- {
- "branch": [
- {
- "verification_hash": "0x4d8f16e234aee6738325cb4e4bee0a4ae83e251614bbf1620961e3af9f702554",
- "revision_type": "link",
- "local_timestamp": "20250223204717",
- "previous_verification_hash": "0xc828a5579c69923a66db6b06e6e47c31dc08ccc8f8340d8e2b190683dc76de21"
- },
- "..."
- ],
- "pagination": {
- "page": 1,
- "limit": 100,
- "total": 4
- }
- }
-```
-```
-
-- **Notes**: `pagination` omitted if not used (no `page` or `limit` provided).
-- **Status Codes**:
- - `200`: Success
- - `404`: Branch hash not found
- - `401`: Unauthorized
-
-## Get Aqua Tree Revision
-- **Method**: `GET`
-- **Path**: `/trees/:revisionHash`
-- **Description**: Retrieves details of a specific revision.
-- **Response**:
- ```json
- {
- "verification_hash": "0x97b36fbde14bfddaa639c7d3b8416d44781ccc1092e536e01c4a7dbd0c90eff9",
- "previous_verification_hash": "",
- "local_timestamp": "20250218190616",
- "revision_type": "file",
- "file_hash": "a7bf1f3efdfaad71b28125b91c1403cba0eaf6db2c8dff9a438d13754de5b468",
- "file_nonce": "ztqu4gByEgd0WKGgakpwMoK2WhieZ-WE0ztzQhCWJ2Y"
- }
- ```
-
-- **Status Codes**:
- - `200`: Success
- - `404`: Revision not found
- - `401`: Unauthorized
-
-## Post New Tree Revision
-- **Method**: `POST`
-- **Path**: `/trees`
-- **Description**: Creates a new revision, validated against `aqua-verifier-js-lib` verifier.
-- **Request Body** (example for `signature` type):
-
- ```json
- {
- "previous_verification_hash": "0x6c64a40493862be542a0c6eb016df21d4c1c6c11208ecc0013d0c209679bc962",
- "revision_type": "signature",
- "signature": "0x6fbf1437d6532e97edc08b7b1e7c09ed21103abc1b6d324550585fbf85e8bfb858e570f4cc35432da45b76aec1d933c7a5870ecba3e06fa29cf510f2cfa0165f1c",
- "signature_public_key": "0x0219b2dee3f0691f26ce35104b7411d379e15dc62ae8d3a0797b7257e87e7a5821",
- "signature_wallet_address": "0x011d801fd833eb98109aaca1923f7652cf16db7f",
- "signature_type": "ethereum:eip-191"
- }
- ```
-
-- **Response**:
- ```json
- {
- "verification_hash": "0xc828a5579c69923a66db6b06e6e47c31dc08ccc8f8340d8e2b190683dc76de21",
- "local_timestamp": "20250223210000"
- }
- ```
-
-- **Validation**: Rejects if:
- - `previous_verification_hash` doesn’t exist.
- - Revision type or fields are invalid/malformed (per `aqua-verifier-js-lib`).
-- **Status Codes**:
- - `201`: Created
- - `400`: Invalid/malformed revision (with error details if `error_mode=verbose`)
- - `404`: Previous hash not found
- - `401`: Unauthorized
-
-## Verify Aqua Tree
-- **Method**: `POST`
-- **Path**: `/verify`
-- **Description**: Delegates verification to `aqua-verifier-js-lib`, returns a detailed report.
-- **Request Body**:
- ```json
- {
- "revisions": {
- "0x97b36fbde14bfddaa639c7d3b8416d44781ccc1092e536e01c4a7dbd0c90eff9": {
- "previous_verification_hash": "",
- "local_timestamp": "20250218190616",
- "revision_type": "file",
- "file_hash": "a7bf1f3efdfaad71b28125b91c1403cba0eaf6db2c8dff9a438d13754de5b468",
- "file_nonce": "ztqu4gByEgd0WKGgakpwMoK2WhieZ-WE0ztzQhCWJ2Y"
- }
- }
- }
- ```
-
-- **Response**:
- ```json
- {
- "report": {
- "0x97b36fbde14bfddaa639c7d3b8416d44781ccc1092e536e01c4a7dbd0c90eff9": {
- "status": "valid",
- "details": "Verification passed per aqua-verifier-js-lib"
- }
- }
- }
- ```
-
-- **Status Codes**:
- - `200`: Success
- - `400`: Malformed input
- - `401`: Unauthorized
-
-## Session Handling
-
-### Login
-- **Method**: `POST`
-- **Path**: `/session`
-- **Request Body** (SIWE-OIDC):
- ```json
- {
- "message": "example.com wants you to sign in with your Ethereum account...",
- "signature": "0x..."
- }
- ```
-
-- **Response**:
- ```json
- {
- "token": "jwt...",
- "expires_at": "20250223214400",
- "wallet_address": "0x011d801fd833eb98109aaca1923f7652cf16db7f"
- }
- ```
-
-- **Status Codes**:
- - `201`: Session created
- - `400`: Invalid SIWE message/signature
-
-### Logout
-- **Method**: `DELETE`
-- **Path**: `/session`
-- **Response**: `204 No Content`
-- **Status Codes**:
- - `204`: Success
- - `401`: Unauthorized
-
-### Session Info
-- **Method**: `GET`
-- **Path**: `/session`
-- **Response**:
- ```json
- {
- "wallet_address": "0x011d801fd833eb98109aaca1923f7652cf16db7f",
- "expires_at": "20250223214400"
- }
- ```
-
-- **Status Codes**:
- - `200`: Success
- - `401`: Unauthorized
-
-## Configuration (JSON)
-```json
-{
- "session": {
- "jwt_lifespan": 3600
- },
- "rate_limit": {
- "requests_per_minute": 600
- },
- "error_mode": "verbose",
- "key_filter": {
- "mode": "whitelist",
- "keys": ["0x011d801fd833eb98109aaca1923f7652cf16db7f"]
- }
-}
-```
-
-- **Notes**:
- - `error_mode`: `"minimal"` (HTTP status only) or `"verbose"` (detailed messages).
- - `key_filter`: `"all"`, `"blacklist"`, or `"whitelist"` for Ethereum wallet addresses.
-
-## Error Handling Examples
-
-### Minimal Mode
-- `400 Bad Request` (no body)
-
-### Verbose Mode
-- **Invalid Revision**:
- ```json
- {
- "error": "Invalid revision",
- "details": "Missing 'signature' field for revision_type 'signature'"
- }
- ```
-
-## Get File Object
-Scalability: Use HTTP range requests (via Range header) to support partial downloads, enabling clients to resume transfers or fetch chunks of large files.
-Integrity: Return the file’s hash in the response headers (e.g., Content-MD5 or a custom header like X-File-Hash) so clients can verify the file matches the requested hash.
-Efficiency: Stream the file content to handle large sizes without loading everything into memory.
-
-- **Method**: `GET`
-- **Path**: `/files/:fileHash`
-- **Description**: Retrieves the file object associated with the specified file hash. Supports large files via streaming and partial content delivery.
-- **Query Params**:
- - None required; optional params like `download` (boolean) could be added later for forcing downloads vs. inline display.
-- **Headers**:
- - `Range` (optional): Specifies byte range (e.g., `bytes=0-1048575` for first 1MB). Supports partial content retrieval per RFC 7233.
-- **Response**:
- - **Status**: `200 OK` (full file) or `206 Partial Content` (range request)
- - **Headers**:
- - `Content-Type`: MIME type of the file (e.g., `application/octet-stream` if unknown).
- - `Content-Length`: Size of the returned content in bytes.
- - `X-File-Hash`: The file’s hash (e.g., `a7bf1f3efdfaad71b28125b91c1403cba0eaf6db2c8dff9a438d13754de5b468`) for client-side verification.
- - `Accept-Ranges`: `bytes` (indicates range requests are supported).
- - `Content-Range` (if `206`): Byte range delivered (e.g., `bytes 0-1048575/5242880`).
- - **Body**: The file content, streamed as a binary response.
-- **Example Response** (full file):
- - **Status**: `200 OK`
- - **Headers**:
- ```
- Content-Type: application/pdf
- Content-Length: 5242880
- X-File-Hash: a7bf1f3efdfaad71b28125b91c1403cba0eaf6db2c8dff9a438d13754de5b468
- Accept-Ranges: bytes
- ```
- - **Body**: [binary file content]
-- **Example Response** (partial file):
- - **Request Header**: `Range: bytes=0-1048575`
- - **Status**: `206 Partial Content`
- - **Headers**:
- ```
- Content-Type: application/pdf
- Content-Length: 1048576
- X-File-Hash: a7bf1f3efdfaad71b28125b91c1403cba0eaf6db2c8dff9a438d13754de5b468
- Accept-Ranges: bytes
- Content-Range: bytes 0-1048575/5242880
- ```
- - **Body**: [first 1MB of binary file content]
-- **Status Codes**:
- - `200`: Success (full file delivered)
- - `206`: Partial Content (range request fulfilled)
- - `404`: File hash not found
- - `401`: Unauthorized
- - `416`: Range Not Satisfiable (if requested range is invalid)
-- **Notes**:
- - Clients can verify integrity by comparing the `X-File-Hash` with the requested `fileHash`.
- - Large files are streamed to avoid memory overload; range support enables resumable downloads.
-
-Explanation
-- **Path**: /files/:fileHash keeps it intuitive and consistent with /trees/:revisionHash.
-- **Range Support**: Using the Range header and 206 Partial Content status allows clients to fetch large files in chunks, critical for scalability and reliability (e.g., resuming interrupted downloads).
-- **Integrity**: The X-File-Hash header echoes the file’s hash back, letting clients confirm the delivered content matches the request. This is lightweight and leverages standard HTTP practices.
-- **Streaming**: The response body is streamed, ensuring the server can handle large files without buffering everything in memory.
-
-
-## Open Todos for the API
-- Add support for file deletion
-- add support for revision deletion
diff --git a/versioned_docs/version-1.3.2/VerifierTests.md b/versioned_docs/version-1.3.2/VerifierTests.md
deleted file mode 100644
index c3090c5d..00000000
--- a/versioned_docs/version-1.3.2/VerifierTests.md
+++ /dev/null
@@ -1,77 +0,0 @@
----
-title: "Verifier Tests"
----
-
-## Overview
-The Aqua verifier MUST validate revisions per the schema defined at [https://aqua-protocol.org/docs/v3/schema_2](https://aqua-protocol.org/docs/v3/schema_2). This document specifies required tests for implementations to ensure compliance with the Aqua protocol, as introduced at [/docs/v3/intro](/docs/v3/intro). Tests are divided into Revision Verification and Relational Verification domains. Implementations MUST pass all tests to be considered conformant.
-
-## Prerequisites
-- **Schema**: Implementations MUST conform to [https://aqua-protocol.org/docs/v3/schema_2](https://aqua-protocol.org/docs/v3/schema_2).
-- **Tools**: Implementations MAY use any framework supporting SHA256 hashing and Ethereum EIP-191 (using the secp256k1 curve) signature validation. Implementations MAY support additional hashing algorithms (e.g., SHA3-512) or signature schemes (e.g., secp256r1) only if specified in an updated schema and supported by new, defined `signature_type` or `witness_network` values.
-
-## Revision Verification Tests
-These tests ensure each revision object in `revisions` is independently valid. Types MUST adhere to the schema at [https://aqua-protocol.org/docs/v3/schema_2](https://aqua-protocol.org/docs/v3/schema_2).
-
-- **RV-01: Version Compliance**
- - The `version` field MUST be one of the following exact strings:
- - `"https://aqua-protocol.org/docs/schema/v1.3.2 | SHA256 | Method: scalar"`
- - `"https://aqua-protocol.org/docs/schema/v1.3.2 | SHA256 | Method: tree"`
- - Implementations MUST reject any other value.
-
-- **RV-02: Required Fields**
- - Every revision MUST include `previous_verification_hash`, `local_timestamp`, `revision_type`, and `version`.
- - Implementations MUST reject revisions missing these fields or containing empty strings for `local_timestamp`, `revision_type`, or `version`.
- - `local_timestamp` MUST be in YYYYMMDDHHMMSS format and MUST represent a valid UTC time after 2020-01-01 00:00:00.
-
-- **RV-03: File Revision Integrity**
- - A `revision_type` of `"file"` MUST include `file_hash` and `file_nonce`.
- - The `file_hash` MUST equal the SHA256 hash of either:
- - The referenced file content concatenated with `file_nonce`, OR
- - The OPTIONAL `content` field (serialized file data) concatenated with `file_nonce`, if present.
- - Implementations MUST reject revisions where `file_hash` does not match either computation.
-
-- **RV-04: Signature Verification | Signature Type: ethereum:eip-191**
- - A `revision_type` of `"signature"` MUST include `signature`, `signature_public_key`, and `signature_wallet_address`.
- - The `signature` MUST validate against `previous_verification_hash` using `signature_public_key` per `signature_type` `"ethereum:eip-191"` (secp256k1 curve).
- - Implementations MUST reject invalid signatures.
-
-- **RV-05: Witness Verification | Witness (Ethereum)**
- - A `revision_type` of `"witness"` MUST include `witness_network`, `witness_address`, and `witness_smart_contract_address`.
- - `witness_network` MUST be one of: `"mainnet"`, `"sepolia"`, `"nostr"`, or `"TSA_RFC3161"`. Other values MUST be rejected.
- - `witness_merkle_root`, if present, MUST be the valid Merkle root hash derived from `witness_merkle_proof`.
- - `witness_smart_contract_address` MUST be a valid Ethereum contract address for the specified `witness_network`, capable of storing and retrieving verification hashes.
- - `witness_transaction_hash`, if present, MUST be a valid transaction hash for the specified `witness_network`.
- - `witness_sender_account_address`, if present, MUST be a valid account address for the specified `witness_network`.
- - `witness_merkle_proof`, if present, MUST be a valid Merkle proof including `previous_verification_hash` as a leaf.
- - Implementations MUST reject witness revisions failing these checks.
-
-- **RV-06: Signature Type Restriction**
- - `signature_type` MUST be one of: `"ethereum:eip-191"` or `"did_key"` for signature revisions. Other values MUST be rejected.
-
-- **RV-07: Witness Type Restriction**
- - `witness_network` MUST be one of: `"mainnet"`, `"sepolia"`, `"nostr"`, or `"TSA_RFC3161"` for witness revisions. Other values MUST be rejected.
-
-- **RV-08: Indexed Content Verification**
- - Each key in `file_index` MUST be a valid `file_hash` from a revision with `revision_type` `"file"`.
- - Implementations MUST reject `file_index` entries referencing invalid or nonexistent `file_hash` values.
-
-## Relational Verification Tests
-These tests ensure consistency across `revisions`, `file_index`, `tree`, and `treeMapping`. Types MUST be strict per [https://aqua-protocol.org/docs/v3/schema_2](https://aqua-protocol.org/docs/v3/schema_2).
-
-- **RL-01: Previous Hash Linking**
- - `previous_verification_hash` MUST match a valid revision key in the pool of all verified revisions or be empty for the first (genesis) revision.
- - Implementations MUST reject invalid or nonexistent references.
-
-- **RL-02: Type: Link Revision**
- - A revision referenced by revision type `link` MUST exist and be valid in the pool of all verified revisions.
- - Implementations MUST reject links to invalid or missing revisions and throw an revision not found error.
-
-- **RL-03: Loop Detection**
- - Implementations MUST have a loop detection mechanism.
-
-- **RL-04: Fork Detection**
- - Implementations MUST have a fork detection mechanism to output deterministic results.
-
-- **RL-05: Timestamp Order**
- - Implementations MUST have a timestamp plausibility check accross revisions for local timestamps
- - Implementations MUST have a timestamp plausibility check for cryptographic timestamps (Witness events)
diff --git a/versioned_docs/version-1.3.2/cli-tool.md b/versioned_docs/version-1.3.2/cli-tool.md
deleted file mode 100644
index 3b1a76e8..00000000
--- a/versioned_docs/version-1.3.2/cli-tool.md
+++ /dev/null
@@ -1,150 +0,0 @@
----
-sidebar_position: 8
----
-
-# AQUA CLI Tool
-
-The AQUA CLI tool (`aqua-js-cli`) is a command-line interface for interacting with the AQUA protocol. It provides functionality for notarizing, signing, witnessing, and verifying files in the AQUA system.
-
-## What is Notarization?
-
-Notarization in AQUA is the process of creating an immutable record of a file or document on the blockchain. When you notarize a file:
-- A unique hash of the file is generated
-- The hash is recorded on the blockchain
-- A proof of existence is created
-- The file's integrity can be verified at any time
-
-This process ensures that the document existed at a specific point in time and hasn't been modified since.
-
-## Getting Started
-
-### Clone the Repository
-
-```bash
-git clone https://github.com/inblockio/aqua-js-cli.git
-cd aqua-js-cli
-```
-
-## Requirements
-
-- Node.js 14.x+ (latest version recommended)
-- npm (Node Package Manager)
-
-## Installation
-
-1. Install dependencies:
-```bash
-npm install
-```
-
-2. Build the project:
-```bash
-npm run build
-```
-
-## Usage
-
-### 1. Notarizing, Signing, and Witnessing
-
-#### Basic Notarization
-```bash
-./notarize.js
-```
-
-#### Signing Files
-Sign files using different methods (cli, metamask, or did):
-```bash
-./notarize.js --sign [cli|metamask|did]
-```
-
-#### Witnessing Files
-Witness files using different methods (eth, nostr, or tsa):
-```bash
-./notarize.js [--witness eth|--witness nostr|--witness tsa]
-```
-
-#### Multiple Chain Witnessing
-Witness multiple AQUA chains:
-```bash
-./notarize.js FILE1,FILE2 --witness eth --vtree --type sepolia
-```
-
-Witness specific revisions:
-```bash
-./notarize.js FILE1@0x_revision_,FILE2@0x_revision_ --witness eth --type cli --vtree
-```
-
-### 2. Verification
-
-#### Basic Verification
-```bash
-./verify.js
-```
-
-#### Verification Options
-
-- Verbose output:
-```bash
-./verify.js .aqua.json -v
-```
-
-- Skip merkle proof verification (faster):
-```bash
-./verify.js .aqua.json --ignore-merkle-proof
-```
-
-### 3. Managing Revisions
-
-#### Delete Last Revision
-```bash
-./notarize.js --remove
-```
-
-#### Link AQUA Chains
-Link one AQUA chain to another:
-```bash
-./notarize.js --link
-```
-
-### 4. Content Management
-
-#### Generate Content Revision
-```bash
-./notarize.js --content
-```
-
-#### Generate Scalar Revision
-```bash
-./notarize.js --scalar
-```
-
-### 5. Forms Management
-
-#### Create Genesis Form
-```bash
-./notarize.js example-form.json --form example-form.json
-```
-Note: For genesis, the filename must match the form name.
-
-#### Create Form Revision
-```bash
-./notarize.js --form example-form.json
-```
-
-#### Update Forms
-
-Delete a form entry:
-```bash
-./form_updater.js example-form.json.aqua.json@ --delete
-```
-
-Update/restore a form entry:
-```bash
-./form_updater.js example-form.json.aqua.json --update
-```
-
-Form operations include:
-- File validation for .aqua.json files
-- Form key detection (exact and partial matches)
-- Handling deleted fields
-- Non-destructive updates preserving original structure
diff --git a/versioned_docs/version-1.3.2/intro.md b/versioned_docs/version-1.3.2/intro.md
deleted file mode 100644
index e9f22ec3..00000000
--- a/versioned_docs/version-1.3.2/intro.md
+++ /dev/null
@@ -1,34 +0,0 @@
----
-title: "Aqua Protocol Version 3"
----
-**Welcome to Aqua: A Cryptographic Trust Protocol for Decentralized Data Integrity**
-
-The Aqua Protocol is a foundational framework for building distributed trust networks. By leveraging hash-chains, cryptographic signatures, and Ethereum-based timestamping, Aqua enables scalable, trustless verification of data integrity and provenance without reliance on centralized authorities. It empowers developers and innovators to create applications that certify, attest, and secure data in an open, private and decentralized way.
-
-#### What Aqua Enables
-Aqua serves as a versatile building block for a wide range of applications, including:
-- **Data Accountability**: Track and verify the origin and history of data (data accounting).
-- **Access Control**: Enforce secure, automated access policies.
-- **Identity Claims and Attestations**: Certify identities and assertions without intermediaries.
-- **Notarization and Beyond**: Provide undeniable proof of data existence and authenticity.
-
-#### What’s Been Built (Prototypes)
-The potential of Aqua is being explored through practical implementations:
-- **Federated Wiki Infrastructure**: A notarized wiki system with built-in trust (PKC, https://github.com/inblockio/aqua-pkc, Protocol v1.2).
-- **Chrome Extension for Verification**: A tool for name resolution and AquaTree validation (Aqua Verifier, https://chromewebstore.google.com/detail/aqua-verifier/gadnjidhhadchnegnpadkibmjlgihiaj, Protocol v1.2).
-- **Firewall-Like Systems**: Automated access control enforcement integrated with Aqua ("Guardian," Protocol v1.2).
-- **Document Signing Service**: A platform for signing and verifying files ("Aquafier," https://aquafier.inblock.io, transitioning from v1.2 to v3).
-- **Decentralized Identity Solution**: A new approach to identity management (Aqua Identity, https://github.com/inblockio/aqua-identity).
-Please request a demo with us via demo@inblock.io.
-
-#### The Vision of Aqua
-Aqua is still evolving, and we’re discovering the full scope of this powerful protocol. Here’s how we see it:
-- **An Open Framework**: Enabling private, decentralized solutions for general data notarization.
-- **A Verifiable Data Structure**: Linking and certifying data with cryptographic precision.
-- **A Protocol for Provenance**: Ensuring clear attribution and integrity of data origins.
-- **A Foundation for Trust**: Powering distributed networks where trust is built-in, not assumed.
-
-#### How It Works
-At its core, Aqua creates portable hash-chains—called AquaTrees—that record a gapless history of data revisions. These trees can be timestamped on Ethereum for immutability, exchanged across services, and verified automatically. Whether securing documents, systems, or identities, Aqua liberates the certification process from institutional gatekeepers, making trust accessible through open cryptographic standards.
-
-We’re excited to see where this journey takes us—and invite you to explore, build, and contribute to the future of decentralized trust with Aqua Protocol Version 3.
diff --git a/versioned_docs/version-1.3.2/schema_2.md b/versioned_docs/version-1.3.2/schema_2.md
deleted file mode 100644
index b6b92ded..00000000
--- a/versioned_docs/version-1.3.2/schema_2.md
+++ /dev/null
@@ -1,349 +0,0 @@
----
-title: "Schema (v3.2)"
----
-
-The shema documentation below outlines the five types of revisions (`file`, `content`, `signature`, `witness`,`link` and `form`) and their respective properties.
-
-This schema defines a structure for atomic revisions of aqua secured files.
-Each revision is uniquely identified by a hash and contains metadata specific to its type.
-
-## Revisions
-
-The `revision` is identified by a unique hash which is also used to verify the integrity of the revision.
-It acts as a globally unique identifier. Unique identifiers are used as unique references to link revisions together or to perform operations on them (transport, access control, etc.).
-
-There are four main types of revisions:
-
-1. **Content Revision**
-1.1 **Form Revision** (a special type of content revision for layer 2 applications)
-2. **Signature Revision**
-3. **Witness Revision**
-4. **Link Revision**
-
-All revision types share properties which are common forming a hash-chain. These are:
-- **`previous_verification_hash`**: (String) The hash of the previous revision in the chain. Empty for the first revision.
-- **`local_timestamp`**: (String) The UTC timestamp of the revision in `YYYYMMDDHHMMSS` format.
-- **`revision_type`**: (String) The type of revision.
-- **`version`**: (String) The schema version and hashing method used.
-
-In addition each revision type has specific properties outlined below.
-
-### Hashing Method
-The hashing method used is SHA256. The revision object sorts all key-values as 'Canonical JSON'
-this ensures no whitespaces, sorted keys, no floating-point ambiguity and unicode normalization.
-
-There are two hashing methods used:
-- **`Scalar`**: Is a simple hash of the stringified revision object. This is the default method for performance reasons.
-- **`Tree`**: Creates a merkle tree of all the values.
- This allows a more granular verification. This is used for e.g. selective disclosure.
-
-### Hash Security
-The system is designed to allow for the hash algorithm to be exchangable.
-Same applies to any other cryptographic cyphers being used (e.g. signatures) to ensure post-quantum security.
-Any type is modular, allowing for new subtypes to be introduced with different cyphers.
-
-### 1. Content Revision
-
-A **Content Revision** represents the initial or updated state of a file which is secured by the Aqua-Protocol. It includes metadata about the file: its hash and index.
-The index is a mutable part of the datastructure, it allows to update file location and the services which handels the file.
-
-#### Properties:
-- **`previous_verification_hash`**: (String) The hash of the previous revision in the chain. Empty for the first revision (genesis revision).
-- **`local_timestamp`**: (String) The UTC timestamp of the revision in `YYYYMMDDHHMMSS` format.
- Its a local timestamp of the server running the aqua-service. For cryptographically secured timestamps the witness revision is used.
-- **`revision_type`**: (String) The type of revision, always `"content"` for this type.
-- **`file_hash`**: (String) The hash of the file content.
-- **`file_nonce`**: (String) A unique nonce associated with the file.
- This is used to ensure that additional entropy is added to the hash to make it globallyunique.
-- **`version`**: (String) The schema version and hashing method used.
-
-#### Example File Revision:
-```json
-{
-"0xd9bc7c36e7b28c6d97c8389881b90e1df163b067b11c69139bf4f24498d5cf92": {
- "previous_verification_hash": "",
- "local_timestamp": "20250224154438",
- "revision_type": "file",
- "file_hash": "bd2e8e2a1b3c5d008e1d43ecb11105f42c5ad4e05922bab98981840b636c661e",
- "file_nonce": "65eddd0e16a995170dbef8feaf86a7928678426f20a309bb6627887915c04efb",
- "version": "https://https://https://aqua-protocol.org/docs/v3/schema_2 | SHA256 | Method: scalar"
-}
-```
-### File Revision
-
-A **File Revision** includes the file's content or reference, hash and nonce.
-
-#### Properties:
-- **`previous_verification_hash`**: (String) The hash of the previous revision in the chain.
-- **`local_timestamp`**: (String) The timestamp of the revision in `YYYYMMDDHHMMSS` format.
-- **`revision_type`**: (String) The type of revision, always `"file"` for this type.
-- **`content`**: (String) The content of the file.
-- **`file_hash`**: (String) The hash of the file content.
-- **`file_nonce`**: (String) A unique nonce associated with the file.
-- **`version`**: (String) The schema version and hashing method used.
-
-### 1.1 Form Revision
-
-Form revisions are a special type of content revision for layer 2 applications.
-They are used to create a form that can be signed by the user.
-
-Native Layer 2 applications are aqua identity and aqua access control.
-The tree verification structure allows for selective disclosure of the form data.
-
-Find detailled examples under the "Aqua Identity" and "Access Control" tabs.
-
-#### Example:
-```json
-"revisions": {
- "0xd9bc7c36e7b28c6d97c8389881b90e1df163b067b11c69139bf4f24498d5cf92": {
- "previous_verification_hash": "",
- "local_timestamp": "20250228211940",
- "revision_type": "form",
- "file_hash": "2a3b63fabff884365782f5457c68491852cf8f3cbf9a9ca4bfffb1da8f295407",
- "file_nonce": "9d68ebcc6b09d3c854c09efec4f872be85deabe436dbae3baa00d4a176b02167",
- "version": "https://aqua-protocol.org/docs/v3/schema_2 | SHA256 | Method: tree",
- "forms_type": "identity_claim",
- "forms_name": "John",
- "forms_surname": "Doe",
- "forms_email": "john.doe@example.com",
- "forms_date_of_birth": "1995-10-15",
- "forms_wallet_address": "0x1234567890abcdef",
- "leaves": [
- "1bea26961b7276cb64c432e67852ec2ce634c20c96192036f6da1fd8adfc9168",
- "ff0edef64dcdf6aafed912534f11d228a88ef6a3f9ef0e5dcd659a131e1a130b",
- "3b5abc4d1a21b05caa891be0650cf25cea133ddb939b1c45a8282bcab686545a",
- "dcb7cfdf2bae4a7e558e58dc9a26bc2627f35f2097c38b3e1493693ed3495239",
- "5122dde9b24bdd39f3eb20f64c18e6a960b6a3320c7cfb7707b8e7de581cc7f2",
- "28d88a09468f136c21475a121b53c626d1c29902a076b7e94c8a77aaa2a45b37",
- "15a1e4c78fa31877be47fa99afee32bd426d6bf74c5297f0d1d706b987c528bd",
- "15df50012dddb9f5b7157aa4dc227b3e1452c19232443ac2b388eeb07a94ec43",
- "74e6c3c9476b3547c42b157edd3a61571fef4b1b109c8a0170fd146008d639d3",
- "d781acf7ba880ecae581ffd8debcb4f5cb430bc2f237e27a6098471a9f7ffa60",
- "43fcaef3dc4b2a2d0550543b638048edcfb710da9276da109a9e011ed1a53ed1",
- "39ccd407bb105ed3be74df4a546d9b10c4f6c80e48b559102b04fa2b29aa83b4"
- ]
- }
-```
-
-### 2. Signature Revision
-
-A **Signature Revision** represents a digital signature applied to a file revision. It includes the signature, public key, and wallet address of the signer.
-
-#### Properties:
-- **`previous_verification_hash`**: (String) The hash of the previous revision in the chain.
-- **`local_timestamp`**: (String) The timestamp of the revision in `YYYYMMDDHHMMSS` format.
-- **`revision_type`**: (String) The type of revision, always `"signature"` for this type.
-- **`signature`**: (String) The digital signature.
-- **`signature_public_key`**: (String) The public key of the signer.
-- **`signature_wallet_address`**: (String) The wallet address of the signer.
-- **`signature_type`**: (String) The type of signature (e.g., `"ethereum:eip-191"`).
- This allows for different signature types to be added to Aqua Protocol.
-- **`version`**: (String) The schema version and hashing method used.
-
-#### Example:
-```json
-{
- "previous_verification_hash": "0xe2922c4c80060a035fa7ace36ed7d9e32aa901382b5651e9f68354bc1bc9edb4",
- "local_timestamp": "20250224154448",
- "revision_type": "signature",
- "signature": "0x799cd8177dc2c5dc34d389601175d550466a73509b71d533aaa3ff0ee958b3b31b574bdfd158a7ad0b186da5f5b440bc18453a6848bc659ccd6de06a09d6ea6e1b",
- "signature_public_key": "0x0380a77a1a6d59be5c10d7ee5e10def79283938bb8a60025d0fe5404e650e8ccc1",
- "signature_wallet_address": "0x568a94a8f0f3dc0b245b853bef572075c1df5c50",
- "signature_type": "ethereum:eip-191",
- "version": "https://aqua-protocol.org/docs/v3/schema_2 | SHA256 | Method: scalar"
-}
-```
-
-### 3. Witness Revision
-
-A **Witness Revision** represents a record of a witness event, such as a blockchain transaction. It includes metadata about the witness event, such as the transaction hash and network.
-
-#### Properties:
-- **`previous_verification_hash`**: (String) The hash of the previous revision in the chain.
-- **`local_timestamp`**: (String) The timestamp of the revision in `YYYYMMDDHHMMSS` format.
-- **`revision_type`**: (String) The type of revision, always `"witness"` for this type.
-- **`version`**: (String) The schema version and hashing method used.
-- **`witness_merkle_root`**: (String) The Merkle root of the witness event.
-- **`witness_timestamp`**: (Number) The timestamp of the witness event.
-- **`witness_network`**: (String) The network where the witness event occurred (e.g., `"sepolia"`).
-- **`witness_smart_contract_address`**: (String) The address of the smart contract involved.
-- **`witness_transaction_hash`**: (String) The hash of the transaction.
-- **`witness_sender_account_address`**: (String) The address of the sender's account.
-- **`witness_merkle_proof`**: (Array) An array of Merkle proofs.
-
-#### Example:
-```json
-{
- "previous_verification_hash": "0x115d8604f5c689602b7703ce5f4c1ba59a731c9c1a3798cbd2d205df1e772ebd",
- "local_timestamp": "20250224154506",
- "revision_type": "witness",
- "version": "https://aqua-protocol.org/docs/v3/schema_2 | SHA256 | Method: scalar",
- "witness_merkle_root": "0x115d8604f5c689602b7703ce5f4c1ba59a731c9c1a3798cbd2d205df1e772ebd",
- "witness_timestamp": 1740411910,
- "witness_network": "sepolia",
- "witness_smart_contract_address": "0x45f59310ADD88E6d23ca58A0Fa7A55BEE6d2a611",
- "witness_transaction_hash": "0xad007675d238746783d697ca8cbc0260f87275430d43ba08dea11d26a00e8850",
- "witness_sender_account_address": "0x568a94a8f0f3dc0b245b853bef572075c1df5c50",
- "witness_merkle_proof": [
- "0x115d8604f5c689602b7703ce5f4c1ba59a731c9c1a3798cbd2d205df1e772ebd"
- ]
-}
-```
-
-### 4. Link Revision
-
-A **Link Revision** represents a record of other revisions belonging to other or the same AquaTree structure. This serves two distinct purposes: 1) To be able to reference other AquaTree objects in a verifiable way. 2) To acknowledge forks within an AquaTree which could be removed without recognition without a link revision to "merge" those revisions into the continues hash-chain structure.
-
-
-#### Example Link Revision:
-```json
-{
-"0x4f714e6e5cbf6e6c4b820ca68b248d8afc4937ef173b0ccad5872ca6ad16d438": {
- "previous_verification_hash": "0x2438975974cfcf054c45046dd3c96a3531da4a2086ba762867c350abe7e2283c",
- "local_timestamp": "20250318210818",
- "revision_type": "link",
- "version": "https://aqua-protocol.org/docs/v3/schema_2 | SHA256 | Method: scalar",
- "link_type": "aqua",
- "link_verification_hashes": [
- "0x8227c0d94b5683cd6787690908e260cbb855b90fc77ae17f52852c667741b02c"
- ],
- "link_file_hashes": [
- "d8cbd265da90ac6bd3357c44de18557f66987ecb1e5bcb78346f4592d6d14c9b"
- ]
- }
-```
-
-## Other Metadata and its role
-
-### File Index
-
-The `file_index` object maps revision hashes to file names in a mutable form.
-This allows for files to be reorganised or to be associated with varios services.
-As the revision is immutable, it is required that this is external to the revision.
-
-#### Example:
-```json
-{
- "0xe2922c4c80060a035fa7ace36ed7d9e32aa901382b5651e9f68354bc1bc9edb4": "LICENSE"
-}
-```
-
-## Tree Structure
-
-The `tree` object represents the hierarchical structure of revisions. Each node contains a `hash` and an array of `children`.
-
-#### Example:
-```json
-{
- "hash": "0xe2922c4c80060a035fa7ace36ed7d9e32aa901382b5651e9f68354bc1bc9edb4",
- "children": [
- {
- "hash": "0x115d8604f5c689602b7703ce5f4c1ba59a731c9c1a3798cbd2d205df1e772ebd",
- "children": [
- {
- "hash": "0x121a8e95204fafdd18fb1ea1287c278693f48b28d88e341f86e3c336e9731eab",
- "children": [
- {
- "hash": "0x105356040bab31f82778a47bb24604bb966a6994b3f3fccc14e0b084f634bde3",
- "children": []
- }
- ]
- }
- ]
- }
- ]
-}
-```
-
-## Tree Mapping
-
-The `treeMapping` object provides paths to specific revisions and identifies the latest revision hash.
-
-#### Properties:
-- **`paths`**: (Object) Maps revision hashes to their paths in the tree.
-- **`latestHash`**: (String) The hash of the latest revision.
-
-#### Example:
-```json
-{
- "paths": {
- "0x105356040bab31f82778a47bb24604bb966a6994b3f3fccc14e0b084f634bde3": [
- "0xe2922c4c80060a035fa7ace36ed7d9e32aa901382b5651e9f68354bc1bc9edb4",
- "0x115d8604f5c689602b7703ce5f4c1ba59a731c9c1a3798cbd2d205df1e772ebd",
- "0x121a8e95204fafdd18fb1ea1287c278693f48b28d88e341f86e3c336e9731eab",
- "0x105356040bab31f82778a47bb24604bb966a6994b3f3fccc14e0b084f634bde3"
- ]
- },
- "latestHash": "0x105356040bab31f82778a47bb24604bb966a6994b3f3fccc14e0b084f634bde3"
-}
-```
-
-## Example
-
-Below is a complete example on how Aquatree looks like
-
-
-```json
-{
- "revisions": {
- "0xe2922c4c80060a035fa7ace36ed7d9e32aa901382b5651e9f68354bc1bc9edb4": {
- "previous_verification_hash": "",
- "local_timestamp": "20250224154438",
- "revision_type": "file",
- "file_hash": "bd2e8e2a1b3c5d008e1d43ecb11105f42c5ad4e05922bab98981840b636c661e",
- "file_nonce": "65eddd0e16a995170dbef8feaf86a7928678426f20a309bb6627887915c04efb",
- "version": "https://aqua-protocol.org/docs/v3/schema_2 | SHA256 | Method: scalar"
- },
- "0x115d8604f5c689602b7703ce5f4c1ba59a731c9c1a3798cbd2d205df1e772ebd": {
- "previous_verification_hash": "0xe2922c4c80060a035fa7ace36ed7d9e32aa901382b5651e9f68354bc1bc9edb4",
- "local_timestamp": "20250224154448",
- "revision_type": "signature",
- "signature": "0x799cd8177dc2c5dc34d389601175d550466a73509b71d533aaa3ff0ee958b3b31b574bdfd158a7ad0b186da5f5b440bc18453a6848bc659ccd6de06a09d6ea6e1b",
- "signature_public_key": "0x0380a77a1a6d59be5c10d7ee5e10def79283938bb8a60025d0fe5404e650e8ccc1",
- "signature_wallet_address": "0x568a94a8f0f3dc0b245b853bef572075c1df5c50",
- "signature_type": "ethereum:eip-191",
- "version": "https://aqua-protocol.org/docs/v3/schema_2 | SHA256 | Method: scalar"
- },
- "0x121a8e95204fafdd18fb1ea1287c278693f48b28d88e341f86e3c336e9731eab": {
- "previous_verification_hash": "0x115d8604f5c689602b7703ce5f4c1ba59a731c9c1a3798cbd2d205df1e772ebd",
- "local_timestamp": "20250224154506",
- "revision_type": "witness",
- "version": "https://aqua-protocol.org/docs/v3/schema_2 | SHA256 | Method: scalar",
- "witness_merkle_root": "0x115d8604f5c689602b7703ce5f4c1ba59a731c9c1a3798cbd2d205df1e772ebd",
- "witness_timestamp": 1740411910,
- "witness_network": "sepolia",
- "witness_smart_contract_address": "0x45f59310ADD88E6d23ca58A0Fa7A55BEE6d2a611",
- "witness_transaction_hash": "0xad007675d238746783d697ca8cbc0260f87275430d43ba08dea11d26a00e8850",
- "witness_sender_account_address": "0x568a94a8f0f3dc0b245b853bef572075c1df5c50",
- "witness_merkle_proof": [
- "0x115d8604f5c689602b7703ce5f4c1ba59a731c9c1a3798cbd2d205df1e772ebd"
- ]
- },
- "0x105356040bab31f82778a47bb24604bb966a6994b3f3fccc14e0b084f634bde3": {
- "previous_verification_hash": "0x121a8e95204fafdd18fb1ea1287c278693f48b28d88e341f86e3c336e9731eab",
- "local_timestamp": "20250224154548",
- "revision_type": "file",
- "content": "GNU GENERAL PUBLIC LICENSE...",
- "file_hash": "bd7aec058dde7038fa2e88607ca870bd88da53e6fc32d6c0f8674b59419c061b",
- "file_nonce": "2da1dc9f782e9f489c35cbd01413399f7c8ac14b3deea6c428b2380dbc7af725",
- "version": "https://aqua-protocol.org/docs/v3/schema_2 | SHA256 | Method: scalar"
- }
- },
- "file_index": {
- "0xe2922c4c80060a035fa7ace36ed7d9e32aa901382b5651e9f68354bc1bc9edb4": "LICENSE"
- },
- "treeMapping": {
- "paths": {
- "0x105356040bab31f82778a47bb24604bb966a6994b3f3fccc14e0b084f634bde3": [
- "0xe2922c4c80060a035fa7ace36ed7d9e32aa901382b5651e9f68354bc1bc9edb4",
- "0x115d8604f5c689602b7703ce5f4c1ba59a731c9c1a3798cbd2d205df1e772ebd",
- "0x121a8e95204fafdd18fb1ea1287c278693f48b28d88e341f86e3c336e9731eab",
- "0x105356040bab31f82778a47bb24604bb966a6994b3f3fccc14e0b084f634bde3"
- ]
- },
- "latestHash": "0x105356040bab31f82778a47bb24604bb966a6994b3f3fccc14e0b084f634bde3"
- }
-}
-```
-
-
diff --git a/versioned_docs/version-1.3.2/sdk/README.md b/versioned_docs/version-1.3.2/sdk/README.md
deleted file mode 100644
index a84055de..00000000
--- a/versioned_docs/version-1.3.2/sdk/README.md
+++ /dev/null
@@ -1,37 +0,0 @@
-# Aqua Protocol SDK Documentation
-
-The Aqua Protocol SDK provides a powerful interface for file notarization, signing, and verification using blockchain and distributed technologies. This documentation will help you understand and use the SDK effectively.
-
-## Table of Contents
-
-- [Getting Started](./getting-started.md)
-- [Core Concepts](./core-concepts.md)
-- API Reference
- - [Aquafier API](./api/aquafier.md)
- - [Chainable API](./api/chainable.md)
- - [Signing](./api/signing.md)
- - [Witnessing](./api/witnessing.md)
- - [Verification](./api/verification.md)
-
-## Quick Example
-
-```typescript
-import { AquafierChainable } from 'aqua-js-sdk';
-
-// Create a new notarization
-const aqua = new AquafierChainable(null)
- .notarize(fileObject)
- .sign("metamask", credentials)
- .witness("eth", "sepolia")
- .verify();
-
-// Get results
-const tree = aqua.getValue();
-const logs = aqua.getLogs();
-```
-
-## Need Help?
-
-- Check our [Troubleshooting Guide](./troubleshooting.md)
-- Review [Common Use Cases](./use-cases.md)
-- See [API Examples](./examples.md)
diff --git a/versioned_docs/version-1.3.2/sdk/api/chainable.md b/versioned_docs/version-1.3.2/sdk/api/chainable.md
deleted file mode 100644
index 9e6ee6dd..00000000
--- a/versioned_docs/version-1.3.2/sdk/api/chainable.md
+++ /dev/null
@@ -1,181 +0,0 @@
-# Chainable API Reference
-
-The `AquafierChainable` class provides a fluent interface for performing operations on Aqua Trees. It allows you to chain multiple operations while maintaining state and collecting logs.
-
-## Quick Example
-
-```typescript
-const aqua = new AquafierChainable(tree)
- .notarize(file)
- .sign("metamask", credentials)
- .witness("eth", "sepolia")
- .verify();
-```
-
-## Constructor
-
-### `new AquafierChainable(initialValue?: AquaTree | null)`
-
-Creates a new chainable Aqua operation sequence.
-
-```typescript
-// Start with no tree
-const aqua = new AquafierChainable(null);
-
-// Start with existing tree
-const aqua = new AquafierChainable(existingTree);
-```
-
-## Methods
-
-### `notarize(fileObject: FileObject, options?: NotarizeOptions): Promise`
-
-Creates a genesis revision for file notarization.
-
-```typescript
-const fileObject = {
- name: "document.pdf",
- hash: "0x...",
- content: "..." // optional
-};
-
-const options = {
- isForm: false,
- enableContent: false,
- enableScalar: true
-};
-
-await aqua.notarize(fileObject, options);
-```
-
-### `sign(signType: SignType, credentials: CredentialsData, enableScalar?: boolean): Promise`
-
-Signs the current Aqua Tree state.
-
-```typescript
-const credentials = {
- mnemonic: "", // For CLI signing
- nostr_sk: "", // For Nostr
- did_key: "", // For DID
- alchemy_key: "", // For Ethereum
- witness_eth_network: "",
- witness_method: ""
-};
-
-await aqua.sign("metamask", credentials);
-```
-
-Supported sign types:
-- `"cli"` - Command-line signing using HDNodeWallet
-- `"metamask"` - Browser or Node.js MetaMask signing
-- `"did"` - Decentralized Identifier signing
-
-### `witness(witnessType: WitnessType, witnessNetwork: WitnessNetwork, witnessPlatform: WitnessPlatformType, credentials: CredentialsData, enableScalar?: boolean): Promise`
-
-Witnesses the current Aqua Tree state.
-
-```typescript
-await aqua.witness(
- "eth", // witnessType
- "sepolia", // witnessNetwork
- "metamask", // witnessPlatform
- credentials, // credentials object
- true // enableScalar
-);
-```
-
-Witness Types:
-- `"eth"` - Ethereum blockchain witnessing
-- `"nostr"` - Nostr protocol witnessing
-- `"tsa"` - Time Stamp Authority witnessing
-
-Networks (for Ethereum):
-- `"mainnet"`
-- `"sepolia"`
-- `"goerli"`
-
-Platforms:
-- `"metamask"` - MetaMask wallet
-- `"cli"` - Command-line interface
-- `"api"` - Direct API calls
-
-### `verify(linkedFileObject: Array = []): Promise`
-
-Verifies the current Aqua Tree state.
-
-```typescript
-await aqua.verify([fileObject]);
-```
-
-### Getters
-
-#### `getValue(): AquaTree`
-Gets the current Aqua Tree state.
-
-#### `getVerificationValue(): Result`
-Gets the result of the last verification operation.
-
-#### `getLogs(): LogData[]`
-Gets all collected operation logs.
-
-## Error Handling
-
-The chainable API uses a Result type for error handling. You can check for errors in the logs:
-
-```typescript
-const aqua = new AquafierChainable(null);
-await aqua.notarize(fileObject);
-
-const logs = aqua.getLogs();
-if (logs.length > 0) {
- console.log("Operation logs:", logs);
-}
-
-const verificationResult = aqua.getVerificationValue();
-if (verificationResult.isErr()) {
- console.error("Verification failed:", verificationResult.data);
-}
-```
-
-## Best Practices
-
-1. Chain operations in logical order:
- ```typescript
- await aqua
- .notarize(file) // First create genesis
- .sign(...) // Then sign
- .witness(...) // Then witness
- .verify(); // Finally verify
- ```
-
-2. Handle errors appropriately:
- ```typescript
- try {
- await aqua
- .notarize(file)
- .sign(...);
- } catch (error) {
- console.error("Operation failed:", error);
- console.log("Logs:", aqua.getLogs());
- }
- ```
-
-3. Use enableScalar when appropriate:
- ```typescript
- await aqua
- .notarize(file, { enableScalar: true })
- .sign("metamask", credentials, true)
- .witness("eth", "sepolia", "metamask", credentials, true);
- ```
-
-4. Check verification results:
- ```typescript
- const result = await aqua
- .notarize(file)
- .verify();
-
- const verificationResult = result.getVerificationValue();
- if (verificationResult.isOk()) {
- console.log("Verification successful");
- }
- ```
diff --git a/versioned_docs/version-1.3.2/sdk/api/signing.md b/versioned_docs/version-1.3.2/sdk/api/signing.md
deleted file mode 100644
index 10be5f3c..00000000
--- a/versioned_docs/version-1.3.2/sdk/api/signing.md
+++ /dev/null
@@ -1,223 +0,0 @@
-# Signing API Reference
-
-The Aqua Protocol SDK provides three distinct signing methods to accommodate different use cases and environments.
-
-## Signature Types
-
-### 1. CLI Signing
-
-Uses ethers.js HDNodeWallet for secure command-line signing.
-
-```typescript
-// Using Chainable API
-await aqua.sign(
- "cli", // signType
- credentials // credentials object
-);
-
-// Using Standard API
-await aquafier.signAquaTree(
- tree,
- "cli",
- credentials
-);
-```
-
-**Features:**
-- Direct signing process
-- Suitable for automation
-- Server-side signing
-- HDNodeWallet integration
-
-**Configuration:**
-```typescript
-const credentials = {
- mnemonic: "your-mnemonic-phrase"
-};
-```
-
-### 2. DID Signing (Decentralized Identifier)
-
-Uses key-did-provider-ed25519 for DID-based signing.
-
-```typescript
-// Using Chainable API
-await aqua.sign(
- "did", // signType
- credentials // credentials object
-);
-
-// Using Standard API
-await aquafier.signAquaTree(
- tree,
- "did",
- credentials
-);
-```
-
-**Features:**
-- Ed25519 signatures
-- DID verification
-- JWS handling
-- key-did-resolver support
-
-**Configuration:**
-```typescript
-const credentials = {
- did_key: "your-did-key"
-};
-```
-
-### 3. MetaMask Signing
-
-Provides browser and Node.js MetaMask integration.
-
-```typescript
-// Using Chainable API
-await aqua.sign(
- "metamask", // signType
- credentials // credentials object
-);
-
-// Using Standard API
-await aquafier.signAquaTree(
- tree,
- "metamask",
- credentials
-);
-```
-
-**Features:**
-- Browser integration
-- Node.js support via local server
-- Environment detection
-- Public key recovery
-- Signature verification
-
-## Batch Signing
-
-For signing multiple trees at once:
-
-```typescript
-// Using Chainable API
-const trees = [tree1, tree2, tree3].map(tree =>
- new AquafierChainable(tree)
- .sign("metamask", credentials)
-);
-
-// Using Standard API
-const result = await aquafier.signMultipleAquaTrees(
- trees,
- "metamask",
- credentials
-);
-```
-
-## Message Format
-
-All signing methods use a standardized message format:
-```typescript
-const message = `I sign this revision: ${hash}`;
-```
-
-## Signature Verification
-
-You can verify signatures after signing:
-
-```typescript
-// Using Chainable API
-const result = await aqua
- .sign("metamask", credentials)
- .verify();
-
-// Using Standard API
-const verified = await aquafier.verifyAquaTree(
- signedTree,
- [fileObject]
-);
-
-// Recover signer's address (MetaMask only)
-const address = await recoverWalletAddress(signature, message);
-```
-
-## Best Practices
-
-1. **Choose the Right Method:**
- - Use CLI for automation and scripts
- - Use MetaMask for interactive applications
- - Use DID for decentralized identity integration
-
-2. **Error Handling:**
-```typescript
-try {
- await aqua.sign("metamask", credentials);
-} catch (error) {
- console.error("Signing failed:", error);
- const logs = aqua.getLogs();
- // Handle failure
-}
-```
-
-3. **MetaMask Environment:**
-```typescript
-// Browser
-await aqua.sign("metamask", credentials);
-
-// Node.js (starts local server)
-await aqua.sign("metamask", {
- ...credentials,
- port: 8545, // Optional server port
- host: "localhost" // Optional server host
-});
-```
-
-4. **Verify After Signing:**
-```typescript
-const result = await aqua
- .sign("metamask", credentials)
- .verify();
-
-if (result.getVerificationValue().isOk()) {
- console.log("Signature verified successfully");
-}
-```
-
-## Common Issues
-
-1. **MetaMask Connection:**
- - Check wallet connection
- - Verify account access
- - Handle user rejections
- - Monitor connection state
-
-2. **DID Signing:**
- - Validate DID format
- - Check key permissions
- - Handle resolver errors
- - Verify JWS format
-
-3. **CLI Signing:**
- - Verify mnemonic format
- - Check wallet derivation
- - Handle key generation errors
- - Monitor signing process
-
-## Security Considerations
-
-1. **Private Key Management:**
- - Never expose private keys in code
- - Use secure key storage
- - Implement key rotation
- - Monitor for unauthorized use
-
-2. **Signature Verification:**
- - Always verify signatures
- - Check signer addresses
- - Validate message format
- - Monitor for replay attacks
-
-3. **Environment Security:**
- - Secure MetaMask connections
- - Protect mnemonic phrases
- - Secure DID keys
- - Monitor signing requests
diff --git a/versioned_docs/version-1.3.2/sdk/api/verification.md b/versioned_docs/version-1.3.2/sdk/api/verification.md
deleted file mode 100644
index a5158fd8..00000000
--- a/versioned_docs/version-1.3.2/sdk/api/verification.md
+++ /dev/null
@@ -1,233 +0,0 @@
-# Verification API Reference
-
-The Aqua Protocol SDK provides comprehensive verification capabilities for validating file authenticity, signatures, and witness proofs.
-
-## Basic Verification
-
-### Using Chainable API
-
-```typescript
-// Verify after any operation
-const result = await aqua
- .notarize(file)
- .sign("metamask", credentials)
- .witness("eth", "sepolia", "metamask", credentials)
- .verify();
-
-// Check verification result
-if (result.getVerificationValue().isOk()) {
- console.log("Verification successful");
-} else {
- console.error("Verification failed:", result.getLogs());
-}
-```
-
-### Using Standard API
-
-```typescript
-const verified = await aquafier.verifyAquaTree(
- tree,
- [fileObject]
-);
-
-if (verified.isOk()) {
- console.log("Tree verified successfully");
-} else {
- console.error("Verification failed:", verified.data);
-}
-```
-
-## Verification Types
-
-### 1. Tree Structure Verification
-
-Verifies the integrity of the Aqua Tree structure:
-- File index validation
-- Hash chain verification
-- Revision order checking
-
-```typescript
-const result = await aquafier.verifyAquaTree(tree, [fileObject]);
-```
-
-### 2. Revision Verification
-
-Verifies specific revisions within the tree:
-
-```typescript
-const result = await aquafier.verifyAquaTreeRevision(
- tree,
- revision,
- revisionItemHash,
- [fileObject]
-);
-```
-
-### 3. Graph Data Verification
-
-Generates and verifies graph data for visualization:
-
-```typescript
-// Full tree verification with graph data
-const graphData = await aquafier.verifyAndGetGraphData(
- tree,
- [fileObject]
-);
-
-// Single revision verification with graph data
-const revisionGraph = await aquafier.verifyAndGetGraphDataRevision(
- tree,
- revision,
- revisionItemHash,
- [fileObject]
-);
-```
-
-## Verification Components
-
-The verification process checks multiple aspects:
-
-1. **File Verification**
- - Hash validation
- - Content integrity
- - Metadata matching
-
-2. **Signature Verification**
- - Signer authentication
- - Message format validation
- - Public key recovery
-
-3. **Witness Verification**
- - Proof validation
- - Timestamp verification
- - Platform-specific checks:
- - Ethereum: Transaction verification
- - Nostr: Event verification
- - TSA: Timestamp validation
-
-## Error Handling
-
-```typescript
-try {
- const result = await aqua.verify();
-
- if (result.getVerificationValue().isOk()) {
- const tree = result.getValue();
- console.log("Verification successful:", tree);
- } else {
- const logs = result.getLogs();
- console.error("Verification failed:", logs);
- }
-} catch (error) {
- console.error("Verification error:", error);
-}
-```
-
-## Graph Data Structure
-
-The verification graph data provides a visual representation of the verification state:
-
-```typescript
-interface VerificationGraphData {
- nodes: {
- id: string;
- label: string;
- type: string;
- status: "verified" | "failed" | "pending";
- }[];
- edges: {
- from: string;
- to: string;
- label: string;
- }[];
-}
-```
-
-## Best Practices
-
-1. **Regular Verification**
-```typescript
-// Verify after each major operation
-await aqua
- .notarize(file)
- .verify() // After notarization
- .sign(...)
- .verify() // After signing
- .witness(...)
- .verify(); // After witnessing
-```
-
-2. **Comprehensive Verification**
-```typescript
-// Include all relevant file objects
-const allFiles = [mainFile, ...linkedFiles];
-await aqua.verify(allFiles);
-```
-
-3. **Error Analysis**
-```typescript
-const result = await aqua.verify();
-const logs = result.getLogs();
-
-// Analyze verification failures
-const failures = logs.filter(log =>
- log.type === "verification_failure"
-);
-
-// Check specific components
-const signatureIssues = logs.filter(log =>
- log.component === "signature"
-);
-```
-
-4. **Graph Data Usage**
-```typescript
-const graphData = await aquafier.verifyAndGetGraphData(
- tree,
- [fileObject]
-);
-
-// Analyze verification path
-const failedNodes = graphData.nodes.filter(node =>
- node.status === "failed"
-);
-```
-
-## Common Issues
-
-1. **File Hash Mismatch**
- - Verify file content hasn't changed
- - Check hash calculation method
- - Validate file encoding
-
-2. **Signature Verification Failure**
- - Check signer address
- - Verify message format
- - Validate signature data
-
-3. **Witness Proof Issues**
- - Verify blockchain transaction
- - Check Nostr event existence
- - Validate TSA timestamp
-
-4. **Tree Structure Issues**
- - Check revision order
- - Verify hash chain
- - Validate file indices
-
-## Performance Considerations
-
-1. **Batch Verification**
- - Group related verifications
- - Cache verification results
- - Reuse file objects
-
-2. **Graph Data Optimization**
- - Request graph data only when needed
- - Cache graph representations
- - Limit verification depth
-
-3. **Error Recovery**
- - Implement retry logic
- - Cache intermediate results
- - Log verification steps
diff --git a/versioned_docs/version-1.3.2/sdk/api/witnessing.md b/versioned_docs/version-1.3.2/sdk/api/witnessing.md
deleted file mode 100644
index b1bfb1ec..00000000
--- a/versioned_docs/version-1.3.2/sdk/api/witnessing.md
+++ /dev/null
@@ -1,223 +0,0 @@
-# Witnessing API Reference
-
-The Aqua Protocol SDK provides three distinct witnessing methods, each offering different trade-offs in terms of security, speed, and decentralization.
-
-## Witness Types
-
-### 1. Ethereum Witnessing
-
-Uses Ethereum blockchain for secure, decentralized witnessing.
-
-```typescript
-// Using Chainable API
-await aqua.witness(
- "eth", // witnessType
- "sepolia", // network
- "metamask", // platform
- credentials // credentials object
-);
-
-// Using Standard API
-await aquafier.witnessAquaTree(
- tree,
- "eth",
- "sepolia",
- "metamask",
- credentials
-);
-```
-
-**Features:**
-- Browser and Node.js support
-- MetaMask integration
-- Automatic environment detection
-- Chain ID validation
-- Network switching
-- Transaction monitoring
-
-**Configuration:**
-```typescript
-const credentials = {
- alchemy_key: "your-alchemy-key",
- witness_eth_network: "sepolia",
- witness_method: "metamask"
-};
-```
-
-### 2. Nostr Witnessing
-
-Uses the Nostr protocol for lightweight, fast witnessing.
-
-```typescript
-// Using Chainable API
-await aqua.witness(
- "nostr", // witnessType
- "default", // network (unused for Nostr)
- "api", // platform
- credentials // credentials object
-);
-
-// Using Standard API
-await aquafier.witnessAquaTree(
- tree,
- "nostr",
- "default",
- "api",
- credentials
-);
-```
-
-**Features:**
-- Event creation and signing
-- Relay communication (damus.io)
-- Event verification
-- Timestamp validation
-- WebSocket handling
-
-**Configuration:**
-```typescript
-const credentials = {
- nostr_sk: "your-nostr-secret-key"
-};
-```
-
-### 3. Time Stamp Authority (TSA)
-
-Uses RFC 3161 Time-Stamp Protocol for official timestamping.
-
-```typescript
-// Using Chainable API
-await aqua.witness(
- "tsa", // witnessType
- "default", // network (unused for TSA)
- "api", // platform
- credentials // credentials object
-);
-
-// Using Standard API
-await aquafier.witnessAquaTree(
- tree,
- "tsa",
- "default",
- "api",
- credentials
-);
-```
-
-**Features:**
-- RFC 3161 compliance
-- ASN.1 encoding/decoding
-- SHA-256 verification
-- Timestamp extraction
-- Base64 handling
-
-## Batch Witnessing
-
-For witnessing multiple trees at once:
-
-```typescript
-// Using Chainable API
-const trees = [tree1, tree2, tree3].map(tree =>
- new AquafierChainable(tree)
- .witness("eth", "sepolia", "metamask", credentials)
-);
-
-// Using Standard API
-const result = await aquafier.witnessMultipleAquaTrees(
- trees,
- "eth",
- "sepolia",
- "metamask",
- credentials
-);
-```
-
-## Verification
-
-After witnessing, you can verify the witness proofs:
-
-```typescript
-// Using Chainable API
-const result = await aqua
- .witness("eth", "sepolia", "metamask", credentials)
- .verify();
-
-// Using Standard API
-const verified = await aquafier.verifyAquaTree(
- witnessedTree,
- [fileObject]
-);
-```
-
-## Best Practices
-
-1. **Choose the Right Method:**
- - Use Ethereum for highest security and decentralization
- - Use Nostr for fast, lightweight witnessing
- - Use TSA for official timestamp requirements
-
-2. **Error Handling:**
-```typescript
-try {
- await aqua.witness("eth", "sepolia", "metamask", credentials);
-} catch (error) {
- console.error("Witnessing failed:", error);
- const logs = aqua.getLogs();
- // Handle failure
-}
-```
-
-3. **Monitor Transaction Status** (Ethereum):
-```typescript
-const result = await aqua
- .witness("eth", "sepolia", "metamask", credentials);
-
-// Check logs for transaction status
-const logs = result.getLogs();
-const txStatus = logs.find(log =>
- log.type === "transaction_status"
-);
-```
-
-4. **Verify After Witnessing:**
-```typescript
-const result = await aqua
- .witness("eth", "sepolia", "metamask", credentials)
- .verify();
-
-if (result.getVerificationValue().isOk()) {
- console.log("Witness verified successfully");
-}
-```
-
-5. **Network Selection** (Ethereum):
- - Use testnets (sepolia, goerli) for development
- - Use mainnet for production
- - Always check gas costs
- - Monitor network status
-
-6. **Credential Security:**
- - Never expose private keys
- - Use environment variables
- - Rotate keys regularly
- - Monitor for unauthorized use
-
-## Common Issues
-
-1. **Ethereum Connection:**
- - Check MetaMask connection
- - Verify network selection
- - Ensure sufficient gas
- - Check Alchemy API key
-
-2. **Nostr Relay:**
- - Check relay connection
- - Verify key format
- - Monitor event propagation
- - Handle timeout errors
-
-3. **TSA Service:**
- - Verify service availability
- - Check response format
- - Validate timestamps
- - Handle encoding errors
diff --git a/versioned_docs/version-1.3.2/sdk/core-concepts.md b/versioned_docs/version-1.3.2/sdk/core-concepts.md
deleted file mode 100644
index 930c99ba..00000000
--- a/versioned_docs/version-1.3.2/sdk/core-concepts.md
+++ /dev/null
@@ -1,136 +0,0 @@
-# Core Concepts
-
-## Aqua Tree Structure
-
-The Aqua Protocol uses a specialized tree structure (AquaTree) to maintain the history and verification state of files. Each tree contains:
-- File metadata
-- Revision history
-- Signatures
-- Witness records
-- Verification proofs
-
-## Signature System
-
-The SDK supports three distinct signing methods:
-
-### 1. CLI Signing
-- Uses ethers.js HDNodeWallet for secure message signing
-- Ideal for automated or server-side operations
-- Simple and direct signing process
-
-### 2. DID Signing (Decentralized Identifier)
-- Implements DID-based signing using key-did-provider-ed25519
-- Supports Ed25519 signatures
-- Verifiable through key-did-resolver
-- Handles JSON Web Signatures (JWS)
-
-### 3. MetaMask Signing
-- Supports both browser and Node.js environments
-- Browser: Direct MetaMask integration
-- Node.js: Local server for MetaMask interaction
-- Features automatic environment detection
-- Includes public key recovery from signatures
-
-## Witness System
-
-The SDK implements three distinct witnessing methods:
-
-### 1. Ethereum Witnessing
-- Supports both browser and Node.js environments
-- Uses MetaMask for transaction signing
-- Features:
- - Automatic environment detection
- - Local server for Node.js MetaMask interaction
- - Chain ID validation
- - Network switching support
- - Transaction status monitoring
-
-### 2. Nostr Witnessing
-- Implements Nostr protocol-based witnessing
-- Uses nostr-tools for protocol operations
-- Features:
- - Event creation and signing
- - Relay communication (damus.io)
- - Event verification
- - Timestamp validation
- - Cross-platform WebSocket handling
-
-### 3. Time Stamp Authority (TSA)
-- Implements RFC 3161 Time-Stamp Protocol
-- Uses DigiCert TSA service
-- Features:
- - ASN.1 encoding/decoding
- - SHA-256 hash verification
- - Timestamp extraction and validation
- - Base64 response handling
-
-## Common Features Across Systems
-
-### Signing Features
-- Standardized message format: "I sign this revision: [hash]"
-- Comprehensive signature verification
-- Return signatures with wallet/DID information
-- Error handling and validation
-
-### Witnessing Features
-- Support for both witnessing and verification
-- Consistent timestamp handling
-- Environment-aware implementations
-- Comprehensive error handling
-- Synchronous and asynchronous operations
-
-## Operation Flow
-
-1. **File Preparation**
- - Hash calculation
- - Metadata collection
- - Content processing (optional)
-
-2. **Tree Creation**
- - Genesis revision creation
- - File index management
- - Tree structure validation
-
-3. **Signing Process**
- - Method selection (CLI/DID/MetaMask)
- - Signature generation
- - Public key recovery
- - Signature verification
-
-4. **Witnessing Process**
- - Platform selection (Ethereum/Nostr/TSA)
- - Transaction/event creation
- - Proof generation
- - Status monitoring
-
-5. **Verification**
- - Signature validation
- - Witness proof verification
- - Tree structure integrity check
- - Timestamp validation
-
-## Best Practices
-
-1. **Choose the Right Tools**
- - Use CLI signing for automation
- - Use MetaMask for interactive browser applications
- - Use DID for decentralized identity integration
- - Choose witnessing method based on security and speed requirements
-
-2. **Error Handling**
- - Always check Result types for errors
- - Monitor witness transaction status
- - Validate signatures before witnessing
- - Keep track of operation logs
-
-3. **Performance Optimization**
- - Enable scalar values when appropriate
- - Batch operations when possible
- - Use chainable API for cleaner code
- - Monitor gas costs for Ethereum operations
-
-4. **Security Considerations**
- - Secure credential management
- - Validate file hashes
- - Verify signatures independently
- - Monitor witness network status
diff --git a/versioned_docs/version-1.3.2/sdk/getting-started.md b/versioned_docs/version-1.3.2/sdk/getting-started.md
deleted file mode 100644
index ced82419..00000000
--- a/versioned_docs/version-1.3.2/sdk/getting-started.md
+++ /dev/null
@@ -1,85 +0,0 @@
-# Getting Started with Aqua Protocol SDK
-
-## Installation
-
-```bash
-npm install aqua-js-sdk
-```
-
-## Basic Concepts
-
-The Aqua Protocol SDK provides a system for file notarization and verification using three main operations:
-
-1. **Notarization**: Creating a genesis revision for your file
-2. **Signing**: Adding cryptographic signatures using various methods
-3. **Witnessing**: Recording the file state on different platforms
-4. **Verification**: Validating the authenticity of files
-
-## Quick Start
-
-### Using the Chainable API (Recommended)
-
-```typescript
-import { AquafierChainable } from 'aqua-js-sdk';
-
-// Prepare your file object
-const fileObject = {
- name: "document.pdf",
- hash: "0x...", // File hash
- content: "..." // Optional file content
-};
-
-// Create credentials (example for MetaMask)
-const credentials = {
- mnemonic: "", // For CLI signing
- nostr_sk: "", // For Nostr witnessing
- did_key: "", // For DID signing
- alchemy_key: "", // For Ethereum operations
- witness_eth_network: "sepolia",
- witness_method: "metamask"
-};
-
-// Create and process your file
-const aqua = new AquafierChainable(null);
-const result = await aqua
- .notarize(fileObject)
- .sign("metamask", credentials)
- .witness("eth", "sepolia", "metamask", credentials)
- .verify();
-
-// Get results
-const tree = result.getValue();
-const logs = result.getLogs();
-```
-
-### Using the Standard API
-
-```typescript
-import { Aquafier } from 'aqua-js-sdk';
-
-const aqua = new Aquafier();
-
-// Create genesis revision
-const genesis = await aqua.createGenesisRevision(fileObject);
-
-// Sign the tree
-const signed = await aqua.signAquaTree(genesis.data.aquaTree, "metamask", credentials);
-
-// Witness the tree
-const witnessed = await aqua.witnessAquaTree(
- signed.data.aquaTree,
- "eth",
- "sepolia",
- "metamask",
- credentials
-);
-
-// Verify the tree
-const verified = await aqua.verifyAquaTree(witnessed.data.aquaTree, [fileObject]);
-```
-
-## Next Steps
-
-- Read about [Core Concepts](./core-concepts.md) to understand the system better
-- Check out [Common Use Cases](./use-cases.md) for practical examples
-- Review the [API Reference](./api/aquafier.md) for detailed documentation
diff --git a/versioned_sidebars/version-1.1.0-sidebars.json b/versioned_sidebars/version-1.1.0-sidebars.json
deleted file mode 100644
index caea0c03..00000000
--- a/versioned_sidebars/version-1.1.0-sidebars.json
+++ /dev/null
@@ -1,8 +0,0 @@
-{
- "tutorialSidebar": [
- {
- "type": "autogenerated",
- "dirName": "."
- }
- ]
-}
diff --git a/versioned_sidebars/version-1.2.0-sidebars.json b/versioned_sidebars/version-1.2.0-sidebars.json
deleted file mode 100644
index caea0c03..00000000
--- a/versioned_sidebars/version-1.2.0-sidebars.json
+++ /dev/null
@@ -1,8 +0,0 @@
-{
- "tutorialSidebar": [
- {
- "type": "autogenerated",
- "dirName": "."
- }
- ]
-}
diff --git a/versioned_sidebars/version-1.3.0-sidebars.json b/versioned_sidebars/version-1.3.0-sidebars.json
deleted file mode 100644
index caea0c03..00000000
--- a/versioned_sidebars/version-1.3.0-sidebars.json
+++ /dev/null
@@ -1,8 +0,0 @@
-{
- "tutorialSidebar": [
- {
- "type": "autogenerated",
- "dirName": "."
- }
- ]
-}
diff --git a/versioned_sidebars/version-1.3.2-sidebars.json b/versioned_sidebars/version-1.3.2-sidebars.json
deleted file mode 100644
index b95d529a..00000000
--- a/versioned_sidebars/version-1.3.2-sidebars.json
+++ /dev/null
@@ -1,99 +0,0 @@
-{
- "tutorialSidebar": [
- {
- "type": "doc",
- "id": "intro",
- "label": "Introduction"
- },
- {
- "type": "doc",
- "id": "schema_2",
- "label": "Schema Reference"
- },
- {
- "type": "doc",
- "id": "VerifierTests",
- "label": "Verifier Tests"
- },
- {
- "type": "category",
- "label": "Developer Tools",
- "items": [
- {
- "type": "doc",
- "id": "RestAPI",
- "label": "REST API"
- },
- {
- "type": "doc",
- "id": "cli-tool",
- "label": "CLI Tool"
- },
- {
- "type": "category",
- "label": "SDK",
- "items": [
- {
- "type": "doc",
- "id": "sdk/getting-started",
- "label": "Getting Started"
- },
- {
- "type": "doc",
- "id": "sdk/core-concepts",
- "label": "Core Concepts"
- },
- {
- "type": "category",
- "label": "API Reference",
- "items": [
- {
- "type": "doc",
- "id": "sdk/api/signing",
- "label": "Signing"
- },
- {
- "type": "doc",
- "id": "sdk/api/verification",
- "label": "Verification"
- },
- {
- "type": "doc",
- "id": "sdk/api/witnessing",
- "label": "Witnessing"
- }
- ]
- }
- ]
- }
- ]
- },
- {
- "type": "category",
- "label": "Security & Identity",
- "items": [
- {
- "type": "doc",
- "id": "AquaIdentity",
- "label": "Aqua Identity"
- },
- {
- "type": "doc",
- "id": "AccessControl",
- "label": "Access Control"
- }
- ]
- },
- {
- "type": "category",
- "label": "Use Cases",
- "items": [
- {
- "type": "doc",
- "id": "Cheque",
- "label": "WAVS integration: Digital Cheque"
- }
- ]
- }
- ]
-}
diff --git a/versions.json b/versions.json
deleted file mode 100644
index 2e5f0bbd..00000000
--- a/versions.json
+++ /dev/null
@@ -1,5 +0,0 @@
-[
- "1.3.2",
- "1.2.0",
- "1.1.0"
-]
+
+
+
+
+
+
+#### Videos
+
+Use the HTML video element for self-hosted video content:
+
+
+
+Embed YouTube videos using iframe elements:
+
+
+
+#### Tooltips
+
+Example of tooltip usage:
+
+