DEV Community

Why Every Developer Will Eventually Design AI Systems

Jaideep Parashar — Fri, 06 Mar 2026 06:18:41 +0000

For most of software history, developers primarily built deterministic systems.

You wrote logic.
You defined rules.
The machine executed them.

The developer’s job was to translate human intent into precise instructions.

AI introduces a different paradigm.

Instead of encoding every rule manually, developers increasingly design systems that interpret context, generate outputs, and make decisions under uncertainty.

This doesn’t create a new profession separate from software engineering.

It gradually transforms the role itself.

Over time, nearly every developer will find themselves designing AI systems—whether they planned to or not.

AI Is Becoming a General Infrastructure Layer

In the past, AI lived in specialized domains:

research labs
recommendation engines
search ranking systems
large enterprise data platforms

Today it is becoming embedded everywhere.

Applications increasingly include AI for:

natural language interaction
automation
classification and prediction
personalization
decision support

Just as web APIs and cloud services became universal infrastructure, AI capabilities are now integrating into everyday software.

Developers don’t need to specialize in machine learning to use them.

They simply become part of the system stack.

The Shift From Rule-Based Systems to Context-Based Systems

Traditional software requires developers to specify every behavior.

AI-based systems operate differently.

Instead of defining exact rules, developers increasingly define:

context
constraints
goals
evaluation criteria
boundaries for safe operation

The system interprets these elements to generate outcomes dynamically.

This moves engineering from:

writing explicit logic

to:

designing decision environments.

Developers become responsible for shaping how intelligent behavior emerges within the system.

Developers Already Design Systems; AI Expands That Responsibility

Software engineers have always designed systems.

They decide:

architecture
data flows
service boundaries
error handling
performance trade-offs

AI systems add new dimensions:

behavior variability
probabilistic outputs
feedback loops
evaluation metrics
model selection and orchestration

These are extensions of existing engineering responsibilities, not entirely new disciplines.

Developers simply move further into systems-level thinking.

AI Features Gradually Turn Into AI Products

Many teams begin by adding small AI capabilities:

chat interfaces
automated summaries
content suggestions

But once these features prove useful, they expand.

Over time they influence:

user experience
business workflows
automation pipelines
operational decisions

At that point, the application itself becomes AI-native.

And the developers maintaining it must understand how the AI behaves within the system.

This naturally pushes developers into AI system design roles.

Engineering Becomes Behavior Design

AI systems behave differently from traditional software.

They can:

produce varying outputs
change behavior over time
respond to subtle context differences

Developers must therefore design systems that answer questions like:

What constitutes a correct output?
When should a human intervene?
How do we detect drift or degraded performance?
What happens when the AI is uncertain?

These are engineering challenges focused on behavior governance, not just code execution.

Why This Doesn’t Require Becoming an ML Researcher

Designing AI systems does not require every developer to:

train models from scratch
study advanced statistics
become machine learning specialists

Instead, developers increasingly work with:

APIs and foundation models
orchestration frameworks
evaluation tools
workflow automation layers

The focus shifts toward:

integration
system architecture
operational monitoring
safe deployment practices

In many cases, the hardest problems are product and system design questions, not mathematical ones.

AI Systems Require Ongoing Operations

Traditional software often stabilizes once deployed.

AI systems behave more like living systems.

They require:

continuous monitoring
evaluation of output quality
updates as models evolve
adjustments to prompts or context
human oversight in sensitive cases

This means developers increasingly participate in AI operations alongside traditional DevOps practices.

The lifecycle of the system becomes continuous rather than static.

The Competitive Advantage Moves Toward System Thinking

Because AI simplifies certain implementation tasks, the most valuable skills shift toward:

problem framing
architectural clarity
workflow design
trade-off evaluation
reliability and safety planning

Developers who understand how AI fits into larger systems will deliver the most value.

The difference will not be who can call an AI API.

It will be who can design systems where AI works reliably and responsibly.

Why This Transformation Is Inevitable

History shows a clear pattern.

Developers once had to manage:

physical servers
networking hardware
operating systems manually

Cloud infrastructure abstracted those concerns.

Later, developers integrated:

web services
authentication platforms
distributed systems

Each wave introduced complexity that became standard practice.

AI is following the same path.

Today it feels specialized.

Within a decade it will feel foundational.

The Real Takeaway

Developers are not being replaced by AI.

They are being asked to operate at a higher level of abstraction.

Instead of writing every rule, they will increasingly design systems that:

interpret context
make probabilistic decisions
collaborate with human judgment
improve through feedback.

AI does not remove the need for developers.

It expands their responsibility from writing deterministic programs to designing intelligent systems.

And as AI becomes embedded in every layer of software, that responsibility will eventually touch nearly every developer.

OpenTableAPI for Developers: Build APIs from Your Table Data

Priyantha Weerasinghe — Fri, 06 Mar 2026 06:12:46 +0000

Introduction

https://www.opentableapi.com

Modern applications rely heavily on APIs to connect services, power user interfaces, and share data between systems. Traditionally, developers build backend applications, manage servers, design databases, and implement CRUD APIs just to expose simple data.
OpenTableAPI simplifies this entire process.
OpenTableAPI allows developers to turn table-based business data directly into APIs without building a backend system from scratch.
Instead of creating and hosting a backend application with a database, teams can use OpenTableAPI as an online CMS and API platform.
This means:
No need to build CRUD APIs
No need to manage a backend server
No need to host a database on a VPS

Developers can simply create tables, manage data through a CMS interface, and instantly access the data through APIs.
This makes OpenTableAPI a powerful option for teams that want a CMS-like system for data management combined with developer-ready APIs.

Why Developers Use OpenTableAPI
Developers and teams use OpenTableAPI because it removes the complexity of building and maintaining backend infrastructure.
Key benefits include:
Instant APIs from table data

Online CMS interface to manage records
No need to build a backend application
No need to host a VPS server for APIs
No need to manage a database server
API-first architecture for developers

Instead of building a traditional stack like:
Frontend → Backend Application → Database
OpenTableAPI simplifies it to:
Frontend / Backend App → OpenTableAPI
This significantly reduces development time and infrastructure management.

OpenTableAPI as an Online CMS
OpenTableAPI works similarly to a content management system (CMS) but is designed for developers who need APIs.
You can:
Create tables
Define columns
Insert and edit records
Manage operational data
Access everything through APIs

Just like a CMS, users can manage content through a web interface, while developers can consume the same data through REST APIs.
This makes it ideal for:
Product data

Internal tools
Operational dashboards
Configuration data
Lightweight SaaS applications

Core API Concept 📦
In OpenTableAPI, each table automatically becomes an API resource.
For every table, the system generates a set of standard REST endpoints.

Because every table follows the same structure, developers can integrate quickly without learning custom API patterns.

Authentication and Access Control
OpenTableAPI secures all requests using API keys.
Requests must include the API key in the header:
X-API-Key:
Each project can generate multiple API keys, and every key can have different permissions.
Permissions can be restricted by:
Table

Endpoint type (GET, POST, PUT, DELETE)

This allows developers to control exactly who can read or modify data.

CMS-Style Permission System
OpenTableAPI includes a CMS-style permission model.
You can control access similar to how permissions work in a traditional CMS.
Users or API keys can be given:
Read Only Access
Users can view data but cannot modify it.
Example use cases:
Analytics dashboards

Public APIs

Frontend applications displaying data

Edit Access
Users can create and update records.
Example use cases:
Admin dashboards

Internal operational tools

Content editors

This ensures safe collaboration between teams while protecting important data.

Example Usage Flow
A typical developer workflow looks like this:
Create a project

Create tables and define columns

Add or manage records through the CMS

Generate API keys

Configure table and endpoint permissions

Access data through API endpoints

Within minutes, developers can go from structured data to a working API.

Best Practices for Developers
To build secure and scalable integrations, follow these best practices.
Use Separate Projects for Environments
Create different projects for:
Development

Staging

Production

This prevents development changes from affecting production data.

Use Separate API Keys for Applications
Use different API keys for:
Frontend applications

Backend services

Internal tools

This allows you to control and restrict access for each system independently.

Apply Least-Privilege Permissions
Enable only the required endpoints.
Example:
Frontend apps → GET only

Admin tools → POST, PUT

Automation jobs → specific tables only

Validate Input Before Sending to the API
Applications should validate user input before sending data to OpenTableAPI to avoid incorrect or malformed records.

Rotate API Keys Periodically
Regular API key rotation improves system security and prevents long-term exposure if a key is leaked.

Business Value
OpenTableAPI bridges the gap between data management and developer APIs.
It allows teams to:
Manage data through a CMS-style interface

Access the same data through structured APIs

Eliminate the need for custom backend infrastructure

This approach provides:
Faster development cycles

Lower infrastructure costs

Simpler collaboration between developers and non-technical teams

Instead of maintaining a backend server and database, teams can use OpenTableAPI as their data backend and API layer.

OpenTableAPI transforms simple tables into a powerful CMS and API platform — allowing developers to build applications faster without managing backend infrastructure.

Vibe Coding Challenge - Day 8: Case Files Dedective Game

labdays — Fri, 06 Mar 2026 06:04:19 +0000

Each one is a unique and different detective game. Artificial Conan Doyle

Announcement
My detective game, Case Files, which I released today, seems to be a good example of this type of game in terms of visuals and interface. You can create case files on any topic and content you want, collect clues, and examine suspects like a detective.
If you'd like to try it, the link is below 👇
casefiles.labdays.io

Context
I started the Vibe Coding Challenge. I plan to release a new product every day, and today is my 7th day. You can visit my website (labdays.io) to learn about the process.

Notes from the 8th day of the Challenge
AI is quite good at the frontend, but when it comes to the backend, it gravitates towards stacks with external dependencies and requires dashboard setups like Supabase.
I'm using Vercel for deployments, and the backend operations are resource-intensive. I need to find a more cost-effective stack and deployment option.
The best thing about Vibe Coding is that you don't even know the features on your site. You just think, "Wow, I hadn't thought of that, it's amazing!"
I admire the work that comes out. However, I'm also curious how far it can continue to be developed. It leaps 100 steps forward initially. However, when you try to build upon it, it cannot linearly add another 100 steps. Its capabilities decrease as the codebase grows.
Doing a project every day is really tiring, but also satisfying. I couldn't continue without the dopamine it gives me.
People are slowly starting to notice my projects. I need to produce more advanced work and develop open-source projects that everyone can use.
I'm realizing that everything digital is starting to become worthless with artificial intelligence. It is not only daily projects like mine that are losing value. I doubt even the projects that are number 1 on Product Hunt are making any profit. I think nowadays, developers are creating for each other in the digital environment. Ordinary people are completely oblivious to all this.
Digital products have become devalued. We need to try to create things that bridge the gap between the digital world and the real world.
The more connected something is to the physical world, the more valuable it becomes.

What is Engineer persona?

Pavanipriya Sajja — Fri, 06 Mar 2026 06:01:42 +0000

What is an Engineer persona in a user research method?

A user persona is a research-based, fictional but realistic representation of a user group, built from patterns found in real data, interviews, and observations. It gives your team a shared mental model of who you're building for.

For Example: A persona for a platform Engineer isn’t one specific person at your company. It's what you learned from interviewing 15 platform engineers across different orgs, distilled into one coherent, usable profile.

Why it is important to consider?:

Developer experience projects fail not because engineers lack skill, but because teams build for an imagined user instead of a researched one. Personas make the real user visible inside engineering decisions.

73% of DevEx friction comes from tools not matching how developers actually think and work — not from technical limitations alone.

3X Teams using personas in design reviews are significantly more likely to catch usability issues before engineering investment begins.

How these personas are useful:

These personas help teams make better decisions by keeping real users at the center of every conversation. Instead of guessing, debates and discussions are grounded in actual evidence from users. Features get prioritized based on what engineers truly struggle with day to day.

Documentation is written around the tasks and goals engineers actually have, not just technical specs. Onboarding is scoped to the right starting point so new users aren't overwhelmed or under-informed. And in every meeting, there's a clear answer to the question "who is this actually for?" which keeps everyone aligned and focused.

Why DevEx is Different from Consumer UX?

Developers are power users with strong mental models and well-established workflows. While they can handle complex systems like Kubernetes, they have very little tolerance for friction in their critical path tasks such as debugging, deploying, or scaling applications.

Unlike consumer UX, which often focuses on visual delight, enjoyable interactions and engagement in platforms like Instagram, Developer Experience (DevEx) focuses on reducing cognitive load. A DevEx persona therefore emphasizes clarity, efficiency, and predictable workflows so engineers can complete high-frequency, high-stakes tasks with minimal mental effort.

👉 In simple terms: Consumer UX tries to make products enjoyable, but Developer experience tries to make complex tasks faster, clearer, and less mentally exhausting.

How to create a Engineer persona?

Creating a developer persona is different from creating a typical consumer persona. Instead of focusing on demographics, DevEx personas focus on workflows, tools, goals, and friction points in technical tasks. Here is a practical step-by-step approach.

1. Start With Real Research Data

Developer personas should always be based on real evidence, not assumptions.

You can collect data through:

Developer surveys
Interviews with engineers
Observing real workflows
Reviewing support issues or GitHub discussions

For teams building infrastructure platforms like Kubernetes, this might include understanding how engineers deploy, debug, and manage clusters.

2. Identify Behavioral Patterns

After collecting data, analyze it to find patterns in how developers work.

Look for similarities in:

Goals (deploy faster, automate operations, reduce downtime)
Pain points (configuration complexity, unclear errors, manual steps)
Workflows (CI/CD pipelines, CLI usage, automation scripts)
Tool usage (for example Docker or Terraform)

These patterns help define distinct developer groups.

3. Define the Persona Structure

A developer persona usually includes the following sections:

Role and Context:

Job role (Platform Engineer, Developer, SRE)
Experience level
Type of environment they work in

Goals:

What they are trying to achieve in their workflow

Key Tasks:

High-frequency tasks like deploying services, debugging failures, or scaling clusters

Pain Points:

Friction points in their daily workflow

Tools and Ecosystem:

Technologies and platforms they regularly use

Mental Models:

How they expect systems to behave

It is useful as a decision-making tool.

4. Focus on Workflows Instead of Demographics

In DevEx, demographics are less important. Instead of describing age or hobbies, focus on:

deployment processes
debugging patterns
infrastructure management workflows

This makes the persona actionable for engineering teams.

5. Validate With Developers

Once the persona is drafted, review it with actual engineers. Ask questions like:

Does this reflect your real workflow?
Are the pain points accurate?
What is missing?

This step helps ensure the persona reflects real developer behavior.

👉 In simple terms: A developer persona is created by studying real developer workflows, identifying patterns in their goals and challenges, and translating those insights into a clear representation that helps teams design better developer tools.

Tools to Create Developer Personas

What tools should we use to design personas? Typically, UX researchers create personas using tools such as Figma or Miro, or other platforms that provide ready-made persona templates. In these tools, researchers usually add persona data directly into the template format.

This approach works well when collaborating with UX design teams or teammates who are already familiar with these design tools. However, when working with developer experience teams, it is important to choose tools that developers can easily access and use to provide feedback.

For this reason, I chose to use Google Sheets to build the persona. A spreadsheet allows the information to be organized in a clear tabular format, making it easier for developers to review the data and add feedback directly.

Choosing the right tool makes collaboration easier and more effective. It also helps avoid repeating the same work across multiple tools, saving both time and effort.

How many personas that you actually need or build and how can we prioritize?

The number of personas you need depends on the diversity of users and their workflows, but in most DevEx or platform products, teams typically build 3–5 core personas. Building too many personas can dilute focus and make it harder for teams to use them in decision-making.

1. How Many Personas Are Usually Needed

In developer-focused products (for example platforms built around Kubernetes), teams usually identify a small set of representative roles such as:

Platform Engineers – manage infrastructure and clusters
Application Developers – deploy and run applications
SRE / Operations Engineers – maintain reliability and monitor systems

Each persona represents distinct goals, workflows, and pain points, not just job titles.

👉 A good rule is: Create enough personas to represent different behaviors, but not so many that teams cannot remember or use them.

2. How to Prioritize Personas

Not all personas should have equal weight. Prioritization usually depends on three factors:

Frequency of Use: Which users interact with the system the most? And High-frequency users should often be prioritized.

Impact on the System: Which users influence the platform architecture or adoption? For example, platform engineers often shape how tools like Kubernetes are configured across organizations.

Critical Workflows: Which personas perform the most critical tasks (deployment, scaling, debugging)? And Improving their experience usually delivers the highest value.

3. Persona Prioritization Model

Teams often classify personas into three levels:

Primary Persona:

The main user the product is designed for,
Most design decisions should support their workflows

Secondary Persona: Important users but with fewer or overlapping needs

Tertiary Persona: Users who interact occasionally or indirectly

👉 Focus design decisions around one primary persona, support 1–2 secondary personas, and avoid building too many additional ones.

How Teams can use this persona?

Personas are useful for engineering teams in several practical ways during a project. Here are five key ways they help:

1. Aligning the Team Around the User

Personas give engineers a clear understanding of who they are building for. This helps teams avoid assumptions and focus on real developer needs, especially when building complex systems like Kubernetes platforms.

2. Prioritizing Features

Personas help teams decide which features matter most. If a feature supports the primary persona’s workflow, it should usually be prioritized over less critical improvements.

3. Identifying Workflow Friction:

By mapping goals and pain points, personas reveal where developers struggle in their workflows, helping engineering teams focus on reducing friction in high-frequency tasks.

4. Supporting Design and Architecture Decisions:

Personas help engineers understand mental models and expected workflows, which guides better decisions when designing APIs, tools, or developer platforms.

5. Improving Communication Across Teams:

Personas create a shared language between product, UX, and engineering teams, making discussions about user needs clearer and more consistent.

👉 Personas help engineering teams align on users, prioritize features, reduce workflow friction, guide design decisions, and improve collaboration across teams.

Conclusion:

Engineer personas are a practical research tool that keeps real developer needs at the center of every product decision. By grounding design and engineering conversations in actual workflows, goals, and pain points rather than assumptions.

Teams can reduce friction, prioritize the right features, and build platforms that developers genuinely want to use. Whether you're designing for Kubernetes, internal tooling, or any developer facing product, a well researched persona is one of the simplest ways to close the gap between what teams build and what engineers actually need.

Next.js Rebuilt, NumPy in TypeScript, Six AI Predictions

Adam — Fri, 06 Mar 2026 05:53:59 +0000

Edwin Ong and Alex Vikati ran Claude Code against 2,430 real repos with zero prompting — no tool names, no hints — and just watched what it picked. The result is rare, unbiased observational data on how AI coding agents actually behave when left to their own devices.

Gergely Orosz returns from The Pragmatic Summit with six predictions for the future of software engineering in the AI era (spoiler: your career is not over, but it is changing). Ian Vanagas from PostHog asks the quieter question: why is every role already starting to feel like an engineering role?

Cloudflare had a productive week. Code Mode compresses entire APIs into 1,000 tokens for agent context — the context window problem just shrunk. Their official Agents SDK ships for production deployments. And, for the boldest move of the week: one Cloudflare engineer rebuilt Next.js from scratch with AI in a single week. Meanwhile, Stripe continues the Minions series with part 2 of their one-shot, end-to-end coding agents.

On the web platform: Una Kravets introduces CSS border-shape — the beginning of the non-rectangular web without clip-path hacks. Tim Perry declares dictionary compression (zstd/Brotli) ridiculously good and finally here — web payloads could shrink dramatically overnight. There's also a thorough empirical study across 500 repositories on frontend memory leaks, and nine PostgreSQL features Thiery Michel wishes he'd known sooner.

Tools this week: sabiql is a driver-less TUI for querying PostgreSQL from your terminal, and numpy-ts brings 94% of NumPy's API to TypeScript — scientific computing finally joins the JavaScript ecosystem.

Enjoy!

Signup here for the newsletter to get the weekly digest right into your inbox.

Find the 13 highlighted links of weeklyfoo #126:

What Claude Code Actually Chooses

by Edwin Ong, Alex Vikati

We pointed Claude Code at real repos 2,430 times and watched what it chose. No tool names in any prompt. Open-ended questions only.

🚀 Read it!, ai, code, claude

Code Mode

by Matt Carey

Give agents an entire API in 1,000 tokens

📰 Good to know, ai, mcp, cloudlfare

Minions

by Alistair Gray

Stripe’s one-shot, end-to-end coding agents—Part 2

📰 Good to know, ai, stripe

The engineeringification of everything

by Ian Vanagas

Why every role seems like an engineering role now (and what it means for you)

📰 Good to know, engineering

Dictionary Compression is finally here, and it's ridiculously good

by Tim Perry

Dictionary compression could completely change how applications send data over the web.

📰 Good to know, compression

The Future of Software Engineering with AI: Six Predictions

by Gergely Orosz

Notes from The Pragmatic Summit and ‘The Future of Software Development’ workshop

📰 Good to know, ai

Frontend Memory Leaks

by Ko-Hsin Liang

A 500-Repository Static Analysis and Five-Scenario Benchmark Study

📰 Good to know, memory, leak, frontend

9 Advanced PostgreSQL Features I Wish I Knew Sooner

by Thiery Michel

My first instinct was to write application-level validation, but something felt off. Surely PostgreSQL had a better way?

📰 Good to know, postgres, database

border-shape

by Una Kravets

the future of the non-rectangular web

📰 Good to know, css

Cloudflare Agents

by Cloudflare

Build and deploy AI Agents on Cloudflare

🧰 Tools, ai, cloudflare

How we rebuilt Next.js with AI in one week

by Steve Faulkner

Last week, one engineer and an AI model rebuilt the most popular front-end framework from scratch.

🧰 Tools, ai, nextjs, cloudflare, vinext

sabiql

by riii111

A fast, driver-less TUI to browse, query, and edit PostgreSQL databases

🧰 Tools, postgres, database, cli

numpy-ts

by Nico D.

Full NumPy, in TypeScript/JavaScript (94% coverage)

🧰 Tools, math, array, matrix

Want to read more? Check out the full article here.

To sign up for the weekly newsletter, visit weeklyfoo.com.

🔐 Matching in the Dark: Zero‑Knowledge Filtering Using 32‑Bit Bitmasks

Venkat — Fri, 06 Mar 2026 05:51:27 +0000

This is Part 2 of a series on building a privacy-first dating platform for HIV-positive communities. Building a Zero-Knowledge Dating Platform for HIV-Positive Communities if you haven't already.

Imagine a database breach. Your dating app's servers are compromised.

For most users, that's embarrassing. For an HIV-positive person on a conventional dating platform, it can mean losing a job, losing housing, or losing family. The stakes are not hypothetical — they are documented, they are real, and they are why this system was built the way it was.

In Part 1, I explained the overall architecture: everything is encrypted client-side using TweetNaCl before it touches the backend. No names, no photos, no health status, no location, no lifestyle — nothing readable ever reaches the server.

But that creates a problem that isn't immediately obvious:

If the server is completely blind, how does it know who to match you with?

This article explains the first half of the answer: blind bitmask filtering using 32-bit integers.

This is the hard filter layer — gender, marital status, region, and other categorical attributes. The next article covers the soft filter layer — AI embeddings and Hamming distance for deeper compatibility.

Why Not Just Encrypt the Filters Too?

You might think: encrypt the filter values and compare encrypted data server-side. The problem is that standard encryption is non-deterministic by design — the same value encrypted twice produces different ciphertext, so you can't compare encrypted strings without either homomorphic encryption (expensive, complex, slow) or leaking the values.

We needed something the server could compare without understanding.

That's where integers come in.

☕ The Core Idea: Switches, Not Strings

The server cannot store or search strings like "Woman", "Single", "East", or "Espresso lover". But the server can compare integers.

A 32-bit integer is just 32 on/off switches. The frontend assigns meaning to each switch. The backend never sees the dictionary that explains what each switch means.

This is the key insight: meaning lives in the client. The server only handles math.

Every user profile generates two masks:

Identity Mask (i_mask) — "Who I am"
Preference Mask (p_mask) — "Who I want"

The frontend sets bits using:

i_mask |= (1 << bit);
p_mask |= (1 << bit);

Only the resulting integers are sent to the server. The dictionary that maps bits to human meaning never leaves the browser.

🧩 Bitmask Layout

Here's a simplified version of the layout used in this platform:

Bits	Category	Values
0–1	Gender	`bit 0` = Man, `bit 1` = Woman
2–3	Marital Status	`bit 2` = Single, `bit 3` = Divorced
4–7	Region	`bit 4` = North, `bit 5` = South, `bit 6` = East, `bit 7` = West
8–9	Coffee Preference	`bit 8` = Espresso, `bit 9` = Latte
10–31	Reserved	Future attributes

This table exists only in the frontend source code. The backend has no awareness of it. Even if someone reads the Erlang source, they will find no reference to gender, region, or coffee preferences — only integers and bitwise operations.

☕ A Concrete Example

Let's walk through two real users being matched — the way the server experiences it.

User A — who she is:
Woman, Single, East, Espresso → i_mask = 330

User A — who she wants:
Man, Single, East or North, Espresso → p_mask = 431

User B — who he is:
Man, Single, East, Espresso → i_mask = 273

User B — who he wants:
Woman, Single, East, Espresso or Latte → p_mask = 459

The server receives four numbers: 330, 431, 273, 459.

It has no idea that 330 means "Woman from the East who drinks Espresso." It's just a number. What it can do is check whether these two people are mutually compatible — without knowing what compatibility means in human terms.

⚡ The Matching Logic in Erlang

Three lines:

ISeeThem = (MyPMask band OtherIMask) =/= 0,
TheySeeMe = (OtherPMask band MyIMask) =/= 0,
IsMatch = ISeeThem andalso TheySeeMe.

band is bitwise AND. If User A's preference mask overlaps with User B's identity mask, and vice versa — it's a match. Both sides have to see each other.

No strings. No JOINs on plaintext columns. No semantic understanding required. Just a CPU instruction that runs in nanoseconds across thousands of profiles.

🔒 Why This Is Genuinely Zero-Knowledge

The server cannot reverse the integers.

330 does not reveal Woman, Single, East, or Espresso. It's an integer. Without the bit-to-meaning dictionary, it's permanently opaque. Even with the source code of the frontend, an attacker would need to know which bits were set by which user — and the mapping only exists client-side at the moment a profile is built.

A breach leaks nothing meaningful.

If the database is compromised, attackers get encrypted blobs and a list of integers. The integers reveal nothing about health status, preferences, or identity without the dictionary — which lives only in the browser.

It's fast.

Bitwise AND is one of the cheapest operations a CPU can perform. Matching 100,000 profiles takes milliseconds. There's no performance tradeoff for the privacy guarantee.

No false positives.

If (maskA band maskB) =/= 0, the overlap is guaranteed. The math doesn't lie.

🏗️ How It Fits the Architecture

┌──────────────────────────┐
│        Frontend          │
│  (Vue + TweetNaCl)       │
├──────────────────────────┤
│ - Collect profile fields │
│ - Generate i_mask/p_mask │
│ - Encrypt profile vault  │
│ - Send: masks + blob     │
└─────────────┬────────────┘
              │
              ▼
┌──────────────────────────┐
│         Backend          │
│   (Erlang + Mnesia)      │
├──────────────────────────┤
│ - Store encrypted blob   │
│ - Store bitmasks         │
│ - Bitwise AND matching   │
│ - Return matched IDs     │
└──────────────────────────┘

The backend returns matched user IDs. The frontend then fetches and decrypts those profiles locally. At no point does the server assemble a readable picture of anyone.

⚠️ What This Doesn't Protect Against

Honesty matters here — especially for a community where trust is everything.

Match count leakage. The server knows how many profiles match a given user, even if it doesn't know why. A user with very specific filters (only one bit set) might have a match count that's statistically revealing. This is a known limitation.

Timing analysis. A sophisticated attacker watching query patterns over time could infer rough filter characteristics from response times. This is mitigated by query normalisation, but not eliminated.

The dictionary is in the source code. The frontend is public. Anyone can read the bit-to-meaning mapping. The protection isn't that the dictionary is secret — it's that the server never has it, so a server-side breach reveals nothing. Client-side attacks (malware, compromised devices) are a separate threat model.

This layer only handles hard filters. It can't assess compatibility, shared values, or personality. That's what the embedding layer is for.

No system is perfectly zero-knowledge. The goal is to make the cost of a breach as close to zero as possible, for the people who have the most to lose.

🌑 Why This Matters

For HIV-positive users, every piece of data that touches a server is a potential liability. This bitmask system lets the platform filter by relationship style, region, lifestyle, and preferences — without the server ever learning what those preferences are.

It's not a perfect solution. But it moves the trust boundary from "trust us not to misuse your data" to "we architecturally cannot access your data." For people who have been let down by institutions before, that difference is everything.

The platform is live at HIVPositiveMatches.com — built on everything this series covers.

▶️ Coming Next: Zero-Knowledge AI Matching

The bitmask layer handles hard categorical filters. But compatibility is more than checkbox matching.

In Part 3, I'll cover:

How the browser generates semantic embeddings locally
How they're binarized into compact binary vectors
How the server computes similarity using Hamming distance
Why this reveals nothing about the underlying text

The bitmask layer finds possible matches. The embedding layer finds meaningful ones — without the server understanding either.

Day 18 — Building a Linux Vulnerability Analyzer 🐧🔍

Hafiz Shamnad — Fri, 06 Mar 2026 05:35:21 +0000

In most cybersecurity learning paths, people focus on tools first. But sometimes the better exercise is building your own. Today I spent time creating a Linux vulnerability analyzer, a command line tool designed to audit a system and surface common security weaknesses.

The idea is simple: treat the Linux machine like a fortress and walk through it gate by gate. Which services are listening? Which configurations are unsafe? Which permissions look suspicious? A small script can turn those questions into a structured security check.

This tool performs a set of system audits that are commonly part of basic security assessments. It collects system information, inspects open ports, reviews SSH configuration, checks firewall status, enumerates user accounts, and looks for risky file permissions such as world writable files or SUID binaries. It also inspects running services and identifies available package updates that might contain security patches.

What made this project interesting was designing it as a modular scanner. Each security check is treated as its own module, so scans can run individually or as part of a full system audit. This makes it easier to extend later with additional checks such as CVE lookups, Docker scanning, or kernel vulnerability analysis.

Another focus was usability. Security tools are most useful when their output is readable, so the scanner produces a structured CLI report with clear sections and warning indicators. Instead of raw command outputs, the results are organized into human readable summaries that highlight potential issues quickly.

At the end of the scan, the tool generates a concise security overview and can optionally export the findings as a JSON report for further analysis or automation workflows.

Projects like this help reinforce how many security insights come directly from the operating system itself. Linux already exposes a lot of valuable signals through logs, configuration files, and system commands. The challenge is collecting and presenting them in a meaningful way.

Building small security utilities like this is a great way to understand how real auditing tools work under the hood.

Day by day, the goal is simple: learn by building.

Detailed Code Explanation

vulnscan is a Python-based command-line security auditing tool designed to analyze Linux desktops and servers for common security issues.

It performs several checks including:

System information collection
Open port discovery
SSH configuration audit
Firewall status verification
User account analysis
World-writable file detection
SUID binary detection
Failed login detection
Running service enumeration
Package update checks

The results are displayed in a structured CLI interface and can also be exported as JSON reports.

1. Shebang and Script Header

#!/usr/bin/env python3

This line tells Linux to run the script using Python 3 from the system environment.

The header comment explains the tool:

vulnscan - Linux Vulnerability Analyzer
A comprehensive security auditing tool with rich CLI output

This indicates the tool is designed to produce clean terminal output using the Rich library.

2. Importing Required Modules

import subprocess
import argparse
import sys
import os
import json
import datetime
from pathlib import Path

Each module serves a purpose:

Module	Purpose
subprocess	Run Linux shell commands
argparse	Handle CLI arguments
os	File permission checks
json	Export scan results
datetime	Timestamp scans
pathlib	File path handling

The scanner relies heavily on Linux commands executed via subprocess.

3. Rich CLI Output Support

The tool attempts to import the Rich library.

from rich.console import Console
from rich.table import Table
from rich.panel import Panel

Rich allows:

colored output
tables
progress spinners
formatted panels

If Rich is not installed, the tool falls back to plain text mode.

Example fallback logic:

except ImportError:
    RICH = False

A simple console class replaces Rich output.

This ensures the tool works even on minimal systems.

4. Command Execution Helper

def run(cmd: str) -> str:

This function runs shell commands safely.

Example:

subprocess.run(cmd, shell=True, capture_output=True)

Features:

Captures stdout
Prevents crashes
Timeout protection
Always returns output

Example usage:

run("uname -r")

Output:

6.5.0-21-generic

5. Status Tag Generator

def _tag(ok: bool) -> str:

Creates status labels for results.

Examples:

✔ OK
✗ WARN

Used when displaying scan results.

6. Section Header Printer

def _section(title: str)

Creates visual separation between scan sections.

Example output:

────────────────── SSH Security Audit ──────────────────

7. System Information Scan

def system_info()

Collects basic system information.

Commands used:

Command	Purpose
grep PRETTY_NAME /etc/os-release	OS name
uname -r	kernel version
uname -m	architecture
hostname	system hostname
uptime -p	system uptime
free -h	RAM
df -h	disk usage
who	logged in users

Example output:

OS: Ubuntu 22.04
Kernel: 6.2
RAM: 8GB
Disk: 40% used

This helps identify outdated or unsupported systems.

8. Open Port Detection

def open_ports()

Uses:

ss -tuln

This lists:

TCP ports
UDP ports
listening services

Example output:

tcp LISTEN 0.0.0.0:22
tcp LISTEN 0.0.0.0:80

Open ports can expose services to attackers.

9. SSH Security Audit

def ssh_audit()

Analyzes /etc/ssh/sshd_config.

Checks include:

Setting	Risk
PermitRootLogin	attackers login as root
PasswordAuthentication	brute force risk
PermitEmptyPasswords	empty password accounts
Protocol	insecure SSH v1
MaxAuthTries	brute force attempts
LoginGraceTime	session hijacking window

Example result:

PermitRootLogin = yes   WARN
PasswordAuthentication = yes   WARN
Protocol = 2   OK

This helps detect weak SSH configurations.

10. Firewall Status Check

def firewall_check()

Checks three firewall systems:

UFW

ufw status

iptables

iptables -L INPUT

firewalld

systemctl is-active firewalld

Example result:

UFW: inactive
iptables rules: 3
firewalld: inactive

A disabled firewall is a major security risk.

11. User Account Audit

def user_audit()

Reads:

/etc/passwd

Extracts:

username
UID
home directory
shell

Important checks:

interactive shells
sudo users
root accounts

Example:

user1 uid=1000 shell=/bin/bash
root uid=0 sudo

Privilege escalation often targets misconfigured user accounts.

12. World Writable File Scan

def world_writable()

Runs:

find / -perm -0002

This identifies files any user can modify.

Example:

/tmp/testfile

These files can be abused for privilege escalation.

13. SUID Binary Detection

def suid_files()

Command:

find / -perm -4000

SUID files execute with root privileges.

Example:

/usr/bin/passwd
/usr/bin/sudo

Attackers often exploit vulnerable SUID binaries.

14. Failed Login Detection

def failed_logins()

Checks:

lastb

If unavailable:

journalctl sshd

This identifies brute force attempts.

Example:

Failed password for root from 192.168.1.10

15. Running Services

def running_services()

Uses:

systemctl list-units --type=service

Example output:

ssh.service
nginx.service
mysql.service

Attack surface increases with more running services.

16. Package Update Check

def package_updates()

Detects package manager automatically:

Manager	Command
APT	apt list --upgradable
DNF/YUM	dnf check-update

Example result:

Upgradable packages: 12
Security updates: 3

Outdated packages often contain known CVEs.

17. Display Functions

Several display functions format scan results.

Examples:

display_ports()
display_users()
display_services()

When Rich is enabled, results appear as tables.

Example:

Proto   State     Address
tcp     LISTEN    0.0.0.0:22

18. Scan Summary

def display_summary()

Counts warnings such as:

insecure SSH settings
world writable files

Example:

Scan completed: 2026-03-06 10:20
Warnings found: 4

19. JSON Export

def export_json()

Allows exporting scan results:

vulnscan --export report.json

Example output file:

{
 "ssh": {...},
 "ports": {...}
}

Useful for:

automation
SIEM ingestion
reporting

20. CLI Argument Parsing

Handled using argparse.

Example commands:

Run full scan

vulnscan

Run specific modules

vulnscan -m ssh firewall ports

Export report

vulnscan --export report.json

List modules

vulnscan --list

Quiet mode

vulnscan -q

21. Module System

Modules are defined in a dictionary:

MODULES = {
    "system": system_info,
    "ports": open_ports
}

This makes the scanner modular and extensible.

Adding new checks becomes easy.

22. Main Function

The main function orchestrates everything:

Parse CLI arguments
Select modules
Run scans
Display results
Export report

Flow:

Parse arguments
↓
Run selected modules
↓
Display results
↓
Export report (optional)

Final Outcome

vulnscan provides a quick security overview of a Linux system.

Capabilities include:

System auditing
SSH security analysis
Firewall detection
Port discovery
Permission checks
User privilege analysis
Service enumeration
Package update checks

Possible Future Improvements

To make the tool even more powerful:

CVE lookup via NVD API
Docker container scanning
Cron job auditing
Kernel vulnerability detection
Risk scoring engine
HTML security reports
CIS benchmark checks

Summary

Tools that analyze Linux security often look similar on the surface, but they are built for very different moments in a security workflow.

My Linux vulnerability analyzer focuses on security auditing and system hygiene. It checks things like SSH configuration, firewall status, open ports, user privileges, file permissions, and available package updates. The goal is to give administrators or learners a clear overview of how securely a system is configured and highlight areas that need improvement.

In contrast, LinPEAS is designed for a completely different scenario. It is used after an attacker or penetration tester already has access to a machine and wants to discover privilege escalation paths. Instead of auditing configuration health, it searches aggressively for ways to gain higher privileges such as sudo misconfigurations, writable services, exposed credentials, or kernel exploits.

So while both tools analyze a Linux system, their goals differ:

A vulnerability analyzer helps defenders audit and harden systems.
LinPEAS helps attackers or penetration testers find ways to escalate privileges.

Understanding this distinction is important because security is not just about breaking systems, but also about building and maintaining them securely.

I compiled 459 landlord-tenant statutes into a database and built free tools on top of it

Kyle — Fri, 06 Mar 2026 05:13:04 +0000

I'm a solo founder building a property management platform. Along the way I needed to solve a compliance problem: every state has different rules for security deposits, evictions, late fees, rent increases, entry notice, habitability, and fair housing. A lease that's legal in Texas can violate laws in New York.

So I compiled the actual statutes. 459 records covering all 50 states and Washington DC. Every record includes the rule summary and the statute citation so you can verify it yourself.

Once I had the data, I realized it was useful beyond just my product. So I built 4 free tools on top of it.

The tools

Landlord-Friendly State Scorecard - grades every state A through F across 5 categories: deposit rules, eviction speed, rent control, late fees, and entry requirements. You can look up a single state or see the full ranking.

rentsolve.ai/tools/landlord-friendly-scorecard

Security Deposit Calculator - pick a state, enter the rent amount, and it shows you the max deposit allowed, return deadline, interest requirements, and penalty for late return.

rentsolve.ai/tools/security-deposit-calculator

ROI Calculator - plug in purchase price, down payment, rent, vacancy, and expenses. Get cash on cash return, cap rate, and a full monthly breakdown.

rentsolve.ai/tools/roi-calculator

Law Lookup - pick a state and a topic and get the rule summary with the actual statute citation.

rentsolve.ai/tools/law-lookup

How it's built

All four tools are static HTML/CSS/JS. No framework, no build step, no backend calls. The data is embedded directly in the page as a JS object. Deployed on Cloudflare Pages.

I went this route because I wanted the tools to load instantly and work without authentication. No API rate limits to worry about, no server costs, and Cloudflare handles caching and CDN automatically.

The data itself was compiled by reviewing state revised statutes, annotated codes, and landlord-tenant acts. Each record includes the state, the topic category, a plain-language summary, and the statute citation.

Some interesting things in the data

24 states have zero cap on how much a landlord can charge for a security deposit
Georgia and West Virginia let landlords file for eviction immediately with no mandatory notice period
Only 3 jurisdictions have statewide rent control: California, Oregon, and DC
Massachusetts won't let you charge a late fee until rent is 30 days past due
14 states have no specific statute on how much notice a landlord must give before entering
DC protects over 21 classes under fair housing law including personal appearance and political affiliation

What the data powers

The database is the backbone of RentSolve AI, the property management platform I'm building. When a landlord drafts a lease through the app, the AI pulls the correct deposit limits, required disclosures, late fee rules, and notice periods for their specific state. The tools are free standalone versions of that same data.

I also published the data as a series of 50-state comparison articles on the blog covering each category with sortable tables and FAQ schema.

What's next

I'm working on adding more categories to the database: required landlord disclosures by state, pet deposit rules, and lease renewal requirements. If you have questions about any specific state's rules, happy to look it up.

I Built a Physics Certification Layer for Motion Data — Here's What I Found

timbo4u — Fri, 06 Mar 2026 05:09:47 +0000

TL;DR: I trained a classifier on robot motion data and kept getting weird failures. The data looked fine. It wasn't fine. So I wrote a tool that checks whether sensor data actually obeys the laws of physics before you train on it. Here's what I learned.

The Problem Nobody Talks About
When you train a model on images or text, bad data is annoying but recoverable — you clean it, re-label it, filter it. The model is usually forgiving.
When you train a physical AI system — a prosthetic hand, a robot arm, a rehabilitation exoskeleton — bad training data doesn't just hurt accuracy. It teaches the system physically impossible movement patterns. A prosthetic hand trained on corrupted EMG data fails the person wearing it. A humanoid robot trained on synthetic motion data that violates rigid-body kinematics learns to move like a cartoon.
The problem is that most motion datasets have no quality floor. They contain:

Synthetic data generated without real sensors (no actual physics coupling)
Corrupted recordings with dropped samples and sensor drift
Mislabeled actions where the label doesn't match the measured physics

And there's no standard way to detect any of this.
I decided to build one.

The Idea: Check the Physics, Not the Labels
Instead of asking "does this data look human?" (subjective, learnable by fakes), I asked: does this data obey the physical laws that govern human movement?
A real human arm moving through space has to satisfy:

Rigid body kinematics — accelerometer and gyroscope on the same limb must couple: a = α×r + ω²×r. Two sensors on the same rigid body cannot disagree.
Jerk bounds — human motion minimizes jerk (third derivative of position). Flash & Hogan proved this in 1985. Superhuman jerk = sensor spike or synthetic artifact.
EMG-acceleration timing — muscle electrical activation precedes limb acceleration by ~75ms. If acceleration comes first, something is wrong.
Resonance frequency — human forearm tremor is 8–12Hz. Always. Vibrations at 40Hz = mechanical noise.
BCG heartbeat — a wrist IMU on a resting human shows the mechanical heartbeat signature at 1–3Hz. No signal = not a human.

These aren't heuristics. They're physics. You can't fake them without running a full skeletal simulation.

What I Built: S2S
Pure Python, zero external dependencies, runs anywhere including embedded systems.
pythonfrom s2s_standard_v1_3.s2s_physics_v1_3 import PhysicsEngine

result = PhysicsEngine().certify(
imu_raw={
"timestamps_ns": [...],
"accel": [...], # [[ax, ay, az], ...] m/s²
"gyro": [...], # [[gx, gy, gz], ...] rad/s
},
segment="forearm"
)

print(result['tier']) # GOLD / SILVER / BRONZE / REJECTED
print(result['physical_law_score']) # 0–100
print(result['laws_passed']) # ['rigid_body_kinematics', 'jerk_bounds', ...]
Each passing record gets an Ed25519 cryptographic signature — tamper-evident provenance. This matters in medical and safety-critical contexts where data chain-of-custody is audited.
bashpip install s2s-certify

The Result That Surprised Me
Real iPhone 11 IMU data (37 seconds of natural hand movement) versus synthetic data generated to look similar:
MetricReal HumanSyntheticRigid body coupling r0.35-0.01Jerk P95 (m/s³)25.854.0Resonance (Hz)5.413.3Physics score69/10053/100Certification tierSILVERBRONZE
r=0.35 (real) vs r=-0.01 (synthetic) — physics alone, no labels, no training required.
Applied to 10,360 windows from UCI HAR + PAMAP2: 9,050 certified (87.4%), 1,310 rejected for physics violations. Those 1,310 windows aren't low quality — they're physically impossible.

Level 4: Where It Gets Interesting
The single-sensor laws are powerful, but the most interesting result came from kinematic chain consistency across multiple sensors.
PAMAP2 has 3 IMUs — hand, chest, ankle. These sensors don't just need to look right individually. They have to be consistent with each other at the physics level:

Ankle leads chest in jerk timing by 50–100ms (force propagates up the skeleton)
Dominant locomotion frequency must agree across all three sensors
Coupling between segments must respect joint constraints

A synthetic generator can fool single-sensor checks by learning the right statistics. It cannot fake cross-sensor timing without running a complete rigid-body skeletal simulation.
Results on PAMAP2 (12 activity classes):
MethodF1 ScoreSingle chest IMU baseline0.7969Multi-sensor naive concat0.8308 (+3.39%)S2S kinematic chain filter0.8399 (+0.91% over concat)Net vs single sensor+4.23%
+4.23% F1 improvement, using 46% less data with curriculum training.

Using the Physics Score as a Training Loss
You don't have to use S2S as a hard filter. Use the score as a soft loss term:
python# s2s_torch.py — physics-aware training loss
import torch
from s2s_standard_v1_3.s2s_physics_v1_3 import PhysicsEngine

class S2SPhysicsLoss(torch.nn.Module):
def init(self, task_loss_fn, lambda_physics=0.1):
super().init()
self.task_loss = task_loss_fn
self.lambda_physics = lambda_physics
self.engine = PhysicsEngine()

def forward(self, predictions, targets, imu_batch):
    task_l = self.task_loss(predictions, targets)
    scores = []
    for sample in imu_batch:
        result = self.engine.certify(sample)
        scores.append(result['physical_law_score'] / 100.0)
    physics_scores = torch.tensor(scores, dtype=torch.float32)
    physics_penalty = (1.0 - physics_scores).mean()
    return task_l + self.lambda_physics * physics_penalty

The formula: L = L_task + λ × (1 - physics_score/100)
Models trained with this loss learn to prefer physically plausible outputs, not just statistically likely ones.

Motion Domain Taxonomy
Not all motion has the same physics envelope. A surgeon's hand and a sprinter's leg are both valid human motion, but with completely different jerk budgets.
DomainJerk ≤Coupling r ≥Robot use casePRECISION80 m/s³0.30Surgical robots, prosthetic handsPOWER200 m/s³0.30Warehouse arms, exoskeletonsSOCIAL180 m/s³0.15Service robots, HRILOCOMOTION300 m/s³0.15Bipedal robots, prosthetic legsDAILY_LIVING150 m/s³0.20Home robots, elder careSPORT500 m/s³0.10Athletic training
The domain classifier automatically assigns one of these to incoming data, then tunes physics thresholds accordingly. You don't want to reject a sprinter for having "too much jerk."

Live Demos
No install needed:

📱 Phone IMU demo — open on your phone, move it, watch real-time physics certification
🎥 Pose camera demo — MoveNet tracks 17 body joints and certifies your movement live

What's Next
The most useful thing right now: if you work with motion data for any application — robotics, prosthetics, sports science, rehab — try running your dataset through S2S and tell me what the rejection rate is. Every new dataset that gets certified (or fails interestingly) teaches something about what's actually in these benchmarks.

timbo4u1 / S2S

S2S — Physics-Certified Sensor Data

Physics-certified motion data for prosthetics, robotics, and Physical AI.

S2S is a physics validation layer for human motion sensor data. Before training a prosthetic hand, surgical robot, or humanoid — run your IMU data through S2S. It verifies the data obeys 11 biomechanical laws and issues a certificate. Bad data gets rejected before it reaches your model.

Live Demos

→ IMU Demo — open on your phone · Real-time certification using phone accelerometer + gyroscope

→ Pose Demo — camera + skeleton · 17-joint body tracking with live physics certification

No install needed. All processing runs on your device. No data sent anywhere.

The Problem

Physical AI (robots, prosthetics, exoskeletons) is trained on motion data. But most datasets contain synthetic data that violates physics, corrupted recordings, and mislabeled actions — with no way to verify the data came from a real human moving in physically…

View on GitHub

BSL-1.1 license — free for research/education, converts to Apache 2.0 on 2028-01-01.
PyPI: pip install s2s-certify · DOI: 10.5281/zenodo.18878307 · Preprint: hal-05531246

Honest question for devs: have you ever been beaten by AI on something you thought was your strength?

Sukriti Singh — Fri, 06 Mar 2026 05:09:19 +0000

I just published a piece about competing against LLMs on VibeCode Arena
same prompt, same scoring criteria, no framing advantage.

The AI scored higher than me on accessibility. First pass.
I've been writing accessible UI for years.

Made me realise I was coasting on an assumption rather than actually
verifying where I stand.

Curious for anyone who's done a real side-by-side comparison:
→ What's one area where AI surprised you?
→ One area where you held up better than expected?

I Watched GPT and Claude Fight Over the Same Code. Here's What I Learned.

Sukriti Singh ・ Mar 6

#ai #career #webdev #programming

TreeSet in Java

Nanthini Ammu — Fri, 06 Mar 2026 04:58:53 +0000

What is TreeSet?

Stores unique elements.
Maintains elements in sorted order (ascending by default).
Does not allow duplicates.
It is part of the Java Collections Framework in Java and implements the Set interface.

Example :

import java.util.TreeSet;

public class Learn {
    public static void main(String[] args) {

        TreeSet tr = new TreeSet();
        tr.add(1000);
        tr.add(300);
        tr.add(500);
        tr.add(10);
        System.out.println(tr);

    }
}

//Even though we inserted 1000 first, TreeSet keeps them sorted.

Output: [10, 300, 500, 1000]

Duplicate Example :

import java.util.TreeSet;

public class Learn {
    public static void main(String[] args) {

        TreeSet tr = new TreeSet();
        tr.add(1000);
        tr.add(1000);
        tr.add(500);
        tr.add(500);
        System.out.println(tr);

    }
}

//Duplicate values are ignored.

Output : [500, 1000]

Null Example :

import java.util.TreeSet;

public class Learn {
    public static void main(String[] args) {

        TreeSet tr = new TreeSet();
        tr.add(null);
        System.out.println(tr);

    }
}

//TreeSet does not allow null.

Output : NullPointerException

Important TreeSet Methods:

add():

To add element/Object.

tr.add(500);

remove():

To remove element/Object.

tr.remove(500);

contains():

To check if element/Object exist.

tr.contains(500);

size():

To find the number of elements/objects.

tr.size();

first():

To find the smallest element/object.

tr.first();

last():

To find the largets element/object.

tr.last();

higher():

To find the next greater element/object.

tr.higher(50);

lower():

To find the previous element/object.

tr.lower(200);

public class Learn {
    public static void main(String[] args) {

        TreeSet tr = new TreeSet();
        tr.add(500);
        tr.add(200);
        tr.add(1000);
        tr.add(50);
        tr.add(10);
        System.out.println(tr);
        tr.remove(500);
        System.out.println(tr);
        System.out.println(tr.size());
        System.out.println(tr.first());
        System.out.println(tr.last());
        System.out.println(tr.higher(50));
        System.out.println(tr.lower(200));



    }
}

Output: 

[10, 50, 200, 500, 1000] //add
[10, 50, 200, 1000]      //remove element 500
4                        //size
10                       //first element
1000                     //last element
200                      //next higher to element 50
50                       //next lower to element 200

Architecting for Vulnerability: Introducing Protective Computing Core v1.0

CrisisCore-Systems — Fri, 06 Mar 2026 04:55:40 +0000

Most software is built on a dangerous premise: the Stability Assumption.

We assume the user has a stable network, stable cognitive capacity, a secure physical environment, and institutional trust. When those conditions hold, modern cloud native architecture works beautifully.

But when people enter a vulnerability state, the Stability Assumption collapses. Cloud dependent apps lock people out of their own data. Helpful auto sync features broadcast metadata from compromised networks. Irreversible actions happen when someone does not have the attention or time to read a modal carefully.

Here is the part we do not say out loud enough. In a crisis, software does not just fail. It can become coercive. You get logged out, you cannot recover the account, your data is suddenly somewhere else, and the only path forward is to comply with whatever the system demands.

We need a systems engineering discipline for designing software under conditions of human vulnerability.

Today, I am open sourcing Protective Computing Core v1.0.

Boundary notes, because truth matters

This is not medical advice.
This is not a regulatory compliance claim.
This is not a claim of perfect security.

What is Protective Computing?

Protective Computing is not a privacy manifesto. It is a strict, testable engineering discipline.

It provides a formal vocabulary and a pattern library for building systems that:

degrade safely
contain failures locally
defend user agency under asymmetric power conditions

The v1.0 Core introduces a normative specification (MUST, SHOULD, MUST NOT), plus a conformance model you can actually review.

Read the spec here:

https://protective-computing.github.io/docs/spec/v1.0.html

The core pillars

Protective Computing Core is built around four pillars. Each one exists because a specific failure pattern keeps hurting people.

1) Local Authority Pattern

The system MUST preserve user authority over locally stored critical data in the absence of network connectivity. Network transport is treated as an optional enhancement, not a dependency for essential utility.

What this prevents: the classic offline lie where the app looks usable, but the moment the network drops the user loses access to their own records.

2) Exposure Surface Minimization

The system MUST NOT increase its exposure surface during crisis state escalation. Analytics, third party telemetry, and remote logging are default off and hard gated.

What this prevents: silent data exhaust during the exact window when a user is least able to notice, consent, or defend themselves.

3) Reversible State Pattern

The system MUST NOT introduce irreversible state transitions during declared vulnerability states unless explicitly confirmed. High impact destructive actions require bounded restoration windows where security invariants allow.

What this prevents: permanent harm caused by a single misclick, mistype, or foggy moment.

4) Explicit Degradation Modes

The system cannot just go offline. It MUST define explicit degradation modes (Connectivity Degradation, Cognitive Degradation, Institutional Latency) and map how essential utility is preserved in each state.

What this prevents: ambiguous failure where nobody knows what is safe, what is unavailable, and what the system is doing behind the scenes.

The reference implementation: PainTracker

To prove these patterns are implementable in standard web technologies, I built a reference implementation:

https://paintracker.ca

PainTracker is an offline first PWA designed for users tracking chronic health data, a highly sensitive payload often logged during high cognitive or physical distress.

Instead of a traditional SaaS architecture, PainTracker implements Protective Computing through:

Encrypted IndexedDB persistence (primary database lives on device)
Zero knowledge vault gating (local security boundary, no remote auth dependency)
Unlock only bounded reversibility (pending wipe window that only a successful unlock can abort)
Hard telemetry gating (verifiable kill switch for outbound requests not explicitly initiated by the user)

Repo:

https://github.com/CrisisCore-Systems/pain-tracker

Example: bounded reversibility without weakening security

Standard security dictates that after N failed unlock attempts, a local vault should wipe.

But under cognitive overload, people mistype passwords. An immediate wipe causes irreversible loss. A generic cancel button weakens brute force resistance.

Protective Computing requires a bounded restoration window that does not weaken the security invariant.

Here is the shape of the solution:

// Bounded reversibility under asymmetric power defense
async function handleFailedUnlock() {
  failedAttempts++;

  if (failedAttempts >= MAX_FAILED_UNLOCK_ATTEMPTS && privacySettings.vaultKillSwitchEnabled) {
    // 1) Enter a bounded degradation state
    // 2) Disclose the pending irreversible action
    // 3) Only a successful cryptographic unlock can abort the timer

    await enterPendingWipeState({
      windowMs: 10_000,
      reason: "failed_unlock_threshold",
      onExpire: () => executeEmergencyWipe()
    });

    UI.showWarning("Vault will wipe in 10s. Enter correct passphrase to abort.");
  }
}

Notice the constraint. There is no cancelWipe() function exposed to the UI. The only path to reversibility is proving local authority.

stateDiagram-v2
  [*] --> Normal
  Normal --> PendingWipe: N failed unlocks & kill switch enabled
  PendingWipe --> Normal: successful unlock within window
  PendingWipe --> Wiped: window expired
  Wiped --> [*]
  note right of PendingWipe: user sees warning UI
  note right of Normal: regular operation
  note right of Wiped: data erased

Measuring posture: the Protective Legitimacy Score (PLS)

In this space, marketing claims like military grade encryption or secure by design are useless. Engineers and regulators need auditable transparency.

Alongside the Core spec, I am publishing a measurement instrument called the Protective Legitimacy Score (PLS). PLS is not a certification. It is a structured disclosure format that forces maintainers to state:

what vulnerability conditions they assume
what compliance level they claim
what they do not claim
where they deviate, and why

PLS rubric (PDF):
https://protective-computing.github.io/PLS_RUBRIC_v1_0_rc1.pdf

Audit evidence index:
https://github.com/protective-computing/protective-computing.github.io/blob/main/AUDIT_EVIDENCE.md

Compliance audit matrix:
https://github.com/protective-computing/protective-computing.github.io/blob/main/COMPLIANCE_AUDIT_MATRIX.md

The goal is simple: replace vibes with checkable posture.

The call for Reference Implementation B

PainTracker proves the discipline works for localized health telemetry. But Protective Computing is domain agnostic.

These patterns are exactly what is needed for:

disaster response cache applications
coercion resistant messaging interfaces
offline first journalistic tooling
legal aid and housing workflows under institutional delay

If you want to contribute, here is the most useful path:

Read the spec v1.0: https://protective-computing.github.io/docs/spec/v1.0.html
Pick one requirement you think is wrong, too vague, or unbuildable.
Submit a review with a concrete counterexample and a better verification procedure.

Review invitation:
https://protective-computing.github.io/docs/independent-review.html

Independent review checklist:
https://github.com/protective-computing/protective-computing.github.io/blob/main/INDEPENDENT_REVIEW_CHECKLIST.md

I do not need agreement. I need pressure testing.

Canonical archive (Zenodo)

If you want the citable artifacts and stable versions, Protective Computing is archived as a Zenodo community. This is the cleanest place to reference exact releases without link rot.

Community:
https://zenodo.org/communities/protective-computing/records

Core canon (Overton Framework v1.3):
https://doi.org/10.5281/zenodo.18688516

Field Guide v0.1:
https://doi.org/10.5281/zenodo.18782339

PLS rubric DOI:
https://doi.org/10.5281/zenodo.18783432

Start here, and support the work if it helped

Fastest route through the catalog (series index):
https://dev.to/crisiscoresystems/start-here-paintracker-crisiscore-build-log-privacy-first-offline-first-no-surveillance-3h0k

Sponsor the build (keeps it independent of surveillance funding):
https://paintracker.ca/sponsor

Star the repo:
https://github.com/CrisisCore-Systems/pain-tracker

If we change the architectural defaults, we can stop building software that breaks exactly when people need it most.