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

Built an open-source Azure Digital Twins alternative on PostgreSQL + Apache AGE

I created an open-source implementation of Azure Digital Twins APIs using PostgreSQL + Apache AGE. It started as a way to avoid vendor lock-in, but I'm expanding it for broader graph database use cases.

**Why PostgreSQL:**

* Combine with other extensions (pgvector for AI embeddings, PostGIS for spatial data)
* Reliability and existing tooling

**Technical approach:**

* Azure Digital Twins REST API compatibility (use official Azure SDKs)
* Apache AGE for graph queries (Cypher support)
* DTDL schema validation

**Use cases beyond Azure DT:**

* Digital twin infrastructure (IoT, smart cities, industrial systems)
* AI agent knowledge bases (semantic relationships without RDF)
* Complex relationship modeling (organizational hierarchies, dependencies)

**Architecture choices I'm curious about:**

* Built operator pattern instead of CRDs (simpler to extend?)
* REST + Cypher query interfaces (flexibility vs. complexity?)
* PostgreSQL foundation vs. purpose-built graph DB

**GitHub:** [https://github.com/konnektr-io/pg-age-digitaltwins](https://github.com/konnektr-io/pg-age-digitaltwins)
**Hosted:** [https://konnektr.io](https://konnektr.io)

Would love feedback your feedback.

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

Luego - a minimal read-it-later iOS app

Hey folks! I've been building this read-it-later app for myself and wanted to share it here as it's open-source. https://github.com/esoxjem/Luego

You can also grab it via TestFlight and receive updates as I release them - esoxjem.github.io/Luego/

Previously, I was a big Pocket user but Mozilla decided to shut it down. I switched to Omnivore but that seems to be shutting down as well. I don't feel like paying monthly, so I decided to "home-cook" it, inspired by Robin Sloan.

As everything is happening on device, the best things to read are blog posts and websites that have clean and simple HTMLs - not news sites and others that do a lot of crap.

I'm using it regularly to read and hope you will find it useful too.

Cheers!

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

We got tired of rogue AI agents, so we built Idun, an open source platform for agents governance ⭐️

Hey everyone!

We are four friends, all working in the industry, we kept hitting the same wall:
cool AI agents but zero real governance.

So we built **Idun** **Agent** **Platform**, an open-source control plane to govern all your AI agents in one place, on your infra:

* Self-hosted (VMs / k8s / whatever cloud you trust)
* One place for **agents, environments, keys, configs**
* **Governance**: RBAC, separation of envs, audit trail
* **Observability**: see what each agent did, which tools it called, where it failed
* Model-agnostic (plug different LLM providers, including “sovereign” ones)

Check out our GitHub: [Idun Agent Platform](https://github.com/Idun-Group/idun-agent-platform)

It’s early, but already running in a few real setups, we're looking for feedbacks and just devs' testing our solution, and a few ⭐️ if we do deserve it!

Thank you so much for looking at it everyone!

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