DEV Community: Zastinian

Hedystia 2.1: A Reactive UI Engine with No Virtual DOM

Zastinian — Sat, 04 Apr 2026 21:55:19 +0000

We just released Hedystia 2.1, and this time we're going full frontend with @hedystia/view — a fine-grained reactive UI engine that builds modern interfaces without a Virtual DOM.

If you've used Hedystia for the backend, you already know our philosophy: type safety, developer experience, and zero compromise on performance. Now we're bringing that same energy to the frontend.

TL;DR: @hedystia/view is a reactive UI framework where components run once, and reactivity updates only the exact DOM nodes that changed. No VDOM diffing. No reconciliation. Just surgical updates.

Install: bun add @hedystia/view
Docs: https://docs.hedystia.com/view/start

Why Build Another UI Framework?

We looked at the existing ecosystem and noticed something: most frameworks either use a Virtual DOM (React, Vue) or require a complete mental model shift (Solid, Svelte). We wanted something different:

No Virtual DOM — Create real DOM nodes directly
Components run once — No re-rendering, ever
Explicit reactivity — You control exactly what's reactive and what isn't
Type-safe end-to-end — Same type safety from backend to frontend
Familiar JSX — No new template syntax to learn

The Core Idea: Signals + JSX

At the heart of View is a signals system. Think of it as atomic reactive cells:

import { sig, val, set, update } from "@hedystia/view";

const count = sig(0);

console.log(val(count)); // 0
set(count, 1);
console.log(val(count)); // 1

The magic happens in JSX with one simple pattern:

function Counter() {
  // This function runs ONCE when the component mounts.
  // Only the text node created by the reactive accessor updates.

  return (
    <div>
      {/* Static — read once during mount */}
      <h1>Counter</h1>

      {/* Reactive — creates a fine-grained effect */}
      <p>Count: {() => val(count)}</p>

      <button onClick={() => update(count, (c) => c + 1)}>
        Increment
      </button>
    </div>
  );
}

The rule: {val(signal)} is static. {() => val(signal)} is reactive. That's it. Apply this pattern to props, children, styles, class names — everything.

No Virtual DOM, No Overhead

When count changes, View doesn't diff a virtual tree or re-render the component. It updates exactly one text node. That's it.

This is possible because:

Component functions execute once during mount
Reactive accessors create effects that track their specific DOM nodes
Signal dependencies trigger targeted updates — no reconciliation needed

The result? UIs that scale without the performance cliff of large re-renders.

Full Reactivity Toolkit

Batch & Untrack

Control when reactivity fires:

import { batch, untrack } from "@hedystia/view";

// Multiple updates, ONE reactive cycle
batch(() => {
  set(user.name, "Alice");
  set(user.email, "alice@example.com");
  set(user.age, 30);
});

// Read without creating a dependency
const snapshot = untrack(() => val(signal));

Memo — Lazy Derived Values

const items = sig([1, 2, 3]);
const doubled = memo(() => val(items).map((x) => x * 2));
const sum = memo(() => val(doubled).reduce((a, b) => a + b, 0));

// Computed lazily — only when read
console.log(val(sum)); // 12

Effects with Cleanup

import { on, once } from "@hedystia/view";

const dispose = on(
  () => val(userId),
  (id, prevId) => {
    console.log(`Switched from ${prevId} to ${id}`);
    // Return cleanup function
    return () => cleanupUser(id);
  }
);

// One-time effect
once(() => val(initialData), (data) => {
  console.log("Loaded:", data);
});

Store — Nested Reactive State

For complex state, use the proxy-based store:

import { store, val, set, patch, snap } from "@hedystia/view";

const user = store({
  name: "Alice",
  address: { city: "Wonderland" },
});

val(user.name);              // "Alice"
val(user.address.city);      // "Wonderland"
set(user.address.city, "NYC");

// Deep partial update
patch(user.address, { city: "Los Angeles" });

// Snapshot to plain object
const copy = snap(user);

Flow Control Components

Conditional Rendering

<Show when={() => val(isLoggedIn)} fallback={<Login />}>
  <Dashboard />
</Show>

Multi-way Conditionals

<Switch>
  <Match when={() => val(status) === "loading"}><Spinner /></Match>
  <Match when={() => val(status) === "error"}><Error /></Match>
  <Match when={() => val(status) === "success"}><Data /></Match>
</Switch>

Keyed Lists

<For each={() => val(users)} key={(u) => u.id}>
  {(user) => <UserCard user={user} />}
</For>

Index-Based Lists

<Index each={() => val(items)}>
  {(item, index) => <div>#{index}: {() => val(item)}</div>}
</Index>

Portal

<Portal>
  <Modal>Content outside hierarchy</Modal>
</Portal>

Data Fetching Built In

Load — Reactive Queries

const userId = sig(1);

const user = load(
  () => `user-${val(userId)}`,  // Key triggers refetch
  async () => {
    const res = await fetch(`/api/users/${val(userId)}`);
    return res.json();
  }
);

// user.data, user.loading, user.error, user.ready

Auto-refetches when the key changes. Auto-aborts previous in-flight requests.

Action — Reactive Mutations

const createPost = action(async (data) => {
  return fetch("/api/posts", { method: "POST", body: JSON.stringify(data) })
    .then((r) => r.json());
});

createPost.run({ title: "Hello" });
// createPost.loading, createPost.error, createPost.data

Context — Dependency Injection

import { ctx, use, Context } from "@hedystia/view";

const themeCtx = ctx<"light" | "dark">("light");

function App() {
  return (
    <Context.Provider value={themeCtx} value={() => "dark"}>
      <Header />
    </Context.Provider>
  );
}

function Header() {
  const theme = use(themeCtx); // "dark"
  return <header class={val(theme)}>Themed</header>;
}

Lifecycle Hooks

function MyComponent() {
  onMount(() => {
    console.log("Mounted");
    return () => console.log("Cleanup");
  });

  onReady(() => {
    // After first render — perfect for focus/measurements
    inputRef.focus();
  });

  onCleanup(() => {
    // Alternative cleanup registration
  });

  return <input ref={(el) => (inputRef = el)} />;
}

Rendering & SSR

import { mount, renderToString } from "@hedystia/view";

// Mount to browser
const app = mount(<App />, document.getElementById("app")!);
app.dispose(); // Unmount

// Server-side rendering
const html = renderToString(<App />);

The Performance Difference

Because View doesn't use a Virtual DOM:

No diffing overhead — Updates go straight to the DOM
No reconciliation — No tree traversal to find what changed
Predictable performance — O(1) updates regardless of tree size
Lower memory — No virtual tree to maintain

For small apps the difference is negligible. For complex dashboards, data tables, and real-time UIs, it's noticeable.

What Else Is New?

Hedystia 2.1 also includes all the features from our recent releases:

2.0 — @hedystia/db: Type-safe ORM with MySQL, SQLite, and File support, smart caching, and migrations
1.10 — Route testing, conditional routes, WebSocket support, and framework-agnostic type generation

Getting Started

# Install
bun add @hedystia/view

# Or with the full framework
bun add hedystia @hedystia/view

Check out the interactive docs at https://docs.hedystia.com/view/start

What's Next?

We're working on:

DevTools for signal debugging
Transition/animation system
More flow control components
Performance profiling utilities

We'd love your feedback! Try it out, break things, and let us know what you think on Discord or GitHub.

Hedystia is an open-source TypeScript backend framework now with a full-stack reactive UI engine. Type-safe from database to DOM.

Hedystia 2.0: A New Type-Safe ORM for TypeScript with Multi-Database Support

Zastinian — Mon, 16 Mar 2026 23:20:36 +0000

Introducing @hedystia/db

We just released Hedystia 2.0, which introduces @hedystia/db — a brand-new database ORM that combines the best of Drizzle and TypeORM:

Drizzle-like schema definition — Functional, composable, no decorators
TypeORM-like query API — Intuitive db.users.find() syntax
One schema, multiple databases — MySQL, SQLite, and File storage

Quick Start

bun add @hedystia/db

Define Your Schema

import { table, integer, varchar, boolean, text, datetime } from "@hedystia/db";

export const users = table("users", {
  id: integer().primaryKey().autoIncrement(),
  name: varchar(255).notNull(),
  email: varchar(255).unique(),
  age: integer().default(0),
  active: boolean().default(true),
  bio: text().nullable(),
  createdAt: datetime(),
});

export const posts = table("posts", {
  id: integer().primaryKey().autoIncrement(),
  userId: integer().references(() => users.id, {
    onDelete: "CASCADE",
  }),
  title: varchar(255).notNull(),
  content: text(),
});

12 column types supported: integer, bigint, varchar, char, text, boolean, json, datetime, timestamp, decimal, float, and blob.

Connect to Any Database

The same schema works across all supported databases:

import { database } from "@hedystia/db";

// SQLite
const db = database({
  schemas: { users, posts },
  database: "sqlite",
  connection: { filename: "./data.db" },
  syncSchemas: true,
  cache: true,
});

// MySQL
const db = database({
  schemas: { users, posts },
  database: "mysql",
  connection: {
    host: "localhost",
    user: "root",
    password: "password",
    database: "myapp",
  },
  syncSchemas: true,
  cache: true,
});

// File-based (JSON) — no driver needed
const db = database({
  schemas: { users, posts },
  database: "file",
  connection: { directory: "./data" },
  syncSchemas: true,
  cache: true,
});

Intuitive Query API

No more verbose query builders. Access your tables directly:

await db.initialize();

// Insert
const user = await db.users.insert({
  name: "Alice",
  email: "alice@example.com",
  age: 25,
});

// Find with conditions
const adults = await db.users.find({
  where: { age: { gte: 18 } },
  orderBy: { name: "asc" },
  take: 10,
});

// Complex queries with OR/AND
const results = await db.users.find({
  where: {
    OR: [
      { name: { like: "%alice%" } },
      { age: { between: [25, 35] } },
    ],
  },
});

// Relations with eager loading
const usersWithPosts = await db.users.find({
  with: { posts: true },
});

// Upsert
await db.users.upsert({
  where: { email: "alice@example.com" },
  create: { name: "Alice", email: "alice@example.com" },
  update: { age: 26 },
});

Full query API: find, findMany, findFirst, insert, insertMany, update, delete, count, exists, upsert, and truncate.

Smart Caching

Built-in cache with adaptive TTL and automatic invalidation:

const db = database({
  schemas: { users },
  database: "sqlite",
  connection: { filename: "./data.db" },
  cache: {
    enabled: true,
    ttl: 60000,       // Base TTL: 60 seconds
    maxTtl: 300000,   // Max TTL: 5 minutes
    maxEntries: 10000,
  },
});

Entity cache — Individual rows cached by primary key
Query cache — Full query results cached by stable key
Auto-invalidation — Mutations automatically invalidate affected caches
Adaptive TTL — Frequently accessed data stays cached longer: baseTTL × (1 + log₂(hitCount + 1))

In our benchmarks: 8x speedup on repeated find() queries and 2.5x on count().

Migration System

Schema sync for development:

const db = database({
  schemas: { users, posts },
  database: "sqlite",
  connection: { filename: "./data.db" },
  syncSchemas: true, // Auto-creates tables and adds missing columns
});

Programmatic migrations for production:

import { migration } from "@hedystia/db";

const addAgeColumn = migration("add_age_column", {
  async up({ schema }) {
    await schema.addColumn("users", "age", {
      name: "age",
      type: "integer",
      primaryKey: false,
      autoIncrement: false,
      notNull: false,
      unique: false,
      defaultValue: 0,
    });
  },
  async down({ schema }) {
    await schema.dropColumn("users", "age");
  },
});

CLI support:

bunx @hedystia/db migration create create_users --path src/database/migrations
bunx @hedystia/db schema create users --path src/database/schemas

Why @hedystia/db?

Feature	@hedystia/db	Drizzle	TypeORM	Prisma
Schema definition	Functional	Functional	Decorators	DSL file
Query API	`db.table.find()`	SQL-like builder	Repository pattern	Generated client
Type safety	Full inference	Full inference	Partial	Generated types
Multi-DB from one schema	✅	❌	Partial	❌
Built-in caching	✅ Adaptive	❌	❌	❌
File-based storage	✅	❌	❌	❌
Zero config start	✅ syncSchemas	❌	❌	❌

Get Started

bun add @hedystia/db

📖 Full documentation: https://docs.hedystia.com/db/start
📝 Blog post: https://docs.hedystia.com/blog/2.0
⭐ GitHub: https://github.com/Hedystia/Hedystia

The TypeScript Framework for APIs at Lightspeed ⚡

Zastinian — Fri, 13 Mar 2026 02:12:29 +0000

Introduction

Are you tired of the "validation gap" between your server and client? Are you fed up with writing complex integration tests for simple routes?

Meet Hedystia, a next-gen TypeScript framework designed for developers who value performance, type safety, and an elite developer experience. Built natively for Bun (but compatible with Node.js and Deno), Hedystia bridges the gap between your backend logic and your frontend consuming it.

🚀 The "Killer Feature": Built-in Route Testing

Most frameworks require you to spin up a separate testing suite and mock a bunch of dependencies just to test a simple endpoint. In Hedystia, testing is a first-class citizen of the route definition.

import { Hedystia, h } from "hedystia";

const app = new Hedystia()
  .get("/users/:id", ({ params }) => ({ id: params.id, name: "John" }), {
    params: h.object({ id: h.number().coerce() }),
    response: h.object({ id: h.number(), name: h.string() }),
    // Test right next to your code!
    test: async ({ createRequest, expect }) => {
      const { response, statusCode } = await createRequest({
        params: { id: 123 },
      });
      expect(statusCode).toBe(200);
      expect(response.id).toBe(123);
    },
  })
  .listen(3000);

// Run all route tests with a single command
const results = await app.runTests();
console.log(results.report);

This isn't just a gimmick—it's a paradigm shift. Your documentation, implementation, and tests live together in harmony.

🔒 End-to-End Type Safety

Hedystia doesn't just "support" TypeScript; it embraces it. When you define a route, Hedystia infers the types for the body, query, params, and response.

Pair it with the @hedystia/client, and you get a fully-typed HTTP client with zero effort.

Server Side

.post("/users", (ctx) => { ... }, {
  body: h.object({
    email: h.string().email(),
    age: h.number()
  })
})

Client Side (Autocompleted!)

import { createClient } from "@hedystia/client";

const client = createClient<typeof app>("http://localhost:3000");

// Fully typed! If you miss a field or use the wrong type, TypeScript will yell at you.
const { data, error } = await client.users.post({
  body: {
    email: "dev@hedystia.com",
    age: 26
  }
});

🧩 Dynamic Routing with `.if()`

Need to toggle features or register routes based on environment variables or configuration? Hedystia's .if() method makes dynamic API design clean and intuitive.

const app = new Hedystia()
  .if((app) => {
    if (process.env.ENABLE_BETA_FEATURES) {
      return app.get("/beta", () => ({ status: "experimental" }));
    }
  })
  .listen(3000);

📡 Real-Time WebSockets

Type safety shouldn't stop at REST. Hedystia provides a powerful, type-safe WebSocket implementation with a client that supports auto-reconnection and event-based handlers.

const app = new Hedystia()
  .ws("/chat", {
    message: (ws, message) => {
      ws.send(`Echo: ${message}`);
    },
  })
  .listen(3000);

// Client-side
client.chat.ws((ws) => {
  ws.onConnect(() => ws.send("Hello!"));
  ws.onMessage((msg) => console.log(msg));
});

🌟 Why Use Hedystia?

Bun-Native Performance: Optimized for the fastest JS runtime.
Multi-Runtime: Works on Deno, Node.js, Cloudflare Workers, and more.
Validation Built-in: Uses a high-performance validation system compatible with Standard Schema (Zod, Arktype, etc.).
Framework-Agnostic Types: Use Hedystia's typing system even with Express, Hono, or Fastify.

Get Started Today

Hedystia is open-source and ready for you to build something amazing.

GitHub: https://github.com/Hedystia/Hedystia
Documentation: https://docs.hedystia.com
NPM: bun add hedystia

What do you think about built-in route testing? Let us know in the comments! 👇

JWT vs PASETO v2 vs TECTO: Choosing the Right Token Protocol in 2026

Zastinian — Sun, 22 Feb 2026 04:13:10 +0000

Tokens are everywhere in modern auth flows. But not all tokens are created equal. In this post we'll compare three approaches side by side — classic JWTs, the more modern PASETO v2, and the brand-new TECTO — across security, ergonomics, and real code.

🔍 The Quick Summary

Property	JWT (HS256)	PASETO v2	TECTO
Payload visible?	✅ Yes (base64)	✅ Yes (signed, not encrypted)	❌ Fully encrypted
Cipher	None (HMAC)	Ed25519 (sign) / XChaCha20 (encrypt)	XChaCha20-Poly1305
Nonce	N/A	24-byte per token	24-byte CSPRNG per token
Key size	Variable	Variable	Exactly 256-bit (enforced)
Tamper detection	HMAC signature	Ed25519 / Poly1305 tag	Poly1305 auth tag
Error specificity	Reveals reason	Reveals reason	Generic "Invalid token"
Algo confusion attacks	⚠️ Yes (the `alg: none` problem)	✅ No	✅ No
Key rotation built-in	❌ DIY	❌ DIY	✅ Native (`kid` in token)

1️⃣ JWT — The Industry Standard

jsonwebtoken is the most widely used token library in Node.js. It's battle-tested, has a massive ecosystem, and is dead-simple to start with.

npm install jsonwebtoken

Creating and verifying a JWT

import jwt from "jsonwebtoken";

const SECRET = "my-secret-key"; // ← This is the problem

// Sign
const token = jwt.sign(
  { userId: 42, role: "admin" },
  SECRET,
  { expiresIn: "1h", issuer: "my-app" }
);

console.log(token);
// eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjQyLCJyb2xlIjoiYWRtaW4iLCJpYXQiOjE3MDAwMDAwMDAsImV4cCI6MTcwMDAwMzYwMCwiaXNzIjoibXktYXBwIn0.SIGNATURE

// Verify
const payload = jwt.verify(token, SECRET) as { userId: number; role: string };
console.log(payload.userId); // 42

⚠️ The Payload is Just Base64

Here's the catch — take the middle segment of any JWT and decode it:

const [, payload] = token.split(".");
const decoded = Buffer.from(payload, "base64url").toString("utf-8");
console.log(decoded);
// {"userId":42,"role":"admin","iat":1700000000,"exp":1700003600,"iss":"my-app"}

Anyone who intercepts the token can read the payload. No key needed. This is by design — JWTs are signed, not encrypted — but many developers don't realize this at first.

⚠️ The `alg: none` / Algorithm Confusion Problem

JWT allows the algorithm to be specified in the header. This led to the infamous alg: none attack where attackers could forge tokens by setting the algorithm to none. Even with modern libraries that block none, HMAC vs RSA confusion attacks are still a real concern if you accept tokens from multiple issuers.

✅ When to use JWT

Public, non-sensitive payloads (user IDs, roles)
Integrating with third-party services that require JWT (OAuth, OIDC)
When your team already has JWT infrastructure

2️⃣ PASETO v2 — The JWT Successor

PASETO (Platform-Agnostic Security Tokens) was designed to fix JWT's footguns. It removes algorithm agility entirely — you pick a version and you get a fixed, well-chosen algorithm. No alg: none, no confusion attacks.

npm install paseto

Local tokens (symmetric, encrypted)

PASETO v2 comes in two flavors: local (symmetric, encrypted) and public (asymmetric, signed). v2.local is the encrypted one.

import { V2 } from "paseto";

const key = await V2.generateKey("local");

// Encrypt
const token = await V2.encrypt(
  { userId: 42, role: "admin" },
  key,
  { expiresIn: "1h", issuer: "my-app" }
);

console.log(token);
// v2.local.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

// Decrypt
const payload = await V2.decrypt(token, key);
console.log(payload.userId); // 42

Public tokens (asymmetric, signed but NOT encrypted)

const { privateKey, publicKey } = await V2.generateKey("public");

// Sign (payload is visible, like JWT)
const token = await V2.sign({ userId: 42 }, privateKey, { expiresIn: "1h" });

// Verify
const payload = await V2.verify(token, publicKey);

✅ What PASETO gets right

No algorithm confusion — the version (v2) pins the algorithm
v2.local encrypts the payload (XChaCha20-Poly1305)
Clean, modern API with async support

⚠️ What PASETO still lacks

No native key rotation story — kid is not part of the token format
You must manage key versioning yourself
Error messages can still reveal failure mode
No entropy validation on keys — you can pass a weak key and it'll silently accept it

3️⃣ TECTO — Encrypted by Default, Security-First

TECTO (Transport Encrypted Compact Token Object) takes a different philosophy: every token is fully encrypted, always. There's no "signed but readable" mode.

bun add tecto

Creating and decrypting a TECTO token

import { generateSecureKey, MemoryKeyStore, TectoCoder } from "tecto";

// 1. Generate a cryptographically secure 256-bit key
const key = generateSecureKey();

// 2. Set up the key store
const store = new MemoryKeyStore();
store.addKey("my-key-2026", key);

// 3. Create a coder
const coder = new TectoCoder(store);

// 4. Encrypt
const token = coder.encrypt(
  { userId: 42, role: "admin" },
  { expiresIn: "1h", issuer: "my-app" }
);

console.log(token);
// tecto.v1.my-key-2026.base64url_nonce.base64url_ciphertext

// 5. Decrypt
const payload = coder.decrypt<{ userId: number; role: string }>(token);
console.log(payload.userId); // 42

The token format is self-describing

tecto.v1.<kid>.<nonce>.<ciphertext>

The kid (key ID) is embedded in the token itself. This enables native key rotation — no extra metadata or headers needed.

Key rotation is a first-class citizen

// Old key still decrypts old tokens
store.addKey("key-2026-01", oldKey);

// Rotate: new tokens use the new key
store.rotate("key-2026-06", newKey);

// Old tokens still work
const oldPayload = coder.decrypt(oldToken); // ✅ uses key-2026-01

// New tokens use new key
const newToken = coder.encrypt({ userId: 99 });
// tecto.v1.key-2026-06.xxxxx.xxxxx

// Remove old key when all old tokens have expired
store.removeKey("key-2026-01");

Entropy validation on every key

import { assertEntropy } from "tecto";

// These all throw KeyError
assertEntropy(new Uint8Array(32));                 // all zeros
assertEntropy(new Uint8Array(32).fill(0xaa));      // repeating byte
assertEntropy(new Uint8Array(16));                 // wrong length

// This is safe
const key = generateSecureKey(); // always produces a valid, high-entropy key
assertEntropy(key); // ✅ passes

Generic errors prevent oracle attacks

try {
  coder.decrypt(tamperedToken);
} catch (err) {
  if (err instanceof InvalidSignatureError) {
    // err.message === "Invalid token"
    // You don't know WHY it failed — and that's the point
    // Attackers can't probe the system by watching error messages
  }
  if (err instanceof TokenExpiredError) {
    // Safe to throw distinctly because we already decrypted successfully
    // err.expiredAt is available, but NOT in err.message (timing protection)
  }
}

🔬 Side-by-Side: Payload Visibility

Let's make this concrete. Suppose you encode { userId: 42, role: "admin" } in each format:

JWT — Fully readable

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.eyJ1c2VySWQiOjQyLCJyb2xlIjoiYWRtaW4ifQ  ← base64 of { userId: 42, role: "admin" }
.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Anyone can atob() the middle segment. No key needed.

PASETO v2.local — Encrypted ✅

v2.local.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxFULL_CIPHERTEXT

Encrypted with XChaCha20-Poly1305. Opaque without the key.

TECTO — Encrypted ✅

tecto.v1.my-key-2026.NONCE_BASE64URL.CIPHERTEXT_BASE64URL

Encrypted with XChaCha20-Poly1305. The kid is visible (it's just a label), but the payload is mathematically unreadable without the key.

🔄 Key Rotation Comparison

Feature	JWT	PASETO v2	TECTO
Key ID in token	❌ Not standard	❌ Not standard	✅ Built-in `kid`
Old token decryptable after rotation	DIY	DIY	✅ `store.rotate()` handles it
Revoke old key	DIY	DIY	✅ `store.removeKey()` zeroes memory
Entropy validation	❌ No	❌ No	✅ `assertEntropy()` enforced

🛡️ Security Properties at a Glance

JWT HS256

✅ Tamper-evident (HMAC)
❌ Payload readable by anyone
❌ Algorithm confusion attack surface
❌ No entropy enforcement on secret

PASETO v2.local

✅ Payload encrypted (XChaCha20-Poly1305)
✅ No algorithm agility (version pins algo)
✅ Authenticated encryption
❌ No native key rotation
❌ No entropy enforcement

TECTO

✅ Payload always encrypted (XChaCha20-Poly1305)
✅ Native key rotation with kid
✅ Entropy validation on all keys
✅ Generic errors (no oracle attacks)
✅ Timing-safe comparisons
✅ Memory zeroing on key removal
✅ Payload size limits (DoS prevention)
✅ Type-checked registered claims (prevents type confusion)

🤔 Which Should You Choose?

Use JWT if:

You need compatibility with OAuth / OIDC / existing infrastructure
Your payload contains no sensitive data (just user IDs, roles)
You're integrating with third-party services

Use PASETO v2.local if:

You want a well-audited, standardized encrypted token
You need interoperability across multiple languages/platforms
You don't need native key rotation

Use TECTO if:

You want encrypted-by-default with zero configuration mistakes possible
You need native key rotation without extra infrastructure
You're building a greenfield TypeScript/Bun project
You want defense-in-depth: entropy validation, generic errors, timing safety, memory zeroing

🚀 Getting Started with TECTO

bun add tecto

import { generateSecureKey, MemoryKeyStore, TectoCoder } from "tecto";

const store = new MemoryKeyStore();
store.addKey("v1", generateSecureKey());

const coder = new TectoCoder(store);

// Encrypt
const token = coder.encrypt({ userId: 42 }, { expiresIn: "1h" });

// Decrypt
const { userId } = coder.decrypt<{ userId: number }>(token);

For persistent key storage, TECTO ships with adapters for SQLite, PostgreSQL, and MariaDB — all following the same KeyStoreAdapter interface.

Final Thoughts

JWT will remain the standard for federated auth and OAuth flows for a long time — and that's fine. But for internal service-to-service tokens, session tokens, or any scenario where payload privacy matters, you should reach for an encrypted token format.

PASETO v2.local is a solid, standardized choice. TECTO goes a step further with batteries-included key rotation, entropy enforcement, and a security-first error model.

The best token protocol is the one you can't misconfigure. TECTO makes a strong case for that.