> ## Documentation Index
> Fetch the complete documentation index at: https://wiki.krkn.tech/llms.txt
> Use this file to discover all available pages before exploring further.

# Why Not Hashtopolis

> This document explains the architectural and philosophical differences between Krkn and Hashtopolis

# TL;DR Summary

> **Krkn** is a modern, distributed, self-contained, streaming-first cracking orchestration system designed for cloud, containers, segmented networks, and long-term cracking intelligence.

> **Hashtopolis** is a traditional centralized cracking management platform designed around shared storage and classic server-agent models.

Both are excellent tools — they simply optimize for **very different deployment philosophies** and **very different operational goals**.

# Part 1 — High-Level Explanation

## What is the core difference?

**Krkn** is a **modern, cloud-native distributed cracking platform** designed around:

* Self-contained jobs
* Pull-based workers
* High-performance networking
* Minimal infrastructure assumptions
* **Persistent encrypted hash intelligence and historical result reuse**
* **Automation-first control plane with webhooks and APIs**

**Hashtopolis** is a **traditional server-based cracking management system** designed around:

* Central file storage
* Agents that download tasks and files
* A classic web application architecture
* Ephemeral task execution without long-term intelligence memory

***

## The User Interface

### Krkn

* **CLI-driven, API-driven system**
* The CLI is:
  * Just a client to the control plane
  * Scriptable
  * Automatable
  * CI/CD friendly
* Humans are **optional**
* Designed to be:
  * Embedded into pipelines
  * Driven by schedulers
  * Triggered by other systems
  * Used headless

### Hashtopolis

* **UI-driven system**
* The web interface is:
  * The primary control plane
  * The primary workflow engine
  * The primary integration surface
* Automation is secondary
* Humans are in the loop by default

## How work is sent to workers

### Krkn

* Workers (**Tentacles**) connect to a controller (**Krkns**).
* When ready, they **ask for work**.
* They receive **everything needed to execute the job in one package**:
  * Hashes
  * Wordlists
  * Rules
  * Masks
* No shared filesystem is required.
* **Before any job runs, hashes are checked against the encrypted intelligence store and previously cracked results are reused automatically.**

### Hashtopolis

* The server tells agents what to do.
* Agents then **download files separately** from a central file store.
* The job references files by ID or path.
* Previously cracked data is not treated as a first-class, reusable intelligence source.

***

## Persistent Hash Intelligence (Major Architectural Difference)

### Krkn

* Maintains a **system-local, encrypted key-value database** of:
  * Hashes
  * Cracked passwords
  * Metadata
* Encryption key:
  * Is **system-specific**
  * **Rotates daily**
* This allows:
  * Instant re-query of previously cracked hashes
  * Deduplication across jobs
  * Historical cracking reuse
  * Long-term cracking intelligence accumulation
* Jobs automatically benefit from **everything the system has ever cracked before**.

### Hashtopolis

* Oriented around:
  * Task execution
  * File-based results
* No first-class, encrypted, system-wide cracking intelligence database
* Historical results are not treated as a core optimization primitive.

***

## Access Control & Multi-Tenancy

### Krkn

* Built-in **user ACL system**:
  * Controls access to jobs, results, datasets, and system functions
  * Designed for multi-user, multi-role environments
* Enables:
  * Operator roles
  * Read-only auditors
  * Automation accounts
  * Segmented access to cracking infrastructure

### Hashtopolis

* Has mature user and permission management
* Tightly coupled to the PHP web application model

***

## Real-Time Automation & Webhooks

### Krkn

* Provides **webhook support** for:
  * Job start
  * Job completion
  * Chunk completion
  * New crack events
  * Error conditions
* Enables:
  * Real-time dashboards
  * SIEM/SOAR integration
  * Slack/Discord alerts
  * Automated follow-on actions (password resets, ticketing, reporting, etc)
* Designed to act as **part of a larger automated security pipeline**, not just a cracking box.

### Hashtopolis

* Primarily UI-driven
* Limited external automation hooks
* Oriented toward human-driven workflows

***

## Why this matters

### Krkn advantages

* Works extremely well in:
  * Containers
  * Cloud environments
  * VPN / NAT / segmented networks
* No shared storage required
* Simpler deployment model for distributed workers
* Better performance over unreliable networks
* Workers are autonomous and self-scheduling
* **Builds long-term cracking intelligence over time**
* **Integrates cleanly into automated security workflows**

### Hashtopolis advantages

* Mature and battle-tested
* Full-featured web UI
* Centralized file storage saves bandwidth
* Easier for non-developers to customize agents
* Strong multi-user and permission model

***

## Networking model

* **Krkn** is capable of using **QUIC** and **HTTP/2**:
  * Faster startup
  * Better multiplexing
  * Better performance on high-latency or restricted networks
* **Hashtopolis** uses traditional **HTTP(S) over TCP**

***

## In short

> **Krkn** is optimized for modern, distributed, containerized environments **and long-term cracking intelligence accumulation**.\
> **Hashtopolis** is optimized for classic server + agents + shared storage environments.

***

# Part 2 — Technical Deep Dive

## 1. Architecture & Technology Stack

### Krkn

* Go-based microservices
* gRPC + Protocol Buffers
* QUIC/HTTP2 transport
* SQLite using `sqlc` for type-safe queries (user & job database)
* **Custom encrypted key-value database for hash intelligence storage**
  * System-specific key
  * Daily key rotation
* Strongly typed, compile-time validated APIs

### Hashtopolis

* PHP monolith
* MySQL
* REST/HTTP with JSON
* Python agents

## 2. Work Distribution Model

### Krkn

* Custom system: **Orchestra**
* Pull-based model:
  * Workers ("Instruments") register with the **Conductor**
  * Workers open streaming gRPC connections
  * Workers request work when ready
* Natural load balancing

### Hashtopolis

* Push/poll model
* Server assigns tasks
* Agents poll HTTP endpoints for work

## 3. Communication Protocol

### Krkn

* gRPC + Protocol Buffers
* QUIC/HTTP2 transport
* Streaming RPCs
* Supports large, chunked payloads:
  * Wordlists
  * Rules
  * Hashlists

### Hashtopolis

* REST API over HTTP(S)
* JSON messages
* Files transferred via separate download endpoints
* Agents reference files by ID/path

## 4. Job Distribution Philosophy

### Krkn

* **Batching system**
* Jobs are grouped into batches
* Each batch contains:
  * Hashes
  * Wordlists
  * Rules
  * Masks
* Entire attack payload is **self-contained**

### Hashtopolis

* Task-based model
* Jobs reference centrally stored files
* Agents must fetch required files separately

## 5. Worker Architecture

### Krkn

* Go-based workers called **Tentacles**
* Execute hashcat directly using shared object files
* Embedded file handling

### Hashtopolis

* Python-based agents
* More flexible for ad-hoc customization

## 6. Data Embedding Strategy

### Krkn

* File contents embedded directly into job payloads:
  * Hashes
  * Wordlists
  * Rules
  * Masks
* Delivered as byte arrays over gRPC streams

### Hashtopolis

* Files stored centrally
* Agents download files separately

## 7. Network Transport

### Krkn

* QUIC (UDP-based)/HTTP2
* Multiplexed streams
* Better performance on:
  * High latency
  * NAT
  * VPN
  * Firewalled environments

### Hashtopolis

* TCP-based HTTP(S)

## 8. Database Design

### Krkn

* SQLite for:
  * Users
  * Jobs
  * Scheduling
  * ACLs
* Custom encrypted key-value store for:
  * Hashes
  * Cracked passwords
  * Historical result indexing
* SQLC-generated type-safe queries

### Hashtopolis

* MySQL
* Traditional ORM / query approach

## 9. Scalability Model

### Krkn

* Streaming chunked transfer
* Pull-based scheduling
* Workers request work when idle
* Natural horizontal scaling

### Hashtopolis

* Central file repository
* Separate download phase
* More I/O coordination required

## 10. Observability & Automation

### Krkn

* Structured logging via Zap
* Orchestra heartbeat and metrics system
* **Webhook-based event streaming**
* **Automation-first integration design**

### Hashtopolis

* Traditional PHP logging and status views

# Key Advantages of Krkn

* Type safety (Protocol Buffers, SQLC)
* Higher performance (QUIC + gRPC)
* Self-contained jobs (no shared filesystem)
* Modern concurrency (Go goroutines)
* Pull-based load balancing
* Cloud/container friendly
* Better for segmented and restricted networks
* **Persistent encrypted cracking intelligence**
* **Automatic re-use of historical results**
* **Webhook-driven automation and integration**
* **Fine-grained ACL system**

***

# Key Advantages of Hashtopolis

* Mature, battle-tested ecosystem
* Full web UI
* Centralized file storage reduces payload size
* Python agents easier to customize
* Strong multi-user and permission model

***

# Final Positioning

> Krkn is not just a distributed cracking scheduler.\
> It is a **cracking intelligence platform** that accumulates knowledge over time, integrates into automated security workflows, and is built for modern infrastructure.

> Hashtopolis is an excellent **task execution and management system** for traditional environments.

They solve **related but fundamentally different problems**.