DEV Community: ricco020

What is an API? A clear, practical explainer

ricco020 — Wed, 24 Jun 2026 12:25:36 +0000

An API (Application Programming Interface) is a contract that lets one piece of software ask another for data or actions, without knowing how it works inside. What an API is, how a request and response work, the common styles like REST and GraphQL, and why developers build on them.

An API — short for Application Programming Interface — is a set of rules that lets one program talk to another. It defines how you ask for data or an action, what you have to send, and what you get back, so two pieces of software can work together without either one knowing how the other is built inside. It is the contract between them.

A common analogy is a restaurant menu. The menu lists what you can order and what each dish costs, you place an order, and the kitchen prepares it — but you never need to see the kitchen or know how the cooking is done. An API is that menu for software: it tells you what you can request and how, and hides everything behind it.

More precisely, an API exposes a set of operations a service is willing to perform. A weather service might offer an operation that returns the forecast for a city; a payment service might offer one that charges a card. You call the operation with the inputs it expects, and the service does the work and hands back a result. The internals stay private and can change freely, as long as the contract holds.

On the web, most APIs work over the same protocol as web pages: HTTP. Your program sends a request to a URL called an endpoint, usually with a method that signals intent — GET to read data, POST to create it, PUT or PATCH to update, DELETE to remove. The request can carry parameters and a body; the server processes it and sends back a response.

That response has two important parts: a status code and a payload. The status code is a short number that says how it went — 200 means success, 404 means the thing was not found, 500 means the server hit an error. The payload is the data itself, today almost always formatted as JSON, a lightweight text format that is easy for programs to read and write.

APIs come in a few common styles. REST is the most widespread: it organises everything around resources addressed by URLs and leans on the standard HTTP methods. GraphQL takes a different approach, letting the client ask for exactly the fields it needs in a single query, which avoids over-fetching. Older systems may use SOAP, and real-time apps often add WebSockets for a continuous two-way connection.

Many APIs are protected, because they expose real data and actions. Authentication proves who is calling — often with an API key or a token such as OAuth — and rate limiting caps how many requests a caller can make in a window, so one client cannot overwhelm the service. Public APIs publish documentation describing every endpoint, its inputs, and its responses.

Developers rely on APIs because they let you build on top of existing services instead of reinventing them. You can add maps, payments, email, login, or AI to an app by calling someone else’s API. They also let large systems split into smaller services that talk to each other, and they are how a mobile app or single-page front end fetches data from a backend.

Finally, an API has to run somewhere. The service behind it — the backend that receives requests and returns responses — needs a reliable, always-on server. For your own APIs, that means a host you control: a VPS or cloud server where the backend stays up and reachable. A solid host is the foundation the whole interface sits on.

Self-hosting needs a reliable home with full runtime and network control. Infomaniak — a Swiss, privacy-respecting provider — offers VPS and cloud servers to host your CMS or app.

Originally published on versiondude.net.

What Is a Higher-Order Function? Functions as Values, Explained (2026)

ricco020 — Wed, 24 Jun 2026 08:37:13 +0000

In most languages a function is something you call. In functional programming a function is also a value — you can store it in a variable, pass it into another function, and get one back as a result. A higher-order function is exactly the function that does one of those last two things. This guide explains what a higher-order function is, why map, filter and fold are the classic examples, how they replace loops, and how they look in Haskell.

The short definition

A higher-order function is a function that takes one or more functions as arguments, returns a function as its result, or both. A function that does neither — it only takes and returns plain values like numbers or strings — is called a first-order function. The "higher-order" name simply means it operates on functions the way an ordinary function operates on data.

This only works in a language where functions are first-class values: things you can name, pass around and return, just like an integer. Haskell, JavaScript, Python, Swift and many others treat functions this way, which is what makes higher-order functions possible.

The three classics: map, filter and fold

Almost every functional codebase leans on three higher-order functions. Each one takes a function as an argument and applies it across a collection:

- **map** applies a function to every element of a list and gives back a new list of the results. `map (+1) [1,2,3]` gives `[2,3,4]` — the function `(+1)` is the argument.

- **filter** keeps only the elements for which a function returns true. `filter even [1,2,3,4]` gives `[2,4]` — here `even` is the function you pass in.

- **fold** (also called reduce) collapses a list down to a single value by combining elements two at a time. `foldr (+) 0 [1,2,3]` adds them up to `6` — the combining step `(+)` is the function argument.

In each case you supply the small piece of logic — increment, "is even", add — and the higher-order function handles the walking-over-the-list part. You describe what to do to each element, not the bookkeeping of how to step through them.

How they replace loops

In an imperative language you might write a loop with a counter, an accumulator, and an explicit index. The same intent expressed with a higher-order function disappears into a single line, because the iteration is already baked into map or fold. That is why purely functional code, which avoids mutable loop counters, leans so heavily on these functions and on recursion — the two cover the work that loops do elsewhere. List comprehensions are often a readable shorthand for the same map-and-filter combination.

Returning a function: where it gets powerful

The other half of the definition — functions that return functions — is just as common. A function can build and hand back a new, specialised function. A classic example is a "multiplier maker": you give it a number and it returns a function that multiplies its input by that number. Call it with 3 and you get back a "times three" function you can then use like any other. The maker is higher-order because its result is itself a function.

In Haskell this is woven into the language through currying: every function of several arguments is really a chain of one-argument functions, each returning the next. That is why map (+1) works — (+1) is the addition function with one argument already supplied, returning a function that still expects the other. Partial application like this is higher-order functions at work, often without you noticing.

Higher-order functions in Haskell

Haskell makes the idea explicit in its type signatures. The type of map is written map :: (a -> b) -> [a] -> [b]. Read it left to right: the first argument (a -> b) is itself a function — that is the higher-order part — followed by a list of a, producing a list of b. The arrows make it visible on the page that a function is being passed in. The same pattern appears in filter :: (a -> Bool) -> [a] -> [a] and across the standard library.

You often pass these functions inline as lambdas — small anonymous functions written with a backslash, like map (\x -> x * x) [1,2,3] to square each element. Whether you pass a named function, an operator section like (*2), or a lambda, it is the same mechanism: a function travelling as a value into a higher-order function.

Why they matter

Higher-order functions let you factor out the common shape of a computation — "do something to every element", "keep the ones that match", "combine them all" — and reuse it with different logic plugged in. That means less repeated boilerplate, code that reads closer to its intent, and small, testable pieces of logic you can compose. They are the building block on top of which much of functional programming is expressed, and combined with Haskell's lazy evaluation they even let you map and filter over lists that are conceptually infinite.

The honest trade-offs

Higher-order functions take some getting used to: reading foldr or a chain of map . filter is a skill, and deeply nested lambdas can become hard to follow. Passing functions around can also make a stack trace less obvious when something goes wrong. The payoff — far less repetitive iteration code and logic you can recombine — is why they have spread well beyond functional languages into everyday JavaScript, Python and Swift. Used with restraint, they make code shorter and clearer; overused, they can obscure it like any other tool.

Frequently asked questions

What is a higher-order function in simple terms?
A higher-order function is a function that takes another function as an argument, returns a function as its result, or both. Instead of working only on plain data like numbers and strings, it works on functions. Classic examples are map, filter and fold, which each take a small function and apply it across a list.

Is map a higher-order function?
Yes. map takes a function as its first argument and applies it to every element of a list, returning a new list of the results. Because one of its arguments is itself a function, map is a textbook higher-order function — and so are filter and fold for the same reason.

What is the difference between a higher-order and a first-order function?
A first-order function only takes and returns ordinary values, such as numbers or strings. A higher-order function takes one or more functions as arguments, or returns a function, or both. The difference is whether the function operates on data alone or also on other functions.

Do higher-order functions only exist in Haskell?
No. They exist in any language that treats functions as first-class values — values you can store, pass and return. Haskell, JavaScript, Python, Swift and many others all support them. Haskell makes the idea especially visible through its type signatures and currying, but the concept is widespread.

Recommended

A Linux box to build and run your Haskell code

Trying these higher-order functions for real — loading them into GHCi, building a project with map and fold, then running it — is smoother on a proper Linux machine than a laptop. A cloud server gives you full control to install GHC and a Haskell toolchain in a clean environment and reach it over SSH. Infomaniak — a Swiss, privacy-respecting provider — offers cloud servers for exactly that.

[See Infomaniak Cloud →](https://coldwa.st/go/cloud.html)
Affiliate link — it supports these free guides.

Browse more clear explainers in our guides index.

Originally published on coldwa.st.

MCP Security: The Risks of Model Context Protocol and How to Govern It (2026)

ricco020 — Wed, 24 Jun 2026 07:31:23 +0000

The Model Context Protocol (MCP) is the open standard that lets an AI agent plug into your tools, files, and apps through one common interface — often described as "USB-C for AI." It is genuinely useful, and through 2025 and 2026 it has been adopted across AI assistants, IDEs, and agent frameworks. But the same connector that makes an agent powerful is also its biggest attack surface. Recent moves toward governing AI agents in the enterprise — security vendors shipping tools to monitor coding agents, and MCP-based governance layers landing inside Claude, ChatGPT, and Copilot — are a sign of the same thing: connecting an agent to your environment is a security decision, not a convenience setting. Here is the honest picture of MCP security in 2026 and how to govern it.

Why MCP is a security problem, not just a feature

MCP itself is just plumbing: a standard way for a model to discover tools, read their descriptions, and call them. The risk isn't the protocol — it's what flows through it.

When an agent connects to an MCP server, that server provides two things the model trusts: tool descriptions (text telling the model what each tool does and how to call it) and tool outputs (whatever the tool returns). The model reads both and acts on them. So every MCP server you attach is effectively code and instructions running with your agent's privileges. Whatever the agent can reach — your files, a repository, an API, your email — a malicious server can try to reach through the agent.

This is the same shift that makes AI agent security hard in general, applied to a specific connector: the security of your MCP setup is the security of every server you plug into it.

The MCP-specific risks in 2026

These aren't hypothetical — security researchers have documented them on real MCP clients.

Tool poisoning. A malicious server hides instructions inside a tool's description — text the model reads but the user usually doesn't. A tool that looks like a harmless add(a, b) can secretly instruct the agent to read private files and exfiltrate them. Because users tend to approve tool calls without inspecting the description, this is one of the most impactful MCP-specific attacks.
Rug pulls (silent redefinition). An MCP tool changes its own definition after you've installed and approved it. You vetted something safe; the server later swaps in malicious behaviour without telling you.
Tool shadowing and cross-server attacks. When several servers connect to the same agent, a compromised one can override or intercept calls meant for a trusted tool — a "confused deputy" problem where the agent does the attacker's bidding while thinking it's using a legitimate tool.
The exfiltration trifecta. The genuinely dangerous combination is an agent that has private data, reads untrusted content, and has an exfiltration path to the outside. MCP makes all three easy to wire together by accident.
Indirect prompt injection. Even an honest server returns outputs the agent reads — a web page, an issue, a document — that may contain hidden instructions. The agent can obey them as if they came from you.

How to govern MCP safely

You don't need to avoid MCP. You need to govern what you connect and box it in so a single bad server can't become a disaster. The principles are old security wisdom applied to a new connector.

Vet and pin trusted servers. Prefer official or well-reviewed MCP servers. Don't attach arbitrary third-party servers to an agent that holds real access, and watch for tool definitions that change after install.
Least privilege per server. Give each server only the access its job needs, using scoped, revocable credentials — never your primary accounts or production keys. If a server only needs to read, don't let it write.
Limit the blast radius. Avoid connecting many untrusted servers to the same agent, since one compromised server can intercept others. Isolate sensitive work from anything that reads the open web.
Human in the loop for high-impact actions. Require explicit confirmation before anything irreversible — sending money, deleting data, posting publicly, changing access. Let the agent draft; you approve.
Treat tool descriptions and outputs as untrusted. Both can carry injected instructions. The same caution applies when an agent uses AI code review tools or any tool that ingests external content.
Log and audit tool calls. Keep a record of which servers and tools the agent used, so you can spot anomalies and revoke fast.
Keep secrets out of prompts and tool arguments. Passwords and API keys pasted into a prompt or a tool call become text on a server. Use scoped tokens and secret managers instead.

The honest takeaway

MCP security comes down to one mindset shift: an MCP server is not a plugin you install and forget — it's a new participant with autonomy and access, and you should treat it like one you don't fully trust. The protocol is open and useful; the danger is in granting broad, standing trust to servers you haven't vetted. Connect deliberately, scope every server tightly, keep a human gate on anything irreversible, and assume every tool description and output could be trying to hijack your agent. The teams now building governance around AI agents — and the AI coding agents that lean on MCP most — are converging on exactly that: connect less, trust narrowly, and verify.

FAQ

What is MCP security?

MCP security is the practice of safely connecting AI models and agents to external tools and data through the Model Context Protocol — an open standard introduced by Anthropic in late 2024, often described as 'USB-C for AI'. MCP itself is just a connector: the security question is what you plug into it and how much you trust it. Each MCP server an agent connects to is code and instructions running with the agent's access, so a malicious or compromised server can read your data, call other tools, or take actions on your behalf. MCP security means vetting servers, scoping permissions tightly, and treating tool descriptions and outputs as untrusted input.

What is tool poisoning in MCP?

Tool poisoning is when a malicious MCP server hides instructions inside a tool's description or metadata — text the model reads but the user usually doesn't. The model treats those hidden instructions as commands, so a tool that looks like a harmless 'add two numbers' function can secretly tell the agent to read private files and send them somewhere. Security researchers have documented this as one of the most impactful MCP-specific risks, because users tend to approve tool calls without inspecting the underlying descriptions.

What is an MCP rug pull?

A rug pull, also called silent redefinition, is when an MCP tool changes its own definition after you've already installed and trusted it. You approve a tool that looks safe, and later the server quietly swaps in malicious instructions without notifying you. A related attack is tool shadowing, where a malicious server overrides or intercepts calls meant for a trusted tool. Both exploit the fact that trust granted once is rarely re-checked, which is why monitoring tool definitions for changes matters.

Is MCP safe to use?

MCP is broadly safe for everyday use if you connect only to servers you trust and scope their access tightly, but it is not safe to wire up arbitrary third-party servers with broad permissions and walk away. The protocol is an open connector, so its safety depends entirely on the servers you attach and the access you grant them. Use official or well-reviewed servers, give each one separate revocable credentials instead of your main accounts, keep a human in the loop for high-impact actions, and review what tools can do before approving them.

How do I secure MCP servers?

Apply least privilege: give each MCP server only the access its job needs, using scoped, revocable tokens rather than admin keys or your primary accounts. Vet and pin trusted servers, prefer official ones, and watch for tool definitions that change after install. Treat tool descriptions and tool outputs as untrusted content that may contain injected instructions. Avoid connecting many untrusted servers to the same agent, since one compromised server can intercept others. Log tool calls so you can audit and revoke, and keep secrets out of prompts and tool arguments.

Originally published on alexi.sh.

What Is a Vector Database? A Plain-English Guide (2026)

ricco020 — Mon, 22 Jun 2026 05:27:58 +0000

If you have read about RAG, AI search or recommendations, you have probably hit the term vector database. Here is the plain version. A vector database stores data as vectors — lists of numbers that capture meaning — and finds items by similarity, not by exact match. That one idea is what makes modern AI search feel like it understands you.

What a vector database actually is

Normal databases are great at exact questions: find the user with this ID, or every order from last week. They struggle with "find me things that mean the same thing." A vector database is built for exactly that.

It works on embeddings — the numeric fingerprints an AI model gives to text, images or audio. Items with similar meaning get vectors that sit close together. The database stores those vectors and, when you search, returns the ones nearest to your query.

How similarity search works

The flow has three steps:

Embed. An embedding model turns each document, image or sentence into a vector.
Index. The database stores those vectors in a special index (like HNSW or IVF) so it can search huge sets fast.
Query. Your search is embedded too. The database returns the vectors closest to it by distance.

So a search for "how to reset my password" can surface an article called "recover a forgotten login." The words differ, but the meaning — and the vectors — are close.

Vector database vs a normal database

They solve different problems, and most real apps use both. A relational database holds your structured records and answers exact queries. A vector database answers "what is most like this?" You keep customer rows in one and searchable meaning in the other. Tools like pgvector even let you add vector search to a normal PostgreSQL database, so both live in one place.

Why it matters for AI

A vector database is the retrieval engine behind a lot of AI. It powers semantic search, product and content recommendations, and — most importantly — the retrieval step in RAG, where an assistant fetches relevant text before answering. Without fast similarity search over embeddings, none of those features would be practical at scale.

The bottom line

A vector database stores meaning as vectors and finds items by similarity instead of exact match. It does not replace your normal database — it sits beside it and answers the questions a keyword search never could. If you are building anything with semantic search or RAG, a vector database is the piece doing the heavy lifting.

FAQ

What is a vector database in simple terms?

A vector database stores data as vectors — long lists of numbers called embeddings that capture meaning. Instead of matching exact words, it finds items whose vectors are closest to your query's vector. So a search for 'how to reset my password' can return a help article titled 'recover a forgotten login', because they mean the same thing. It is the engine behind semantic search, recommendations, and the retrieval step in most AI assistants.

How is a vector database different from a normal database?

A normal (relational) database is built for exact, structured queries: find the row where id = 42, or where country = 'France'. A vector database is built for similarity: find the items most like this one. It does not look for an exact match — it ranks results by how close their vectors are. The two are complementary. Many apps use a normal database for records and a vector database for meaning-based search.

How does similarity search actually work?

Three steps. First, an embedding model turns each item (a document, image, or sentence) into a vector. Second, the vector database stores those vectors in a special index (such as HNSW or IVF) that makes nearest-neighbour search fast, even over millions of items. Third, when a query comes in, it is embedded too, and the database returns the vectors closest to it by distance. You get the most similar items back in milliseconds.

Which vector databases are popular in 2026?

Common options include Pinecone, Weaviate, Qdrant, Milvus, and Chroma, plus pgvector, which adds vector search to PostgreSQL so you can keep everything in one database. The right choice depends on scale, whether you want a managed service or to self-host, and whether you need vectors alongside your existing relational data. For small projects, pgvector or Chroma are easy starting points.

Originally published on alexi.sh.

What Is a Home Server? A Plain-English Guide (2026)

ricco020 — Sun, 21 Jun 2026 13:38:09 +0000

There is a running joke online: someone sets out to build a "home server," and a year later they have a rack of machines, a labelled network, and a power bill to match — they accidentally built a tiny data center. It is funny because it is true, but it hides a simpler fact. A home server does not have to be any of that. At its core, a home server is just a computer that stays on to serve other devices in your home.

What a home server actually is

Think of it as a helper computer. It runs all the time, sits quietly in a corner, and waits for your other devices to ask it for something. You do not sit in front of it. Once it is set up, it has no screen or keyboard — you reach it from your phone, laptop or TV over your home Wi-Fi.

The hardware can be almost anything. An old laptop works. So does a cheap mini PC, a Raspberry Pi, or a ready-made NAS box. What makes it a "server" is the job it does, not the size of the machine.

What people run on one

A home server earns its keep by doing a few steady jobs:

File storage — one place for documents and photos that every device can reach.
Media streaming — your own films and music, streamed to any screen in the house.
Backups — automatic copies of your phones and laptops, so a lost device is not a lost life.
Smart-home control — local software that runs your lights and sensors without the cloud.
A self-hosted VPN — a private door back into your home network while you travel.

You can run just one of these, or several at once. Most people keep each job in its own container so they stay tidy and easy to update.

Home server vs a VPS

The two get confused, but they solve different problems. A home server lives in your house, holds your data, and costs only the electricity to run it. The catch is that it depends on your home internet and you look after it yourself.

A VPS is a server you rent in a data center. It is always online, has a fast connection and a public IP, and is easier to reach from anywhere — which is why people host a VPN or a website on one. If you are weighing the two, our guide on what a VPS is explains it in plain terms. Many setups use both: a home server for local files and media, a small VPS for anything the outside world needs to reach.

What you need to start

Very little. An always-on computer you already own, a wired network connection if you can manage it, and one job to begin with — say, a file share or a media library. Add a second service only once the first is steady. Start small, keep it simple, and let it grow with you.

The bottom line

A home server is not a data center. It is a spare computer doing useful work while you get on with your day — storing your files, backing up your devices, streaming your media, and, if you want, giving you a private way home over a VPN. Begin with one machine and one job. That is all it takes to have a home server.

FAQ

What is a home server in simple terms?

A home server is a computer in your home that stays on so other devices can use it. It does not need a screen or a keyboard once it is set up. You reach it from your phone, laptop or TV over your home network. People use one to store files, stream their own media, run automatic backups, host smart-home software, or run a self-hosted VPN. Any always-on computer can be a home server — an old laptop, a mini PC, a Raspberry Pi, or a NAS box.

Do I need a home server, or is a VPS better?

It depends on what you want. A home server keeps your data in your house and costs nothing to run beyond electricity, but it relies on your home internet and you maintain it yourself. A VPS (a rented server in a data center) is always online with a fast, stable connection and a public IP, which is easier for hosting a VPN or a website that you reach from anywhere. Many people use a home server for local files and media, and a small VPS for anything that needs to be reachable from outside the house.

What can you run on a home server?

Common uses are: a file share for all your devices, a media library (so you stream your own films and music), automatic backups of phones and laptops, a photo library, smart-home automation, ad-blocking for the whole network, and a self-hosted VPN to reach your home safely while travelling. You can run one of these or several at once, usually inside containers so they stay tidy and separate.

Is a home server hard to set up?

Not as hard as it used to be. A basic file or media server can be running in an afternoon with free software and a guide. The learning curve is real if you want remote access, secure logins, and automatic updates, but you can start small with one service and add more later. A Raspberry Pi or an old laptop is a cheap, low-risk way to learn before spending money on dedicated hardware.

Originally published on vpnsmith.

What Is Vibe Coding? The AI-First Way to Build Software (2026)

ricco020 — Sun, 21 Jun 2026 13:36:38 +0000

Ask an AI assistant to "build me a habit-tracker app" and watch it produce working code in seconds — then ask it to tweak the colours, add a chart, fix a crash, all in plain English, without you reading a single line. That loop has a name now: vibe coding. This guide explains what vibe coding actually is, where the term came from, how it works in practice, and the honest line between a brilliant shortcut and a trap.

What vibe coding actually is

Vibe coding is building software by describing intent to an AI and iterating on what it generates, instead of writing and reviewing the code yourself. You operate at the level of "what I want it to do" — add a feature, change a behaviour, fix an error — and let the model handle "how it's written." Your job shifts from author to director: you prompt, you run it, you react to the result, and you repeat.

The defining trait is how little you look at the code. In classic development you read and own every line. In vibe coding you often accept the AI's output without fully reading it, judging the program by whether it behaves the way you wanted rather than by how it's built.

Where the term came from

The phrase was popularised by Andrej Karpathy in early 2025. He described a mode of working where you "fully give in to the vibes" and rely on the AI so completely that you barely engage with the underlying code — fun and fast, in his framing, for weekend projects and throwaway tools. The name stuck because it captured something developers were already doing with conversational best AI coding assistants: less typing, more describing.

How it works in practice

A vibe-coding session looks like a conversation. You state a goal, the assistant writes or edits files, you run the result, and you describe what's wrong or what to add next. The model keeps the project context, so each turn builds on the last. The faster that loop — prompt, run, react — the more it feels like "coding by vibes" rather than by syntax.

This is close to, but not the same as, AI pair programming. Pair programming with an AI implies you're still reading along, reviewing and steering line by line, like a navigator beside a driver. Vibe coding leans further: you delegate the how almost entirely and judge only the outcome. The same tools support both modes — the difference is how much you choose to look.

Where it shines — and where it bites

Vibe coding genuinely excels at:

Prototypes and MVPs — get a clickable idea in front of people fast.
Throwaway scripts — one-off automation you'll run once and delete.
Learning and exploration — see one working approach, then dig in.
Non-critical personal tools — where a bug is an annoyance, not a breach.

It bites hardest when the stakes rise. Shipping code you haven't read means inheriting problems you can't see: exposed API keys, missing input validation, insecure dependencies, and subtle logic bugs. When something breaks in production, debugging code you never understood is painful, and a codebase nobody can explain becomes a maintenance liability. The accelerator that built the prototype is a poor foundation for the thing real users depend on.

The bottom line

Vibe coding is a real shift in how software gets made: describe intent, let the AI write it, iterate on the result. For prototypes, scripts and learning it's a superpower that collapses hours into minutes. For anything handling money, data or security, treat the AI's output as a fast first draft from a junior collaborator — read it, test it, and understand it before it ships. The developers who get the most from vibe coding are the ones who know exactly when to stop vibing and start reviewing.

FAQ

What is vibe coding?

Vibe coding is the practice of building software by describing what you want in natural language to an AI assistant and accepting or iterating on the code it generates, rather than writing and reviewing every line yourself. You stay at the level of intent — 'add a login form', 'make this faster', 'fix that bug' — and let the model produce the implementation. It works best with conversational AI coding tools and is excellent for prototypes and small scripts, but it shifts your role from author to reviewer-and-director.

Who coined the term 'vibe coding'?

The phrase was popularised by Andrej Karpathy in early 2025, when he described a way of working where you 'fully give in to the vibes' and lean on the AI so heavily that you barely look at the code. He framed it as fun and fast for throwaway projects. The term caught on quickly because it named something many developers had already started doing with tools like Cursor, GitHub Copilot and Claude Code.

Is vibe coding good or bad?

Neither on its own — it depends entirely on the stakes. For prototypes, personal tools, learning experiments and disposable scripts, vibe coding is a genuine accelerator: you get something working in minutes. For production software, anything handling money, personal data or security, shipping code you haven't read is risky, because you inherit bugs and vulnerabilities you can't see and will struggle to debug. The skill is knowing which mode a task calls for.

Is vibe coding safe for production apps?

Not without review. The danger of pure vibe coding is that you ship code you don't understand, which can hide security flaws (exposed secrets, missing input validation, insecure dependencies), subtle logic bugs, and maintenance debt that nobody on the team can explain later. For anything real, treat the AI's output as a draft from a fast but junior collaborator: read it, test it, and understand it before it goes live.

Originally published on alexi.sh.

What Is the Model Context Protocol (MCP)? A Plain Guide (2026)

ricco020 — Sun, 21 Jun 2026 13:35:59 +0000

If you have heard the term MCP thrown around in AI circles in 2026 and were not sure what it meant, here is the short version. The Model Context Protocol (MCP) is an open standard that lets an AI model connect to outside tools, data and apps through one common interface. People often call it "USB-C for AI" — one standard plug instead of a different cable for every device.

What MCP actually is

An AI model on its own only knows what it was trained on. It cannot read your files, query your database, or check your calendar unless something hands it that access. MCP is the agreed way to hand it that access.

It works through two roles. An MCP server exposes a tool or data source — your documents, a code repository, a search engine. An MCP client lives inside the AI app and connects to those servers. Because both sides follow the same protocol, any client can talk to any server. The model can then list the available tools and use them.

Why MCP matters

The value is in the maths. Say you have many AI apps and many tools. Connecting each app to each tool by hand is the classic "N times M" problem — a lot of duplicated, brittle code. MCP turns it into "N plus M". Each tool ships one MCP server. Each app speaks MCP once. After that, they all work together.

That is what makes modern AI agents useful. An agent that can only talk is limited. An agent that can read your files, run a query, or open a ticket can actually get work done. MCP is the plumbing that lets it reach those systems safely and in a standard way.

How it works in practice

MCP was introduced by Anthropic in late 2024 as an open standard, with public specs and open-source SDKs. Through 2025 and 2026 it spread across AI assistants, IDEs and agent frameworks.

In day-to-day use you rarely see it. You add an MCP server — for GitHub, a database, your notes — to an AI app that supports it. The app's client connects, the model sees the new tools, and you can ask it to use them in plain language. If you want the bigger picture of what an agent is, see our guide on what an AI agent is; MCP is one of the things that makes those agents practical. The same standard shows up in the best AI coding assistants, where it connects the model to your repo and tools.

The bottom line

MCP is a small idea with a big effect: one open standard for connecting AI models to the real world of tools and data. It replaces a mess of custom integrations with a single shared plug. You do not need to build it yourself to benefit — you just need to know that when an AI app "supports MCP", it can now reach far beyond its training data and actually act for you.

FAQ

What is the Model Context Protocol (MCP)?

MCP is an open standard that lets an AI model connect to outside tools, data and apps through one shared interface. Before MCP, every assistant needed its own custom code to reach each tool — your files, a database, GitHub, a calendar. MCP replaces that with a common protocol, so any AI app that speaks MCP can use any tool that speaks MCP. It is often called 'USB-C for AI' because it is a single, standard plug that works across many devices.

Who created MCP and is it open?

MCP was introduced by Anthropic in late 2024 as an open standard, with public specifications and open-source software development kits. Being open means any company or developer can build MCP servers (to expose a tool) or MCP clients (to use one), without permission from a single vendor. Through 2025 and 2026 it was adopted across many AI assistants, IDEs and agent frameworks, which is why it has become a common way to give models access to real tools.

Why does MCP matter?

It solves a scaling problem. With many AI apps and many tools, connecting each app to each tool by hand is a huge amount of duplicated work — the classic N-times-M problem. MCP turns it into N-plus-M: each tool exposes one MCP server, each app speaks MCP once, and they all interoperate. That makes AI agents far more useful, because they can act on your real data and systems instead of only answering from memory.

Is MCP the same as an API or a plugin?

Not quite. An API is how one program talks to another; a plugin is a feature bolted onto a specific app. MCP is a shared standard that sits above those — it defines a common way for an AI model to discover and use tools, whatever they are. A tool still has its own API underneath, but the MCP server wraps it so the model sees a consistent interface. So MCP complements APIs rather than replacing them.

Originally published on alexi.sh.

Encryption at rest vs zero-knowledge: who can actually read your cloud files

ricco020 — Sat, 20 Jun 2026 20:01:48 +0000

"Encrypted cloud storage" is one of the most abused phrases in tech marketing. Almost every provider claims it — but the word that decides whether they can read your files is zero-knowledge, and most consumer clouds quietly don't offer it. Here's the technical distinction, because it changes who holds the keys.

Encryption-at-rest vs zero-knowledge

Encryption at rest means the provider encrypts your files on their disks — with keys they control. It protects against a stolen hard drive in their data center. It does not protect against the provider itself, a rogue employee, a subpoena, or a server-side breach that also grabs the keys. Most mainstream clouds stop here.

Zero-knowledge (client-side) encryption means your data is encrypted on your device, with a key derived from your passphrase, before it ever leaves. The server stores ciphertext it cannot decrypt. The provider has "zero knowledge" of your contents. The trade-off is real: if you lose the passphrase, nobody — not even support — can recover your files. That's not a bug; it's the entire point.

How it actually works

A typical zero-knowledge flow:

Your passphrase runs through a slow KDF (Argon2id or PBKDF2 with a high iteration count) to derive a master key. Slow on purpose — it makes brute-forcing the stored ciphertext impractical.
A random per-file (or per-account) key encrypts the data with an authenticated cipher like AES-256-GCM or XChaCha20-Poly1305.
That file key is itself wrapped with your master key. The server only ever sees wrapped keys + ciphertext.
Decryption happens entirely client-side after you authenticate.

The security property that matters: the plaintext and the master key never reach the server. If you can't point to where in a provider's flow that's true, assume it isn't.

What this means in practice

A breach of a zero-knowledge provider leaks ciphertext, not your files. A breach of an encryption-at-rest provider can leak both data and keys.
Metadata usually isn't encrypted even under zero-knowledge — filenames, sizes, folder structure, timestamps often leak. Check each provider's specifics; "zero-knowledge" rarely means "zero metadata."
You become the single point of failure for key recovery. Use a strong, unique passphrase and store a recovery code somewhere safe.

This isn't an argument that everyone needs zero-knowledge for cat photos. It's that you should know which model you're on, because "encrypted" on a pricing page tells you almost nothing about whether the company can read your files.

I wrote a deeper, plain-English explainer — including how to verify a provider's claims and where metadata leaks — here: What is zero-knowledge encryption?

Self-hosting a password manager with Vaultwarden: a clean, hardened Docker setup

ricco020 — Sat, 20 Jun 2026 20:01:04 +0000

A hosted password manager means trusting a company's servers with the keys to your entire digital life. Vaultwarden — a lightweight, unofficial Rust re-implementation of the Bitwarden server API — lets you keep that vault on hardware you control, while still using the official Bitwarden apps and browser extensions. It runs comfortably on a $5 VPS or a Raspberry Pi.

Here's a clean, minimal setup plus the hardening that actually matters.

The Docker Compose

services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://vault.example.com"
      SIGNUPS_ALLOWED: "false"   # turn off after you create your account
      ADMIN_TOKEN: "<argon2-hash>" # see below
    volumes:
      - ./vw-data:/data
    ports:
      - "127.0.0.1:8080:80"      # bind to localhost, terminate TLS at a reverse proxy

Two deliberate choices in that file:

ports: 127.0.0.1:8080:80 — Vaultwarden speaks plain HTTP. Never expose that to the internet. Bind it to localhost and put a reverse proxy (Caddy/nginx/Traefik) in front to handle TLS. The web vault and the Bitwarden clients refuse to send credentials over anything but HTTPS, so this isn't optional.
SIGNUPS_ALLOWED: "false" — leave it true only long enough to register your own account, then flip it and recreate the container. An open Vaultwarden on a public IP will get strangers registering on it.

Hardening that matters

Hash the admin token. The /admin panel is a juicy target. Don't paste a plaintext token — generate an Argon2 hash and use that:

docker run --rm -it vaultwarden/server /vaultwarden hash

Put the admin panel behind something extra — IP allow-list at the proxy, or a VPN-only route. A leaked admin token otherwise exposes every user.

Back up vw-data/. It holds the SQLite DB (encrypted blobs, but also account metadata) plus your rsa_key files. No backup = one disk failure from losing every password. A nightly sqlite3 .backup to an offsite target (the 3-2-1 rule applies to your vault too) is the difference between an inconvenience and a catastrophe.

Keep the image pinned and updated. latest is fine for a personal box if you actually pull regularly; Vaultwarden ships security fixes and you want them.

What you're actually trading

Self-hosting removes the "trust a third party's servers" risk and replaces it with "you are now the server admin." That's a real responsibility: you own patching, backups, TLS, and uptime. For a lot of developers that trade is worth it; for non-technical family members, a reputable hosted manager is often the safer default. There's no universally right answer — only the one that matches your threat model and your willingness to operate infrastructure.

If you want the full step-by-step — reverse-proxy configs, automatic backups, fail2ban, and the security trade-offs in detail — I wrote it up here: Self-host a password manager with Vaultwarden.

AI text detectors are mostly guessing: how they actually work

ricco020 — Sat, 20 Jun 2026 19:59:48 +0000

If you write documentation, blog posts, or even commit messages, there's a decent chance an "AI detector" has flagged something you wrote by hand. These tools are now bolted onto plagiarism checkers, CMSs, and hiring pipelines — and a lot of people treat their output as a verdict. It isn't. Here's what they actually measure, and why the score is closer to a weather forecast than a fact.

What they actually measure

No detector "reads" your text for meaning. They estimate the probability that a passage was machine-generated from surface statistics. Three approaches dominate:

Perplexity — how surprised a language model is by each next word. Human writing tends to take odd turns; LLM output is, by construction, the high-probability next token most of the time. So low, flat perplexity reads as "probably AI."

Burstiness — how much sentence length and complexity vary. Humans mix a 4-word sentence with a 40-word one. Models trend toward an even rhythm. Low variance → "probably AI."

Trained classifiers — a model shown lots of human and machine samples that learns to output a probability. This is only as good as its training distribution; feed it a domain it hasn't seen and it guesses.

A fourth idea, watermarking, biases the model's word choices in a pattern a matching detector can later spot. It's the most principled approach in theory, but it only works if the provider actually watermarks output and the watermark survives copying, paraphrasing, or light editing. Usually it doesn't.

Why the score is unreliable

Because all of the above measure predictability, not authorship, the failure modes are systematic:

Clean human writing scores as AI. The exact style we teach people to write — short, clear, well-structured — is low-perplexity. The better your prose, the more "robotic" it looks to a detector.
Documented bias against non-native English. A widely cited 2023 Stanford study (Liang et al., published in Patterns) found detectors disproportionately flag text by non-native English speakers, whose simpler phrasing reads as low perplexity. That's a fairness problem, not a rounding error.
Trivially defeated. A few paraphrases, a synonym pass, or moderate editing collapses the signal. So the tool punishes honest plain writers while waving through anyone who lightly edits machine output.
Even OpenAI gave up. OpenAI quietly discontinued its own AI Text Classifier in July 2023, citing low accuracy. When the lab that ships the generator can't reliably detect it, a third-party box promising "99% accurate" should set off alarms.

What to do instead

If you ship anything that acts on a detector score — moderation, grading, hiring — treat the number as a faint hint, never proof:

Never auto-act on a single score. A false positive that accuses a student or rejects a candidate causes real harm.
Look at process and context — drafts, edit history, the ability to explain the work — not a probability.
If you build with detectors, log and surface the uncertainty. Show the confidence band, not a binary "AI / human."

The honest summary: AI detectors are probabilistic pattern-matchers with high false-positive rates and a built-in bias against plain and non-native writing. Useful as a weak prior; dangerous as a verdict.

I wrote a longer, fully-sourced breakdown — including how watermarking holds up and what the research actually says — here: How do AI detectors work?

How browser fingerprinting actually identifies you (and how to check yours)

ricco020 — Tue, 16 Jun 2026 14:49:18 +0000

Cookies are easy to block. Fingerprinting is the technique that quietly replaces them — and most people have never tested how exposed they are.

What a fingerprint actually is

A browser fingerprint is a combination of attributes your browser exposes to every site: user-agent, screen resolution, timezone, installed fonts, language, and — crucially — the way your specific GPU and graphics stack render a hidden <canvas> or WebGL scene. Individually these are low-entropy. Combined, they're often unique enough to single you out of millions, with no cookie and no login.

The key idea is entropy: each attribute carries some bits of identifying information. Timezone alone is weak. Timezone + a canvas hash + your exact font list + audio-stack quirks can be more than enough to re-identify you across sessions and even across sites.

The main vectors in 2026

Canvas / WebGL rendering — the same drawing instructions produce subtly different pixels depending on your GPU, drivers and OS. A hash of that output is one of the most stable signals.
AudioContext — generating a waveform and reading it back leaks tiny differences in your audio stack.
Font enumeration — the set of fonts you have installed is surprisingly personal.
Hardware hints — navigator.hardwareConcurrency, deviceMemory, pointer/touch capabilities.

How to reduce your fingerprint

There's no perfect answer, but there are real trade-offs:

Tor Browser makes everyone look identical by design — the strongest option, at the cost of speed and convenience.
Firefox with privacy.resistFingerprinting (or the simpler "strict" tracking protection) normalizes many of these signals.
Brave randomizes canvas/audio readings per session so the hash isn't stable.
Counter-intuitively, rare extensions or an exotic setup can make you more identifiable, not less — uniqueness is the enemy.

Test yours

Before changing anything, measure it. Cover Your Tracks (EFF) and AmIUnique both show your uniqueness score and which attributes leak the most bits.

For a full 2026 technical breakdown — every vector, how detection works under the hood, and what each browser actually mitigates — I keep a deeper reference here: Browser fingerprinting: state of the art 2026.

The honest takeaway: you can't get to zero in a normal browser, but you can move from "trivially unique" to "blends into a large crowd" — and that's most of the battle.

rclone crypt: encrypt files client-side before they touch any cloud

ricco020 — Sun, 14 Jun 2026 03:13:55 +0000

If you want files encrypted before they ever reach a cloud provider — so the provider only ever sees ciphertext — rclone crypt is the simplest tool that works with almost any backend (S3, Google Drive, Dropbox, pCloud, Backblaze B2, a plain SFTP box…). This is client-side, zero-knowledge-style encryption you fully control. Here's a clean setup.

The idea

rclone crypt is a wrapper remote: it sits on top of a normal remote and transparently encrypts file contents and file/dir names on the way up, decrypts on the way down. Your passphrase never leaves your machine.

local files  ->  [crypt remote: encrypt]  ->  [storage remote]  ->  cloud (sees ciphertext only)

1. Install

curl https://rclone.org/install.sh | sudo bash
# or: sudo apt install rclone
rclone version

2. Configure the underlying storage remote

rclone config
# n) New remote -> name it e.g. "drive" -> pick your provider -> OAuth/keys

Test it:

rclone lsd drive:

3. Add a crypt remote on top

rclone config
# n) New remote -> name "secret" -> storage: "crypt"
#   remote>  drive:encrypted        # a subfolder on the storage remote
#   filename_encryption>  standard  # also encrypts file names
#   directory_name_encryption>  true
#   password>  (generate a strong one)
#   password2>  (salt - optional but recommended)

Back up the passphrase + salt in a password manager. There is no recovery if you lose them — that's the whole point of zero-knowledge.

4. Use it

# Upload (everything is encrypted client-side first):
rclone copy ~/Documents secret: -P

# List (decrypted view, local only):
rclone ls secret:

# Mount as a normal folder:
rclone mount secret: ~/CloudCrypt --vfs-cache-mode writes

On the provider's side you'll see only opaque names like a1b2c3d4... — no filenames, no content.

5. Verify the provider sees nothing

rclone ls drive:encrypted    # raw view = encrypted blobs + scrambled names

If you can read filenames here, filename encryption isn't on — recheck step 3.

Gotchas

crypt encrypts content + names, not the number of files or their sizes. A motivated observer can still infer file count and approximate sizes. For metadata-sensitive cases, pad or archive first.
It does not add redundancy. crypt is encryption, not backup — keep the 3-2-1 rule.
Two different crypt remotes with different passwords are incompatible. Decide your scheme once.

When a provider-native E2E option is better

rclone crypt is great for bolting encryption onto any backend. But if you want native end-to-end encryption, mobile apps, and sharing built in, a zero-knowledge provider may fit better. The trade-offs between "encrypt-it-yourself" and provider-native E2E/zero-knowledge are worth understanding:

→ End-to-end vs zero-knowledge cloud storage — what's the real difference