Forem: Devs Daddy

Typescript Application Security from A to Z: A Guide to Protecting Against Obvious and Not-So-Obvious Vulnerabilities

Devs Daddy — Wed, 29 Apr 2026 12:36:47 +0000

I often notice how careless some developers are about the security of their applications. They only begin to think about protection methods when they have to rewrite a large portion of the application. Today, we'll cover classic and other attack methods, examine where the compiler falls short, and build modern protection based on best practices and specific code examples.

This article specifically provides simplified attack methods and vulnerability examples to make it easier to understand the mechanics.

Introduction

TypeScript has undoubtedly become one of the leaders in web development. It's used to build powerful React applications and complex microservices on Nest or Fastify. Developers often value type safety, but this isn't classic security, as a string in TypeScript is still just a string, potentially vulnerable to SQL injection and XSS vulnerabilities. The compiler doesn't check business logic, doesn't filter input data, and doesn't detect that you've shared a JWT secret in a public repository.

I built this article around a simple principle: types are not a defense, but a tool of discipline. We'll examine attacks and defenses on two key platforms:

Backend (Node.js, Express/Fastify/NestJS): injections, prototype pollution, unsafe deserialization, data leaks through errors.
Frontend (React, Next.js, Angular): XSS, CSRF, prototype poisoning through dependencies, sensitive data leaks, SSR attacks.

In each section, I've provided real code examples, a simple explanation of the vulnerability, and mitigation methods. So, a fascinating journey into the world of application security awaits us.

Backend: When a request arrives before type checking

TypeScript on the server enforces contracts between layers, but the entry point, an HTTP request, is always raw data. Even if you use NestJS with decorators like @Body(), validation may be absent or incomplete.

Case 1: SQL injection via TypeORM (yes, it's possible)

Many people think that ORMs completely protect against injection attacks. But when a developer resorts to raw queries or tricky operators, TypeScript won't save them.

Vulnerable Code (Basic Case Study with Raw Data):

import { getConnection } from 'typeorm';

app.get('/users', async (req, res) => {
  const { sortColumn, order } = req.query;

  // We wait for sortColumn = "name", order = "ASC"
  // But call raw query
  const users = await getConnection().query(
    `SELECT * FROM users ORDER BY ${sortColumn} ${order}`
  );
  res.json(users);
});

Here, the parameters are directly substituted into SQL. The attacker sends:

GET /users?sortColumn=name&order=ASC; DROP TABLE users; --

TypeScript sees sortColumn: string, and everything looks fine from its perspective. But the relational database receives two queries.

Solution: Validate allowed values and use parameterized queries or an API that doesn't allow concatenation.

import { IsIn, IsString } from 'class-validator';
import { validateOrReject } from 'class-validator';

class UsersQueryDto {
  @IsIn(['name', 'email', 'createdAt'])
  sortColumn!: string;

  @IsIn(['ASC', 'DESC'])
  order!: 'ASC' | 'DESC';
}

app.get('/users', async (req, res) => {
  const dto = new UsersQueryDto();
  Object.assign(dto, req.query);
  await validateOrReject(dto);

  const users = await userRepository.find({
    order: { [dto.sortColumn]: dto.order },
  });
});

This way, we guarantee that nothing but the expected columns will end up in the ORDER BY clause.

It would seem so... Elijah, what are you talking about? We already use Query Builder, these are obvious things! But I've also seen solutions where the developer inserted partially raw queries. For example:

app.get('/search', async (req, res) => {
  const { q } = req.query;

  const users = await userRepository.find({
    where: {
      name: Raw(alias => `${alias} LIKE '%${q}%'`)
    }
  });
  res.json(users);
});

And it turns out that here the search string q is directly pasted into the SQL expression.

GET /search?q=%25'%3BDROP%20TABLE%20users%3B--

And if you still can't give up Raw SQL code inserts, the right solution would be to use parameterized placeholders (supported, for example, in TypeORM):

where: {
  name: Raw(alias => `${alias} ILIKE :query`, { query: `%${q}%` })
}

Another similarly dangerous pattern is to build a query using createQueryBuilder, concatenating strings for conditions or sorting.

app.get('/users', async (req, res) => {
  const { filter } = req.query; // filter = "admin'; DROP TABLE users; --"
  const qb = userRepository.createQueryBuilder('user');
  if (filter) {
    qb.where(`user.role = '${filter}'`);
  }
  const users = await qb.getMany();
  res.json(users);
});

String interpolation within .where() exposes the same injection opportunities as direct SQL. An attacker gains complete control over the query.

A safer alternative: use QueryBuilder parameters:

if (filter) {
  qb.where('user.role = :role', { role: filter });
}

Key lesson: Any string concatenation when forming SQL is suspect, even if it is hidden behind ORM methods.

Case 2: NoSQL Injection in MongoDB with Mongoose

Even when using ODM, you can still get an injection if you pass objects directly from a query.

app.post('/login', async (req, res) => {
  const { username, password } = req.body;
  // req.body can contain: { username: { $ne: null }, password: { $ne: null } }
  const user = await UserModel.findOne({ username, password }).exec();
  if (user) {
    res.json({ token: generateToken(user) });
  } else {
    res.status(401).send();
  }
});

If the client sends JSON with MongoDB operators ($gt, $ne), the query will become { username: { $ne: null }, password: { $ne: null } } and return the first user it encounters.

Solution: explicit typing and normalization of input data using libraries like mongo-sanitize or manual validation:

function sanitizeInput(obj: Record<string, unknown>): Record<string, string> {
  const clean: Record<string, string> = {};
  for (const [key, value] of Object.entries(obj)) {
    if (typeof value !== 'string') {
      throw new Error('Invalid input type');
    }
    clean[key] = value;
  }
  return clean;
}

But it's better to use proven validators, such as Zod or class-validator, to prohibit objects with suspicious properties at the DTO level.

Raising the Bar. Case Study 3: Prototype Pollution

In Node.js, objects inherit from Object.prototype, and changing this prototype can have catastrophic consequences, ranging from logic changes to remote code execution.

An example of such code is a deep merge function:

// Danger function
function deepMerge(target: any, source: any) {
  for (const key in source) {
    if (typeof source[key] === 'object' && source[key] !== null) {
      if (!target[key]) target[key] = {};
      deepMerge(target[key], source[key]);
    } else {
      target[key] = source[key];
    }
  }
}

app.put('/settings', (req, res) => {
  const userSettings = JSON.parse(fs.readFileSync('settings.json', 'utf-8'));
  // Danger
  deepMerge(userSettings, req.body);
  fs.writeFileSync('settings.json', JSON.stringify(userSettings));
  res.send('ok');
});

And if the request is:

{ "__proto__": { "isAdmin": true } }

After such a merge, any new object will have isAdmin === true. This could bypass authorization checks.

Protection: Never use recursive merges without property checks. Modern libraries (lodash.merge) offer protection, but it's safer not to use them for user data at all. It's better to explicitly define the schema:

import { z } from 'zod';

const SettingsSchema = z.object({
  theme: z.enum(['light', 'dark']),
  notifications: z.boolean(),
});

app.put('/settings', (req, res) => {
  const parsed = SettingsSchema.safeParse(req.body);
  if (!parsed.success) {
    return res.status(400).json({ errors: parsed.error });
  }

  // Work only with parsed.data
});

Zod will automatically discard all undeclared keys, including proto and constructor.

Secure Integration of JWT and Sessions

JWT has become an industry standard, but its misuse often leads to token theft and privilege escalation.

Case 4: Lack of Algorithm Validation

Let's look at the vulnerable code:

import jwt from 'jsonwebtoken';

app.get('/profile', (req, res) => {
  const token = req.headers.authorization?.split(' ')[1];
  if (!token) return res.status(401).send();
  const decoded = jwt.verify(token, config.publicKey);
  // Attack: The attacker signs the token with the "none" or HS256 algorithm with the public key.
});

If the library doesn't specify an acceptable algorithm, you can use the "none" algorithm or a symmetric algorithm if you know the public key.

Solution: explicitly specify acceptable algorithms.

const decoded = jwt.verify(token, config.publicKey, {
  algorithms: ['RS256'], // or ['ES256']
});

Additionally, never use jwt.decode() for verification. Only verify.

Case 5: Secrets in Code and Configurations

Accidentally committing a .env file with JWT_SECRET=super-secret to the repository is a classic example. TypeScript doesn't scan string contents. Use:

process.env and tools like dotenv-vault.
Configuration validation at startup, using Zod.

Configuration verification using Zod:

const envSchema = z.object({
  JWT_SECRET: z.string().min(32),
  DB_URL: z.string().url(),
});
const env = envSchema.parse(process.env);

If the variable is missing or incorrect, the application will crash on startup with a clear error.

Protecting against SSTI (Server-Side Template Injection) in template engines

If you outsource HTML rendering to the server (Nunjucks, EJS, Pug), careless passing of user input to the template can lead to code execution.

Example of vulnerability:

app.get('/hello', (req, res) => {
  const name = req.query.name;
  res.render('hello', { name });
});
// EJS Template: <h1>Hi <%= name %></h1>

Although <%= %> escapes HTML, in some engines it's possible to inject executable code via template engine parameters (as with { constructor: ... }). The best defense is to never pass raw input to a template without context processing and to avoid using advanced template engine features (such as eval).

If you're using Next.js or React for SSR, a similar attack can occur via dangerouslySetInnerHTML:

function Profile({ bio }: { bio: string }) {
  return <div dangerouslySetInnerHTML={{ __html: bio }} />;
}

Here, TypeScript assumes that bio = string, but the variable could contain XSS.

The obvious rule, even from the method's name, is to never use dangerouslySetInnerHTML with unvalidated user input, and if necessary, use DOMPurify.

Frontend: Browser Security

On the client, TypeScript gives a false sense of security. Let's look at the main attack vectors where types won't help.

Case 6: XSS via HTML injection

As shown above, passing unescaped text to innerHTML or the dangerouslySetInnerHTML JSX attribute is a direct route to XSS. But there are less obvious places.

Unsafe code in React:

function Comment({ text }: { text: string }) {
  return (
    <a href={`https://example.com/?q=${text}`}>
      Search
    </a>
  );
}
// Если text = "javascript:alert(1)"

The browser will execute JavaScript on click. TypeScript is unaware of the context of the string.

Protection: URL validation and use of encodeURIComponent. A Content Security Policy (CSP) with strict directives is also a good idea.

Case 7: Sensitive Data Leaking into the Build

Environment variables (API keys, internal URLs) often leak into the client bundle because the developer used process.env.NEXT_PUBLIC_* or forgot about the server/client boundary. TypeScript doesn't distinguish between where the code will be executed.

Protection: Clearly separate environment variables. In Next.js, for example, only variables prefixed with NEXT_PUBLIC_ are accessible on the client. Everything else should only be read on the server (getServerSideProps / API Routes).

Case 8: CSRF with Mutations

If your cookies are passed automatically and your API accepts POST requests without additional validation, an attacker can trick the user into sending an unwanted request.

TypeScript won't automatically add a CSRF token. You need to implement either a synchronous token or a SameSite cookie and Origin/Referer validation.

An example of a simple check in Next.js API routes:

import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

const allowedOrigins = ['https://myapp.com'];

export function middleware(req: NextRequest) {
  const origin = req.headers.get('origin');
  if (req.method !== 'GET' && (!origin || !allowedOrigins.includes(origin))) {
    return new NextResponse(null, { status: 403 });
  }
  return NextResponse.next();
}

Dependencies and Supply Chain

TypeScript projects pull hundreds of packages. Each dependency can become an entry point. Typing doesn't protect against malicious code in postinstall scripts or obfuscated packages.

Specific Incident: Event-Stream
In 2018, the popular event-stream npm package was compromised: malicious code was added to it that stole cryptocurrency keys from another package. TypeScript was powerless here: the malware can be buried deep in dependencies and contain no types at all.

Protective Measures:

Use npm audit, snyk, and socket.dev.
Check package licenses and reputation.
Minimize the number of dependencies.
Add a check for known vulnerabilities to CI/CD.

Types as an Element of Security Infrastructure

Despite all of the above, TypeScript can significantly enhance security if used consciously:

Typed DTOs and strict interfaces. Use not just "any" types, but precise types, enumerations, and discriminated unions. This eliminates many validation errors even at the coding stage.
Branded types (nominal typing). For example, we can create a SafeHtml type that can only be accessed through a sanitization function.
Exhaustive switches and protection against incompleteness. Ensures that all possible states are handled (for example, when parsing authentication statuses).

An example of a protected SafeHtml type:

type SafeHtml = string & { readonly __brand: unique symbol };

function sanitizeHtml(input: string): SafeHtml {
  return DOMPurify.sanitize(input) as SafeHtml;
}

function render(html: SafeHtml) {
  document.getElementById('app')!.innerHTML = html;
}

Level Up. Five subtle modern attacks on TypeScript applications

Now we'll move on to threats that rarely make it into basic guides, but are increasingly common in real-world projects. All examples focus on the TypeScript stack.

Dependency Confusion via Typed Packages

An attacker publishes a package with an internal name to the public npm, but with a higher version. TypeScript projects are particularly vulnerable due to the habit of using @types/* or corporate naming conventions.

Example: Your company uses an internal package @mycompany/auth, which is stored in a private registry. The attacker publishes @mycompany/auth to npm with version 99.0.0 and malicious code in the postinstall. If .npmrc doesn't specify a strict scope registry, npm install will pull in the public version.

// Code from dangerous repo (index.d.ts and index.js)
export function login(login: string, password: string): boolean;
// In JS: process.env.JWT_SECRET send to the hacker server

Security:

Configure .npmrc to link the scope to a private registry.
Use npm install --prefer-offline and block queries to the public registry for internal names at the network level.
In the CI pipeline, check package integrity using npm audit --audit-level=high and compare hashes.

Timing attack on string comparisons (JWT, API keys)

A classic mistake: checking tokens or keys using ===. In Node.js, string comparisons are performed byte by byte and take varying amounts of time. An attacker can measure the response and guess the token character by character.

Example of vulnerable code:

const expectedApiKey = process.env.API_KEY!;
app.post('/webhook', (req, res) => {
  const apiKey = req.headers['x-api-key'] as string;
  if (apiKey !== expectedApiKey) {  // Danger!
    return res.status(403).send('Forbidden');
  }
});

If the lengths are unequal, the comparison fails immediately, but if the first character is correct, it takes a little longer. By repeating the queries with different values, the key can be recovered.

Security: Use crypto.timingSafeEqual to compare secrets.

import { timingSafeEqual } from 'crypto';

function constantTimeCompare(a: string, b: string): boolean {
  const bufA = Buffer.from(a);
  const bufB = Buffer.from(b);
  return timingSafeEqual(bufA, bufB);
}

And be sure to normalize the length so that the pause does not give away the length of the key.

GraphQL: Introspection Abuse and Argument Injections

On the Apollo Server (TypeScript) backend, introspection is often left enabled in production. This allows an attacker to obtain the full schema and find secret mutations or fields accessible only to admins. Injection via unvalidated arguments becomes even more dangerous.

Resolver vulnerability:

const resolvers = {
  Query: {
    user: (_: unknown, args: { id: string }) => {
      // id  doesn't checked
      return db.raw(`SELECT * FROM users WHERE id = '${args.id}'`);
    }
  }
};

Steps to protect:

Disable introspection in production.
Validate arguments using Zod or graphql-scalars.

Example of disabling introspection in configs:

const server = new ApolloServer({
  typeDefs,
  resolvers,
  introspection: process.env.NODE_ENV !== 'production',
});

Validation example:

mport { z } from 'zod';
const userIdSchema = z.string().uuid();

user: (_: unknown, args: { id: string }) => {
  const id = userIdSchema.parse(args.id);
  return db.query('SELECT * FROM users WHERE id = $1', [id]);
}

SSRF via URL parsing in Node.js

Many applications accept URLs from the user (for example, to import an avatar). Attackers bypass these checks using Unicode tricks or redirects.

Example of vulnerable code:

app.post('/import', async (req, res) => {
  const { url } = req.body as { url: string };
  const parsedUrl = new URL(url);
  if (parsedUrl.hostname === 'localhost' || parsedUrl.hostname === '127.0.0.1') {
    return res.status(400).send('Invalid URL');
  }
  const response = await fetch(url);
  // ...
});

Bypass hostname verification: http://127.0.0.1:80@evil.com (the part before the @ is considered credentials, resulting in hostname = evil.com, and the request goes to 127.0.0.1).

Another example: http://0x7f.0.0.1/ (IP hex notation).

Protection:

Don't parse the URL yourself. Use a library like is-ip or check the final IP after DNS resolution.
Restrict the scheme to http and https. Disallow raw IP.

import { promises as dns } from 'dns';
async function resolveIp(url: string): Promise<string> {
  const hostname = new URL(url).hostname;
  const addresses = await dns.resolve4(hostname);
  return addresses[0]; // упрощённо
}

// Checks for private ranges
// (10/8, 172.16/12, 192.168/16, 127/8)

RCE via unsafe deserialization in TypeScript

Some libraries allow functions to be serialized or eval'd during deserialization for convenience. For example, serialize-javascript (used in Next.js) is safe, but packages like node-serialize and cookie-serialize allow RCE to be replicated.

Example of vulnerable code:

import * as serialize from 'node-serialize';

app.get('/state', (req, res) => {
  const state = serialize.unserialize(req.cookies.state);
  // state can contain an objects with code
});

Attack example: a state cookie with a serialized object, where the rce field is: "_$$ND_FUNC$$_function(){ require('child_process').exec('rm -rf /') }".

Protection: Never use deserialization that can restore functions. Use only JSON. For example:

const state = JSON.parse(req.cookies.state || '{}');

If complex types are required, use zod for validation after JSON.parse, but do not run the code. Any imports of libraries with extended serialization should be prohibited.

A practical security checklist for a TypeScript project

For the backend:

Validate all incoming data via Zod / class-validator / io-ts. No any or as.
Parameterized database queries, no string concatenation (even within Raw() and QueryBuilder methods).
Clean objects from proto and constructor (or use safe map/reduce).
Fixed JWT algorithms, short token lifetimes, and refresh tokens with rotation.
Secure CORS settings (no * with credentials).
Logging without token/password leaks.
Helmet-like middleware.

For the frontend:

No dangerouslySetInnerHTML without DOMPurify.
CSP headers prohibiting inline scripts.
Proper use of encodeURIComponent and URL validation.
Separation of sensitive environment variables: only what is truly needed is included in the client code.
CSRF protection: SameSite=Strict/Lax, Origin check, tokens for state-changing requests.
Regular and very careful updating of dependencies.

General practices:

Linter with security rules (eslint-plugin-security).
Static analysis with type checking, but not excessively so; remember that any casting breaks security.
Runtime type checks (ts-runtime, type guards) for server data, as the API response may also be different from what you described in the interface.

Conclusion

TypeScript is a truly powerful tool, but it's not a bodyguard. Strong typing reduces bugs and makes code more predictable, but it doesn't eliminate classic web vulnerabilities. Today, we examined real-world examples where the compiler is completely blind to the dangers: from SQL substitution (even through high-level TypeORM operators) to prototype pollution, timing attacks, and deserialization.

Furthermore, the last five cases demonstrate that attacks are adapting to modern technologies, and defenses must evolve.

The main takeaway: think of types as the foundation on which you build a multi-layered security system. Validate everything at the boundaries of trust, never trust the client, and remember that any is not a type, but a security hole.

Security is a process, not a final state. Make your TypeScript not only strict but also secure.

Thanks for reading.
What other types of vulnerabilities would you like to explore, perhaps in more depth and from less obvious perspectives?

DLSS 5 is not a failure. The Future of rendering: A deep technical look at new approaches after 15 years in Game Development

Devs Daddy — Wed, 22 Apr 2026 21:58:53 +0000

Hello everyone! Before we start, let's get to know a few people we haven't met yet. My name is Elijah, I am a technical director at a company that develops products based on machine learning. Previously, I worked in game development for 15 years and went through several technical milestones. I was partly inspired to write this article by the recent srach that appeared after the announcement of DLSS 5 from Nvidia.

In this article, we will omit the marketing jamb of Nvidia itself and the technically crude demos, but rather dive into the near-term technical future that awaits us in the gamedev industry, going through the history of the graphics pipeline.

The beginning of a revolution in the graphics pipeline

There has been a really huge shift in the rendering architecture of games over the past five years. If for two decades before that, progress rested on the inexorable mathematics of Moore's law, where improving rendering quality was reduced to increasing computing power and increasing the number of polygons and shaders, today everything has changed. Now, in order to achieve high visual quality in games, it is not brute force head-on, but new approaches that change the established essence of building a game image over decades, including on the basis of AI technologies. Today, more than 80% of all pixels on the screen in the most advanced (from a technical point of view) games go not the classic way, but mixed approaches and new tricks (new approaches to calculating light, super-sampling based on AI, etc.).

Today we will focus on how it influenced (and will continue to influence) AI is like rendering in games to understand the essence of a shift in graphics. To do this, we will initially look at two key topics: first, the fundamental differences between DLSS and all previous approaches to resolution enhancement and anti-aliasing (from SSAA to TAAU), and secondly, the place that neural network scaling occupies in the modern graphics pipeline, after which we will review the near future of rendering in games.

From super-sampling to neural synthesis of a scene

To assess the place of DLSS (including the future 5th version) in the graphical pipeline, we will trace the evolution of anti-aliasing and scaling from the very first implementations to the modern approach using AI computing.

The Era of "pure mathematics": SSAA, MSAA, FXAA and their limitations

Classical methods of dealing with "ladders" at the boundaries of game objects were based on a simple but computationally expensive principle: processing a higher-resolution image or parts of it.

Let's look at three classic anti-aliasing algorithms in games:

SSAA (Supersampling Anti-Aliasing): The most "honest", but also voracious method. The scene is rendered at a resolution higher than the user's target (for example, 4K for output to an FHD monitor), and then the resulting frame is compressed back to the desired size. SSAA processes each subpixel, including shading, which gives a reference image quality, but leads to a drop in performance (I hope you understand why). For modern games with complex shaders and geometry, this approach is impractical.
MSAA (Multisample Anti-Aliasing): This method appeared as an attempt to optimize SSAA. The essence of optimization boils down to the fact that shading is processed only once for each primitive (for example, a triangle) inside a pixel, and not for each sample, as SSAA does. Although this approach significantly reduces the load on the GPU, it is worth considering that MSAA effectively smooths only the edges of the geometry, but does not cope with other elements of the pipeline, such as smoothing textures. Also, its cost is still high for complex scenes.
FXAA (Fast Approximate Anti-Aliasing): Post-processing smoothing, which analyzes a ready-made 2D frame, searches for high-contrast borders in it and blurs them. This is the cheapest method in terms of performance, but its main drawback is the inevitable "soap" of the entire image, including textures and interface elements, which leads to a loss of clarity and detail.

The Age of Temporal Accumulation: TAA and its Heirs (TAAU)

A key breakthrough occurred with the transition to temporal methods that use information not only from the current frame, but also from previous ones.

What has changed in the approaches:

TAA (Temporal Anti-Aliasing): Instead of rendering each pixel, TAA slightly shifts the camera position each frame, accumulates information from previous frames using motion vectors of objects, and then calculates the average value. This allows you to get a quality close to SSAA, with performance comparable to a single frame rendering. TAA has become an industry standard for many years, but it has its own fundamental problems: gouging, loss of detail on small and fast-moving objects, and the overall "soapy" feeling of the picture in some implementations and scenes.
TAAU (Temporal Anti-Aliasing Upsampling): The logical development of TAA. Realizing that temporal accumulation allows you to restore details from subpixel information, the developers began to use it to scale the image, rendering the scene in lower resolution and "upscale" to high resolution using frame history.

It is TAAU that is the direct predecessor of DLSS, but with one critical difference: TAAU relies on hard-coded rules and is not able to "understand" the scene, but only mathematically averages pixels, which often leads to artifacts.

The DLSS Revolution: From CNN to Vision Transformer

NVIDIA DLSS (Deep Learning Super Sampling) and its FSR counterpart have made a qualitative leap by replacing purely mathematical TAAU approaches with machine learning models capable of making more "intelligent" decisions about how to restore an image.

The first generations used convolutional neural networks (CNN). Their main disadvantage is "myopia": the model analyzed pixels only within a limited spatial window (the receptive field or the area of the input image). This led to problems familiar to gamers: if an object moved too fast, CNN would "lose" sight of it, which caused flickering and gushing on small details like foliage, wires, or hair.

The transition to the Vision Transformer architecture in the 4th version of DLSS has become a fundamental progress. Unlike CNN, Transformer can evaluate the significance and relationship of any pixels in a frame, regardless of the distance between them, thanks to an additional attention mechanism. The model learned to "understand" the context of the entire scene, which made it possible to radically increase image stability by reducing the number of artifacts and, for the first time, bring the image closer to the native resolution after upscaling (and sometimes surpass it in clarity).

Technical integration into the graphics pipeline: DLSS's place in the rendering pipeline

For those who are interested in the topic of how graphics pipelines work and what shaders have to do with it, I wrote an article about this a long time ago using the example of the Unity game engine. However, the essence of + is the same for all game engines. So I recommend reading it for a better understanding of the topic.

DLSS is not a "black box" that simply receives a low resolution input and outputs a high one. This is a complex system that is deeply integrated into the rendering process, requiring developers not only to call the API, but also to prepare specific data.

Therefore, when you see a bad DLSS, it's probably the game developer himself, not the technology.

Input data: what is needed for DLSS to work?

For DLSS to work correctly, the game's graphics engine must provide a special set of buffers, each of which is critically important to the algorithm:

Color Buffer: Roughly speaking, this is a frame rendered in low resolution. This is a "rough sketch" based on which the final image will be built.
Motion Vectors: A critical component. For each pixel, this buffer shows where it has moved compared to the previous frame. This allows DLSS to understand the dynamics of a scene, correctly link pixels from different frames, and avoid the effect of gouging.
Depth Buffer: Information about the distance from the camera to each pixel. It helps the model understand the structure of the scene and which objects overlap each other, which is especially important for proper processing of the edges of the geometry.
Jitter Offsets: To get more information than is contained in one frame, the camera is slightly shifted by a fraction of a pixel in each frame according to a special pattern (as in the previously described TAA). DLSS must know exactly the amount of this offset in order to "subtract" it from the motion vectors and correctly combine pixels from different frames.

How DLSS is integrated into the pipeline

DLSS is not embedded at any time, but in a strictly defined place of the graphic pipeline. Integration with the game engine takes place through an open SDK, which provides an interface for technologies (DLSS, Reflex, etc.).

Example of pipeline stages based on DLSS operation:

Geometry rendering and shading: The game engine does all the "hard" work: calculates geometry, lighting, materials, and shadows. All this happens in a reduced resolution.
Early post-processing: DLSS must be embedded before effects such as film grain, chromatic aberration, vignettes, and most importantly, before the user interface (UI). This is necessary for the neural network to work with a "clean" image of the scene, and not with effects superimposed on top of it, which can confuse it and distort the final result.
DLSS call: At this stage, all prepared input data (color buffers, depths, motion vectors) is transferred to DLSS. The model processes them using its weights and generates the final frame in the target (high) resolution.
Late post-processing and UI: After DLSS has done its job, effects that should remain "native" to the monitor resolution (chromatic aberration, vignette, etc.) are applied on top of the resulting high-quality image, and, most importantly, the interface is at the target resolution, remaining as clear and undistorted as possible.
Screen output: The final frame is sent to the display.

All this paves the way for mass adoption of technologies, especially when DirectX 12 and other vendors discover new DLSS-like approaches based on AI rendering (compression of textures, materials) at the API level, making them a standard part of the toolkit of a modern developer.

DLSS 5: Paradigm Shift towards AI scene Synthesis

DLSS 5 gives a start to redefining the very approach to problem statement. If previous versions worked with an already rendered frame, restoring or completing pixels, the new model uses the structural data of the engine: depth buffer, albedo, motion vectors, normals, identifiers of materials and lighting. The network doesn't just "finish painting" - it rethinks the visual properties of the scene.

NVIDIA claims that DLSS 5 is capable of analyzing the semantics of a scene: recognizing skin, hair, fabrics, various types of lighting, and generating more accurate pixels for subsurface scattering on the skin or more realistic material responses. We are talking about a controlled modification of the final image, which remains deterministic and temporally stable.

The fact that many "experts" were swearing at the final result is more likely now - it's just the dampness of the technology itself and the "handedness" of the developers who helped create the techno demonstration. It is worth considering that the approach to rendering itself is changing, so the first steps will be jackal, but earlier technologies without AI also went this way.

Multi Frame Generation: from linear interpolation to adaptive synthesis

The mathematics of frame generation

In the classical frame generation scheme (DLSS 3), one interpolated frame was generated for each rendered frame, which resulted in a speed increase of about 100%. DLSS 4 increased the gain by about two more times (three generated frames per one rendered one).

The key question is: at what FPS does this make sense? Let's assume that with an input stream of 60 FPS after super-sampling, the output can reach 360 FPS on the display. This corresponds to a time window of ~16.6 ms between rendered frames, within which the neural network must predict five intermediate states of the scene. Think about the answer yourself and write it in the comments.

In general, in the Blackwell architecture, which serves as the basis for motion prediction, linear motion vector interpolation becomes insufficient at high generation coefficients. DLSS 4.5 adds dynamic coefficient adjustment: in scenes with high complexity (for example, particle explosions), the model can reduce the coefficient to maintain quality, and in relatively static scenes it can increase it. However, again, it's up to the developers.

And that's where it's worth making a remark. Nvidia engineers are people who work solely to move their technology forward, and graphics programmers who work on rendering are not only listed in the red book, firstly, they are used to established approaches and cannot quickly switch to the updated pipeline of the render without breaking anything, and secondly Like everyone else, they stick to release dates. If you have an idea of what is meant by "rebuild the graphics pipeline", then you should understand why at first there are inevitable shoals in the use of new technology.

The problem is input delays (input lag) and the solution is via Reflex

The generation of intermediate frames fundamentally increases the input lag: you see, the generated frame does not contain a reaction to user input, this reaction appears only in the next rendered frame.

NVIDIA compensates for this with Reflex technology, which synchronizes the CPU and GPU so that the rendering queue is minimal. However, the implementation also strongly depends on the game engine and the correctness of embedding into the overall lifecycle of rendering and the rest of the logic.

What if you compress data instead of pixels?

DLSS is certainly cool and well-known. But this is just one of the approaches where AI is used in the rendering process. Let's look at other approaches.

AI-assisted texture compression: saving video memory

One of the most pressing problems of modern game development is the huge increase in texture volumes. Traditional block compression methods (BC1-BC7) achieve coefficients 4:1 <=> 8:1, but their effectiveness comes down to fundamental limitations: compression occurs independently for each block, without taking into account the global texture structure.

The engineers decided to approach the task in a fundamentally different way: instead of storing a compressed image, a trained neural network (or its weights) is stored, capable of reconstructing a texture of arbitrary resolution in runtime. For example, NVIDIA claims a sevenfold reduction in the use of VRAM and system memory compared to traditional block-compressed textures with comparable visual quality.

Technically, it works as follows: at the build stage of the game, textures are passed through a training procedure that takes less than a minute for thousands of assets (depending on the hardware, of course). The result is a compact representation for the model, which is decompressed by tensor kernels in real time when loaded into memory. Since unpacking takes place on the fly, there is no need to store all MIP levels in video memory at the same time. The AI can generate the required level on demand.

For AAA games, this means not only saving video memory, but also drastically reducing the size of the games themselves, speeding up downloads, and allowing you to increase texture density without increasing memory requirements.

Compression of shaders and materials

Complex materials are layered structures that combine dozens of maps and hundreds of mathematical operations. Rendering high-level materials (e.g. porcelain, silk, multilayer leather) in real time has so far been impractical due to the high computational cost.

AI shaders use trained neural networks to calculate complex shader code.

Architecturally, this means that instead of executing the full shader graph on each pixel, the GPU performs inference, which outputs the final shader parameters. The gain is achieved due to the fact that tensor kernels perform matrix operations much more efficiently than shader kernels.

Inference instead of ray tracing

Everyone knows how voracious ray tracing remains - Ray Tracing and, in particular, Path Tracing. Path tracing requires tracing hundreds or thousands of rays per pixel to converge indirect lighting. The new approach allows us to replace most of this work with an inference: after tracing one or two bounces, the neural network predicts the result of an infinite number of subsequent bounces.

For example, a similar technology (NRC) has already become available through the RTX Global Illumination SDK and will soon appear in RTX Remix. A practical consequence of this approach is the ability to achieve the visual quality of traditional Path Tracing with performance comparable to simpler global lighting techniques.

A small note. All the described technologies rely on specialized computing units. The evolution of tensor core from each generation directly determines how effectively AI rendering models work.

Based on this, RTX 20/30 series users receive identical image quality, for example from DLSS 4.5, but with a significant drop in performance due to the lack of native FP8/FP4 support in tensor cores.

Let's look into the inevitable future: AI rendering as a new standard

So, having talked about current technologies and a changing approach (somewhere else not ideal, experimental, but already gaining momentum), let's look into the near future of rendering in AI-based games.

Development trajectory until 2030

Analyzing the current technological vectors and already available solutions, we can safely predict several key areas:

Complete replacement of traditional shaders with inference: the first technologies like RTX Neural Shaders already demonstrate that neural networks can accelerate complex calculations on materials more efficiently than handwritten shader code, especially due to the improved architecture of tensor cores. The next step, of course, is the unification of all materials for the AI model, where the shader is compiled into the weights of a small inference.
Smooth transition from frame generation to scene generation: existing technologies for working with scene primitives (geometry, lighting, textures) are leading the way to a more optimized and advanced game production pipeline at the stage level, which will free the hands of artists and technical artists, eliminating the routine work of optimizing scenes at the AI level. And then, as an option, it is the generation of any primitives in order to select the initial sketches for the artists in seconds, rather than hours of manual work.
Hybrid computing models: Modern video cards already contain separate tensor cores, raytracing cores, and shader cores. Future architectures are likely to spread these specialized blocks even further, allowing classical rendering, ray tracing, and inference to be performed in parallel.
Standardization of AI rendering: Microsoft has already added support for AI rendering to DirectX, which paves the way for universalization (at least at the DirectX API level). The same ARM is developing its own GDK for developers, opening the door to super-sampling and denoising based on AI for mobile devices.

However, with all the achievements, there are still a number of fundamental problems that hundreds of engineers are working on:

Determinism: Generative models are inherently random. Competitive gaming requires pixel-by-pixel repeatability of the result, which is difficult to achieve without fixing the LED. However, the development of more and more new approaches reduces randomness to a minimum.
Energy consumption: inference certainly consumes a lot of energy. In mobile gaming and on portable devices (e.g. Steam Deck, Nintendo Switch) this is a critical limitation. But a lot of work is also being done in this direction, offering new options for optimizing models.
Backward compatibility: As the computing requirements of new models grow, old GPUs lose their ability to perform them efficiently, which creates fragmentation of the user base. Here, rather, the result will depend on the speed of the emergence of generally accepted standards in development, since we are only at the beginning of the path.

There has already been an aversion to technology in history. You just don't remember it. How has the industry digested past graphic revolutions?

The controversies surrounding the introduction of AI rendering: from "fake frames" and "soap instead of graphics" to the fear of losing control over the visual result, are certainly very loud, but they are not something new to the industry. Virtually every fundamental change in rendering architecture over the past 25 years has encountered similar resistance before becoming a new standard.

Compute shaders vs. a regular pipeline (2001-2004)

Before the advent of GeForce 3 and DirectX 8, the graphics pipeline was a rigidly defined chain of operations: vertex transformation, lighting using fixed formulas, rasterization, texture mixing. And then we were allowed to program our own vertex and pixel shaders for each stage, which opened the way to normal maps, dynamic shadows, and complex materials.

At that time, people were afraid that shaders were too slow, developers couldn't handle writing complex code, and that shaders that could be coded were crutches, not a step forward.

In reality, after just five years, games without shaders have become a relic of the past. Half-Life 2, Doom 3, Far Cry have demonstrated that a programmable pipeline is not just a replacement for the old one, but a tool that allows you to create masterpieces that were previously impossible. Developers quickly mastered HLSL and GLSL, and performance increased due to hardware acceleration of shader blocks.

Transition to Deferred lighting (Deferred Rendering, 2007-2011)

Classic forward rendering recalculated the lighting for each object, which made multiple dynamic light sources impractical. Deferred rendering divided the process into two passes: first, geometric attributes are written to the G‑buffer, and only then the lighting is calculated only in the screen space. This made it possible to use dozens and hundreds of dynamic light sources in the frame. But today it seems commonplace.

But at that time, many argued that the g-buffer would eat up a lot of memory, the powerful MSAA smoothing would have to be thrown in the trash, and all transparent objects would have to be replaced with something, because they break.

But in reality, the industry found compromises, because the pros outweighed all the cons. And so, instead of MSAA, new types of smoothing appeared first (FXAA, SMAA, later replaced by TAA and TAAU), which eventually even surpassed in quality. And the approach itself has become an industry standard.

Physically correct rendering (PBR, 2013-2016)

In the era before PBR, materials were described by standard parameters (specular power, glossiness), which behaved differently in different lighting conditions and required manual adjustment to each scene. The physically correct approach introduced a unified BRDF model based on the measurable additional properties of real materials: metallic, roughness, albedo.

However, at first, the reaction was harsh - they said that all games would become the same and plastic, old textures would have to be redone from scratch, and artists would lose creative control.

But something else happened: PBR did not destroy the styling. He gave the artists a predictable foundation on top of which stylistic solutions can be applied. The transition to PBR, of course, required additional staff training and the introduction of new tools (such as Substance Painter, Quixel), but the result was a leap in realism and stability of materials between different scenes and projects. Today, even stylized cartoon games use a PBR pipeline adapted to aesthetics.

Today

And now, starting in 2018, it all started with the transfer of raytracing technologies from film rendering to gaming. The first implementations were modest: only shadows or reflections with a low number of rays per pixel.

Seven years later, ray tracing has already become the standard in the AAA segment. Cyberpunk 2077 in Path Tracing mode, Alan Wake 2, Black Myth: Wukong with full RT: these are examples of how the technology has matured and become a standard. Denoising and upscaling (including DLSS) have evolved to make RT playable. Current-generation consoles have received hardware RT blocks, and AMD and Intel are catching up with NVIDIA in tracing performance.

The current transition to AI rendering shows all the same patterns as previous revolutions.

Is another revolution waiting for us? Let's summarize the results

Each of the past revolutions took time to adapt, update the toolkit, train developers, and optimize hardware. AI rendering is no exception.

It does not cancel out the work of artists and programmers, but gives them a new level of abstraction: instead of manually dealing with noise, smoothing or optimizing materials, developers will be able to rely on models trained on huge data sets of photo-realistic or stylized content.

Moreover, as we have already seen above, history shows that after the adoption of a new paradigm or technology, the industry does not just return to its previous level of quality, but enters a new stage. Shaders didn't kill 2D sprites, but they gave us normal maps and dynamic shadows. PBR did not make the games monotonous, but gave a new basis for both photo realism and stylization (for example, Dishonored 2).

AI rendering will not destroy "classic" graphics, but will allow for real-time visual complexity.

Another question is how developers will use technology, because there are examples where developers, even with a significant leap in technology, take a step back (hello Battlefield 6).

The next five years will determine how much AI rendering will permeate every aspect of game creation. Judging by the current trajectory, by 2030 the line between "rendering" and "generation" will become indistinguishable, or very blurred.

So, thanks for reading!

I am waiting for your forecasts and ideas in the comments!

⚡Extremely Fast Way to Work with Binary Data - Flash Buffer for TypeScript

Devs Daddy — Thu, 09 Apr 2026 13:06:39 +0000

Speed up binary I/O with zero-copy performance, automatic offset management, and a set of advanced tools.

Working with binary data in JavaScript and TypeScript has always been a chore. Manually tracking offsets, worrying about endianness, and constantly copying memory—it's easy to get bogged down in boilerplate code. Existing libraries only address some of the issues, but they either tie to Node.js Buffer or don't support modern features like SharedArrayBuffer.

Today I'm excited to introduce Flash-Buffer: a lightning-fast binary data library that makes manipulating ArrayBuffers as easy as working with JSON.

🤔 Problem: Binary data is complex and slow

Whether you're parsing a custom network protocol, reading media file headers, or serializing game state for transmission over WebSocket, you'll encounter the same inconveniences:

Manual offset management. Every read or write requires updating the offset variable. This is a source of infinite per-unit errors.
Data copying. Standard methods often create new buffers instead of working with existing ones. This kills performance on large data sets.
Lack of convenient abstractions. You want to write a string or a floating-point number, but you have to fiddle with DataView and TextEncoder.

Flash-Buffer solves these problems by providing an intuitive API that remains incredibly fast.

🚀 Key Features

Zero-Copy. Reading data returns a Uint8Array, which is a direct "view" of the memory location. No unnecessary copying just pure performance.
Smart memory management. Automatic buffer expansion on write (exact, powerOfTwo, fixed strategies), built-in buffer pool to reduce GC load, native resize() support for ArrayBuffer.
Cross-platform. Works in browsers, Node.js, Deno, and Bun. Supports SharedArrayBuffer for efficient data exchange between threads without copying.
Advanced data formats:
- VarInt (LEB128) with ZigZag encoding-like Protobuf.
Bitwise operations (BitBuffer) for flags, compressed data, and cryptography.
C-strings (null-terminated).
Stream adapters for the Web Streams API.
Schematic serialization. Use TypeScript decorators (@field) to describe the class structure, and the library will automatically serialize it to and from a binary buffer.

💻 Usage examples

Basic reading and writing:

import { FlashBuffer } from 'flash-buffer';

// Create a buffer (auto-growing, little-endian by default)
const buf = new FlashBuffer({ endianness: 'little' });

// Write data
buf.writeUint32(0xDEADBEEF);
buf.writeString('Hello, Flash!', 'utf-8', true); // true = prefix length as uint32

// Reset the offset for reading
buf.reset();

// Read data back
const value = buf.readUint32();
const strLength = buf.readUint32();
const str = buf.readString(strLength);

console.log(value.toString(16)); // 'deadbeef'
console.log(str);               // 'Hello, Flash!'

Working with VarInt (Variable-Length Integers):

import { FlashBuffer } from 'flash-buffer';

const buf = new FlashBuffer();

// Write a large number (less than 128) in one byte instead of four
buf.writeVarUint(127);

// Write a negative number efficiently using ZigZag encoding
buf.writeVarInt(-15);

buf.reset();

console.log(buf.readVarUint()); // 127
console.log(buf.readVarInt());  // -15
console.log(buf.offset);        // 3 (1 byte for 127 + 2 bytes for -15)

Bit-level operations:

import { FlashBuffer } from 'flash-buffer';

const buf = new FlashBuffer();
const bits = buf.bit();

// Write a sequence of bits that may cross byte boundaries
bits.writeBits(0b11111, 5);
bits.writeBits(0b10101, 5);
bits.flush(); // Important: flush to finalize the byte and align the offset

buf.reset();
const readBits = buf.bit();
console.log(readBits.readBits(5)); // 0b11111 (31)
console.log(readBits.readBits(5)); // 0b10101 (21)

Serializing objects using decorators:

import { FlashBufferSchema, field } from 'flash-buffer';

/* Create serializable class (Player) */
class Player {
  @field({ type: 'uint32' }) id: number = 0;
  @field({ type: 'string' }) name: string = '';
  @field({ type: 'float32' }) x: number = 0;
  @field({ type: 'float32' }) y: number = 0;
}

/* Create new Player */
const player = new Player();
player.id = 1;
player.name = 'John';
player.x = 100.5;
player.y = 200.5;

/* Serialize and Restore Object */
const buf = FlashBufferSchema.serialize(player);
const restored = FlashBufferSchema.deserialize(Player, buf.reset());

📊 Comparison with similar libraries

Several excellent libraries exist for binary data manipulation. Flash Buffer was designed to combine their strengths and offer unique capabilities.

Feature	flash-buffer	smart-buffer	@hazae41/binary	@jsonjoy.com/buffers
Zero-Copy	✅	❌	✅	❌
`SharedArrayBuffer`	✅	❌	❌	❌
Automatic Growth	✅	✅	❌	✅
Streaming (Web Streams)	✅	❌	❌	✅
Bit-Level Operations	✅	❌	❌	❌
VarInt (LEB128)	✅	❌	❌	❌
C-Strings	✅	✅	❌	❌
Schema Serialization	✅	❌	✅	❌
Buffer Pool	✅	❌	❌	❌

Unique advantages of Flash Buffer:

Full support for SharedArrayBuffer the key to copy-free multithreading.
Modern DataView-style API intuitive and concise.
A wide range of out-of-the-box tools: from VarInt to Serialization and streams.

📦 Installation and getting started

Just install via NPM (zero-dependency library):

npm install flash-buffer

Or clone from GitHub:
https://github.com/devsdaddy/flash-buffer/

💎 Conclusion

Flash-Buffer was created to free you from the pain of manually handling binary data. It combines the performance of zero-copy, the convenience of high-level abstractions, and support for modern web standards. If you write network protocols, parse files, or develop high-load services, try Flash-Buffer and you'll be surprised at how simple binary code can be.

I welcome stars, issues, and pull requests on GitHub. Share your experiences or questions in the comments!

A Post-Quantum Hybrid Encryption for High-Load Systems in TypeScript

Devs Daddy — Mon, 06 Apr 2026 19:59:04 +0000

What is this post about?

This paper presents QuarkDash Crypto (a quantum resistant hybrid encryption algorithm), an open-source TypeScript library implementing a hybrid encryption protocol resistant to quantum computer attacks. QuarkDash combines post-quantum key exchange based on Ring-LWE, a fast stream cipher (ChaCha20 or Gimli), a quantum-resistant KDF, and a SHAKE256-based MAC, as well as built-in mechanisms for protecting against replay and timing attacks.

Benchmark results are presented demonstrating throughput of up to 2.8 GB/s and session setup time of approximately 10 ms, which outperforms classical asymmetric schemes (RSA, ECC) and is comparable to symmetric encryption (AES), but with additional quantum resistance.

If you're not interested in the implementation details, you can skip straight to the TypeScript library.

Introduction

With the development of quantum computers, many widely used cryptographic algorithms (RSA, ECC, DSA) are becoming vulnerable to Shor's and Grover's algorithms. In response, the cryptographic community is developing post-quantum cryptographic algorithms (PQC).

However, implementing PQC in real-world systems poses challenges: performance, key size, and compatibility. QuarkDash addresses these issues by offering a hybrid approach: post-quantum key encapsulation (using Ring-LWE) and high-performance symmetric encryption.

Selection of cryptographic primitives

1. Post-quantum key exchange: Ring-LWE

Ring-LWE (Ring Learning with Errors) is one of the most studied candidates for the NIST PQC finals. It is based on the difficulty of finding errors in a ring of integer polynomials. QuarkDash Crypto uses the following parameters:

Ring dimension N = 256
Modulus Q = 7681 (a prime number supporting fast NTT)
Primitive root ω = 7

These parameters provide 128-bit post-quantum security with compact keys (public key ~2 KB, private key ~1 KB). Polynomial multiplication is implemented using NTT (Number Theoretical Transform) with complexity O(N log N), making key exchange very fast (~8 ms on modern processors).

2. Symmetric Encryption: ChaCha20 and Gimli

For data encryption after a session is established, QuarkDash Crypto offers two stream ciphers:

ChaCha20 is a standardized (RFC 7539) high-performance cipher resistant to timing attacks. It uses 20 rounds, a 256-bit key, and a 12-byte nonce. Its software implementation is faster than AES without hardware acceleration.
Gimli is a lightweight cipher designed for embedded systems. It uses 24 rounds, a 384-bit state, and provides 256-bit security. Gimli is faster than ChaCha20 on 32-bit architectures and requires less code.

In my TypeScript implementation, the choice of cipher is specified via configuration (cipher: ChaCha20 | Gimli), which allows the library to be adapted to different platforms.

3. Quantum-resistant KDF and MAC: SHAKE256

For key derivation and authentication, I use SHAKE256, an extensible hash function based on the Keccak sponge that is resistant to quantum attacks. Since the Web Crypto API does not have built-in support for SHAKE256, I emulate it by repeatedly calling SHA-256 in counter mode (which is sufficient for protocol purposes).

So, it turns out that:

KDF (Key Derivation Function): takes a shared secret (32 bytes), a salt (32 bytes), and a token, returning 64 bytes of key material.
MAC: computed as SHAKE256(macKey || data, 32). Constant-time comparison is used.

4. Protection against replay attacks

Each encrypted message contains a 12-byte header: a timestamp (8 bytes, Unix time in milliseconds) and a sequence number (4 bytes). During decryption, the following is checked:

The timestamp deviation does not exceed the specified value (5 minutes by default).
The sequence number has not been repeated (a sliding window of the last 1000 packets is stored).

This prevents replay attacks both within a session and over long periods of time.

QuarkDash's Algorithm (Step-by-Step)

1. Long-Term Key Generation (Ring-LWE)

Choose a random polynomial a with coefficients from Z_Q.
Choose small polynomials s (secret) and e (error) with coefficients {-1, 0, 1}.
Calculate b = a ⊗ s + e (multiplication via NTT, addition coefficientwise).
Public key: (a, b), private: s

2. Session Establishment (KEM)

Initiator (for example, client):
- Receives Receiver's public key (a, b).
- Generates small s', e'.
- Computes u = a ⊗ s' + e' (ciphertext).
- Computes w = b ⊗ s', rounds the coefficients to bits → sharedSecret.
- Sends u to Receiver.
Receiver (for example, server):
Using his secret s, computes w' = u ⊗ s, rounds → the same sharedSecret.

3. Session Key Derivation (KDF)

keyMaterial = SHAKE256(salt || sharedSecret || "session-key", 64)
sessionKey = keyMaterial[0:32]
macKey = keyMaterial[32:64]

4. Message encryption

For each message:

Generate header = timestamp(8) || sequence(4).
ciphertext = streamCipher.encrypt(plaintext).
mac = SHAKE256(macKey || header || ciphertext, 32).
Send header || ciphertext || mac.

5. Decryption and verification

Split into header, ciphertext, and mac.
Check mac (constant time).
Check timestamp (within the window).
Check sequence (not repeating).
plaintext = streamCipher.decrypt(ciphertext).

What's it. This algorim provides very fast and secured encryption between two entities (for example, for realtime connection between client and server).

Security

1. Post-quantum security

Ring-LWE has no known quantum algorithms for efficiently solving it (unlike factorization or discrete logarithm).
SHAKE256 provides resistance to quantum attacks (unlike SHA-2, which can theoretically be weakened by Grover's algorithm, but with less effect).
The combination of Ring-LWE and SHAKE256 provides 128-256-bit security against both quantum and classical attacks.

2. Protection against side-channel attacks

All MAC comparisons are performed in constant time (constantTimeEqual).
Keys are erased from memory (secureZero).
There are no branches on secret data in critical areas (cipher, KDF, MAC).

3. Forward Secrecy

Each session uses ephemeral key exchange (via KEM). Even if the server's long-term key is compromised, past sessions remain protected.

4. Replay Protection

The built-in timestamp and sequence number prevent replay attacks within a specified time window.

Performance

Below are the results of synthetic benchmarks in comparison with other popular algorithms.

Operation	QuarkDash (ChaCha20)	QuarkDash (Gimli)	AES-256-GSM	ECDH (P-256) + AES	RSA-2048
Key generation	12.3ms	12.1ms	N/A	1.2ms	48ms
Session (KEM)	8.7ms	8.5ms	N/A	3.4ms	42ms
Encryption (1KB)	0.003ms	0.0028ms	0.005ms	0.05ms	0.8ms
Decryption (1KB)	0.003ms	0.0028ms	0.005ms	0.05ms	0.1ms
Encryption (1MB)	0.42ms	0.38ms	0.85ms	21ms	102ms
Decryption (1MB)	0.42ms	0.38ms	0.85ms	21ms	1080ms
Speed (MB/s)	2300	2630	1176	48	0.9

Advantages of QuarkDash over other algorithms

1. AES (symmetric encryption) in comparison

Quantum resistance – AES is vulnerable to Grover's algorithm (brute-force attack speeds up by √N).
Built-in key exchange – no pre-distribution of keys is required.
Forward secrecy – compromising a long-term key does not reveal past sessions.
Replay protection – in AES, this must be implemented separately.
Faster when implemented in software (QuarkDash is faster than AES without hardware acceleration).

2. ECC (Asymmetric on Elliptic Curves) in comparison

Quantum resistance – Shor's algorithm breaks ECC in polynomial time.
Better performance for large messages – ECIES encrypts data using AES, but adds the overhead of ECDH.
Smaller packet size – 44 bytes versus 61 bytes for ECIES.
Easier to implement – no need to check points on the curve or protect against subgroup attacks.

3. RSA (asymmetric factorization) in comparison

Quantum resistance – RSA is broken by Shor's algorithm.
Huge performance gap – RSA is 250+ times slower for encryption, 1000+ times slower for decryption.
Smaller keys – No, RSA has a 256-byte key, while QuarkDash has 2 KB (but 256 bits of security versus 112 bits for RSA-2048).
No padding issues – RSA requires complex OAEP, which is susceptible to oracle attacks.
Linear scaling – QuarkDash has O(n) complexity, while RSA has O(n³).

Characteristic comparison

Characteristic	QuarkDash (ChaCha20)	QuarkDash (Gimli)	AES-256-GSM	ECDH/P-256 + AES	RSA-2048 + AES
Type	Hybrid	Hybrid	Symmetric	Asymmetric (KEX)	Hybrid
Quantum stability	✅ Ring-LWE	✅ Ring-LWE	❌ No	❌ No	❌ No
Encryption speed (1mb)	~2.5 GB/s	~2.8 GB/s	~1.2 GB/s	~50 MB/s (ECIES)	~10 MB/s
Decryption speed (1mb)	~2.5 GB/s	~2.8 GB/s	~1.2 GB/s	~50 MB/s	~1 MB/s
Session speed	~10-15 ms	~10-15 ms	0 ms (pre-shared)	~5 ms	~50 ms
Public key size	~2 KB	~2 KB	N/A	33 bytes	256 bytes
Private key size	~1 KB	~1 KB	N/A	32 bytes	256 bytes
Overhead size	44 bytes	44 bytes	28 bytes	61 bytes	256+ bytes
Forward secrecy	✅	✅	❌	⚠️ optional	❌
Replay security	✅	✅	❌	❌	❌
Authentication	✅ MAC (SHAKE256)	✅ MAC (SHAKE256)	✅ (GSM)	✅ (ECIES)	❌
Timing attacks security	✅ constant-time	✅	⚠️ Partial	⚠️ Partial	❌
The Difficulty of Quantum Hacking	2^256	2^256	2^128 (Grover)	0 (Shor)	0 (Shor)

QuarkDash Crypto installation and use cases for web apps

Below I have provided an example of using the QuarkDash algorithm based on an implementation I wrote in TypeScript that can be used in your web applications.

You can use the QuarkDash library as a regular library for both Backend and Frontend applications without any additional dependencies.

Installation using NPM:

npm install quarkdash

Or using GitHub:

git clone https://github.com/devsdaddy/quarkdash
cd ./quarkdash

Basic example

/* Import modules */
import {CipherType, QuarkDash, QuarkDashUtils} from "../src";

/* Alice - client, bob - server, for example for key-exchange */
const alice = new QuarkDash({ cipher: CipherType.Gimli });
const bob = new QuarkDash({ cipher: CipherType.Gimli });

/* Generate key pair */
const alicePub = await alice.generateKeyPair();
const bobPub = await bob.generateKeyPair();

/* Initialize session at bob and jpin alice public key */
const ciphertext = await alice.initializeSession(bobPub, true) as Uint8Array;
await bob.initializeSession(alicePub, false);
await bob.finalizeSession(ciphertext);

/* Encrypt by alice and decrypt by bob */
const plain = QuarkDashUtils.textToBytes('Hello QuarkDash 🔒!');
const enc = await alice.encrypt(plain);
const dec = await bob.decrypt(enc);
console.log("Decrypted:", QuarkDashUtils.bytesToText(dec));

Conclusion

QuarkDash is the first TypeScript library that combines post-quantum key exchange (Ring-LWE), a fast stream cipher (based on ChaCha20/Gimli), and quantum-resistant KDF/MAC (based on SHAKE256) into a single hybrid protocol.

It is production-ready, features high performance (up to 2.8 GB/s), protection against side-channel and replay attacks, and provides a simple and extensible API.

The library is available on GitHub and npm. The source code is open-sourced under the MIT license. I invite the community to test, review, and contribute improvements.

Thanks for reading!

Useful Links:

[Boost]

Devs Daddy — Mon, 02 Feb 2026 17:44:41 +0000

Neurosell became the organizer and sponsor of the AI Pulse 2026 conference in Perm

Devs Daddy for Neurosell ・ Feb 2

#ai #conference #machinelearning #community

Neurosell became the organizer and sponsor of the AI Pulse 2026 conference in Perm

Devs Daddy — Mon, 02 Feb 2026 17:44:25 +0000

On January 30, the startup Neurosell became one of the organizers and sponsors of the first AI conference in 2026—AI Pulse in Perm. The conference brought together more than 200 participants from leading companies in Russia and the CIS, as well as hundreds of online participants. More than 25 presentations were given, and there was an extensive networking program, an expo zone, and much more.

Conference guests

The event was attended by representatives of more than 150 different companies, including TON Foundation, Ozon, Selectel, AllSee, AiDee, Neurosell, Timeweb Cloud, School 21, and other industry leaders.

The conference opened with a heated discussion on the future of artificial intelligence, with experts from the Ministry of Digital Development of the Perm Region, the Federation Council, and companies such as Reactive, Spectr, Neurosell, neuromus, Wikibot, and Plati po Miru.

What else did the program include?

The program also featured two sessions of presentations: one for businesses and one for developers, an exhibition of solutions from startups and companies, over 11 hours of networking, prize draws, and an official party for speakers and VIP guests.

What were the key points of the conference?

In addition to active networking and heated discussions about the upcoming challenges and prospects for artificial intelligence in 2026, more serious topics were increasingly raised at the conference, such as changes in fundamental AI technologies (replacing classic LLM), optimization of classic LLM models, increasing business automation, but at the same time more conscious use of AI in all aspects of life.

For more details, please see the recordings of the presentations, which will be available on the AI Pulse 2026 conference website in the coming days:
https://aipls.ru/

The conference was organized by:

Morion Digital High-Tech Park;
AI Hub Artificial Intelligence Community;
Neurosell;

The next conference is scheduled for August this year and will be even larger in scale.

Neurosell won the award - best startup of the week with Virton AI product

Devs Daddy — Mon, 26 May 2025 10:31:25 +0000

Today, Neurosell shared the win for Startup of the Week by Product Radar. Let's find out how it happened and what results it yielded.

Why did Neurosell enter the competition?

The flagship product of startup Neurosell is AI-powered virtual fitting rooms. The team has great expertise in development, including in AI organization. The Virton AI startup is already working with pilot projects and testing many hypotheses, weekly algorithms. So why being an already growing startup - Virton AI was sent to the competition?

First and foremost - the company enters contests to get expert feedback and community involvement. For Virton AI it is important to get not only customer experience, but also support and feedback from industry experts.

Alexander Khopyorsky - Founder at Brat AI, no code for AI Agent - became the project hunter. Including the exchange of experience with other industry representatives is an important point in the formation of the company's product strategy.

What did the Virton AI team get out of the competition?

First and foremost, our team gained experience with the community. It was important for us to get feedback both from other founders in related fields and to learn more about working with communities like Product Radar. Such experience helps us adjust our product strategy and internal processes. - Elijah Rastorugev, Neurosell & Virton AI CTO

Naturally, this is just the beginning of the journey for Virton AI, but already, after just one month of an active public beta, the team has secured many key partners, including pilot projects with various brands.

To learn more about Virton AI, visit the product's website:
https://virton.tech/en/

Neurosell shared new Virton AI successes and new brand partnerships

Devs Daddy — Thu, 22 May 2025 13:33:06 +0000

In today's weekly digest, Neurosell shares new successes and partnerships with apparel brands, IT integrators, and other company news.

Integrations with new brands and examples of Virton working as a cross-platform solution

One of the major Virton AI collaboration announcements among fashion companies was the launch of a pilot with premium clothing brand DeBacker's. The brand integrated with a fitting room based on Shopify, which is the first such integration.

Now the Neurosell team is actively working on other integration options, including Telegram and VK mini-apps. Examples of such integrations can be seen below:

These integrations with new sales channels for an apparel brand can be up and running in a single day, which is one of the benefits of going full-fledged with Virton AI.

Participating in the battle of startups on Product Radar

Also this week, Neurosell began competing in a battle for the title of Startup of the Week and Month on the Product Radar platform with Virton AI. The project hunter was Alexander Khopyorsky, founder of Brat AI

You can vote for Virton AI on the Product Radar page:
https://productradar.ru/product/virton/

New records and Virton AI users

Well, the latest news from Neurosell is that Virton AI's daily user traffic grew over 100% this week to over 3,000 daily users.

The product is currently in training and in collaboration with brands to develop its algorithms.

More details can be found on the Virton AI website:
https://virton.tech/

Neurosell announces new product - marketplace based on Virton AI fitting room, talks about updates and new partnerships

Devs Daddy — Sun, 18 May 2025 16:30:43 +0000

The other day, Neurosell, a startup developing Virton AI-based virtual fitting rooms, talked about Virton's upcoming updates, including the launch of a marketplace based on current services, as well as new pilot projects.

Virton AI-powered martkeplaces announced

Today Neurosell announced a new product - a marketplace based on Virton AI. This functionality will work in parallel with the usual fitting rooms, but in addition to the usual fitting rooms, a marketplace based on applications for Google Play, Android, as well as VK Mini Apps and Telegram Mini Apps will be launched.

Every store that connects a fitting room will immediately be placed in the marketplace, thus opening up a new audience for Virton. The marketplace is scheduled to launch in June 2025.

Virton AI analytical tools

Advanced analytics will be available to all Virton AI users in the coming weeks. This will include an overview of popular products, a look at the number of generations, generation of picks based on product popularity, and an overview of the audience cross-section, including a breakdown by day.

Already now, there is functionality to track UTM fitting room tags, which are generated automatically for each product.

New pilot projects and partners

Neurosell has also announced partnerships for Virton AI virtual fitting room pilots with brands such as Nishtyak Bratok, Zanovo, Murka, NashLosь, DSM Icons, Knives and other apparel brands. This helps in training the neural network even faster and better. Pilot projects are planned for six months, during which time the generation quality is expected to improve by more than 90%.

More detailed information is always available on the official Virton AI website:

https://virton.tech/

Neurosell launched a major update to Virton AI and talk about future development plans

Devs Daddy — Sat, 10 May 2025 16:17:24 +0000

Hi everyone, we're here with Neurosell. Today we're going to talk about the past week's progress, including the launch of the new Virton AI update, development plans for the near future and new partner destinations.

This is gonna be interesting, let's go!

Virton AI's massive new update

Today we launched a major new update to our artificial intelligence-based virtual fitting rooms - Virton AI. It includes new functionality for online store owners, updated algorithms for working with photos, widgets and internal tests of video fitting in motion. Below, we tell you about everything in order.

Online Store Dashboard

Started a personal store management cabinet to implement a fitting room widget without programming knowledge. To do this, you only need to customize the widget appearance, fill in the products and connect the widget to the site.

You don't need to fully customize products like in regular catalogs of online stores - you only need to customize the product photo, name and link for purchase, specifying categories.

Appearance can be adjusted to your site - upload logos, adjust the color palette. Changed your site design? No problem - the widget automatically updates all settings when you save them in your control panel.

![Virton AI](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/t9gfbsc2jv7lvg8vgjfb.png

Virton AI virtual fitting room algorithm update

We've also updated our algorithms, making them even more accurate for trying on products. And the fitting widget itself has become clearer, more user-friendly and simpler.

In addition, we have internally tested the online fitting room algorithm based on video in motion. The result of the video sample from the internal tests can be seen in this video:

The launch of new algorithms for fitting accessories, hats, shoes by photo is planned for June, but with video fitting - we plan to start in August. If you have your own online store, right now you can join us on preferential terms (the first months are free), and then be one of the first to receive priority updates.

Neurosell and Virton AI partnership areas

Starting Monday, Neurosell will begin working with partners like Shopify, InSales and other online store building platforms to make it quick and easy for anyone to build full product card integration into their website.

In addition, we can already now individually connect the fitting room to your VK community or Telegram bot.

Pilot programs and new integrations

Virton AI is scheduled to roll out next week as pilot projects with 8+ apparel brands who will help train the algorithm at a discounted rate. For now, anyone can test our algorithms unlimitedly by installing the widget for free:

As a final note, I'd like to extend a huge thank you for the support of all the apparel brands who are helping with the development of Virton AI, as well as the Neurosell team for their prompt work on the algorithm.

Try Virton AI for free

See you in a week!

Neurosell announces $800K seed round of investment to refine and scale Virton AI - fitting rooms for online stores

Devs Daddy — Tue, 29 Apr 2025 11:10:41 +0000

Today, the Neurosell team is announcing the launch of the next round of Seed investment of $800,000 to improve the product and scale it to market. To date, the company has already raised $60,000 Pre-Seed investment for initial hypothesis tests.

What's the plan to do?

In addition to expanding the development team and launching marketing campaigns, Neurosell plans to take the accuracy of the algorithms to the next level, providing a new quantum leap.

Key product readiness criteria based on Seed round highlighted for Virton AI:

Increase in generation speed by more than 115% - to an acceptable 5-6 seconds;
Improving generation quality and its average rating up to 90%;
Provision of tariff plans for businesses;
Expansion of generation options in new projections (back, side, etc.);
Expansion of supported product categories (shoes, jewelry, hats, etc. will be added);

It is worth noting that Virton AI is part of Neurosell's ecosystem of products, which allows it to have big data to learn from e-commerce partners. Also, in the coming days, the company plans to launch a personal account for businesses, allowing them to create widgets and integrations for any online store in a few minutes.

You can follow Virton AI news in the official resources:

Neural Network training on the example of Virton's virtual fitting room

Devs Daddy — Wed, 23 Apr 2025 10:35:33 +0000

Introduction

Hi everyone, we are here with the Neurosell team. In today's article we would like to share our experience in training neural networks on the example of our product - Virton virtual fitting room. We will tell you about the complexities of the algorithm, user experience and training opportunities.

First things first, let's review what our goals were:

Maximum preservation of context to get an accurate result of fitting in the image (for example, the user wants to match a T-shirt to his shorts in style;
Accurate product image transfer with preserving poses, adding details of fabric folds, etc;
Relative economy of algorithms;

What do we use for training and work?

UNet-based generative and reference models;
PyTorch under the hood, transformers and diffusers;
SCHP for pose detection and correction;
DensePose for body pixelization;
NVidia Cuda-based servers;

Now that we have a quick look at the goals and technologies, let's break down what we are doing to train the algorithms, looking at the main challenges and current results.

Training algorithms, metrics in current format

Initial training of the algorithms was performed on the large **DeepFashion **database, which offers many variations of different fashion items. Other sources for pose detection were also used. However, there is a disadvantage in using such databases - they do not provide real user experience and train models in ideal conditions.

What to do in such a case? Run beta versions of the algorithms!
As a result, real users start trying on clothes, creating new generations and pre-training the algorithm. And in the case of pilot products on online stores, we can make the algorithm even better, getting new styles, different users with their own understanding of how the services work.

So, what we have achieved in two weeks of training the algorithms:

At launch and in the first week of operation - generation accuracy was in the neighborhood of 30%;
On the second week of work, some correction of UX and internal algorithms - the accuracy increased to 60%;

Thus, by pre-training the algorithms on real users we bring the results to commercial values and this is only for 2 weeks of work.

What affects the accuracy of an algorithm?

Under ideal conditions, of course, we get great results, but in the real world it doesn't work that way. We get different users who often take photos that are not quite right for the neural network to work. And all of this has to be taken into account.

In our case, accuracy is affected by:

The quality of the original photos;
Compliance with color rules (if the person in the photo starts to merge with the background, or if he or she has monochromatic clothes that are difficult to segment);
Presence of other people in the frame;
Using photos that are not full-length;
Posing (crossed legs, arms, etc.);

The more of these indicators are combined together, the lower the quality of generation becomes. What to do in this case:

First work through the UX and explain to the user in clear language under what conditions they might have a bad result;
Do-train models on segmentation in various non-ideal poses for the algorithm;
Implement Multi-View Pose Transfer (for sideways photos and other body rotations;
Implement body part intersection detection, e.g. using pose detection algorithms (there are good examples on Tensorflow) and alert the user to problems;

Generation examples - from successes to epic fails

And as the final block of this article - we decided to share with you the results of generation, among which there are excellent, and there are quite funny and even strange.

Conclusion

What I would like to summarize in the end: any neural networks trained on ideal data and various open databases, as a rule, do not take into account the user factor, which definitely affects the result. Therefore, it is worthwhile to densely engage in pre-training of models on your real users, work with UX and look for new options to improve algorithms (for example, by introducing new additional tools).

And as always, discussions and your questions are welcome!