Is there an identity provider I can host myself?

Lately, I've been building a lot of services at work, and for each one, I have to program the authentication and authorization, which results in many credentials for services provided by the same vendor. So, I had the idea of ​​using an identity provider, similar to how Google login works.


Before delving into researching what's needed to develop an identity provider on my own, I wanted to see if anything already exists in the open-source community.


The requirements are simple: the ability to identify yourself as a user in a service; the ability for the service to revoke user access at any time; the ability to manage that user's permissions to certain modules within the system; and the ability to create a revocable API key, meaning that access can also be server-to-server, not just client-to-server.


The preferred method is JWT, in most cases through its header, but in certain specific cases using query parameters.


I hope I've explained myself clearly.


Clarification: I intend to use this not only at work, but also in services I create on my own where I want to control access for friends and family who also use them.

https://redd.it/1pjwvwz
@r_opensource

AMLTRIX: an open source knowledge graph to standardize AML investigations (think MITRE ATT&CK for money laundering)

Hi r/opensource,

I wanted to share a project we’ve been working on called AMLTRIX. It's an open source knowledge graph dedicated to standardizing the AML investigation process and the fight against financial crime. As far as we know, it’s the first of its kind (!!)

So far we haven’t done a lot of marketing for this since, well, it’s open source, and the budget for it is minimal, but whoever tries it, usually loves it.

If you work in AML, you might know that banks and regulators work in silos. Every institution builds its own proprietary rule sets and definitions, creating a lack of a common language for money laundering management.
So we hope that our "Periodic table" for AML will be a solution.

We decided to apply cybersecurity principles (specifically the MITRE ATT&CK framework) to financial crime. We analyzed over 1,000 regulatory sources ((FATF, FinCEN, EU Directives, etc.) to build a unified, machine readable knowledge graph that maps out the "Kill Chain" of money laundering.

AMLTRIX currently defines 250+ adversarial techniques and 1,950+ defensive mappings. It is designed to help analysts reduce duplicative work in financial crime investigations and helps devs build risk-based AML programs. We’ve structured it to cover everything from traditional methods to emerging digital threats.

For example, the dataset includes detailed mappings for:

- Traditional typologies: techniques like structuring, smurfing, and cuckoo smurfing.

- Complex evasion: trade-based money laundering (TBML), export overvaluation, etc.

- Crypto & digital assets: cryptojacking, crypto ATM mules, and NFT/Metaverse based asset transfers.

- Sanctions evasion, underground banking and maaaany more.

We made all the typologies machine-readable. We want to enable developers to build better AI detection models and transaction monitoring systems that can flag complex patterns across different institutions.

Of course, it’s free to access and open for contribution.
We are inviting data scientists, devs, and investigators to critique the model, add missing techniques, or use the data to train new open source models. Also, do you think there’s any other sub that would find this useful instead of spammy? Thank you! Oh, and AMA!

(Full Disclosure: Although the project is OS, the development was started by AMLYZE team. I am part of that team too. We built this because we were frustrated by the lack of standardized data in the industry, we have no plans to somehow monetize this or whatever)

Repository: https://github.com/Amlyze/amltrix-data
Web: https://framework.amltrix.com/

https://redd.it/1pjwcm0
@r_opensource

Chess-tui: Play lichess from your terminal
https://github.com/thomas-mauran/chess-tui

https://redd.it/1pjzfb4
@r_opensource

Turn any long webpage/document into one infinite vertical screenshot

Built this because manually screenshotting long web pages is masochism. It watches while you scroll automatically grabbibng screenshots and stitches them together at the end.

Unlike browser extensions that break on modern websites or manual tools, this actually handles dynamic content properly most of the times. All alternatives I found fail on scrolling elements or en up needing manual intervention. This works with any application and deals with moving parts, headers and backgrounds better.

GitHub: https://github.com/esauvisky/emingle (has video proof it actually works)

Requires a bit of Python knowledge to use for the time being, but if enough people ask for it I can make it easier to use.

https://redd.it/1pju62k
@r_opensource

Blast – An Open-Source Cross-Platform Password & Secrets Manager

Hey everyone! I am here to introduce you Blast, an open-source password and secrets keeper written fully in Flutter — available across Android, iOS, Windows, Web, macOS (and Linux if you build it yourself).

I built Blast because I wanted something simple, privacy-first, and transparent:

No locked-in cloud service
A single encrypted file holding all your credentials
Works across devices and operating systems
Open source → inspect it, improve it, fork it
Free to use — built for the community, and because I needed it myself 🙂

What makes Blast different?

No proprietary cloud — choose your own (OneDrive, Dropbox, local filesystem, more planned)
Entire vault = one encrypted JSON file
AES-256 encryption
Multi-platform: one codebase, many devices
Self-hostable, portable, extensible

Features

Advanced search & sorting
Favorites + tags
Dynamic attributes per entry
Unlimited cards/fields (device-memory based)
Markdown notes
Built-in password generator
Attribute visualization as text / QR / barcode
Import support (KeePass XML, Password Safe XML)
Dark/Light theme
Growing cloud support matrix

Try it out:

🌐 Web: https://blast.duckiesfarm.com

Windows Store: https://apps.microsoft.com/detail/9NZ7L5SNVSXX

Android / iOS / macOS TestFlight: DM me if you’d like access

Linux: build locally

GitHub repo with full README + source here: https://github.com/nicolgit/blast

I built Blast because I needed a free, open, cross-platform password manager — and I’d love to share it with anyone who might find it useful. If you try it out, any feedback or suggestions are hugely appreciated! Bug reports, features, opinions — everything helps. 🙏

Thanks for reading! 🔥

https://redd.it/1pk2qns
@r_opensource

MinIO is dead but there is a new one

MinIO is no longer open source and RustFS is kinda fishy since their website has tons of fake testimonials etc.

There is a new one called Alarik (alarik.io) and is completely open source.

It seems like there are not a lot of open source s3 compatible object stores out there right? Which ones are you guys migrating to and why?

Would love to start a conversation about this!

https://redd.it/1pk3pz1
@r_opensource

Disappointed after outreachy final result

Sorry, I had to call this out. This year’s outreachy selected interns seems extremely biased and without any background checks.

They selected college students from India in the fall term which was strictly prohibited in their very own guidelines.

Hardly anyone from lgbtq community instead they took straight men. This was supposed to support beginners but they have completely ignored their very own rules.

And I mean your participants can lie but isn’t it upto the organisers to do background checks before selecting people.

My advice: People just lie and apply because neither the maintainers nor the organisers give a fuck. The current list of selected interns is a prime example.


https://redd.it/1pk5zg4
@r_opensource

USBSniff 0.1.0-beta - A Portable System Investigator written in Python easy to setup.
https://github.com/Davvois/USBSniff

https://redd.it/1pk6p4x
@r_opensource

Impressive Open Source Project: "Eaglercraft" - A full port of Minecraft 1.8 Java to JavaScript/WebGL via TeaVM

I wanted to highlight this project because the engineering is fascinating.

The developer (lax1dude) managed to decompile the original Minecraft 1.8 source and utilize a tool called TeaVM to compile the Java bytecode directly into JavaScript. It replaces the LWJGL OpenGL calls with a custom WebGL implementation.

The result is the full game engine running natively in the browser without plugins.

Live Mirror(s): 

https://eaglercraft.com/

https://eaglercraft.ir/

https://eaglercraft.dev/


Source code: (reddit auto removes it for some reasons, check out the first link under "source" section)

https://redd.it/1pk374s
@r_opensource

kew, a terminal music player, version 3.7 has just been released
https://github.com/ravachol/kew

https://redd.it/1pk9h25
@r_opensource

Open source etiquette

I’m new to open source. A reviewer and I have gone back and forth on several small mistakes I made (code style issues, etc.). When they caught another oversight, I replied “Good catch, fixed.”
They responded saying that’s not how you talk to someone reviewing your work, comparing it to saying “good catch” to a teacher grading your exam.
Was I being rude? Maybe they’re just frustrated with my repeated mistakes?

AI usage: grammar


https://redd.it/1pk8hcq
@r_opensource

Maxun v0.0.30 | SDK + AI Mode

Hey everyone! We just shipped a new update — this one adds two big things we’ve been working towards for a while.

For anyone new: Maxun is an open-source, self-hostable web data extraction platform.

We’re \~99% OSS, and features like scheduling, webhooks, and full robot management are all available in open source** & not gated behind a cloud plan.

GitHub: https://github.com/getmaxun/maxun

AI Mode (LLM Extraction) - Beta

You can now build extract robots by simply describing what you want in plain language. No recording needed (Recorder mode still exists!)
Example: Extract Names, Rating & Duration of Top 50 Movies from IMDb
[https://github.com/user-attachments/assets/f714e860-58d6-44ed-bbcd-c9374b629384](https://github.com/user-attachments/assets/f714e860-58d6-44ed-bbcd-c9374b629384)
Works with local LLMs via Ollama, or cloud models if you prefer accuracy.
Docs: [https://docs.maxun.dev/robot/extract/llm-extraction](https://docs.maxun.dev/robot/extract/llm-extraction)

Node.js SDK (v0.0.1)

This has been requested a few times, and we are happy to finally bring it to you.
Repository: [https://github.com/getmaxun/node-sdk](https://github.com/getmaxun/node-sdk)
Supports both extraction styles


LLM extraction (describe what you want)

Example: Extract the first 15 Company Names, Denoscriptions and Batch Information from YC
https://github.com/user-attachments/assets/71a6f10b-5b2a-45dd-9ef7-53d0bcf2b76d

Non-LLM extraction (selectors, auto pagination, auto list capture)

Auto List Capture https://docs.maxun.dev/sdk/sdk-extract#1-auto-list-capture is something we haven’t seen in any other non-LLM SDK — one selector, and Maxun figures out the fields inside each item.

Know more: https://docs.maxun.dev/category/sdk

Would love any feedback — this release is still beta and will get more stable through the month.

https://redd.it/1pkdd0s
@r_opensource

GitHub - necdetsanli/do-not-ghost-me: Anonymous reports and stats about recruitment ghosting. Next.js + PostgreSQL, privacy-first and open source.
https://github.com/necdetsanli/do-not-ghost-me

https://redd.it/1pk72gf
@r_opensource

( Open-Source Concept ) Auto-Disable 2FA for Inactive Emails

( https://github.com/Shyranoia/2FA-Auto-Disable )

Hello, this is a proof-to-concept project from GitHub that helps companies and freelancers without the hassle of technical support.

It's a concept, not a program, but its implementation is essential for any email, depending on the scenario where 2AF has been lost. (No Reviews, Notifications Only) And Feedbacks/Reviews/Opinions are welcome.


https://redd.it/1pk78x5
@r_opensource

What is Digital Provenance? (In 30 Seconds or Less)
https://youtube.com/shorts/O_tSwkmnCSo

https://redd.it/1pk7hqx
@r_opensource

🔧 TheITApprentice — Looking for Brutal, Technical Feedback

Hey all 👋

Not selling anything, not hyping a startup – I just want people who know their stuff to tear this apart.

Repo: [**https://github.com/andynaisbitt/Fast-React-CMS**](https://github.com/andynaisbitt/Fast-React-CMS)
Live demo: [**https://theitapprentice.com**](https://theitapprentice.com)

Stack: TypeScript, React, FastAPI, Postgres, SQLAlchemy, Alembic.

# What I’m asking for

🔥 **Roast the code quality**
Tell me what’s messy, over-engineered, under-engineered, or just weird.

🔒 **Try to break the security (theoretically)**
I’m particularly interested in:

* SQL injection possibilities (SQLAlchemy usage, raw queries, etc.)
* XSS vectors (SVG uploads, user input, content rendering)
* CSRF token implementation
* JWT auth & refresh-token rotation
* Any auth / session / role issues

🏗️ **Review the architecture**

* Does the folder/domain structure make sense?
* Any obvious scaling bottlenecks?
* Anything you’d completely rethink?

Also curious about:

* Alembic migration strategy
* React patterns / performance issues
* API design (RESTfulness, error handling, versioning)

If you spot anything *seriously* dangerous (especially security-wise), feel free to DM me instead of dropping a 0-day in the comments 😅

I’ve worked in IT for \~10 years, and this is me trying to build something lightweight and cheap to host (currently \~£0.30/day). I fully expect parts of it to suck – please tell me **where** and **why** so I can fix it.

Thanks in advance 🙏
Andy

https://redd.it/1pkcc2n
@r_opensource

Encryptable - Zero-knowledge MongoDB ODM where not even the developer can access user data

# Encryptable

I built a zero-knowledge Spring Data MongoDB framework where even I (the developer) can't access user data.
Entity IDs are cryptographically derived from user secrets (no username→ID mappings), all data is encrypted with keys derived on-demand (no key storage), and the database contains only encrypted blobs.
This eliminates legal liability for data breaches—as you can't leak what you can't access.
Released as Encryptable - open-source Kotlin/Spring framework with O(1) secret-based lookups.

---

## Why I build this

I started building a file upload service and realized something terrifying: I didn't want legal liability for user data if breached.

Even with "secure" systems, developers face two fundamental problems:

### 1. Legal Liability (Developer Risk)

Even with encrypted data:
- Developer/company can decrypt user data (keys stored somewhere)
- Data breaches expose you to lawsuits - "You had access, so you're responsible"
- Compliance burden - Must prove you protected data adequately
- Trust issue - Users must trust you won't access their data

### 2. Inefficient Addressing (Technical Issue)

The standard pattern requires mapping:

username → user_id → encrypted_data

This creates problems:
- Username leaks reveal identity even if passwords are hashed
- Requires queryable index (username field must be searchable)
- Two-step lookup - Query username, then fetch data (not O(1))
- Database admins can correlate users across tables using usernames


The real question: How do you build a system where you physically cannot access user data, even if compelled?

## The Solution: Cryptographic Addressing + Zero-Knowledge Architecture

What if the user's secret is the address?

Behind the scenes, Encryptable derives the entity ID using HKDF:

// Internal: CID derivation (you don't write this)
// There are two strategies:
// - @HKDFId derives ID from secret using HKDF
// - @Id uses the ID directly* (making it a non-secret)
//   * needs to be a 22 Char Base64URL-Safe String
id = metadata.idStrategy.getIDFromSecret(secret, typeClass)

Now you can retrieve entities directly by secret:

// O(1) direct lookup - no username needed
val user = userRepository.findBySecretOrNull(secret)

If the entity exists, the secret was correct.
If not found, user doesn't exist.

No password hashes. No usernames. No mapping tables. Just cryptographic derivation.

## How It Works

1. Entity Definition:

@Document
class User : Encryptable<User>() {
    @HKDFId override var id: CID? = null  // Derived from secret
    @Encrypt var email: String? = null
    @Encrypt var preferences: UserPrefs? = null
}

2. Storage (what's in MongoDB):

{
  "_id": "xK7mPqR3nW8tL5vH2bN9cJ==",  // Binary UUID (subtype 4) - HKDF(secret)
  "email": "AES256GCM_encrypted_blob",
  "preferences": "AES256GCM_encrypted_blob"
}

> Note: Encryptable ID's uses a format called CID (Compact ID) - a 22-character Base64 URL-Safe String representing 128 bits of entropy.

3. Retrieval:

// User provides secret
val user = userRepository.findBySecretOrNull(secret)
// Behind the scenes:
// 1. Derive ID from secret using HKDF
// 2. MongoDB findById (O(1) direct lookup)
// 3. If found, decrypt fields using secret.
// 4. Return entity or null

## Security Properties

✅ Zero-knowledge - Database cannot decrypt without user secret
✅ Anonymous - No usernames or identifiers stored
✅ Non-correlatable - Can't link entities across collections without secrets
✅ Deterministic - Same secret always finds same entity
✅ Collision-resistant - HKDF output space is 2^128 (Birthday bound: 2^64)
✅ One-way - Cannot reverse entity ID back to secret

> ⚠️ Developer Responsibility: Encryptable provides the foundation for zero-knowledge architecture, but achieving true zero-knowledge requires developer best practices. Not

Encryptable - Zero-knowledge MongoDB ODM where not even the developer can access user data

# Encryptable

I built a zero-knowledge Spring Data MongoDB framework where **even I (the developer) can't access user data**.
Entity IDs are cryptographically derived from user secrets (no username→ID mappings), all data is encrypted with keys derived on-demand (no key storage), and the database contains only encrypted blobs.
This eliminates legal liability for data breaches—as you can't leak what you can't access.
Released as **Encryptable** - open-source Kotlin/Spring framework with O(1) secret-based lookups.

---

## Why I build this

I started building a file upload service and realized something terrifying: **I didn't want legal liability for user data if breached.**

Even with "secure" systems, developers face two fundamental problems:

### 1. Legal Liability (Developer Risk)

Even with encrypted data:
- **Developer/company can decrypt user data** (keys stored somewhere)
- **Data breaches expose you to lawsuits** - "You had access, so you're responsible"
- **Compliance burden** - Must prove you protected data adequately
- **Trust issue** - Users must trust you won't access their data

### 2. Inefficient Addressing (Technical Issue)

The standard pattern requires mapping:
```
username → user_id → encrypted_data
```

This creates problems:
- **Username leaks reveal identity** even if passwords are hashed
- **Requires queryable index** (username field must be searchable)
- **Two-step lookup** - Query username, then fetch data (not O(1))
- **Database admins can correlate users** across tables using usernames


**The real question:** How do you build a system where you **physically cannot** access user data, even if compelled?

## The Solution: Cryptographic Addressing + Zero-Knowledge Architecture

What if the user's secret **is** the address?

Behind the scenes, Encryptable derives the entity ID using HKDF:
```kotlin
// Internal: CID derivation (you don't write this)
// There are two strategies:
// - @HKDFId derives ID from secret using HKDF
// - @Id uses the ID directly* (making it a non-secret)
// * needs to be a 22 Char Base64URL-Safe String
id = metadata.idStrategy.getIDFromSecret(secret, typeClass)
```

Now you can retrieve entities directly by secret:
```kotlin
// O(1) direct lookup - no username needed
val user = userRepository.findBySecretOrNull(secret)
```

**If the entity exists, the secret was correct.**
**If not found, user doesn't exist.**

No password hashes. No usernames. No mapping tables. Just cryptographic derivation.

## How It Works

**1. Entity Definition:**
```kotlin
@Document
class User : Encryptable<User>() {
@HKDFId override var id: CID? = null // Derived from secret
@Encrypt var email: String? = null
@Encrypt var preferences: UserPrefs? = null
}
```

**2. Storage (what's in MongoDB):**
```json
{
"_id": "xK7mPqR3nW8tL5vH2bN9cJ==", // Binary UUID (subtype 4) - HKDF(secret)
"email": "AES256GCM_encrypted_blob",
"preferences": "AES256GCM_encrypted_blob"
}
```

> **Note**: Encryptable ID's uses a format called CID (Compact ID) - a 22-character Base64 URL-Safe String representing 128 bits of entropy.

**3. Retrieval:**
```kotlin
// User provides secret
val user = userRepository.findBySecretOrNull(secret)
// Behind the scenes:
// 1. Derive ID from secret using HKDF
// 2. MongoDB findById (O(1) direct lookup)
// 3. If found, decrypt fields using secret.
// 4. Return entity or null
```

## Security Properties

✅ **Zero-knowledge** - Database cannot decrypt without user secret
✅ **Anonymous** - No usernames or identifiers stored
✅ **Non-correlatable** - Can't link entities across collections without secrets
✅ **Deterministic** - Same secret always finds same entity
✅ **Collision-resistant** - HKDF output space is 2^128 (Birthday bound: 2^64)
✅ **One-way** - Cannot reverse entity ID back to secret

> **⚠️ Developer Responsibility:** Encryptable provides the foundation for zero-knowledge architecture, but achieving true zero-knowledge requires developer best practices. Not

storing user details such as usernames, passwords, or other plaintext identifiers in the database is **your responsibility**. Encryptable gives you the tools—you must use them correctly. [Learn more about secure implementation patterns](https://github.com/WanionTechnologies/Encryptable/blob/main/docs/BEST_PRACTICES.md)

## Performance Benefits

**Traditional Spring Data MongoDB:**
```kotlin
// Query by username = O(log n) index scan
interface UserRepository : MongoRepository<User, String> {
fun findByUsername(username: String): User?
}

// Usage
val user = userRepository.findByUsername("alice") // Index scan on username field
```

**Encryptable (Cryptographic Addressing):**
```kotlin
// Query by secret = O(1) direct ID lookup
interface UserRepository : EncryptableMongoRepository<User>

// Usage
val user = userRepository.findBySecretOrNull(secret) // Direct O(1) ID lookup
```

**Key differences:**
- ❌ Traditional: Query parsing → Index scan → Document fetch
- ✅ Encryptable: ID derivation → Direct document fetch (O(1))

No query parsing. No index scans. No username field needed. Just direct ID-based retrieval.

## Beyond Authentication

This pattern enables:
- **Anonymous file storage** (file_id derived from upload secret)
- **URL shorteners** (short_url derived from creator secret, enabling updates without authentication)
- **Encrypted journals** (entry_id = HKDF(master_secret + date))
- **Zero-knowledge voting** (ballot_id derived from voter secret)

Any system where "possession of secret = ownership of data."

### Practical Example: Deriving Secrets from User Credentials

You can derive secrets from user-provided data:

```kotlin
// User provides: email + password + 2FA code
val email = "nexus@wanion.tech"
val password = "December12th2025"
val twoFactorCode = "123456"

try {
// Derive master secret using HKDF
val userSecret = HKDF.deriveFromEntropy(
entropy = "$email:$password:$twoFactorCode",
source = "UserLogin",
context = "LOGIN_SECRET"
)

// Use master secret to find user entity
val user = userRepository.findBySecretOrNull(userSecret)

when (user) {
// If is null means authentication failed
null -> println("Authentication failed: invalid credentials")
// Successful login
else -> println("Welcome back, user ID: ${user.id}")
}
} finally {
// CRITICAL: Mark for wiping all sensitive strings from memory
// They will be zeroed out at request end.
markForWiping(email, password, twoFactorCode)
}
```

**Benefits:**
- ✅ No passwords stored in database (not even hashes!)
- ✅ 2FA is part of the secret derivation (stronger than traditional 2FA)
- ✅ Each entity type gets its own derived secret
- ✅ Zero-knowledge: server never sees the plaintext credentials

**Important:** Encryptable automatically wipes secrets and decrypted data, but you must manually register user-provided plaintext (password, email, etc.) for clearing to prevent memory dumps from exposing credentials.

---

## From Side Project to Framework

What started as a solution to avoid legal liability for a file upload service turned into something far more significant.
The combination of cryptographic addressing, deterministic cryptography without key storage, and zero-knowledge architecture wasn't just solving my immediate problem—it was solving a fundamental gap in the security ecosystem.

I started calling this side project **Encryptable** and realized it was way *bigger* than I ever could have hoped for.

---

## Implementation Details

**Framework:** Encryptable (Kotlin/Spring Data MongoDB)
**Encryption:** AES-256-GCM (AEAD, authenticated encryption)
**Key Derivation:** HKDF-SHA256 (RFC 5869)
**ID Format:** 22-character Base64URL (128-bit entropy)
**Memory Safety:** Automatic wiping of secrets/decrypted data after each request

## Four Core Innovations

Encryptable introduces **four paradigm-shifting innovations** that have never been combined in a single framework:

### 1. **Cryptographic Addressing**
Entity IDs are cryptographically derived

from secrets using HKDF.
No mapping tables, no username lookups—just pure cryptographic addressing.
This enables O(1) secret-based retrieval and eliminates correlation vectors.

### 2. **Deterministic Cryptography Without Key Storage**
All encryption keys are derived on-demand from user secrets.
Zero keys stored.
The framework operates in a perpetual "keyless" state, making key theft physically impossible.

### 3. **ORM-Like Experience for MongoDB**
Encryptable brings the familiar developer experience of JPA/Hibernate to MongoDB—with encryption built-in. Annotations like `@Encrypt`, `@HKDFId`, and repository patterns that feel native to Spring developers.

### 4. **Automated Memory Hygiene**
All secrets, decrypted data, and intermediate plaintexts are automatically registered for secure wiping at request end.
Thread-local isolation ensures sensitive data never lingers in JVM memory across requests.

> **Deep dive:** [Technical Analysis of Encryptable's Innovations](https://github.com/WanionTechnologies/Encryptable/blob/main/docs/INNOVATIONS.md)

## Limitations & Trade-offs

❌ **Secret loss = permanent data loss** (by design - true zero-knowledge)
❌ **No queries on encrypted fields** (can't search encrypted email)
❌ **Requires users to remember/store secrets** (UX challenge)
❌ **MongoDB only** (current implementation)

> **Full trade-off analysis:** [Understanding Encryptable's Limitations](https://github.com/WanionTechnologies/Encryptable/blob/main/docs/LIMITATIONS.md)

## Documentation

I spent as much time on documentation as coding:

- **51,644 words** across 46 markdown files (AI-assisted, guided by me)
- Cryptographic theory and security analysis
- Compliance considerations (GDPR, HIPAA, etc.)
- Threat models and attack surface analysis
- Best practices

**Some highlights**:
- [Cryptographic Addressing Deep-Dive](https://github.com/WanionTechnologies/Encryptable/blob/main/docs/CRYPTOGRAPHIC_ADDRESSING.md)
- [Security Without Secret](https://github.com/WanionTechnologies/Encryptable/blob/main/docs/SECURITY_WITHOUT_SECRET.md)
- [AI-Made Security Audit](https://github.com/WanionTechnologies/Encryptable/blob/main/docs/AI_SECURITY_AUDIT.md)

## Code Stats

- **2,503 source lines** (surprisingly compact)
- **Kotlin** (learned it specifically for this project after 9 years of Java)
- **4 months** of development (solo)
- **v1.0.0** - Stable release, not alpha/beta

## F.A.Q.

**Q: How is this different from E2EE apps (Signal, ProtonMail)?**
A: Those encrypt *in transit* and *at rest*, but the server still manages keys. Encryptable derives keys on-demand from user secrets, but never stores them. The database contains only encrypted blobs, and keys exist only during the request lifecycle.

**Q: Similar to blockchain addresses?**
A: Conceptually yes (address derived from private key), but without blockchain overhead. This is for traditional databases.

**Q: What about HashiCorp Vault / KMS?**
A: Those are key *management* systems. Encryptable is key *elimination* - no keys stored anywhere, all derived from user secrets on-demand.

## Release Info

- **Date:** December 12th, 2025
- **GitHub:** https://github.com/WanionTechnologies/Encryptable
- **Maven Central:** `tech.wanion:encryptable:1.0.0` and `tech.wanion:encryptable-starter:1.0.0`
- **License:** Apache 2.0
- **Language:** Kotlin (JVM 21+)

## Community Feedback Wanted

I'm releasing this today and would love feedback on:

1. **Security concerns** - Am I missing attack vectors?
2. **Use cases** - What would you build with this?
3. **Porting** - Interest in other languages/databases?
4. **Criticism** - What's wrong with this approach?

I've tried to be radically transparent about limitations. This isn't a silver bullet - it's a tool with specific trade-offs.

## Try It

**GitHub:** https://github.com/WanionTechnologies/Encryptable
**Maven Central:** https://central.sonatype.com/artifact/tech.wanion/encryptable

```kotlin
// build.gradle.kts
dependencies {
implementation("tech.wanion:encryptable:1.0.0")
}
```

Full examples:

[examples/](https://github.com/WanionTechnologies/Encryptable/tree/main/examples)

---

Thanks for reading! This is my first major open-source release, and I'm both excited and terrified to see how the programming community reacts.

**— WanionCane**

https://redd.it/1pkih02
@r_opensource