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

Turned my personal post-install noscript into a free open-source tool (+180 apps & configs)
https://kaic.me/win-post-install

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

Open-sourcing a research tool I built - PRISM for Bayesian hypothesis comparison

Sharing a tool I built for my own research in case it's useful to others.
What it is:
PRISM (Protocol for Rigorous Investigation of Scientific Mechanisms) - a Python framework for comparing multiple hypotheses against scientific evidence using Bayesian methods.
Why I built it:
I needed to decide between competing explanations for a research problem. Each had supporting studies, but I kept cherry-picking based on recency or "gut feel." Wanted something more rigorous.
Features:
Bayesian updating with empirical base-rate priors
Evidence weighting by study design quality
Correlation correction for non-independent evidence
Meta-analysis with heterogeneity assessment
Uncertainty decomposition
Tech:
Python 3.8+
NumPy, SciPy only
~1000 lines
Well-documented (methodology in THEORYOFOPERATION.md)
License: MIT
Looking for:
Users who might find it useful
Contributors with stats/meta-analysis expertise
Feedback on code quality and API design
GitHub: https://github.com/Dr-AneeshJoseph/Prism
Not a company, not monetizing - just a researcher sharing a tool.

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

SXO: High-performance server-side JSX

SXO is a multi-runtime tool for server-side JSX that runs seamlessly across Node.js, Bun, Deno, and Cloudflare Workers. It also includes SXOUI, a UI library similar to shadcn/ui.

- https://sxoui.com
- https://github.com/gc-victor/sxo

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

My first, small, open source project: MonoBitPainter
https://github.com/xgenium/MonoBitPainter

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

Open Source in Focus: 4 Tools That Keep Systems Running | The JetBrains Blog
https://blog.jetbrains.com/blog/2025/12/12/open-source-in-focus-4-tools-that-keep-systems-running/

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