Report on Nymja.ai - 2 trimester 2025

🪻 Nym Squad League Submissions
Report on Nymja.ai - 2 trimester 2025
none 0.0 0
1

Report Nymja.ai MVP| Nym SDK Grant

Nymja.ai was a project funded by NSL’s Grant SDK. It is an MVP, delivering an open-source hub of LLMs (chatbots) with a focus on privacy, as a desktop and mobile web application.

You can test it at: ai.tupinymquim.com

Project Overview

Nymja.ai is an open-source chatbot that integrates multiple LLMs, offering increased privacy, so you can chat without exposing your IP or personal data.

It has the following open-source models:

  • DeepSeek V3 65B

  • Mistral Nemo

  • Llama 3.2-11B Vision

  • Dolphin 3.0 (Mistral 24B)

  • Nous DeepHermes 3 8B

  • Qwen QWQ 32B

  • Gemma 3 27B

  • Kimi Dev 72B

The system operates in two distinct modes:

1.Proxy Mode: where all requests to external APIs are proxied to conceal the client’s IP address.
2. Mixnet Mode: where requests are routed through Nym’s mixnet to anonymize both IP addresses and user metadata.

Features

This MVP allows users to:

  • create an anonymous profile

  • change your credentials

  • chat with 8 LLMs for free (asynchronous stream)

  • Support for code and Markdown

  • Create/delete conversation

  • Mobile/desktop responsiveness

  • support for multiple users.

  • 1000 free requests per day (for all users).

Security and Privacy Measures

All data stored from user is end-to-end encrypted.

No personal information is ever persisted on our server.

User registration is fully anonymous and is secured by a 24-word mnemonic phrase.

Conversations and authentication credentials remain encrypted at rest.

Third-Party API Usage

The API consulted for the bots’ responses is OpenRouter. From there, I request the LLMs mentioned above, free of charge, with a total daily limit of 1000 requests. No access to the user’s history, however, only to each conversation.

So it’s not a production infrastructure, but a low-cost one aimed at testing.

To provide template-based responses, we rely on third-party APIs, which necessarily decrypt the conversation content to generate replies.

Implementation Status and Roadmap

At present, Mixnet Mode is not yet available due to temporary unavailability of the Nym TypeScript SDK.

We plan to integrate mixfetch in a future release, enabling all traffic to traverse Nym’s mixnet for metadata anonymity.

Technologies and Frameworks

Nymja.ai is underpinned by a modern and maintainable technology stack. On the server side, we employ Python asynchronously, in conjunction with Django’s ORM to facilitate rapid development, clear code organization, and robust data modeling.

All persistent data is managed by PostgreSQL, ensuring transactional integrity and powerful querying capabilities. To achieve environment consistency and simplify deployment, each service is fully containerized using Docker.

The client interface is built with Next.js and React, augmented by TypeScript for enhanced type safety and developer productivity.

Finally, the application is also backed by nginx and CloudFlare.

The project is open-souce, feel free to view and contribute.

Accomplished Objectives

Through this funded project, we have successfully delivered a Minimum Viable Product that:

  • Provides a unified gateway to multiple open-source large language models (LLMs).
  • It incorporates Nym’s privacy-by-design principles at every layer, ensuring that user information and IP addresses remain confidential.
  • Supports both Proxy Mode and Mixnet Mode (the latter pending SDK availability) to guarantee anonymous interactions.

Future Directions

Ahead, our main focus will be on:

  1. Improving scalability and UX: We want to improve our infrastructure in the future to accommodate thousands of simultaneous connections, employing load balancing and horizontal scaling strategies to maintain low latency under heavy load, and also improving on product branding, UI and UX.

  2. Feature enrichment: Addition of new features such as file uploads, real-time audio streaming and AI-driven voice calls.

  3. Sustainable monetization: We intend to introduce a tiered model offering a free access level alongside premium subscription plans, which will unlock higher capacity models and priority computing resources.

Even though this coming season I have decided to focus on another development project, more in line with the needs of the community at the moment (not yet posted), I believe that Nymja.ai has great commercial value - cause private chatbot/ai are indeed scarce - and I intend to return to it in the future, especially when the TypeScript SDK has been normalized.

User Feedback

Your insights are invaluable in guiding the evolution of this project. I invite all interested users to share their experiences, suggestions, and any encountered issues via the following feedback form:

Finally, I would like to thank the community and the staff for their trust and support. :innocent:

3 Likes
2

hey, good looking stuff. We forked it and I’m now working on a PR. It should allow mixnet to work with this thing and also a ton of Dev Exp and QoL improvements :slight_smile: + docs

3

Nice! How u pretend to connect to the mixnet? The mixfetch from the Nym TypeScript SDK is curently not working.

4

Hi psydent,

Thank you for your submission. I briefly looked through the application and have some feedback on the account registration mechanism

1. Conflicting Claims About Privacy

On the registration page, the app states:

“We take your privacy seriously, which means you don’t need to create an account to use our AI chat. You generate your own anonymous Access Code that you use to connect your devices. Securely generate your Access Code in your browser and save it somewhere secure.”

followed by:

“Never share your Access Code—not even with us!”

This strongly implies that the mnemonic/access code is generated client-side, which is not the case. Instead, the code is generated on the server side through a GET request to:

GET /api/auth/mnemonic/

If privacy is a core value of the application, the mnemonic should never be generated server-side, let alone transmitted over the network. Sensitive secrets like mnemonics or seed phrases should only be generated in the client’s browser to avoid any possibility of interception or logging.

2. Insecure Transmission via GET Parameters

After receiving the mnemonic, the next step in the flow makes a request like:

GET https://ai.tupinymquim.com/register-credentials?mnemonic=wish+oil+custom+wink+obvious+...

This is a serious security vulnerability.

HTTP GET parameters are logged by default in:

  • Web server logs
  • ISP logs
  • Browser history
  • Intermediate proxies

Anyone with access to these logs could extract the mnemonic phrase.

3. Mnemonics Sent Again in POST Request

Following that, there’s a POST request to:

POST https://ai.tupinymquim.com/api/auth/register/

With payload:

{
  "username": "alice",
  "password": "xxxxxx",
  "mnemonic_phrase": "never gonna give you up"
}

This appears to store or register the mnemonic server-side.

This contradicts the principle stated earlier — “Never share your Access Code—not even with us!”

If the mnemonic is truly private and central to user authentication, it should never be:

  • Sent over the wire
  • Stored in a database
  • Reconstructed from server logs
5

Sachin,

Thank you for taking the time to review the project and provide such detailed feedback — I really appreciate it.

You’re absolutely right: the current implementation of the account registration flow conflicts with the privacy guarantees we claim. While the mnemonic is encrypted before storage and never exposed in plaintext in our database, the fact that it’s generated server-side and transmitted via GET and POST requests introduces vulnerabilities that undermine user privacy — particularly for a project that’s meant to prioritize it.

This was a flaw in the architecture, and I take full responsibility for the oversight. It was an attempt to simplify the onboarding process early on, but I now realize that it creates a false sense of security and contradicts the “never share your Access Code — not even with us” principle.

Moving forward, we’ll refactor the flow to ensure that:

  • Mnemonics are generated entirely on the client side ,
  • No sensitive data is ever transmitted over the network (especially not in URLs),
  • Authentication is handled using a derived hash or secure keypair registration (instead of the raw mnemonic),
  • And all documentation and messaging is updated to reflect this approach accurately.

Thank you again for raising these points — this kind of feedback is invaluable, and I’ll make sure the next iteration reflects these privacy-first principles properly.

Best,

psydenst

1 Like