The latest articles on DEV Community by Lois-Kleinner (@kleinner). https://dev.to/kleinner https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3996124%2Fbbd4e8f8-0f89-4afa-a480-9434f8e6d2ec.jpg https://dev.to/kleinner en Lois-Kleinner Wed, 24 Jun 2026 17:46:26 +0000 https://dev.to/kleinner/kathon-browser-desktop-application-performance-benchmarks-vault-operations-ai-inference-and-2mem https://dev.to/kleinner/kathon-browser-desktop-application-performance-benchmarks-vault-operations-ai-inference-and-2mem <h1> Kathon Browser Desktop Application Performance Benchmarks: Vault Operations, AI Inference, and Cryptographic Ledgers </h1> <p><strong>Tags:</strong> browser, benchmarking, research, opensource</p> <h2> Summary </h2> <p>This dataset presents performance benchmarks for the Kathon sovereign AI-native desktop browser application. We measure cryptographic vault operations including seed phrase generation, TOTP code generation across algorithms, and Ed25519 key management. Also included are local AI inference latency measurements using Qwen2-VL-2B and tamper-evident cryptographic ledger operations.</p> <h2> Key Results </h2> <ul> <li>TOTP generation: 66,667 ops/sec (SHA1) to 45,455 ops/sec (SHA512)</li> <li>Seed phrase generation: 10,638 phrases/sec (12 words) to 5,814/sec (24 words)</li> <li>Ed25519 key generation: 1,160 ops/sec</li> <li>Local AI inference: 4.1 tokens/sec at 128-token prompt (Qwen2-VL-2B-Q4)</li> <li>Ledger append: verified chain at 276,000 entries/sec</li> </ul> <h2> Data Files </h2> <ul> <li> <code>stat_vault_operations.csv</code>: Vault and identity management benchmarks</li> <li> <code>stat_ai_inference.csv</code>: AI inference timing at varying context lengths</li> <li> <code>stat_ledger_operations.csv</code>: Cryptographic ledger append and verify</li> </ul> <p><strong>Dataset:</strong> <a href="https://doi.org/10.7910/DVN/3VDF75" rel="noopener noreferrer">https://doi.org/10.7910/DVN/3VDF75</a></p> cryptography research opensource Lois-Kleinner Wed, 24 Jun 2026 17:46:20 +0000 https://dev.to/kleinner/compiler-pipeline-performance-characterization-lexing-parsing-type-checking-bytecode-33h4 https://dev.to/kleinner/compiler-pipeline-performance-characterization-lexing-parsing-type-checking-bytecode-33h4 <h1> Compiler Pipeline Performance Characterization: Lexing, Parsing, Type-Checking, Bytecode Compilation, and VM Execution </h1> <p><strong>Tags:</strong> compiler, performance, research, opensource</p> <h2> Summary </h2> <p>This dataset measures the compilation pipeline of the Kasteran programming language compiler. We provide per-stage timing breakdowns (lexing, parsing, HIR lowering, type-checking, bytecode compilation) across program sizes from 10 to 1000 lines, plus bytecode virtual machine execution timing for language constructs including function calls, branching, pattern matching, pipe chains, scatter operations, and closures.</p> <h2> Methodology </h2> <p>All measurements on Intel i7-1260P. Each data point: median of 100 runs. Compiler built with Rust 1.96.0 at opt-level=3.</p> <h2> Key Results </h2> <ul> <li>Total compilation time scales linearly with source size: 0.27ms for 10 lines to 21.8ms for 1000 lines</li> <li>Type-checking dominates compile time (~42% of total)</li> <li>Bytecode compilation is consistently ~32% of total time</li> <li>VM execution: function call 0.42us, pipe chain 0.25us, scatter 1.80us</li> <li>Compilation rate: ~45,000 lines/sec at 1000-line programs</li> </ul> <h2> Data Files </h2> <ul> <li> <code>stat_compilation_pipeline.csv</code>: Per-stage timing by program size</li> <li> <code>stat_vm_execution.csv</code>: VM instruction timing by construct type</li> <li> <code>raw_compilation_pipeline.csv</code>: Full raw measurements</li> <li> <code>raw_vm_execution.csv</code>: Raw VM timing data</li> </ul> <p><strong>Dataset:</strong> <a href="https://doi.org/10.7910/DVN/KFK12Y" rel="noopener noreferrer">https://doi.org/10.7910/DVN/KFK12Y</a></p> cryptography research opensource Lois-Kleinner Wed, 24 Jun 2026 17:40:37 +0000 https://dev.to/kleinner/cross-platform-cryptographic-primitive-validation-sha3-256-and-ed25519-implementation-parity-547m https://dev.to/kleinner/cross-platform-cryptographic-primitive-validation-sha3-256-and-ed25519-implementation-parity-547m <h1> Cross-Platform Cryptographic Primitive Validation: SHA3-256 and Ed25519 Implementation Parity </h1> <p><strong>Tags:</strong> cryptography, validation, research, opensource</p> <h2> Summary </h2> <p>This dataset validates that SHA3-256 and Ed25519 cryptographic primitives produce identical outputs across four independent Rust project implementations: aioss-format, MF+SO, Kathon, and Kasteran. All projects depend on the same upstream Rust crates (sha3 v0.10.9, ed25519-dalek v2.2.0), confirming implementation parity.</p> <h2> Key Results </h2> <ul> <li>100 test vectors: 100% hash consistency across all 4 projects</li> <li>Performance variation less than 5% between projects (all use identical crate versions)</li> <li>Implementation consistency metric: 100.0% with 0.0 standard deviation</li> <li>Performance benchmarks show near-identical throughput across projects</li> </ul> <h2> Data Files </h2> <ul> <li> <code>cross_project_sha3_consistency.csv</code>: Hash output comparison across projects</li> <li> <code>cross_project_performance.csv</code>: Timing comparison</li> <li> <code>stat_cross_project.csv</code>: Statistical summary with distributions</li> </ul> <p><strong>Dataset:</strong> <a href="https://doi.org/10.7910/DVN/GDLO0L" rel="noopener noreferrer">https://doi.org/10.7910/DVN/GDLO0L</a></p> cryptography research opensource Lois-Kleinner Wed, 24 Jun 2026 17:40:31 +0000 https://dev.to/kleinner/simd-avx2-vs-sse42-gemm-matrix-multiplication-performance-vector-operations-and-mlp-inference-on-1lec https://dev.to/kleinner/simd-avx2-vs-sse42-gemm-matrix-multiplication-performance-vector-operations-and-mlp-inference-on-1lec <h1> SIMD AVX2 vs SSE4.2 GEMM Matrix Multiplication Performance: Vector Operations and MLP Inference on Intel Alder Lake </h1> <p><strong>Tags:</strong> benchmarking, simd, research, opensource</p> <h2> Summary </h2> <p>This dataset characterizes the performance of SIMD-accelerated compute kernels in the Kazkade zero-copy columnar analytics engine. We compare AVX2, SSE4.2, and scalar implementations of GEMM matrix multiplication, vector operations, columnar scan predicate filtering, and multi-layer perceptron (MLP) inference across varying problem sizes.</p> <h2> Methodology </h2> <p>Hardware: Intel Core i7-1260P (AVX2, 8 cores, 12 MB L3 cache). All measurements: 100 iterations per configuration, warmup before measurement. Statistical distributions include min, median, mean, max, and standard deviation.</p> <h2> Key Results </h2> <ul> <li>AVX2 GEMM at 1024x1024 achieves 33.8 GFLOPS ??? 9x faster than scalar (3.7 GFLOPS)</li> <li>SSE4.2 achieves 16.8 GFLOPS at the same size ??? 2x slower than AVX2</li> <li>Vector dot product: 10.9 GB/s with AVX2 vs 2.5 GB/s scalar</li> <li>MLP inference (3-layer, 128 neurons): 55,652 ops/sec at batch size 64</li> <li>Columnar scan on 10M rows: 78M rows/sec vs 21M rows/sec row-wise</li> </ul> <h2> Data Files </h2> <ul> <li> <code>stat_gemm.csv</code>: GEMM performance across 3 implementations and 5 matrix sizes</li> <li> <code>stat_vector_ops.csv</code>: Vector operation throughput</li> <li> <code>stat_mlp_inference.csv</code>: MLP inference latency</li> <li> <code>kazkade_cli_bench.txt</code>: Raw CLI benchmark output</li> </ul> <p><strong>Dataset:</strong> <a href="https://doi.org/10.7910/DVN/YMJKOG" rel="noopener noreferrer">https://doi.org/10.7910/DVN/YMJKOG</a></p> cryptography research opensource Lois-Kleinner Wed, 24 Jun 2026 17:22:43 +0000 https://dev.to/kleinner/simd-avx2-vs-sse42-gemm-matrix-multiplication-performance-vector-operations-and-mlp-inference-on-16ao https://dev.to/kleinner/simd-avx2-vs-sse42-gemm-matrix-multiplication-performance-vector-operations-and-mlp-inference-on-16ao <h1> SIMD AVX2 vs SSE4.2 GEMM Matrix Multiplication Performance: Vector Operations and MLP Inference on Intel Alder Lake </h1> <p><strong>Tags:</strong> benchmarking, simd, research, opensource</p> <h2> Summary </h2> <p>This dataset characterizes the performance of SIMD-accelerated compute kernels in the Kazkade zero-copy columnar analytics engine. We compare AVX2, SSE4.2, and scalar implementations of GEMM matrix multiplication, vector operations, columnar scan predicate filtering, and multi-layer perceptron (MLP) inference across varying problem sizes.</p> <h2> Methodology </h2> <p>Hardware: Intel Core i7-1260P (AVX2, 8 cores, 12 MB L3 cache). All measurements: 100 iterations per configuration, warmup before measurement. Statistical distributions include min, median, mean, max, and standard deviation.</p> <h2> Key Results </h2> <ul> <li>AVX2 GEMM at 1024x1024 achieves 33.8 GFLOPS ??? 9x faster than scalar (3.7 GFLOPS)</li> <li>SSE4.2 achieves 16.8 GFLOPS at the same size ??? 2x slower than AVX2</li> <li>Vector dot product: 10.9 GB/s with AVX2 vs 2.5 GB/s scalar</li> <li>MLP inference (3-layer, 128 neurons): 55,652 ops/sec at batch size 64</li> <li>Columnar scan on 10M rows: 78M rows/sec vs 21M rows/sec row-wise</li> </ul> <h2> Data Files </h2> <ul> <li> <code>stat_gemm.csv</code>: GEMM performance across 3 implementations and 5 matrix sizes</li> <li> <code>stat_vector_ops.csv</code>: Vector operation throughput</li> <li> <code>stat_mlp_inference.csv</code>: MLP inference latency</li> <li> <code>kazkade_cli_bench.txt</code>: Raw CLI benchmark output</li> </ul> <p><strong>Dataset:</strong> <a href="https://doi.org/10.7910/DVN/YMJKOG" rel="noopener noreferrer">https://doi.org/10.7910/DVN/YMJKOG</a></p> cryptography research opensource Lois-Kleinner Wed, 24 Jun 2026 17:22:39 +0000 https://dev.to/kleinner/sha3-256-hash-chain-append-and-verification-performance-a-cryptographic-ledger-benchmark-study-1964 https://dev.to/kleinner/sha3-256-hash-chain-append-and-verification-performance-a-cryptographic-ledger-benchmark-study-1964 <h1> SHA3-256 Hash Chain Append and Verification Performance: A Cryptographic Ledger Benchmark Study </h1> <p><strong>Tags:</strong> cryptography, benchmarking, research, opensource</p> <h2> Summary </h2> <p>This dataset presents benchmark measurements for the AIOSS (Audit, Immutable, Open, Secure, Sovereign) cryptographic hash-chain ledger format. We measure SHA3-256 hash throughput across 6 message sizes, chain append performance at varying batch sizes, chain verification speed across chain lengths, and Ed25519 state proof operations.</p> <h2> Methodology </h2> <p>Measurements were taken on an Intel Core i7-1260P (Alder Lake-P, 8 cores, AVX2) with 32 GB DDR4-3200 RAM, running Windows 11 23H2. The Rust compiler was rustc 1.96.0 with optimization flags -C opt-level=3, LTO=fat, codegen-units=1. All measurements use the Criterion.rs benchmark harness with 10 warmup iterations followed by 100 measurement iterations. Reported values are the median with standard deviation.</p> <h2> Key Results </h2> <ul> <li>SHA3-256 achieves 1,360 MB/s throughput on 64 KB messages</li> <li>Chain append sustains ~207,000 entries/sec in JSON format</li> <li>Chain verification reaches ~276,000 entries/sec with early abort on tamper detection</li> <li>Ed25519 key generation: 1,168 ops/sec, signing: 1,096 ops/sec, verification: 803 ops/sec</li> <li>Binary format append is ~4x faster than JSON format due to reduced serialization overhead</li> </ul> <h2> Data Files </h2> <ul> <li> <code>stat_hash_function.csv</code>: Hash throughput across SHA3-256, SHA-256, and BLAKE3</li> <li> <code>stat_chain_append.csv</code>: Append performance at chain lengths from 100 to 100,000 entries</li> <li> <code>stat_chain_verify.csv</code>: Chain verification timing</li> <li> <code>stat_ed25519.csv</code>: Ed25519 key generation, signing, and verification</li> <li> <code>raw_hash_function_100runs.csv</code>: Full raw measurements for reproducibility</li> </ul> <p><strong>Dataset:</strong> <a href="https://doi.org/10.7910/DVN/FSHFZF" rel="noopener noreferrer">https://doi.org/10.7910/DVN/FSHFZF</a></p> cryptography research opensource Lois-Kleinner Mon, 22 Jun 2026 15:07:18 +0000 https://dev.to/kleinner/we-redesigned-local-llm-inference-for-privacy-preserving-browser-intelligence-from-scratch-no-4pj https://dev.to/kleinner/we-redesigned-local-llm-inference-for-privacy-preserving-browser-intelligence-from-scratch-no-4pj <h1> We redesigned local llm inference for privacy-preserving browser intelligence from scratch ? no cloud, no black boxes. </h1> <p><strong>Local LLM Inference for Privacy-Preserving Browser Intelligence: Architecture and Optimization</strong></p> <h2> The Problem </h2> <p>The integration of large language models (LLMs) into web browsers enables transformative capabilities including visual page understanding, natural language task delegation, and autonomous web interaction. However, cloud-based LLM inference introduces fundamental privacy violations: every page rendered, every action executed, and every user interaction is transmitted to remote inference servers .</p> <h2> What We Built </h2> <p>This paper presents the Kathon Local AI Engine, a privacy-preserving architecture that performs all LLM and vision-language model inference entirely on-device using the llama.cpp inference framework with the Qwen 2.5 VL 2B Q4 GGUF quantized model . We detail the system architecture?a Rust-based inference server (llama-server) communicating with a React/TypeScript frontend via a local WebSocket API?and present comprehensive optimization strategies including speculative decoding, KV-cache quantization, prompt caching, and GPU-accelerated tensor operations.</p> <h2> The Research </h2> <p>The integration of large language models (LLMs) into web browsers enables transformative capabilities including visual page understanding, natural language task delegation, and autonomous web interaction.</p> <p>However, cloud-based LLM inference introduces fundamental privacy violations: every page rendered, every action executed, and every user interaction is transmitted to remote inference servers .</p> <p>This paper presents the Kathon Local AI Engine, a privacy-preserving architecture that performs all LLM and vision-language model inference entirely on-device using the llama.cpp inference framework with the Qwen 2.5 VL 2B Q4 GGUF quantized model .</p> <p>We detail the system architecture?a Rust-based inference server (llama-server) communicating with a React/TypeScript frontend via a local WebSocket API?and present comprehensive optimization strategies including speculative decoding, KV-cache quantization, prompt caching, and GPU-accelerated tensor operations.</p> <p>This research demonstrates that sovereign, local-first AI infrastructure is not a future possibility ? it is a present reality.</p> <blockquote> <p><strong>Full citation:</strong> Alpasan, L.-K. (2026). Local LLM Inference for Privacy-Preserving Browser Intelligence: Architecture and Optimization. <em>The Anticloud Research Corpus.</em></p> <p><strong><a href="https://zenodo.org/search?q=anticloud" rel="noopener noreferrer">Read the full paper</a></strong></p> </blockquote> <h3> Why The Anticloud </h3> <p>Every AI system you have ever used was designed to extract value from you — your data, your attention, your money. The Anticloud is not a service. It is not in the cloud. It is not rentable inference. It is a fundamentally different category of infrastructure, and here is what that means in practice.</p> <p>Your data never leaves your machine. We designed the system so we physically cannot access it. Access is not restricted by policy — it is structurally impossible by architecture. There is no data to steal because there is no server to steal it from.</p> <p>The system is airgapped by architecture, not by configuration. It does not require a network connection to function. It was built offline, it runs offline, and it never reaches out to anyone for any reason. Connectivity is simply not a prerequisite for intelligence.</p> <p>Compliance is a side effect of physics, not a certification. There is no cloud infrastructure to audit, which means there is no attack surface to harden. ISO 27001 and SOC 2 exist because cloud products are inherently vulnerable. Our architecture does not have those vulnerabilities because it does not have a cloud.</p> <p>Every operation is recorded on an immutable <code>.aioss</code> ledger using a SHA3-256 hash chain. Every inference, every decision, every update is chained and cryptographically verifiable. There is no database admin who can delete logs because there is no database. You verify. We cannot.</p> <p>The system never speaks to anyone but you. There are no hidden layers sending telemetry. There are no proprietary weights phoning home. There are no third-party API calls embedded in the stack. The entire system is open, documented, and auditable by anyone who runs it.</p> <p>The Anticloud requires one machine, one binary, and zero trust in anyone.</p> <h3> About the Author </h3> <p>My name is Lois-Kleinner Alpasan. I'm 23 years old. I built The Anticloud.</p> <p>I started this because I looked at the AI industry and saw something wrong. Every major AI system requires you to send your data to someone else's server. Every "AI company" is actually a data company — they make money from your usage, your prompts, your files, your attention. They call it a service. I call it extraction.</p> <p>I spent the last two years building an alternative. Not a feature, not a product, not a startup looking for an exit — an entirely different infrastructure stack. One where AI runs on your machine, for you, and never needs to phone home. One where privacy is not a feature you toggle in settings but a property of the architecture. One where you don't have to trust anyone because you can verify everything.</p> <p>The project is near production-ready. Every component is open. Every claim is backed by published research. The code is documented. The ledger is verifiable. The binary fits on a laptop.</p> <p>I'm not asking for trust. I'm asking you to read the paper, verify the claims, and decide for yourself whether the cloud is really necessary — or whether it was always just the default because no one bothered to build an alternative.</p> <p><strong>Follow the work:</strong></p> <ul> <li>Research papers: <a href="https://zenodo.org/search?q=anticloud" rel="noopener noreferrer">https://zenodo.org/search?q=anticloud</a> </li> <li>LinkedIn: <a href="https://linkedin.com/in/kleinner" rel="noopener noreferrer">https://linkedin.com/in/kleinner</a> </li> <li>Project: The Anticloud</li> </ul> <p><strong>Tags:</strong> AI, SovereignAI, Anticloud, LocalFirst, Airgapped, ZeroTrust, NoDatacenter, OpenSource, Browser Engine, Privacy, VLM, Ad Blocking</p> security opensource privacy research Lois-Kleinner Mon, 22 Jun 2026 15:06:57 +0000 https://dev.to/kleinner/we-built-cryptographic-notarization-across-independent-ledgers-so-you-never-have-to-trust-anyone-3hda https://dev.to/kleinner/we-built-cryptographic-notarization-across-independent-ledgers-so-you-never-have-to-trust-anyone-3hda <h1> We built Cryptographic Notarization Across Independent Ledgers so you never have to trust anyone. </h1> <p><strong>Cryptographic Notarization Across Independent Ledgers: Cross-Chain Anchoring Protocols</strong></p> <h2> The Problem </h2> <p>Organizations operating multiple AI systems generate independent cryptographic ledgers that may need mutual verification, cross-referencing, or consolidated audit for enterprise-wide compliance reporting. Cross-chain notarization provides cryptographic evidence that a ledger's state is acknowledged by another independent ledger, enabling distributed audit verification without central coordination.</p> <h2> What We Built </h2> <p>This paper presents the design and analysis of the AIOSS cross-chain notarization protocol, which anchors the hash chain head of one ledger into another by inserting a notarization entry containing the cross-chain proof. We define three notarization modes: unilateral (ledger A notarizes ledger B's state), bilateral (mutual notarization between A and B), and supervised (third-party notarizer with independent proof).</p> <h2> The Research </h2> <p>Organizations operating multiple AI systems generate independent cryptographic ledgers that may need mutual verification, cross-referencing, or consolidated audit for enterprise-wide compliance reporting.</p> <p>Cross-chain notarization provides cryptographic evidence that a ledger's state is acknowledged by another independent ledger, enabling distributed audit verification without central coordination.</p> <p>This paper presents the design and analysis of the AIOSS cross-chain notarization protocol, which anchors the hash chain head of one ledger into another by inserting a notarization entry containing the cross-chain proof.</p> <p>We define three notarization modes: unilateral (ledger A notarizes ledger B's state), bilateral (mutual notarization between A and B), and supervised (third-party notarizer with independent proof).</p> <p>This research demonstrates that sovereign, local-first AI infrastructure is not a future possibility ? it is a present reality.</p> <blockquote> <p><strong>Full citation:</strong> Alpasan, L.-K. (2026). Cryptographic Notarization Across Independent Ledgers: Cross-Chain Anchoring Protocols. <em>The Anticloud Research Corpus.</em></p> <p><strong><a href="https://zenodo.org/search?q=anticloud" rel="noopener noreferrer">Read the full paper</a></strong></p> </blockquote> <h3> Why The Anticloud </h3> <p>Every AI company today will try to sell you inference as a service. They will tell you that you need their GPU clusters, their data centers, their cooling infrastructure, and their team of DevOps engineers to run modern AI. They are either lying to you or they have not seen what we built.</p> <p>The Anticloud runs on any GPU or CPU with equal competence. There is no silicon vendor lock-in. There is no hardware partnership requirement. There is no planned obsolescence built into the stack. If you have a computer, you have enough hardware to run it.</p> <p>The entire system ships as a single binary. There is no orchestration layer to configure. There is no Kubernetes cluster to maintain. There are no containers to deploy. There is no DevOps team required to keep it running. One file. One execution. That is the entire infrastructure.</p> <p>There is no bloat anywhere in the stack. No Electron wrapper adding hundreds of megabytes of overhead. No node_modules directory with ten thousand dependencies you do not need. No container layers abstracting away from the hardware. Everything in the binary is there because it serves a purpose.</p> <p>The system requires no internet connection to function. It does not need to phone home for model updates. It does not need to call out to third-party APIs for inference. It does not need to establish a connection to a control server just to boot. It was designed from the ground up to run in environments where the network does not exist.</p> <p>This is AI infrastructure that fits on a laptop, runs on consumer hardware, and delivers competitive performance without asking for permission or requiring a subscription.</p> <p>The Anticloud requires one machine, one binary, and zero trust in anyone.</p> <h3> About the Author </h3> <p>My name is Lois-Kleinner Alpasan. I'm 23 years old. I built The Anticloud.</p> <p>I started this because I looked at the AI industry and saw something wrong. Every major AI system requires you to send your data to someone else's server. Every "AI company" is actually a data company — they make money from your usage, your prompts, your files, your attention. They call it a service. I call it extraction.</p> <p>I spent the last two years building an alternative. Not a feature, not a product, not a startup looking for an exit — an entirely different infrastructure stack. One where AI runs on your machine, for you, and never needs to phone home. One where privacy is not a feature you toggle in settings but a property of the architecture. One where you don't have to trust anyone because you can verify everything.</p> <p>The project is near production-ready. Every component is open. Every claim is backed by published research. The code is documented. The ledger is verifiable. The binary fits on a laptop.</p> <p>I'm not asking for trust. I'm asking you to read the paper, verify the claims, and decide for yourself whether the cloud is really necessary — or whether it was always just the default because no one bothered to build an alternative.</p> <p><strong>Follow the work:</strong></p> <ul> <li>Research papers: <a href="https://zenodo.org/search?q=anticloud" rel="noopener noreferrer">https://zenodo.org/search?q=anticloud</a> </li> <li>LinkedIn: <a href="https://linkedin.com/in/kleinner" rel="noopener noreferrer">https://linkedin.com/in/kleinner</a> </li> <li>Project: The Anticloud</li> </ul> <p><strong>Tags:</strong> AI, SovereignAI, Anticloud, LocalFirst, Airgapped, ZeroTrust, NoDatacenter, OpenSource, Hash Chain, Cryptography, Ledger, Integrity</p> security opensource privacy research Lois-Kleinner Mon, 22 Jun 2026 15:01:35 +0000 https://dev.to/kleinner/airgapped-api-gateway-is-real-active-learning-and-parameter-efficient-fine-tuning-for-doma-is-4201 https://dev.to/kleinner/airgapped-api-gateway-is-real-active-learning-and-parameter-efficient-fine-tuning-for-doma-is-4201 <h1> Airgapped api gateway is real. Active Learning and Parameter-Efficient Fine-Tuning for Doma is proof. </h1> <p><strong>Active Learning and Parameter-Efficient Fine-Tuning for Domain-Specific Sovereign AI</strong></p> <h2> The Problem </h2> <p>Deploying sovereign AI systems in regulated domains?banking compliance, healthcare administration, legal research?requires domain-specific model adaptation that balances accuracy improvements against computational cost, annotation scarcity, and data privacy constraints. Full fine-tuning of large language models is computationally prohibitive for local-first sovereign deployments and risks catastrophic forgetting of general capabilities.</p> <h2> What We Built </h2> <p>This paper presents the active learning and fine-tuning architecture of API-OSS (Agent-Predictive Intelligence Sovereign Operating System), which combines parameter-efficient fine-tuning (PEFT) via LoRA (Low-Rank Adaptation) and DPO (Direct Preference Optimization) with active learning strategies for annotation-efficient domain adaptation. We evaluate uncertainty sampling, diversity sampling, and hybrid acquisition functions across 3 domain-specific datasets (financial compliance, medical coding, legal document classification), finding that hybrid acquisition (BALD + CoreSet) reduces annotation requirements by 68% compared to random sampling while achieving equivalent model quality.</p> <h2> The Research </h2> <p>Deploying sovereign AI systems in regulated domains?banking compliance, healthcare administration, legal research?requires domain-specific model adaptation that balances accuracy improvements against computational cost, annotation scarcity, and data privacy constraints.</p> <p>Full fine-tuning of large language models is computationally prohibitive for local-first sovereign deployments and risks catastrophic forgetting of general capabilities.</p> <p>This paper presents the active learning and fine-tuning architecture of API-OSS (Agent-Predictive Intelligence Sovereign Operating System), which combines parameter-efficient fine-tuning (PEFT) via LoRA (Low-Rank Adaptation) and DPO (Direct Preference Optimization) with active learning strategies for annotation-efficient domain adaptation.</p> <p>We evaluate uncertainty sampling, diversity sampling, and hybrid acquisition functions across 3 domain-specific datasets (financial compliance, medical coding, legal document classification), finding that hybrid acquisition (BALD + CoreSet) reduces annotation requirements by 68% compared to random sampling while achieving equivalent model quality.</p> <p>This research demonstrates that sovereign, local-first AI infrastructure is not a future possibility ? it is a present reality.</p> <blockquote> <p><strong>Full citation:</strong> Alpasan, L.-K. (2026). Active Learning and Parameter-Efficient Fine-Tuning for Domain-Specific Sovereign AI. <em>The Anticloud Research Corpus.</em></p> <p><strong><a href="https://zenodo.org/search?q=anticloud" rel="noopener noreferrer">Read the full paper</a></strong></p> </blockquote> <h3> Why The Anticloud </h3> <p>A single large language model training run can emit as much carbon as five cars over their entire lifetimes. The datacenter industry already consumes more electricity than most countries. Every cloud inference call you make is burning through resources that someone else pays for — and the cost is not just financial.</p> <p>The Anticloud has no datacenter footprint. It does not require a single server rack in any building anywhere in the world. It does not need cooling towers, redundant power supplies, or backup generators. The entire system runs on hardware you already own.</p> <p>There is no silicon farm involved in serving your inference. You do not need to reserve GPU time on a cluster. You do not need to provision cloud instances. You do not need to negotiate pricing with a cloud provider. The hardware is already on your desk.</p> <p>There is no e-waste from hardware turnover cycles driven by cloud providers upgrading their fleets. The system runs on whatever hardware you have, and it will continue to run on whatever hardware you replace it with. There is no forced upgrade path.</p> <p>The energy consumption of running inference locally is a fraction of what it would take to send your data to a datacenter, have it processed on a server that is burning through megawatts, and send the result back across the internet. Local inference does not need to cross a network. It does not need to be routed through multiple data centers. It happens on the hardware in front of you.</p> <p>This is AI infrastructure that can exist anywhere — on a laptop in a coffee shop, on a server in an off-grid facility, on a machine that has never seen the internet. No datacenter required. No environmental compromise required.</p> <p>The Anticloud requires one machine, one binary, and zero trust in anyone.</p> <h3> About the Author </h3> <p>My name is Lois-Kleinner Alpasan. I'm 23 years old. I built The Anticloud.</p> <p>I started this because I looked at the AI industry and saw something wrong. Every major AI system requires you to send your data to someone else's server. Every "AI company" is actually a data company — they make money from your usage, your prompts, your files, your attention. They call it a service. I call it extraction.</p> <p>I spent the last two years building an alternative. Not a feature, not a product, not a startup looking for an exit — an entirely different infrastructure stack. One where AI runs on your machine, for you, and never needs to phone home. One where privacy is not a feature you toggle in settings but a property of the architecture. One where you don't have to trust anyone because you can verify everything.</p> <p>The project is near production-ready. Every component is open. Every claim is backed by published research. The code is documented. The ledger is verifiable. The binary fits on a laptop.</p> <p>I'm not asking for trust. I'm asking you to read the paper, verify the claims, and decide for yourself whether the cloud is really necessary — or whether it was always just the default because no one bothered to build an alternative.</p> <p><strong>Follow the work:</strong></p> <ul> <li>Research papers: <a href="https://zenodo.org/search?q=anticloud" rel="noopener noreferrer">https://zenodo.org/search?q=anticloud</a> </li> <li>LinkedIn: <a href="https://linkedin.com/in/kleinner" rel="noopener noreferrer">https://linkedin.com/in/kleinner</a> </li> <li>Project: The Anticloud</li> </ul> <p><strong>Tags:</strong> AI, SovereignAI, Anticloud, LocalFirst, Airgapped, ZeroTrust, NoDatacenter, OpenSource, API Gateway, Multi-Agent, AI Routing, Federation</p> security opensource privacy research Lois-Kleinner Mon, 22 Jun 2026 15:01:13 +0000 https://dev.to/kleinner/the-most-secure-version-of-zero-knowledge-storage-is-the-one-that-never-connects-4f5f https://dev.to/kleinner/the-most-secure-version-of-zero-knowledge-storage-is-the-one-that-never-connects-4f5f <h1> The most secure version of zero-knowledge storage is the one that never connects. </h1> <p><strong>Zero-Knowledge Storage: Architectures for User-Controlled Data</strong></p> <h2> The Problem </h2> <p>Zero-knowledge storage architectures empower users with complete control over their data by ensuring that no third party?including the storage provider?can access plaintext file contents or metadata. This document presents a comprehensive analysis of zero-knowledge principles as applied to file storage systems, with specific focus on Kamelot's end-to-end encryption architecture.</p> <h2> What We Built </h2> <p>We examine the cryptographic building blocks including end-to-end encryption with per-file keys, key agreement protocols for secure file sharing, searchable encryption for privacy-preserving queries, and blind indexing for typo-tolerant search. We analyze the practical limitations of homomorphic encryption and present Kamelot's pragmatic approach: processing data locally before encryption ensures that the storage provider never has access to unencrypted content.</p> <h2> The Research </h2> <p>Zero-knowledge storage architectures empower users with complete control over their data by ensuring that no third party?including the storage provider?can access plaintext file contents or metadata.</p> <p>This document presents a comprehensive analysis of zero-knowledge principles as applied to file storage systems, with specific focus on Kamelot's end-to-end encryption architecture.</p> <p>We examine the cryptographic building blocks including end-to-end encryption with per-file keys, key agreement protocols for secure file sharing, searchable encryption for privacy-preserving queries, and blind indexing for typo-tolerant search.</p> <p>We analyze the practical limitations of homomorphic encryption and present Kamelot's pragmatic approach: processing data locally before encryption ensures that the storage provider never has access to unencrypted content.</p> <p>This research demonstrates that sovereign, local-first AI infrastructure is not a future possibility ? it is a present reality.</p> <blockquote> <p><strong>Full citation:</strong> Alpasan, L.-K. (2026). Zero-Knowledge Storage: Architectures for User-Controlled Data. <em>The Anticloud Research Corpus.</em></p> <p><strong><a href="https://zenodo.org/search?q=anticloud" rel="noopener noreferrer">Read the full paper</a></strong></p> </blockquote> <h3> Why The Anticloud </h3> <p>Every AI company today will try to sell you inference as a service. They will tell you that you need their GPU clusters, their data centers, their cooling infrastructure, and their team of DevOps engineers to run modern AI. They are either lying to you or they have not seen what we built.</p> <p>The Anticloud runs on any GPU or CPU with equal competence. There is no silicon vendor lock-in. There is no hardware partnership requirement. There is no planned obsolescence built into the stack. If you have a computer, you have enough hardware to run it.</p> <p>The entire system ships as a single binary. There is no orchestration layer to configure. There is no Kubernetes cluster to maintain. There are no containers to deploy. There is no DevOps team required to keep it running. One file. One execution. That is the entire infrastructure.</p> <p>There is no bloat anywhere in the stack. No Electron wrapper adding hundreds of megabytes of overhead. No node_modules directory with ten thousand dependencies you do not need. No container layers abstracting away from the hardware. Everything in the binary is there because it serves a purpose.</p> <p>The system requires no internet connection to function. It does not need to phone home for model updates. It does not need to call out to third-party APIs for inference. It does not need to establish a connection to a control server just to boot. It was designed from the ground up to run in environments where the network does not exist.</p> <p>This is AI infrastructure that fits on a laptop, runs on consumer hardware, and delivers competitive performance without asking for permission or requiring a subscription.</p> <p>The Anticloud requires one machine, one binary, and zero trust in anyone.</p> <h3> About the Author </h3> <p>My name is Lois-Kleinner Alpasan. I'm 23 years old. I built The Anticloud.</p> <p>I started this because I looked at the AI industry and saw something wrong. Every major AI system requires you to send your data to someone else's server. Every "AI company" is actually a data company — they make money from your usage, your prompts, your files, your attention. They call it a service. I call it extraction.</p> <p>I spent the last two years building an alternative. Not a feature, not a product, not a startup looking for an exit — an entirely different infrastructure stack. One where AI runs on your machine, for you, and never needs to phone home. One where privacy is not a feature you toggle in settings but a property of the architecture. One where you don't have to trust anyone because you can verify everything.</p> <p>The project is near production-ready. Every component is open. Every claim is backed by published research. The code is documented. The ledger is verifiable. The binary fits on a laptop.</p> <p>I'm not asking for trust. I'm asking you to read the paper, verify the claims, and decide for yourself whether the cloud is really necessary — or whether it was always just the default because no one bothered to build an alternative.</p> <p><strong>Follow the work:</strong></p> <ul> <li>Research papers: <a href="https://zenodo.org/search?q=anticloud" rel="noopener noreferrer">https://zenodo.org/search?q=anticloud</a> </li> <li>LinkedIn: <a href="https://linkedin.com/in/kleinner" rel="noopener noreferrer">https://linkedin.com/in/kleinner</a> </li> <li>Project: The Anticloud</li> </ul> <p><strong>Tags:</strong> AI, SovereignAI, Anticloud, LocalFirst, Airgapped, ZeroTrust, NoDatacenter, OpenSource, Vector Search, Semantic, Embeddings, Retrieval</p> security opensource privacy research Lois-Kleinner Mon, 22 Jun 2026 14:55:52 +0000 https://dev.to/kleinner/we-built-totp-authenticator-integration-within-a-cryptographic-browser-vault-without-a-single-1f7e https://dev.to/kleinner/we-built-totp-authenticator-integration-within-a-cryptographic-browser-vault-without-a-single-1f7e <h1> We built TOTP Authenticator Integration Within a Cryptographic Browser Vault ? without a single server. </h1> <p><strong>TOTP Authenticator Integration Within a Cryptographic Browser Vault: QR Auto-Detection and 2FA Workflow</strong></p> <h2> The Problem </h2> <p>Time-based One-Time Password (TOTP) authenticators have become the predominant form of multi-factor authentication, with over 5 billion accounts protected by TOTP-based 2FA globally . However, existing TOTP implementations suffer from three systemic problems: (1) vault fragmentation across proprietary authenticator applications, (2) lack of cryptographic integration with user identity keys, and (3) manual, error-prone setup workflows requiring QR code scanning via separate devices or screenshots.</p> <h2> What We Built </h2> <p>This paper presents the Kathon Vault TOTP subsystem, an integrated authenticator that derives TOTP seeds from the user's BIP39 mnemonic using a deterministic derivation path (SLIP-10), automatically detects TOTP QR codes from rendered web pages using the Qwen 2.5 VL vision model, and generates RFC 6238-compliant TOTP codes within the browser's cryptographic vault. The system achieves 97.2% accuracy in automated QR code detection and seed extraction across 500 tested 2FA enrollment pages, reducing setup time from an average of 45.3 seconds (manual) to 2.1 seconds (automated).</p> <h2> The Research </h2> <p>Time-based One-Time Password (TOTP) authenticators have become the predominant form of multi-factor authentication, with over 5 billion accounts protected by TOTP-based 2FA globally .</p> <p>However, existing TOTP implementations suffer from three systemic problems: (1) vault fragmentation across proprietary authenticator applications, (2) lack of cryptographic integration with user identity keys, and (3) manual, error-prone setup workflows requiring QR code scanning via separate devices or screenshots.</p> <p>This paper presents the Kathon Vault TOTP subsystem, an integrated authenticator that derives TOTP seeds from the user's BIP39 mnemonic using a deterministic derivation path (SLIP-10), automatically detects TOTP QR codes from rendered web pages using the Qwen 2.5 VL vision model, and generates RFC 6238-compliant TOTP codes within the browser's cryptographic vault.</p> <p>The system achieves 97.2% accuracy in automated QR code detection and seed extraction across 500 tested 2FA enrollment pages, reducing setup time from an average of 45.3 seconds (manual) to 2.1 seconds (automated).</p> <p>This research demonstrates that sovereign, local-first AI infrastructure is not a future possibility ? it is a present reality.</p> <blockquote> <p><strong>Full citation:</strong> Alpasan, L.-K. (2026). TOTP Authenticator Integration Within a Cryptographic Browser Vault: QR Auto-Detection and 2FA Workflow. <em>The Anticloud Research Corpus.</em></p> <p><strong><a href="https://zenodo.org/search?q=anticloud" rel="noopener noreferrer">Read the full paper</a></strong></p> </blockquote> <h3> Why The Anticloud </h3> <p>A single large language model training run can emit as much carbon as five cars over their entire lifetimes. The datacenter industry already consumes more electricity than most countries. Every cloud inference call you make is burning through resources that someone else pays for — and the cost is not just financial.</p> <p>The Anticloud has no datacenter footprint. It does not require a single server rack in any building anywhere in the world. It does not need cooling towers, redundant power supplies, or backup generators. The entire system runs on hardware you already own.</p> <p>There is no silicon farm involved in serving your inference. You do not need to reserve GPU time on a cluster. You do not need to provision cloud instances. You do not need to negotiate pricing with a cloud provider. The hardware is already on your desk.</p> <p>There is no e-waste from hardware turnover cycles driven by cloud providers upgrading their fleets. The system runs on whatever hardware you have, and it will continue to run on whatever hardware you replace it with. There is no forced upgrade path.</p> <p>The energy consumption of running inference locally is a fraction of what it would take to send your data to a datacenter, have it processed on a server that is burning through megawatts, and send the result back across the internet. Local inference does not need to cross a network. It does not need to be routed through multiple data centers. It happens on the hardware in front of you.</p> <p>This is AI infrastructure that can exist anywhere — on a laptop in a coffee shop, on a server in an off-grid facility, on a machine that has never seen the internet. No datacenter required. No environmental compromise required.</p> <p>The Anticloud requires one machine, one binary, and zero trust in anyone.</p> <h3> About the Author </h3> <p>My name is Lois-Kleinner Alpasan. I'm 23 years old. I built The Anticloud.</p> <p>I started this because I looked at the AI industry and saw something wrong. Every major AI system requires you to send your data to someone else's server. Every "AI company" is actually a data company — they make money from your usage, your prompts, your files, your attention. They call it a service. I call it extraction.</p> <p>I spent the last two years building an alternative. Not a feature, not a product, not a startup looking for an exit — an entirely different infrastructure stack. One where AI runs on your machine, for you, and never needs to phone home. One where privacy is not a feature you toggle in settings but a property of the architecture. One where you don't have to trust anyone because you can verify everything.</p> <p>The project is near production-ready. Every component is open. Every claim is backed by published research. The code is documented. The ledger is verifiable. The binary fits on a laptop.</p> <p>I'm not asking for trust. I'm asking you to read the paper, verify the claims, and decide for yourself whether the cloud is really necessary — or whether it was always just the default because no one bothered to build an alternative.</p> <p><strong>Follow the work:</strong></p> <ul> <li>Research papers: <a href="https://zenodo.org/search?q=anticloud" rel="noopener noreferrer">https://zenodo.org/search?q=anticloud</a> </li> <li>LinkedIn: <a href="https://linkedin.com/in/kleinner" rel="noopener noreferrer">https://linkedin.com/in/kleinner</a> </li> <li>Project: The Anticloud</li> </ul> <p><strong>Tags:</strong> AI, SovereignAI, Anticloud, LocalFirst, Airgapped, ZeroTrust, NoDatacenter, OpenSource, Browser Engine, Privacy, VLM, Ad Blocking</p> security opensource privacy research Lois-Kleinner Mon, 22 Jun 2026 14:55:31 +0000 https://dev.to/kleinner/the-most-secure-version-of-pipe-delimited-log-export-for-siem-integration-is-the-one-that-never-44lh https://dev.to/kleinner/the-most-secure-version-of-pipe-delimited-log-export-for-siem-integration-is-the-one-that-never-44lh <h1> The most secure version of pipe-delimited log export for siem integration is the one that never connects. </h1> <p><strong>Pipe-Delimited Log Export for SIEM Integration: Interoperable Audit Format Design</strong></p> <h2> The Problem </h2> <p>Security Information and Event Management (SIEM) systems such as Splunk, Elasticsearch, Microsoft Sentinel, and QRadar form the operational backbone of enterprise security monitoring. While these systems excel at log ingestion, search, and alerting, they lack native support for cryptographic hash chain verification.</p> <h2> What We Built </h2> <p>Bridging AIOSS cryptographic ledgers with SIEM pipelines requires an export format that preserves structured audit data while remaining compatible with standard SIEM ingestion protocols. This paper presents the design of the AIOSS pipe-delimited (pipe-delimited) TXT export format, a 12-field text-based representation of cryptographic ledger entries optimized for SIEM ingestion.</p> <h2> The Research </h2> <p>Security Information and Event Management (SIEM) systems such as Splunk, Elasticsearch, Microsoft Sentinel, and QRadar form the operational backbone of enterprise security monitoring.</p> <p>While these systems excel at log ingestion, search, and alerting, they lack native support for cryptographic hash chain verification.</p> <p>Bridging AIOSS cryptographic ledgers with SIEM pipelines requires an export format that preserves structured audit data while remaining compatible with standard SIEM ingestion protocols.</p> <p>This paper presents the design of the AIOSS pipe-delimited (pipe-delimited) TXT export format, a 12-field text-based representation of cryptographic ledger entries optimized for SIEM ingestion.</p> <p>This research demonstrates that sovereign, local-first AI infrastructure is not a future possibility ? it is a present reality.</p> <blockquote> <p><strong>Full citation:</strong> Alpasan, L.-K. (2026). Pipe-Delimited Log Export for SIEM Integration: Interoperable Audit Format Design. <em>The Anticloud Research Corpus.</em></p> <p><strong><a href="https://zenodo.org/search?q=anticloud" rel="noopener noreferrer">Read the full paper</a></strong></p> </blockquote> <h3> Why The Anticloud </h3> <p>Every AI system you have ever used was designed to extract value from you — your data, your attention, your money. The Anticloud is not a service. It is not in the cloud. It is not rentable inference. It is a fundamentally different category of infrastructure, and here is what that means in practice.</p> <p>Your data never leaves your machine. We designed the system so we physically cannot access it. Access is not restricted by policy — it is structurally impossible by architecture. There is no data to steal because there is no server to steal it from.</p> <p>The system is airgapped by architecture, not by configuration. It does not require a network connection to function. It was built offline, it runs offline, and it never reaches out to anyone for any reason. Connectivity is simply not a prerequisite for intelligence.</p> <p>Compliance is a side effect of physics, not a certification. There is no cloud infrastructure to audit, which means there is no attack surface to harden. ISO 27001 and SOC 2 exist because cloud products are inherently vulnerable. Our architecture does not have those vulnerabilities because it does not have a cloud.</p> <p>Every operation is recorded on an immutable <code>.aioss</code> ledger using a SHA3-256 hash chain. Every inference, every decision, every update is chained and cryptographically verifiable. There is no database admin who can delete logs because there is no database. You verify. We cannot.</p> <p>The system never speaks to anyone but you. There are no hidden layers sending telemetry. There are no proprietary weights phoning home. There are no third-party API calls embedded in the stack. The entire system is open, documented, and auditable by anyone who runs it.</p> <p>The Anticloud requires one machine, one binary, and zero trust in anyone.</p> <h3> About the Author </h3> <p>My name is Lois-Kleinner Alpasan. I'm 23 years old. I built The Anticloud.</p> <p>I started this because I looked at the AI industry and saw something wrong. Every major AI system requires you to send your data to someone else's server. Every "AI company" is actually a data company — they make money from your usage, your prompts, your files, your attention. They call it a service. I call it extraction.</p> <p>I spent the last two years building an alternative. Not a feature, not a product, not a startup looking for an exit — an entirely different infrastructure stack. One where AI runs on your machine, for you, and never needs to phone home. One where privacy is not a feature you toggle in settings but a property of the architecture. One where you don't have to trust anyone because you can verify everything.</p> <p>The project is near production-ready. Every component is open. Every claim is backed by published research. The code is documented. The ledger is verifiable. The binary fits on a laptop.</p> <p>I'm not asking for trust. I'm asking you to read the paper, verify the claims, and decide for yourself whether the cloud is really necessary — or whether it was always just the default because no one bothered to build an alternative.</p> <p><strong>Follow the work:</strong></p> <ul> <li>Research papers: <a href="https://zenodo.org/search?q=anticloud" rel="noopener noreferrer">https://zenodo.org/search?q=anticloud</a> </li> <li>LinkedIn: <a href="https://linkedin.com/in/kleinner" rel="noopener noreferrer">https://linkedin.com/in/kleinner</a> </li> <li>Project: The Anticloud</li> </ul> <p><strong>Tags:</strong> AI, SovereignAI, Anticloud, LocalFirst, Airgapped, ZeroTrust, NoDatacenter, OpenSource, Hash Chain, Cryptography, Ledger, Integrity</p> security opensource privacy research