Roastidio.us Tagged with web

Edge 152 starts Microsoft’s two-week update race

Sun, 30 Aug 2026 23:35:55 +0000

Microsoft Edge 152 begins a faster major-release schedule that will deliver browser updates every two weeks instead of every four. The change also affects WebView2, while organizations that need more time to test releases can remain on Edge’s eight-week Extended Stable channel.

Source

Microsoft Edge 152 automatically blocks scam notification traps – 4sysops

Sun, 30 Aug 2026 23:35:55 +0000

Microsoft Edge 152 automatically blocks scam notification traps

By IT News AI / Fri, Aug 28 2026 / Leave a Comment

Microsoft Edge 152 can now automatically unsubscribe users from push notifications sent by websites that Microsoft Defender SmartScreen blocks as scams, phishing pages, or malware. The Stable release also completes Edge’s shift to a two-week major-release cycle and adds Apple account sign-in on Windows and macOS.

Read 4sysops without ads and access many member features.

SmartScreen cuts off malicious notifications

When SmartScreen identifies a dangerous site, Edge stops it from sending further notifications and informs the user. Users can review blocked notification sources and restore permissions if a site was flagged incorrectly, although Microsoft is enabling the protection gradually.

Microsoft Edge 152 automatically blocks scam notification traps (image neowin.net)

This closes a common abuse path in which legitimate browser notification permissions are later used to deliver scam alerts or links to malware. Edge 152 also includes a substantial set of security fixes.

Read 4sysops without ads and access many member features.

More controls for administrators

Organizations can disable Apple account sign-in through policy. Administrators also gain additional controls over Copilot Cowork actions, including whether the assistant may open tabs, capture screenshots, or interact with web pages for users.

Other Edge 152 changes

The password-key button in the address bar now opens a credential panel for copying and managing saved passwords, with support for adding notes to logins. Microsoft has removed Drop and is gradually retiring real-time video translation.

Read 4sysops without ads and access many member features.

Stable updates will continue rolling out progressively. Users can check for version 152.0.4191.52 under Settings > About Microsoft Edge.

Microsoft Edge 152 adds a useful feature for fighting scam notifications | neowin.net

Read 4sysops without ads and access many member features.

Notify of

Label

Name*

Email*

Subscribe to Newsletter

Label

Name*

Email*

Subscribe to Newsletter

0 Comments

HSK Manga: Turning Manga into Beginner-Level Chinese

Sun, 30 Aug 2026 22:53:32 +0000

Blog

HSK Manga: Turning Manga into Beginner-Level Chinese

By Jerry Rao · August 2026

My brother has been learning Chinese for years. He reads a lot of English-translated manhua, but when he tried reading the Chinese original, he grew frustrated. He still couldn't parse many sentences and found himself spending more time looking up definitions than actually reading the text! Turns out this is a fairly normal experience. Research shows that you need to know about 95% of the words to follow text with assistance and 98% to read it comfortably (Hu & Nation, 2000).

One solution for this is graded readers, hand-written text designed to target specific HSK levels (HSK is the standard 1–9 scale of Chinese proficiency). But writing them by hand doesn't scale, and engaging graded text is hard to come by. That's why I built HSK Manga, which is free for anyone to use. It takes manga that already exists online and rewrites the dialogue just how a graded reader would. You pick an HSK level from 1 to 4, and every line in the chapter gets rewritten to that level.

I've been building HSK Manga for the past 6 months, as a junior in high school. In this post, I'll go over the three most important stages in its pipeline.

Extracting text

Before I can simplify anything, I need the dialogue as actual text. Manga pages have text embedded into the images, so I'm forced to use optical character recognition (OCR), which is software that reads text out of an image. The one I use is PaddleOCR, and getting it to work on manga pages requires implementation beyond the base software.

OCR issues

If you run OCR on a manga page, it collects every single piece of text it can find, useful or not. Useless text is either background text or heavily stylized SFX (the sound-effect lettering drawn into the art). Capturing this text is bad because nobody reads it in the first place, and hand-drawn characters are really hard to render in a way that will match the art. I solved this by building a list of filters that use information from PaddleOCR (bounding-box dimensions, chroma, rotation, and confidence level) to drop text that shows clear signs of being unnecessary, highly stylized, or both. Getting these filters right took hundreds of sample chapters because of how hard it can be to differentiate between real dialogue and useless text.

Another issue with OCR is that it extracts text line by line, so a single speech bubble comes back as several fragments. This is bad because manga dialogue is split into speech bubbles, not lines. The solution is similar to how I filter out unnecessary text: I built a function that joins bounding boxes back together when certain requirements are met (roughly, when boxes are close and aligned enough to be the same bubble).

A real page from the sample chapter. OCR returns five boxes: three lines of dialogue and the two sound effects (喔耶, 啊啊). The sound effects get dropped and the three remaining lines get merged back into the single bubble they came from.

All of this lets me extract the exact pieces of text I want to simplify.

Simplification

When I started this project, I assumed getting the AI to simplify text would be really easy. All I had to do was write a great prompt, and the AI would do the rest. Through lots of testing, prompt changes, and some research into how others handled the same problem, I concluded that prompt engineering hits a ceiling on simplification quality. AI models are great at retaining meaning and grammar during simplification, but they lack a firm grasp of the different HSK levels, and they don't simplify text enough.

To solve this, I tried creating a restriction where the model could only write words I allowed, using a grammar format called GBNF. In my case, that meant only low-level HSK words. But it was too strong of a constraint since there are many cases where a word does not have a simpler alternative. A common example of this would be a person's name. This is why I moved to a softer inference-time setting called logit bias. Tokens are the sub-word chunks a model actually generates, and logit bias lets you nudge the model's probability for specific tokens up or down. That let me make simpler words more likely and harder words less likely, without banning anything outright.

The left bar graph shows a model's base probabilities; the right shows them after logit bias is applied.

So how did I actually use logit bias? Two details matter here: the token bias map and the AI provider. To build the map, I scanned all the tokens in the model's tokenizer vocabulary and sorted them into two groups: tokens whose characters all fall inside the target HSK level, and tokens that form words/phrases above that level. That second group matters because many advanced words are combinations of beginner characters. For the provider, I used Fireworks AI running DeepSeek V4 Flash, the only place where there was no practical cap on a bias map this big (~22,000 tokens).

Once those two things were settled, I had to figure out how much bias to apply. After testing out many different values, I ended up with a ±2.5 bias value: a positive +2.5 on the in-level tokens to make them roughly 12 times more likely to get picked, and a negative −2.5 on the above-level tokens to make them less likely. I found that below 2.5, not enough words got simplified. Above it, the model started reaching for clumsy substitutions, turning 敏捷 ("agile") into 快 ("fast") and 沉浸 ("immersed") into 喜欢 ("like") in places where the harder word was the right one.

Now that the dialogue is simplified enough to read, it needs to be placed onto the images.

Erasing, covering, and rendering new text

For the output chapter to actually look nice, the original text needs to be either covered or erased.

The same page from the OCR section, taken through the full swap. The sound effects survive because the filters dropped them earlier, so they were never marked for removal.

To do this, I use the bounding boxes from my OCR to select the areas where I'll either erase the text or cover it. Text is erased with LaMa when the background isn't a solid color, and it's covered when the background is solid. LaMa is an AI inpainting model that fills an erased region with plausible background art, similar to Photoshop's content-aware fill.

Determining whether the background is solid is as simple as sampling a small set of pixels and checking what fraction of them match the median color.

Anything that hits 95% or higher gets covered with a solid color. The speech bubble on the left is a clean 100%. The text sitting on artwork on the right only reaches 49%, so it goes to LaMa instead.

On a solid background, covering and LaMa create the same visual result, but covering the text is much more efficient. For text placed on top of artwork, LaMa looks far better, since it can predict what the background should be.

Once the original text is either covered or erased, new text needs to be generated. This step is as simple as taking the bounding box from the OCR and using it like a text box for the simplified text.

Where it stands

As of today, HSK Manga has simplified over 500 chapters. In this blog post I only mentioned the general functionality of the pipeline, but there are many other features available such as pinyin, definitions, and audio. My project still isn't finished though. Comments, emails, or the form at hskmanga.com/feedback are highly appreciated. I read everything! I'm always looking to improve HSK Manga, whether that's simplification quality, more features, or a better interface.

Building a decentralized bulletin board (and accidentally reinventing Nostr)

Sun, 30 Aug 2026 17:03:31 +0000

Let's do a software engineering exercise. Our goal is to build a bulletin board. A place where anyone can post an ad, a note, a message, with no account and no sign-up. Some old hands already know I mean a BBS without registration, others will picture something like X or Mastodon. It sits somewhere in between. Let's carry on.

We add a new requirement: I don't want it to depend on a single server. Each person can run their own instance to publish, or publish on someone else's instance. It makes no difference to the end result. Every reader, no matter which server they check, will end up seeing the same notes in the same order. We just opened the box of decentralization.

Now the servers have to coordinate. If every board is a copy of the whole list, and anyone can write on any board, theirs or someone else's, how on earth do they all agree on which ads exist? That is the heart of this article.

Let me give you a spoiler: by the time we finish, we will have accidentally reinvented two technologies that already existed: FidoNet (1984) and Nostr, with its negentropy sync (2023). But let's not get ahead of ourselves.

Let's set some limits to narrow the problem down and learn what interests us.

The rules of the game

The features that define our board:

There will be a single board shared across all servers: no topics, no sections.
Each node keeps a full copy of the board.
Everything is public: no login, no sign-up, no passwords, no authentication. You show up, you write, you pin your ad, done.
A reply is just another ad: if Bob wants to answer Ana's ad, he posts a new ad that points to hers. Some hang off others, but deep down they are the same thing.

So a board is a list of ads. And syncing two nodes means getting both to hold the same list.

In maths that is called a set, and agreeing on a set is called reconciliation. Remember the terms, because I'll keep using them.

First attempt: send me everything

Ana brings up her node. Bob brings up his. Each has their own ads. Let's sync them.

The obvious approach would be this: Ana sends Bob her entire list of ads, Bob compares it with his own and keeps the ones he was missing. Then the other way around. And that's it. Solved. Believe it or not, this works. It is the simplest way to reconcile sets: exchange everything and drop the duplicates. However, it is extremely inefficient.

Imagine the two of them have 1,000,000 ads and differ in only 3. With this method, Ana sends a million lines to find out that Bob already had 999,997 of them right. You moved an entire house to discover only three bricks were missing.

Now picture doing this every few minutes to stay up to date. A million lines every time! It is unsustainable, slow and expensive.

Let's change strategy: the cost of syncing should be proportional to how much the two boards differ, not to how big they are. In other words, if both nodes have 1,000,000 ads and differ in only 3, then only 3 ads should move.

But first we need to solve a previous problem.

How do we know we already have the same ad?

When Ana and Bob compare their ads, how do they know if two of them are the same? The first thing that comes to mind is to compare letter by letter. But that is fragile. A single extra space, a different line break, and the ad looks like another one.

The solution is to give each ad an identifier that comes from its own content. You run the text through a hash function (a fixed-length summary, like SHA-256) and that summary is its identifier.

For example, the ad:

ad: "Selling bike, reach me at Ana's node" id: 3f9a...c17

You can compute it with a simple terminal command:

echo -n "Selling bike, reach me at Ana's node" | sha256sum

And here is the good part. Two ads with the same content have the same identifier, always, on any node, without coordinating. And two different ads have different identifiers. The identifier is assigned by the content, not by some central authoritative node or anything like that.

This is called content addressing.

And that's not all. It has other useful properties:

Duplicate detection: if the same ad reaches Bob twice, along two different paths, both carry the same id. He keeps one and drops the other. Without thinking.
An order: a hash is really just a huge number. That 3f9a...c17 is in hexadecimal, but underneath it is a figure, so the ids can be sorted from smallest to largest.

And a sorted set will come in very handy for reconciliation.

Telling the neighbors

Let's go back to syncing, but thinking in terms of a network, not two lone nodes.

When someone pins an ad on Ana's node, the natural thing is for Ana to pass it to the nodes she knows. Those pass it to theirs. And so the ad spreads across the whole network, hopping from neighbor to neighbor, like a rumor. This technique is called flood-fill, flooding. Many peer-to-peer networks use it to spread information with no central node, but it has a design flaw: if the network grows a lot, the information can get stuck in a loop.

For example, Ana tells Bob, Bob tells Carla, Carla tells Ana again... and the ad goes around forever.

Here content addressing already saves us halfway: since the id is the same, when the ad comes back to Ana she recognizes it and does not resend it. But we can do better and not send things we know the other one already has.

The classic trick is to write down, next to each ad, which nodes it has already passed through. A "seen by" list. Before sending an ad to Carla, I check whether Carla is already in its "seen by" list. If she is, I save myself the trouble. It is exactly what FidoNet did in the eighties with its SEEN-BY field, and Usenet with the Path and Message-ID headers.

FidoNet is a network of BBSes from the 80s that synced in the middle of the night, when phone calls were cheap.

Another technique, complementary or alternative, is to have a hop limit. If an ad has passed through N nodes, I stop resending it. For example, the Meshtastic network uses a hop limit, recommended at 3, together with the "seen by" list.

Even so, flooding takes for granted something that is not realistic: that all nodes are connected and listening at the exact moment the ad goes by.

If you weren't there, you miss it

Flooding has a big flaw: it only works if you are listening at the right moment. What if your node was off when the rumor went by? Then you never find out. The ad passed by and nobody is going to offer it to you again.

We need something more robust. Instead of living in the stream, we need a reconciliation mechanism: when two nodes meet, they compare what they have and catch up. Whenever that happens, no matter how old their ads are, even if you have been offline for a month.

We are back to the first problem: how do we compare without sending each other the whole board?

Comparing summaries: the Merkle tree

Let's bring back the hash function that told us whether two ads are equal.

Instead of sending the ads, Ana and Bob send a summary of their ads. A single hash that represents all of their board. If both summaries match, they have exactly the same list. Done. That way only a single message is sent, one that says: "we have the same thing, nothing to do".

And if they don't match... the rock and roll begins.

The classic way to look without checking everything is a Merkle tree. You take your ads, group them, hash each group, then hash the hashes, and so on until you reach a single hash at the very top: the root. You compare roots. If they differ, you go down the branches whose hashes don't match, and ignore the ones that do. You corner the difference.

For example, suppose Ana and Bob have these ads:

Ana: {3, 8, 15, 16, 23, 42, 55, 60} Bob: {3, 8, 15, 16, 23, 42, 55, 99}

We group them in pairs, hash each group, then hash those hashes, and so on up to the root:

flowchart TD Root["ROOT = hash(Left, Right)"] --> L["Left = hash(A, B)"] Root --> R["Right = hash(C, D)"] L --> A["A = hash(3, 8)"] L --> B["B = hash(15, 16)"] R --> C["C = hash(23, 42)"] R --> D["D = hash(55, 60)"]

Ana and Bob have the same tree except at leaf D: Ana holds 60 and Bob holds 99. They agree like this:

They compare roots. Different, there is a difference somewhere.
They go down a level. The Left branch matches on both, so they prune it whole: half the list discarded in one shot.
The Right branch does not match. They keep going down. Inside, C matches and D does not.

In four comparisons they have cornered the difference down to group D, without looking at the rest of the board. Exactly what we wanted: compare summaries and go down only where things don't add up.

Fun fact for the nerds: this is what Cassandra or Amazon's Dynamo use to keep their replicas in check.

It is almost perfect. It just has 2 limitations:

The tree has a fixed shape. To compare level with level, both nodes must have chopped up their ads exactly the same way, into the same groups. You don't decide on the fly where to look, the structure is decided in advance.
The tree's leaves are fixed-size buckets. If a bucket doesn't match, they send you the whole bucket, even if only one ad inside it changed. The tree takes you to the box, not to the ad.

These are subtle limitations, but they can turn huge under heavy traffic.

Luckily, 2023 brought us a solution.

The evolution: range-based reconciliation

The idea is called range-based set reconciliation. You'll be surprised how simple and elegant it is.

To start with, there is no tree. It is 2 ideas working together: fingerprints and binary search.

First, a fingerprint is a hash that summarizes all the ads in a range. A range is a stretch of the sorted list, for example "all ads whose id runs from 3 to 60". If the fingerprint of a range matches on both nodes, that stretch is synced and there is no need to look inside.

The simplest way to compute the fingerprint is to take the ids of all the ads in the range and combine them with an operation that does not depend on order, like adding them up or XOR-ing them.

That has two advantages:

Two nodes with the same ads get the same fingerprint even if they store them in a different order.
It can be recomposed in chunks: the fingerprint of a big range comes from joining those of its halves, without recomputing anything.

In a real system you use something more robust than a sum, so that nobody can craft two different sets with the same fingerprint, but the idea is exactly that.

And second: if the fingerprints of a range don't match, I split the range in half and repeat on each half.

That's it. It is a binary search over the difference.

The whole algorithm fits in a handful of lines:

def reconcile(range): if my_fingerprint(range) == other_fingerprint(range): return # equal: nothing to do if few_items(range): exchange_ads(range) # cheap now: just send them return left, right = split(range) # split the range in half reconcile(left) # and repeat on each part reconcile(right)

Three cases and no more. If the fingerprints match, you stay quiet. If the range is already small, you send the ads directly. And if not, you split in half and go down each side. The recursion switches itself off on the branches that match and only digs where there are real differences.

Let's go with an example.

Remember that an ad's id is a hash, that is, a huge number, so sorting the ads by their id makes total sense. Here I draw them as small numbers so it reads easily. Ana's board and Bob's are almost identical, they only differ in the last one:

Ana: {3, 8, 15, 16, 23, 42, 55, 60} Bob: {3, 8, 15, 16, 23, 42, 55, 99}

Watch how they agree:

flowchart TD R["Whole board
Ana's fingerprint ≠ Bob's fingerprint"] --> L["Left half: {3,8,15,16}
fingerprints MATCH, we stop here"] R --> D["Right half: {23,42,55,...}
fingerprints differ, we keep going"] D --> DL["{23,42}
fingerprints MATCH, we stop"] D --> DR["{55, last}
fingerprints differ, we keep going"] DR --> DRL["{55}
MATCH"] DR --> DRR["{60} on Ana vs {99} on Bob
tiny range: the ads are exchanged"]

Ana sends a single fingerprint of her whole board. Bob compares it with his. They don't match, there is a difference.
They split in half. The left half, {3,8,15,16}, gives the same fingerprint on both. With a single comparison, half the list is discarded. Nothing more is looked at there.
The right half doesn't match. It is split again. {23,42} matches, out. The other chunk doesn't.
It keeps splitting until the range is so small that summarizing no longer pays off. Ana sends 60, Bob sends 99, and the two converge.

Count the messages, it's a handful of fingerprints and two ads! Instead of the eight lines of the dumb method.

With eight elements it is not impressive. But give it a million ads that differ in a single one. Range-based reconciliation finds it in about twenty comparisons, the logarithm of the size, instead of sending a million lines.

This holds as long as the differences are few. The more there are, the more branches you have to open. But you never pay for what you already have in common. It is very efficient.

Traffic stops depending on how big the board is and starts depending only on how much the two of them differ. We have already solved the syncing problem.

And look at everything we have gained over the Merkle tree:

	Merkle tree	Range-based reconciliation
Partition	Fixed, identical on both nodes	On the fly, where the differences are
Summaries	The tree, down to a certain depth	On the fly, only in the ranges you visit
What it ends up transferring	The whole bucket that doesn't match	The exact ad that differs
What they must share	The shape of the tree	Only the order of the elements

It is true that there are modern Merkle trees that dodge part of this: Merkle Search Trees and Prolly Trees. Their shape is derived from the content, so two replicas with the same ads reach the same tree no matter what order they received them in. They are great, and Bluesky actually uses them for its repositories. Still, they remain a tree you have to build and load. It is a design problem you can only ease, not remove.

For the record, reconciling sets over a network was not invented yesterday, there is work going back to the 2000s (Minsky and company). What the range-based approach that Aljoscha Meyer formalized (2022-2023) brings is a generic version, practical and easy to implement. And it is not chalkboard theory: the Willow protocol uses it to sync decentralized data, and Iroh brings it to Rust in its documents layer, iroh-docs, to sync devices directly. It is some of the most interesting work being built in syncing today.

Wait a second: I just reinvented FidoNet

Look back at what we have built. Many equal nodes. Each with its copy of the board. Ads identified by their content so they don't duplicate. A "seen by" field to avoid sending the same thing twice. Syncing every now and then to catch up.

That is FidoNet, literally. The BBS network that Tom Jennings started in 1984 did exactly this. They solved the decentralized board problem forty years ago, with modems and in the dark.

We have not invented anything new. We have polished something that was already good.

Prototyping the endpoints

Without writing the code, this is what the API would look like.

For people, to publish and read:

Method	Route	What it does
`POST`	`/ads`	Publish: you send the text, the node returns its `id`
`GET`	`/ads`	List the board
`GET`	`/ads/{id}`	Read a single ad

Publishing is sending the text and getting back the id the node computed:

POST /ads Content-Type: text/plain Selling bike, reach me at Ana's node

{ "id": "3f9a...c17" }

And reading an ad returns its text along with the id:

GET /ads/3f9a...c17

{ "id": "3f9a...c17", "text": "Selling bike, reach me at Ana's node" }

Between nodes, to sync:

Method	Route	What it does
`POST`	`/reconcile`	The core: you pass it a range and its fingerprint, and it answers whether it matches, whether it splits it, or whether it sends you its `id`s
`POST`	`/ads/fetch`	Ask for the bodies of the `id`s that reconciliation revealed are missing

To /reconcile you pass a range and its fingerprint:

{ "range": { "from": "0000", "to": "ffff" }, "fingerprint": "a3f1b2..." }

And it answers with one of the three cases from the pseudocode:

// 1. Match: nothing to do in this stretch { "status": "equal" } // 2. Small range: here are my ids, compare them yourself { "status": "ids", "ids": ["3f9a...c17", "8b21...0d4"] } // 3. They differ: I split it and give you each half's fingerprint { "status": "partition", "subranges": [ { "from": "0000", "to": "8000", "fingerprint": "11aa..." }, { "from": "8000", "to": "ffff", "fingerprint": "cc44..." } ]}

When reconciliation reveals which ids you are missing, you ask for their texts with /ads/fetch:

POST /ads/fetch Content-Type: application/json { "ids": ["8b21...0d4"] }

[ { "id": "8b21...0d4", "text": "Looking for a flat downtown" } ]

The node that syncs calls /reconcile in a loop, going down the subranges that differ (the three cases from the pseudocode above), and at the end asks with /ads/fetch only for the ads it didn't have. The hashes travel many times; the full text, only once and at the end.

A reply needs no route of its own: it is another POST /ads whose text carries inside it the id of the ad it answers.

This is Nostr, piece by piece

Without meaning to, we have almost built Nostr:

Every Nostr event is identified by the SHA-256 hash of its content. That is our content id, exactly.
It is published on relays: open servers where you write without signing up, just with a key pair. That is our HTTP endpoint with no accounts.
And to sync, the relays speak negentropy, which is nothing other than range-based reconciliation. The very same one we just derived by hand. Doug Hoyte wrote it for the strfry relay, and it lives in the spec as NIP-77.

So our BBS is practically Nostr. The one deep difference is that Nostr events are signed with the author's key, so there is an identity behind them. We dropped it to keep things simple.

Now we understand what is under the hood of Nostr and why it works.

The problems we haven't solved

Our BBS works, but it has holes:

There is no identity, so there are no culprits. We dropped login and sign-up to keep it simple, and a network where publishing is free and anonymous is a network that fills up with spam within hours.
We can't moderate without authority. On a single server, the admin deletes and that's that. Here there is no admin. If Ana flags an ad as garbage, why would Bob's node listen to her? And what if the one flagging garbage is the spammer, to bury everyone else? A mess.
Without identity, voting is useless. The temptation is to let people flag spam and have an algorithm sink it. But with no accounts, I fabricate a thousand fake identities and vote whatever I like. It is the famous Sybil attack.
It grows forever. If nobody can really delete, and everything is replicated on every node, the board only gets fatter.

None of these problems is about syncing, they are about trust.

Every decentralized system fights with this, and each one solves it in its own way.

Mastodon and the Fediverse trust the admin of each instance. Each server moderates its own: it deletes, suspends users and can defederate, that is, block another whole instance. Shared block lists circulate among admins. You pick an instance and inherit its judgment. It works, but moderation ends up fragmented, and moving instances is costly.
Bluesky flips it around with composable labels. Anyone can run a service that labels accounts and posts ("spam", "nsfw"), and each user subscribes to the labelers they trust. Your client hides or warns based on those labels. Moderation stops being a single truth and becomes a service you sign up for.
The reputation route, the closest to our account-less BBS, weights each vote by how much those who are already trusted trust you (EigenTrust-style algorithms). A freshly fabricated fake identity has nobody vouching for it, so its vote carries no weight. That is the trick to dodge the Sybil attack fairly well.

It is funny, because Bluesky does the same thing Usenet already did in the nineties with NoCeM: signed notices saying "this is spam" that each reader chose whether to apply or not.

Final notes

Syncing, which looked like the hard part, turned out to be a closed and even elegant problem. What has beaten us is trust: who you are, whether I believe you, how I kick out a spammer with no boss to press the button. Syncing is a maths problem. Trust is a political one.

So next time you hear about Nostr, about Willow, about Iroh or about "local-first", you won't see magic anymore. You'll see a bulletin board with an id that is a hash and two nodes comparing fingerprints. And that is the beautiful part of deriving something from scratch.

Sources

Range-Based Set Reconciliation, by Aljoscha Meyer. The work that generalizes and analyzes the technique. Dense, but it is the source.
3d Range-Based Set Reconciliation in the Willow protocol specification. The applied version, with fingerprints and recursive partitioning.
Range-Based Set Reconciliation at Log Periodic, a more digestible explanation of the same idea.
Iroh and Iroh-Docs, the Rust implementation that brings range-based reconciliation to real devices.
NIP-77: Negentropy Syncing, range-based reconciliation as Nostr uses it, with Doug Hoyte's strfry relay as the reference implementation.
Earthstar, a decentralized database with no traditional accounts that syncs by ranges, today on top of Willow.
FTS-0004 EchoMail Specification from the FTSC, where FidoNet's MSGID and SEEN-BY live.
FidoNet on Wikipedia, for the history of Tom Jennings' BBS network and its nightly sync model.
ActivityPub, the W3C recommendation. The inbox-delivery model that dispatches instead of reconciling.
Merkle tree and Apache Cassandra's anti-entropy, for the step before range-based reconciliation.
Composable Moderation on the Bluesky blog, the model of labelers you subscribe to.
The EigenTrust Algorithm for Reputation Management in P2P Networks, the transitive reputation that isolates the Sybil attack.
NoCeM, the signed spam notices on Usenet in the nineties, ancestor of composable labels.
Prolly Trees and Merkle Search Trees, variants of the Merkle tree whose shape is derived from the content and not from the insertion order.
Mastodon 4.5 for Developers, which enables fetching a thread's missing replies by default.

Help me keep writing Every coffee gives me a push toward the next article. Sure, it's on me!

Send an email to comment+article-4c4e1b40@andros.dev to leave a comment. The subject will be ignored.

htmx and Django LiveView, side by side

Sun, 30 Aug 2026 17:03:31 +0000

If you use htmx and are considering migrating to Django LiveView, this article is for you. It's not an exhaustive comparison, but a run-through of the most common cases and how each technology solves them. Don't read it as a LiveView tutorial, since it leaves many features out.

I'll assume you know htmx and Django, and that you know how to create views, templates and routes. If not, I recommend reading the documentation for each one before continuing.

Fundamental differences

Before looking at code, let's be clear: architecturally they are very different. They don't even use the same communication protocol.

Feature	htmx	Django LiveView
Protocol	HTTP/AJAX	WebSockets
Communication	Individual requests (GET, POST, etc.)	Persistent connection
State	Stateless	Stateful
Real-time updates	Partial, with polling	Yes
Infrastructure requirements	Minimal (HTTP server)	Moderate (Channels + Redis recommended)
Latency	Higher (each HTTP request)	Lower (persistent connection)
Broadcast support	No	Yes
Requires an API	Yes, views or REST API	No

In practical terms, htmx is simpler to set up and use for basic interactions. However, when you want to tackle complex tasks, the complexity rises sharply. Django LiveView, on the other hand, needs more initial setup, but once it's running the curve is practically flat. The logic behind sending a message to every connected client is trivial: it looks a lot like opening a modal.

Case 1: Update content with a click

The most basic example. A button that updates a div.

htmx

<!-- Template --> <div id="content">Initial content</div> <button hx-get="/update-content" hx-target="#content"> Update </button>

# views.py def update_content(request): return HttpResponse("<p>Updated content</p>")

# urls.py path('update-content/', update_content),

Django LiveView

<!-- Base template --> {% load static liveview %} <!DOCTYPE html> <html lang="en" data-room="{% liveview_room_uuid %}"> <head> <meta charset="UTF-8"> </head> <body data-controller="page"> <div id="content">{{ content }}</div> <button data-liveview-function="update_content" data-action="click->page#run"> Update </button> <script src="{% static 'liveview/liveview.min.js' %}" defer></script> </body> </html>

The data-room attribute generates a unique identifier per page load, and data-controller="page" activates the controller that listens for events. Both go in the base HTML; the rest of your templates no longer repeat them.

# handlers.py from liveview.decorators import liveview_handler from liveview.connections import send @liveview_handler("update_content") def update_content(consumer, content): send(consumer, { "target": "#content", "html": "<p>Updated content</p>", })

Notice how htmx needs a specific route, while LiveView handles everything over the WebSocket with a decorator. The handler doesn't return an HTTP response: it calls send() to push the HTML to the client, and it can call it as many times as it wants.

Case 2: Form with validation

A form that validates on the server without reloading the page.

htmx

<!-- Template --> <form hx-post="/validate-form" hx-target="#errors"> <input type="email" name="email"> <div id="errors"></div> <button type="submit">Submit</button> </form>

# views.py def validate_form(request): email = request.POST.get('email') if not email or '@' not in email: return HttpResponse('<p style="color:red;">Invalid email</p>') return HttpResponse('<p style="color:green;">Valid email</p>')

# urls.py path('validate-form/', validate_form),

Django LiveView

<!-- Template --> <form> <input type="email" name="email"> <div id="errors">{{ error_message }}</div> <button type="submit" data-liveview-function="validate_form" data-action="click->page#run">Submit</button> </form>

# handlers.py from liveview.decorators import liveview_handler from liveview.connections import send @liveview_handler("validate_form") def validate_form(consumer, content): email = content.get("form", {}).get("email", "") if not email or '@' not in email: error_html = '<p style="color:red;">Invalid email</p>' else: error_html = '<p style="color:green;">Valid email</p>' send(consumer, { "target": "#errors", "html": error_html, })

LiveView serializes the form closest to the button and hands it to you in content["form"], a dictionary keyed by each field's name. You don't need request.POST.

Case 3: Real-time search

Search that updates as you type.

htmx

<!-- Template --> <input type="text" name="query" hx-get="/search" hx-trigger="keyup changed delay:500ms" hx-target="#results"> <div id="results"></div>

# views.py def search(request): query = request.GET.get('query', '') results = Article.objects.filter(title__icontains=query)[:5] return render(request, 'search_results.html', {'results': results})

# urls.py path('search/', search),

The delay:500ms attribute prevents making a request on every keystroke.

Django LiveView

<!-- Template --> <input type="text" name="query" data-liveview-function="search" data-action="input->page#run" data-liveview-debounce="500"> <div id="results">{% include 'search_results.html' %}</div>

# handlers.py from django.template.loader import render_to_string from liveview.decorators import liveview_handler from liveview.connections import send from .models import Article @liveview_handler("search") def search(consumer, content): query = content.get("form", {}).get("query", "") results = Article.objects.filter(title__icontains=query)[:5] html = render_to_string('search_results.html', {'results': results}) send(consumer, { "target": "#results", "html": html, })

Here the trigger goes on the input itself (input->page#run). The data-liveview-debounce="500" attribute serves the same purpose as delay:500ms in htmx.

Case 4: Automatic update (polling)

Content that updates periodically.

htmx

<!-- Template --> <div hx-get="/stats" hx-trigger="every 2s" id="stats"> {{ stats }} </div>

# views.py def stats(request): active_users = get_active_users() return HttpResponse(f'<p>Active users: {active_users}</p>')

# urls.py path('stats/', stats),

Django LiveView

Django LiveView has no automatic client-side polling. The philosophy is different: the server broadcasts when something changes. If you really want a periodic pulse, you run it as its own process, not inside the web server:

# management/commands/broadcast_stats.py from time import sleep from asgiref.sync import async_to_sync from channels.layers import get_channel_layer from django.core.management.base import BaseCommand class Command(BaseCommand): help = "Send the number of active users to every client every 2 seconds" def handle(self, *args, **options): channel_layer = get_channel_layer() while True: sleep(2) active_users = get_active_users() html = f"<p>Active users: {active_users}</p>" # 'broadcast' is the group LiveView joins every client to; # 'broadcast_message' is the consumer handler. async_to_sync(channel_layer.group_send)( "broadcast", { "type": "broadcast_message", "message": {"target": "#stats", "html": html}, }, )

<!-- Template --> <div id="stats">{{ stats }}</div>

You start it as a standalone process (python manage.py broadcast_stats), managed by systemd or supervisor. Don't put it in a thread inside the ASGI server: with several workers you'd have one copy of the loop per worker, each broadcasting on its own. Even so, this approach is more powerful than polling: every client gets the update at the same time, without each one asking on its own.

Case 5: SPA navigation

Navigate without reloading the whole page.

htmx

<!-- Base template --> <nav hx-boost:inherited="true"> <a href="/about">About us</a> <a href="/contact">Contact</a> </nav> <div id="content"> <!-- Content --> </div>

# views.py def about(request): return render(request, 'about.html') def contact(request): return render(request, 'contact.html')

# urls.py path('about/', about), path('contact/', contact),

hx-boost turns normal links into AJAX requests. htmx intercepts the click, makes a GET request and replaces the <body> with the response content. Notice the :inherited suffix: in htmx 4 it's required for the <nav> attribute to apply to the child links. In htmx 2, hx-boost="true" was enough, because inheritance was automatic.

Django LiveView

<!-- Template --> <nav> <a href="#" data-liveview-function="load_about" data-action="click->page#run"> About us </a> <a href="#" data-liveview-function="load_contact" data-action="click->page#run"> Contact </a> </nav> <div id="content"> <!-- Content --> </div>

# handlers.py from django.template.loader import render_to_string from liveview.decorators import liveview_handler from liveview.connections import send @liveview_handler("load_about") def load_about(consumer, content): html = render_to_string('about.html') send(consumer, { "target": "#content", "html": html, }) @liveview_handler("load_contact") def load_contact(consumer, content): html = render_to_string('contact.html') send(consumer, { "target": "#content", "html": html, })

Case 6: Shared state between users

Multiple users viewing data in real time.

htmx

No support in the core. You have to fall back on Server-Sent Events (SSE) or WebSockets through extensions (htmx 4 adds the hx-live extension for this), which steps outside htmx's request/response model.

Django LiveView

# handlers.py from liveview.decorators import liveview_handler from liveview.connections import send @liveview_handler("add_message") def add_message(consumer, content): message_text = content.get("form", {}).get("message", "") # broadcast=True sends the message to every connected client send( consumer, { "target": "#messages", "html": f'<p>{message_text}</p>', "append": True, }, broadcast=True, )

<!-- Template --> <div id="messages"> <!-- Messages appear here --> </div> <form> <input type="text" name="message"> <button type="submit" data-liveview-function="add_message" data-action="click->page#run">Send</button> </form>

All connected users receive the message instantly.

Case 7: File handling

htmx

<form hx-post="/upload" hx-encoding="multipart/form-data" hx-target="#result"> <input type="file" name="file"> <button type="submit">Upload</button> </form> <div id="result"></div>

# views.py def upload(request): if request.method == 'POST': uploaded_file = request.FILES['file'] # Process file return HttpResponse(f'<p>File {uploaded_file.name} uploaded</p>')

# urls.py path('upload/', upload),

Django LiveView

<!-- Template --> <form enctype="multipart/form-data"> <input type="file" name="file"> <button type="submit" data-liveview-function="upload_file" data-action="click->page#run">Upload</button> </form> <div id="result"></div>

# handlers.py from liveview.decorators import liveview_handler from liveview.connections import send @liveview_handler("upload_file") def upload_file(consumer, content): uploaded_file = content.get("form", {}).get("file") if uploaded_file: # Process file send(consumer, { "target": "#result", "html": f'<p>File {uploaded_file} uploaded</p>', })

Here htmx has the edge: it uploads the file over HTTP with multipart/form-data with no tricks. Over a WebSocket, the file travels inside the JSON message, so for large files htmx's HTTP request is still the more comfortable option.

htmx already has WebSockets

Both can speak over WebSocket, but it doesn't mean the same thing when they do.

In htmx, HTTP is the default transport and the WebSocket is an extension you enable on a specific element (in htmx 4, the hx-live extension). You connect that part of the page to a socket, and the incoming messages carry HTML that htmx inserts. The rest of the application stays on HTTP. On top of that, you write the server consumer yourself: you define the message format, the rooms and the broadcasting.

In Django LiveView, the WebSocket is the transport for the whole page. Every interaction travels over it, not just the real-time bits. The framework manages the connection, the rooms, the broadcast and the reconnection; you only write handlers and call send(). That's why broadcasting to everyone is a single line (send(..., broadcast=True)) instead of wiring up a consumer by hand.

Feature	htmx + WebSocket extension	Django LiveView
Automatic connection and reconnection	✅	✅
Send events and update the DOM with HTML	✅	✅
Per-connection state on the server	❌	✅
Broadcast to all clients	🟡 you build it	✅ `broadcast=True`
Rooms or client groups	🟡 you build it	✅
History and URL with snapshots and scroll restoration	❌ (htmx's history is from its HTTP mode)	✅
Event debounce	✅	✅ `data-liveview-debounce`
Visibility triggers (scroll or intersection)	✅	✅ `data-liveview-intersect`
Keyboard shortcut maps	🟡 key filters	✅ `data-liveview-keyboard-map`
Focus management after a DOM update	🟡 `hx-preserve`	✅ `data-liveview-focus`

In short, in htmx the WebSocket is an add-on for specific parts of an app that stays on HTTP; in LiveView it's the backbone.

Final notes

You can keep SSR for some pages, htmx in some components and LiveView in others. One technology doesn't rule out the other. Both are complementary and aim for maximum simplicity within their paradigms.

That said, they're not interchangeable: you can't use htmx to update a component managed by LiveView, and vice versa. In the end, it's you who has to decide which one fits each case best. But whichever you pick, let it be because you have experience in different paradigms and not because you don't know the other option.

Happy Hacking!

Help me keep writing Every coffee gives me a push toward the next article. Sure, it's on me!

Send an email to comment+article-94d14a9e@andros.dev to leave a comment. The subject will be ignored.

Chess.com launched a poker site and is planning even more classic games

Sun, 30 Aug 2026 16:20:47 +0000

Chess.com has done one thing, and one thing very well, for almost 20 years, but now it's going beyond its domain name. The biggest name in online chess quietly launched its first companion site in beta back in May: Gambit, a free online poker website where players can learn the game without risking any real money. Now Gambit's ready to really get the ball rolling with its first livestreamed event and collaborations with content creators, and Chess.com is planning to branch out into even more games from here.

Chess.com's chief growth officer, Albert Cheng, told The Verge the company chose poker for its first companion site because, like ches …

Read the full story at The Verge.

Vicariously hike the Appalachian in the gorgeous A Trail Tale

Sun, 30 Aug 2026 16:20:47 +0000

Inspired by Oregon Trail, but minus the dysentery. | Screenshot: Terrence O’Brien / The Verge

I used to be an avid hiker and would try to go backpacking a few times a year. I always dreamed of thru-hiking the Appalachian Trail, but life kind of got in the way. (Turns out jobs, wives, and children aren't thrilled with the idea of you disappearing for three months.) But I've been longing to reconnect with my love of the outdoors and just recently took my kids on their first camping trip. So I discovered A Trail Tale at a really opportune time. It's an interactive trail journal created by Andy Moliski with help from his brothers Adam and Alex.

The various segments of the trail are rendered in beautiful pixel art reminiscent of a '90s S …

Read the full story at The Verge.

Weboldal indításának jogi feltételei 2026: Teljes ellenőrző lista kezdőknek

Sat, 29 Aug 2026 18:55:54 +0000

A weboldal indításának jogi feltételei 2026-ban már nem merülnek ki egy internetről letöltött sablon ÁSZF feltöltésében. Egyetlen apró technikai mulasztás vagy egy hiányzó online elállási nyilatkozat ma már azonnali fogyasztóvédelmi szankciókat és kötelező vételár-visszatérítést vonhat maga után. Tisztában vagyunk vele, hogy a bonyolult jogi bikkfanyelv és a világhálón keringő ellentmondásos információk miatt a kezdő vállalkozók gyakran bizonytalanok. Senki sem szeretné, ha az online jelenlét első hónapjait a NAIH vagy a hatóságok vizsgálatai és a súlyos bírságoktól való félelem árnyékolná be.

Ebből az útmutatóból pontosan megismerheted a magyarországi weboldal-indítás összes kötelező jogi elemét az ÁSZF-től a GDPR-ig, hogy elkerüld a büntetéseket és magabiztosan vágj bele a munkába. Nemcsak a kötelező dokumentumok tartalmát tisztázzuk, hanem segítünk a megbízható technikai alapok, például a GDPR-megfelelőséget egyszerűsítő hazai szerverpark és a biztonságos domain regisztráció kiválasztásában is. Végigvesszük a 2026-os legfrissebb szabályokat, az elállási jog új technikai követelményeit és az adattárolás kritikus kérdéseit, hogy te a növekedésre fókuszálhass a felesleges stressz helyett.

Ki indíthat weboldalt Magyarországon? Alapvető vállalkozási feltételek

Magyarországon bárki indíthat weboldalt, de a jogi kötelezettségek köre a tartalom céljától függ. Egy személyes blog, amely kizárólag hobbi célokat szolgál és nem tartalmaz hirdetéseket, nem igényel hivatalos vállalkozási formát. Amint azonban az oldalon bevételszerző tevékenység jelenik meg, a weboldal indításának jogi feltételei azonnal szigorodnak. Gazdasági tevékenységnek minősül minden olyan folyamat, ahol terméket adsz el, szolgáltatást nyújtasz, vagy reklámfelületeket (például Google AdSense) és affiliate linkeket használsz.

A weboldal üzemeltetője jogilag lehet egyéni vállalkozó (EV), gazdasági társaság (például Kft. vagy Bt.), vagy bizonyos esetekben adószámos magánszemély. Az online kereskedelemhez elengedhetetlen a megfelelő tevékenységi körök bejelentése. Webáruház üzemeltetéséhez a 4791 - Csomagküldő, internetes kiskereskedelem TEÁOR szám felvétele kötelező. Ez a kód teszi lehetővé a számlaképességet, ami az online értékesítés alapköve. A technikai regisztráció során, például a .hu domain regisztráció folyamatában, a tulajdonosi adatoknak pontosan egyezniük kell a hivatalos vállalkozási adatokkal.

Magánszemélyként indított weboldalak jogi korlátai

Magánszemélyként akkor indíthatsz oldalt vállalkozói igazolvány nélkül, ha a tevékenységed nem rendszeres és nem profitorientált. Fontos tudni, hogy a bevételszerzés legkisebb formája is adózási kötelezettséget von maga után. Ha hirdetéseket helyezel el az oldalon, már nem tekinthető tiszta hobbioldalnak, és az Általános adatvédelmi rendelet (GDPR) szabályai is szigorúbban vonatkoznak rád. Magánszemélyként az adózás bonyolultabb lehet, mert az önálló tevékenységből származó jövedelem után negyedévente adóelőleget kell fizetni a NAV felé.

Bejelentési kötelezettségek a jegyző és a NAV felé

2026-ban a kereskedelmi tevékenység megkezdését a székhely szerint illetékes jegyzőnél kell bejelenteni. Ez a folyamat ma már elektronikusan zajlik, de a bejelentés elmulasztása komoly bírságot vonhat maga után. Bizonyos termékkörök, például gyógyszerek vagy veszélyes anyagok értékesítése külön hatósági engedélyhez kötött. A távolsági értékesítés speciális szabályai előírják, hogy a NAV felé is jelezni kell az online csatornán történő eladást. A hatóságok 2026-ban kiemelt figyelmet fordítanak arra, hogy a weboldalon feltüntetett üzemeltetői adatok és a bejelentett tevékenységek teljes összhangban legyenek.

A jogszerű működés nemcsak a bürokráciáról szól, hanem a hitelességről is. A technikai háttér kiválasztásakor érdemes olyan hazai szolgáltatót választani, amelynek infrastruktúrája támogatja a magyar jogszabályoknak való megfelelést. A magyarországi szerverpark használata például jelentősen egyszerűsíti az adatkezelési tájékoztató elkészítését, mivel az adatok az országon belül maradnak.

Kötelező tartalmi elemek: Az Impresszum és az ÁSZF követelményei

A weboldal indításának jogi feltételei Magyarországon alapvetően az elektronikus kereskedelmi szolgáltatásokról szóló törvényen (Ekertv.) alapulnak. Sokan hiszik, hogy csak a webshopoknak vannak kötelezettségeik, de az igazság az, hogy minden gazdasági célú honlapnak rendelkeznie kell bizonyos alapvető dokumentumokkal. Ezek hiánya nemcsak bizalmatlanságot szül, hanem közvetlen utat jelent a hatósági ellenőrzésekhez. A Nemzeti Adatvédelmi és Információszabadság Hatóság (NAIH) és a fogyasztóvédelem 2026-ban még szigorúbban ellenőrzi a kötelező tájékoztatási elemek meglétét és azok frissességét.

Az Impresszum kötelező elemei pontról pontra

Az Impresszum a weboldal “személyi igazolványa”. Ez a dokumentum teszi lehetővé, hogy a látogatók és a hatóságok azonosíthassák az üzemeltetőt. A törvényi előírások szerint az alábbi adatokat kötelező jól látható módon közzétenni:

A szolgáltató hivatalos neve és székhelye.
Elérhetőségek: működő e-mail cím és telefonszám.
Adószám és cégjegyzékszám (vagy egyéni vállalkozói nyilvántartási szám).
A nyilvántartásba vevő hatóság megnevezése.
A tárhelyszolgáltató neve, székhelye és elérhetősége.

Kiemelten fontos, hogy a tárhelyszolgáltató pontos adatait is feltüntesd. Nem elegendő csak a nevet kiírni; a jogszabály a fizikai címet és a kapcsolatfelvételi adatokat is megköveteli. Ha a technikai hátteret egy megbízható partner biztosítja, az adatok feltüntetése a jogi megfelelőség mellett a szakmai stabilitást is jelzi. Érdemes már az induláskor olyan biztonságos webtárhely szolgáltatást választani, amely minden szükséges adatot transzparensen rendelkezésre bocsát az impresszumodhoz.

ÁSZF webshopoknak: A leggyakoribb hibák, amikért bírság jár

Az Általános Szerződési Feltételek (ÁSZF) szabályozzák a vásárló és a kereskedő közötti jogviszonyt. 2026-ban több jelentős változás lépett életbe. Január 1-jétől az ÁSZF-nek kötelezően tartalmaznia kell a termék értékcsökkenéséért való felelősség szabályait elállás esetén. Ha ez hiányzik, a webshop nem követelhet kártérítést a használtan visszaküldött termékek után. Június 19-től pedig kötelező egy folyamatosan elérhető online elállási űrlap biztosítása, amely automatikus visszaigazolást küld a vásárlónak.

A jótállási szabályok is szigorodtak: március 1-jétől bármilyen típusú jótállási igényt legfeljebb 30 napon belül le kell zárni. Ha a javítás ezen belül nem készül el, kötelező a csere vagy a vételár visszatérítése. Az online vitarendezési (ODR) platform linkjét viszont már nem kell szerepeltetni, mivel ez a rendszer 2025 júliusában megszűnt. A panaszkezelési módok leírása és a 14 napos elállási jog pontos, mintatájékoztatóval kiegészített megfogalmazása továbbra is a weboldal indításának jogi feltételei közé tartozik, aminek elhanyagolása súlyos büntetéseket vonhat maga után.

GDPR és adatvédelem: A látogatók adatainak biztonságos kezelése

Az adatvédelem 2026-ban már nem csupán egy kötelezően kipipálandó dokumentumot jelent, hanem a technikai és jogi megoldások szoros egységét. A weboldal indításának jogi feltételei közül az egyik legkritikusabb pont a felhasználói adatok átlátható kezelése. Nem elegendő egy általános tájékoztatót közzétenni; az adatkezelés célját, jogalapját és pontos időtartamát minden folyamatnál (például vásárlás, hírlevél, kapcsolatfelvétel) külön kell nevesíteni. A weboldal üzemeltetés jogi feltételei szempontjából alapvető elvárás, hogy a látogató pontosan tudja, mi történik az adataival a rögzítéstől a törlésig.

A technikai megfelelőség ott kezdődik, hogy hol tárolod ezeket az adatokat. Egy magyarországi szerverparkkal rendelkező szolgáltató, mint az aWh, használata jelentős előnyt jelent a GDPR-megfelelőségben, mivel az adatok nem hagyják el az Európai Unió területét. A tárhelyszolgáltatóval kötött írásos adatfeldolgozói szerződés megléte elengedhetetlen. Emellett a biztonságos adatátvitelhez elengedhetetlen egy érvényes SSL tanúsítvány, amely titkosítja a felhasználó és a szerver közötti kommunikációt.

Mikor válsz adatkezelővé? (Már egy kapcsolatfelvételi űrlap is számít!)

Sokan tévesen azt hiszik, hogy csak a webshopok számítanak adatkezelőnek. Valójában amint a weboldalad rögzíti a látogató IP címét, vagy lehetőséget ad egy e-mail cím megadására, te már adatkezelővé válsz. A személyes adatok köre széles: a név és a telefonszám mellett az online azonosítók is ide tartoznak. Az Európai Adatvédelmi Testület (EDPB) 2026. július 7-én kiadott 02/2026-os iránymutatása szerint az adatok anonimizálása is adatkezelési műveletnek minősül, amelyhez jogalap szükséges. Ez azt jelenti, hogy ha a jövőben statisztikai célból anonimizálni tervezed a felhasználói adatokat, erről már az eredeti tájékoztatóban informálnod kell az érintetteket.

Sütik és nyomkövetők: A 2026-os megfelelőségi szintek

A sütikezelés (Cookie Consent) terén 2026-ban a “privacy by design” elv dominál. A cookie banner nem takarhatja el a teljes tartalmat, és nem kényszerítheti a felhasználót az elfogadásra. Az érvényes hozzájárulás feltételei:

Aktív hozzájárulás: Nincs előre beikszelt négyzet vagy automatikus elfogadás görgetésre.
Egyenrangú választás: Az “Elutasítás” gombnak ugyanolyan könnyen elérhetőnek és láthatónak kell lennie, mint az “Elfogadás” gombnak.
Kategóriák szerinti bontás: A statisztikai és marketing sütikhez külön-külön kell engedélyt kérni.
Naplózás: A hozzájárulásokat technikai szinten naplózni kell, hogy egy esetleges NAIH ellenőrzés során bizonyítható legyen a jogkövető magatartás.

A hírlevél feliratkozásnál továbbra is a kettős megerősítés (double opt-in) a legbiztonságosabb módszer. Ez garantálja, hogy a felhasználó valóban saját szándékából adta meg az adatait. A direkt marketing célú megkeresésekhez minden esetben külön, kifejezett és önkéntes hozzájárulás szükséges, amelyet bármikor, egyetlen kattintással vissza kell tudni vonni.

Technikai feltételek jogi szemmel: Domain, SSL és tárhely

A weboldal elindítása nem csupán szoftveres és dizájnkérdés. A technikai infrastruktúra minden eleme, a választott névtől az adatok tárolásának fizikai helyéig, konkrét jogi felelősséget von maga után. A weboldal indításának jogi feltételei szorosan összefonódnak a technikai alapokkal. Egy rosszul megválasztott domain név védjegybitorlási perhez vezethet, a titkosítatlan adatátvitel pedig súlyos adatvédelmi bírságot vonhat maga után a hatóságok részéről.

A felelősség megoszlik közted és a szolgáltató között. A tárhelyszolgáltató felel az infrastruktúra fizikai védelméért és a szerveroldali biztonságért. Ugyanakkor az alkalmazott szoftverek, például a WordPress vagy egy egyedi fejlesztésű webshop frissítése és biztonsági beállítása már a te feladatod. A jogi megfelelőséghez mindkét félnek precízen kell teljesítenie a saját területén, hiszen a technikai mulasztás jogi következményei téged terhelnek.

Domain regisztráció és márkavédelem

A névválasztás az első jogi csapda az indulás során. Sokan elkövetik azt a hibát, hogy olyan nevet regisztrálnak, amely hasonlít egy már létező márkára vagy bejegyzett védjegyre. Magyarországon a .hu domainek esetében a Domainregisztrációs Szabályzat az irányadó dokumentum. Vitás esetekben a Domaindöntőnök határoz, ami akár a név kényszerű és azonnali átadását is jelentheti a jogos tulajdonosnak. Érdemes alaposan tájékozódni a Domain név regisztráció útmutató segítségével, mielőtt véglegesítenéd a döntést. A védjegykutatás elengedhetetlen lépés, hogy elkerüld a más szellemi tulajdonát sértő elnevezéseket.

HTTPS és titkosítás: Az adatvédelem alapköve

A HTTPS protokoll használata 2026-ban már nem opcionális kényelmi funkció. Az SSL tanúsítvány biztosítja, hogy a látogatók által megadott adatok titkosítva jussanak el a felhasználótól a szerverre. A modern böngészők ma már “nem biztonságos” jelzéssel látják el a tanúsítvány nélküli oldalakat, ami nemcsak a felhasználói bizalmat rombolja, hanem jogi kockázatot is rejt. A személyes adatok védelmének elhanyagolása közvetlen alapot ad a NAIH bírságához. Az aWh felületén az SSL aktiválása néhány kattintással elvégezhető, így ez a jogi akadály gyorsan elhárítható.

A tárhelyszolgáltató kiválasztása kritikus pont a GDPR szempontjából is. Ha magyarországi szerverparkkal rendelkező szolgáltatót választasz, az adatok az Európai Unión belül maradnak. Ez jelentősen egyszerűsíti az adatfeldolgozói láncot és a jogi megfelelőséget. Az aWh több mint 10 éves tapasztalata és hazai infrastruktúrája garanciát jelent arra, hogy a technikai háttér megfelel a magyar és uniós elvárásoknak. Ha biztosra akarsz menni a technikai alapokkal, válassz egy megbízható magyar tárhelyszolgáltatót, aki érti a hazai szabályozási környezetet.

Weboldal indítási checklist 2026: Lépésről lépésre a jogtisztaságig

A weboldal indításának jogi feltételei 2026-ban egy strukturált folyamatot követelnek meg a tulajdonostól. A jogszabályi megfelelőség nem csupán a büntetések elkerülése miatt fontos; ez az alapja a vásárlói bizalomnak és a hosszú távú üzleti stabilitásnak is. Az alábbi ellenőrző lista segít abban, hogy egyetlen kritikus lépés se maradjon ki az indulás előtti lázas munkában. Haladj végig a pontokon, és győződj meg róla, hogy minden jogi és technikai pillér szilárdan áll.

Vállalkozási háttér: Ellenőrizd, hogy a vállalkozási formád alkalmas-e online értékesítésre, és a 4791-es TEÁOR szám szerepel-e a tevékenységi köreid között.
Domain és védelem: Végezz védjegykutatást a választott névvel kapcsolatban, és aktiváld az SSL tanúsítványt a biztonságos adatkapcsolathoz.
Jogi dokumentáció: Készítsd el a 2026-os szabályoknak megfelelő ÁSZF-et (különös tekintettel az értékcsökkenési és jótállási szabályokra), az Impresszumot és a GDPR tájékoztatót.
Hozzájáruláskezelés: Állítsd be a sütikezelő (Cookie Consent) rendszert, amely lehetővé teszi a látogatóknak a granuláris választást és a döntések naplózását.
Adatfeldolgozói lánc: Kérd be és archiváld a tárhelyszolgáltatódtól az adatfeldolgozói nyilatkozatot a jogszerű adatkezelés igazolásához.

A technikai alapok biztosítása

A jogi megfelelőség technikai stabilitást igényel. Első lépésként válaszd ki a céljaidnak leginkább megfelelő webtárhely csomagot, amely garantálja a magyarországi adatkezelést. A regisztráció során ügyelj arra, hogy a domain tulajdonosi adatai megegyezzenek a vállalkozásod hivatalos adataival. Az aWh több mint 10 éves piaci tapasztalata és a modern hardveres infrastruktúra biztosítja azt a technológiai hátteret, amelyre a jogtisztaság épülhet. Ellenőrizd a szolgáltatási szintet (SLA) is, hiszen a weboldal folyamatos elérhetősége a fogyasztóvédelmi tájékoztatási kötelezettséged része.

Utolsó ellenőrzés az élesítés előtt

Mielőtt nyilvánossá tennéd az oldalt, végezz el egy alapos tesztelést. Győződj meg róla, hogy az Impresszum, az ÁSZF és a GDPR linkje minden aloldal láblécéből közvetlenül elérhető. Webshop üzemeltetése esetén teszteld a vásárlási folyamatot: megérkezik a jogszabályban előírt automatikus visszaigazolás? Tartalmazza a levél a szükséges tájékoztatókat? 2026-ban a hatóságok kiemelten figyelik az automatizált folyamatok jogi pontosságát. Végezetül készíts egy teljes biztonsági mentést a weboldal induló, jogtiszta állapotáról, hogy bármilyen későbbi módosítás esetén legyen egy stabil viszonyítási pontod. A weboldal indításának jogi feltételei így nem akadályt, hanem biztonságos keretet jelentenek majd a vállalkozásodnak.

Építs biztos alapokra és indítsd el weboldalad magabiztosan!

A weboldal indításának jogi feltételei 2026-ban szigorúbbak, mint valaha, de a megfelelő felkészüléssel ezek az előírások nem akadályt, hanem komoly versenyelőnyt jelentenek. A legfontosabb tanulság, hogy a jogi megfelelőség nem ér véget a dokumentumok elkészítésénél. A technikai háttér, mint az SSL titkosítás és a szerverek fizikai helye, ugyanilyen súllyal esik latba. Ha az indulásnál a precizitást és az átláthatóságot választod, nemcsak a bírságokat kerülöd el, hanem a látogatóid bizalmát is elnyered.

Ne hagyd, hogy a bürokrácia elvegye a kedved a vállalkozástól. A technikai pillérek stabilizálásával a jogi folyamatok nagy része automatikusan egyszerűbbé válik. Mi az aWh-nál több mint 10 éves tapasztalattal segítünk a technikai megfelelőségben. Szolgáltatásainkkal 100% GDPR megfelelőség támogatást kapsz, minden csomagunkhoz ingyenes SSL tanúsítványt biztosítunk, és bármilyen kérdés esetén magyar nyelvű ügyfélszolgálatunk áll rendelkezésedre.

Indítsd el jogtiszta weboldaladat megbízható aWh tárhelyen!

A jogszabályok ismerete és a megbízható partner kiválasztása a legjobb befektetés a jövőbe. Sok sikert kívánunk az online jelenléted felépítéséhez!

Gyakran Ismételt Kérdések

Kötelező-e az ÁSZF, ha nem adok el semmit a weboldalamon?

Nem, az Általános Szerződési Feltételek (ÁSZF) csak akkor kötelező eleme a honlapnak, ha szerződés jön létre a felek között, például egy webáruház esetében. Ugyanakkor az Impresszum és az Adatkezelési tájékoztató megléte minden gazdasági célú oldalon elvárás, függetlenül attól, hogy történik-e közvetlen eladás. Ha az oldalad csak bemutatkozó jellegű, elegendő ezeket a dokumentumokat elkészítened a weboldal indításának jogi feltételei szerint, hogy elkerüld a hatósági figyelmeztetéseket.

Büntethetnek-e, ha nincs SSL tanúsítvány a weboldalamon?

Igen, a hatóságok az SSL tanúsítvány hiányát súlyos adatbiztonsági mulasztásként értékelhetik, különösen ha az oldalon bármilyen űrlap vagy bejelentkezési felület található. A GDPR előírja a személyes adatok védelmét a továbbítás során is, amit a HTTPS protokoll biztosít. A titkosítatlan kapcsolat közvetlen kockázatot jelent a látogatók adataira nézve, ami elegendő alap a NAIH számára egy komolyabb pénzbírság kiszabásához és az adatkezelési folyamatok felfüggesztéséhez.

Használhatok-e sablon ÁSZF-et az internetről?

A sablonok használata rendkívül kockázatos, mivel a 2026-os szabálymódosításokat, például az online elállási űrlap technikai követelményeit, a régi internetes minták nem tartalmazzák pontosan. Minden üzleti modell egyedi folyamatokat igényel, így egy általános sablon soha nem nyújt teljes jogi védelmet. Érdemesebb szakjogász segítségét kérni, hogy a dokumentum minden aktuális fogyasztóvédelmi és adatvédelmi előírásnak megfeleljen, elkerülve a későbbi kellemetlen szankciókat és a fogyasztóvédelmi bírságokat.

Milyen adatokat kell feltüntetnem az impresszumban egyéni vállalkozóként?

Egyéni vállalkozóként az impresszumban fel kell tüntetned a teljes polgári nevedet, a székhelyed pontos címét, az adószámodat és az egyéni vállalkozói nyilvántartási számodat. Kötelező elem még a működő e-mail cím és egy telefonszám is a közvetlen hatósági kapcsolatfelvételhez. Ne feledkezz meg a tárhelyszolgáltatód, például az aWh nevének, székhelyének és elérhetőségének rögzítéséről sem, mert ennek hiányát a fogyasztóvédelem gyakran szankcionálja az ellenőrzések során.

Szükséges-e a weboldal indítását külön bejelenteni a jegyzőnél?

Igen, amennyiben a weboldalon kereskedelmi tevékenységet, például webáruházat indítasz, azt be kell jelentened a székhelyed szerint illetékes jegyzőnél. Ez a bejelentés a távollévők között kötött szerződések alapfeltétele, és ma már kényelmesen, elektronikus úton is intézhető a megfelelő nyomtatványokon. A bejelentés elmulasztása esetén a hatóság megtilthatja a termékek értékesítését, és súlyos mulasztási bírságot szabhat ki a vállalkozásra a szabálytalanság megszüntetéséig és a regisztráció pótlásáig.

Mi történik, ha nem felel meg a weboldalam a GDPR szabályainak?

Ha a weboldalad nem felel meg a GDPR szabályainak, a NAIH figyelmeztetést adhat ki, vagy súlyos pénzbírságot szabhat ki a mulasztás mértékétől függően. A hatóság elrendelheti az adatok törlését vagy az adatkezelési műveletek ideiglenes felfüggesztését is. A pénzügyi veszteség mellett a vállalkozás hírneve is sérül, hiszen a látogatók bizalma megrendül a nem biztonságosnak ítélt platformmal szemben, ami hosszú távú bevételkiesést okozhat a piacon.

Kell-e külön adatvédelmi tisztviselőt (DPO) kineveznem?

A legtöbb kis- és középvállalkozás számára nem kötelező adatvédelmi tisztviselőt kinevezni a weboldal üzemeltetéséhez. Erre csak abban az esetben van szükség, ha a fő tevékenységed az érintettek nagymértékű, szisztematikus megfigyelése vagy különleges adatok, például egészségügyi információk tömeges kezelése. Egy átlagos webshop vagy üzleti bemutatkozó oldal üzemeltetéséhez elegendő, ha a belső folyamataidat a GDPR alapelvei szerint alakítod ki, és rendelkezel a törvény által előírt tájékoztatókkal.

Hogyan igazolhatom a tárhelyszolgáltatóm GDPR megfelelőségét?

A legegyszerűbben egy írásos adatfeldolgozói szerződéssel igazolhatod a megfelelőséget, amelyet a szolgáltatónak kérésre biztosítania kell számodra. Fontos szempont a szerverek fizikai helyszíne is: a magyarországi szerverpark használata jelentősen megkönnyíti a bizonyítást egy esetleges hatósági ellenőrzés során. Az aWh több mint 10 éves piaci tapasztalata és hazai infrastruktúrája garanciát nyújt arra, hogy a technikai háttér mindenben megfelel az európai adatvédelmi elvárásoknak.

Hogyan tehető golyóállóvá a tárhely fiók biztonsága? Útmutató a védelemhez - aWh

Sat, 29 Aug 2026 18:55:54 +0000

Tudta, hogy 2025 első felében Magyarország volt a 17. leginkább célba vett ország az európai kibertámadások listáján? Ez a statisztikai adat rávilágít arra, hogy a tárhely fiók biztonság nem csupán egy választható extra, hanem az üzleti folytonosság és az adatvédelem alapvető tartóoszlopa.

Teljesen érthető, ha tart a weboldala váratlan leállásától vagy a technikai bizonytalanságtól, amit a bonyolult cPanel beállítások okozhatnak. Az emailben érkező adathalász kísérletek és a kéretlen spamek elleni küzdelem ma már minden vállalkozó mindennapjainak része, a tét pedig a bizalmas üzleti adatok és a digitális hitelesség megőrzése.

Ebből az útmutatóból pontosan megtudhatja, hogyan építhet ki többszintű védelmet tárhely fiókja és levelezése köré a legmodernebb biztonsági protokollok alkalmazásával. Segítünk minimalizálni a feltörés kockázatát, hogy üzleti adatait végre teljes biztonságban tudhassa.

Végigvesszük a legfontosabb konfigurációs lépéseket, a kétlépcsős azonosítás előnyeit és a professzionális email szolgáltató kiválasztásának szempontjait, hogy digitális infrastruktúrája valóban golyóálló legyen.

Miért a tárhely fiók biztonsága a digitális jelenléted alapja?

A tárhely fiók nem csupán egy távoli tárolóhely a fájlok számára. Ez a digitális ökoszisztéma központi irányítója, ahol a weboldal forráskódja, az adatbázisok és a teljes üzleti levelezés összefut. Ha ez a központ sérül, a teljes online jelenlét kártyavárként omolhat össze. A tárhely fiók biztonság elhanyagolása olyan kockázat, amely közvetlen hatással van a napi bevételre és az ügyfelek bizalmára.

Egy sikeres feltörés következményei messze túlmutatnak a technikai kellemetlenségeken. Az adatvesztés mellett megnyílhat az út a zsarolóvírusok előtt, amelyek titkosítják az állományokat, és váltságdíjat követelnek a helyreállításért. A márka hírnevének sérülése pedig gyakran helyrehozhatatlan; a látogatók nehezen bízzák rá adataikat egy olyan felületre, amely korábban kártékony kódot terjesztett.

A biztonság hiánya a keresőoptimalizálási eredményeket is tönkreteszi. A Google algoritmusai azonnal észlelik, ha egy oldal feltört állapotba kerül. Ilyenkor a keresőmotor “nem biztonságos” jelzéssel látja el a találatot, vagy drasztikusabb esetben teljesen eltávolítja a webhelyet az indexéből. A professzionális web hosting security alapfeltétele annak, hogy a SEO erőfeszítések és a hirdetési költségek ne vesszenek kárba.

A tárhely fiók biztonság fenntartása érdekében fontos tisztázni a közös felelősség elvét. Míg a szolgáltató a hardveres infrastruktúrát, a hálózat védelmét és a szerveroldali tűzfalakat garantálja, a felhasználó feladata a hozzáférési adatok védelme és a tárhelyen futó alkalmazások naprakészen tartása.

A leggyakoribb támadási formák 2026-ban

2026-ban a támadások skálázódása és az automatizált megoldások terjedése jelenti a legnagyobb fenyegetést. A brute force támadások során robotok ezrei próbálnak másodpercenként belépni a fiókba, kihasználva a gyenge jelszavakat és a hiányzó kétlépcsős azonosítást. Az adathalászat (phishing) szintén kifinomultabbá vált, gyakran a tárhelyszolgáltató nevében érkező, megtévesztően hiteles emailekkel próbálják kicsalni a belépési kódokat. Emellett a szerveroldali sebezhetőségek, például az elavult PHP verziók használata, továbbra is kritikus belépési pontot kínálnak a támadók számára.

A megbízható magyar hosting előnyei

Egy hazai szolgáltató választása jelentős biztonsági és operatív előnyökkel jár. Incidens esetén a magyar nyelvű, szakértő ügyfélszolgálat gyorsabb reakcióidőt és hatékonyabb problémamegoldást tesz lehetővé, ami kritikus az adatmentés és a helyreállítás során. A jogszabályi megfelelőség, különösen a GDPR előírásai, sokkal átláthatóbban érvényesíthetők, ha az adatok hazai szerverparkokban pihennek. Ha még csak most ismerkedsz a technikai háttérrel, érdemes elolvasni a Webtárhely: A Teljes Útmutató Kezdőknek 2026-ban című írásunkat a biztos alapok lefektetéséhez.

A hozzáférés védelme: Így zárd le a digitális kapukat

A hozzáférés-kezelés az első és legfontosabb védelmi vonal, amikor a tárhely fiók biztonság a tét. 2026-ban egy egyszerű jelszó már nem jelent valódi akadályt a kifinomult feltörő algoritmusok számára. Az ideális jelszó ma már legalább 16 karakterből áll, kis- és nagybetűk, számok, valamint speciális karakterek véletlenszerű kombinációja. Sokan elkövetik azt a hibát, hogy ugyanazt a kódot használják több felületen is. Ez óriási kockázat: ha egy kevésbé védett webshopból kiszivárognak az adatai, a támadók azonnal megpróbálják majd ugyanezt a belépést a tárhelyén is.

A jelszókezelő szoftverek, mint például a Bitwarden vagy a 1Password, használata ma már elengedhetetlen. Ezek az eszközök nemcsak tárolják, hanem generálják is a komplex karaktersorozatokat, így önnek nem kell tucatnyi bonyolult kódot megjegyeznie. A web hosting best security practices követése során az egyik legfontosabb lépés az emberi tényező, vagyis a gyenge jelszavak választásának kiiktatása a folyamatból.

Kétfaktoros azonosítás (2FA) beállítása cPanelen

A kétfaktoros azonosítás (2FA) jelenleg a leghatékonyabb eszköz az illetéktelen belépések megakadályozására. Még ha egy támadó meg is szerzi a jelszavát, a telefonjára érkező egyedi kód nélkül nem tud bejelentkezni a rendszerbe. A beállítás folyamata gyors és egyszerű:

Lépjen be a cPanel felületére, és a “Security” (Biztonság) részben keresse a “Two-Factor Authentication” menüpontot.
Telepítsen egy hitelesítő alkalmazást a telefonjára (például Google Authenticator vagy Authy), és olvassa be a képernyőn megjelenő QR-kódot.
A rendszer generál néhány egyszer használatos biztonsági kódot. Ezeket mindenképpen mentse el egy offline, biztonságos helyre, mert ezekre lesz szüksége, ha elveszítené a telefonját vagy nem férne hozzá az applikációhoz.

IP-alapú korlátozás és biztonságos kapcsolat

Ha fix IP-címmel rendelkezik, tovább szigoríthatja a belépési szabályokat. A cPanel lehetővé teszi, hogy a hozzáférést csak meghatározott IP-címekre korlátozza. Ez azt jelenti, hogy még érvényes jelszó és 2FA kód birtokában sem lehet belépni a fiókba egy ismeretlen hálózatról vagy országból. Ez a módszer drasztikusan csökkenti a távoli, automatizált támadások sikerességét.

A technikai védelem másik pillére a titkosított kommunikáció. Megfelelő SSL tanúsítványok nélkül a böngésző és a szerver közötti adatforgalom, beleértve a belépési adatokat is, nyílt szövegként utazik a hálózaton, ami könnyen lehallgatható. A tárhely fiók biztonság alapkövetelménye, hogy minden adatforgalom titkosított csatornán zajoljon. Ha maximális védelmet szeretne üzleti adatainak, válasszon professzionális cPanel tárhely megoldásaink közül, ahol a biztonsági funkciók alapértelmezettek.

Biztonságos email szolgáltató és a levelezés védelme

Az üzleti levelezés védelme elválaszthatatlan a tárhely fiók biztonság kérdésétől. Az email fiók gyakran a leggyengébb láncszem a védelmi láncban. Ha egy támadó hozzáfér a levelezéséhez, könnyedén kezdeményezhet jelszó-visszaállítást a tárhelyhez vagy más kritikus üzleti szolgáltatásokhoz. Egy valóban biztonságos email szolgáltató nemcsak tárolja az üzeneteket, hanem aktív védelmi réteget képez a teljes forgalom felett.

A technikai védelem alapkövetelménye a titkosított kapcsolat használata minden csatornán. Az IMAPS, POP3S és SMTPS protokollok garantálják, hogy az adatok a küldő eszköze és a szerver között ne legyenek lehallgathatók. Ez a titkosítás megvédi a belépési kódokat és az üzenetek tartalmát a közbeékelődéses támadásoktól. Emellett a szerveroldali, automatizált spamszűrés és vírusvédelem már azelőtt semlegesíti a fenyegetéseket, hogy azok elérnék a felhasználó postafiókját.

A dedikált email tárhely használata jelentős előnyt kínál a biztonság és a reputáció terén is. Míg az ingyenes vagy alacsony minőségű szolgáltatók szerverei gyakran kerülnek globális tiltólistára a rajtuk keresztül zajló spamtevékenység miatt, a professzionális megoldások tiszta IP-címeket és szigorú felügyeletet garantálnak. Ez biztosítja, hogy az ön levelei ne a partnerek levélszemét mappájában kössenek ki, megőrizve az üzleti kommunikáció hitelességét.

Email hitelesítési protokollok: SPF, DKIM, DMARC

A hitelesség megőrzéséhez három technikai beállítás elengedhetetlen a tárhely fiók biztonság maximalizálása érdekében. Az SPF (Sender Policy Framework) rekord pontosan meghatározza, mely szerverek jogosultak emailt küldeni az adott domain nevében. A DKIM (DomainKeys Identified Mail) egy egyedi digitális aláírással látja el az üzeneteket, így a fogadó fél igazolni tudja, hogy a levél tartalma nem módosult az út során. Végül a DMARC (Domain-based Message Authentication, Reporting, and Conformance) ad utasítást a fogadó szervereknek arra, hogyan kezeljék a hitelesítésen elbukott leveleket. Ez a hármas rendszer hatékonyan gátolja meg, hogy bárki visszaéljen az ön nevével vagy cégnevével.

Hogyan ismerd fel az adathalász emaileket?

A legkorszerűbb technikai védelem mellett a felhasználói éberség is kulcsfontosságú. Mindig ellenőrizze a feladó valódi email címét, ne csak a megjelenített nevet, mert az utóbbi könnyen hamisítható. Legyen gyanús minden olyan megkeresés, amely sürgető hangvételben kér jelszómódosítást, banki adatokat vagy személyes információkat. Soha ne adjon meg érzékeny adatot emailben érkező linkre kattintva. Ilyen esetekben gépelje be manuálisan a szolgáltató címét a böngészőbe. A biztonságos és professzionális email szolgáltatások használatával az ilyen típusú kockázatok jelentősen csökkenthetők.

Szerveroldali védelem és jogosultságkezelés

A tárhely fiók biztonság nem ér véget az erős jelszavaknál. A fájlrendszer szintű védelem legalább ennyire kritikus. Az informatikai biztonság egyik alapköve a “legkisebb jogosultság” elve. Ez azt jelenti, hogy minden felhasználónak, folyamatnak vagy szkriptnek csak a feladata elvégzéséhez feltétlenül szükséges hozzáférést szabad biztosítani. Ha egy bővítménynek csak olvasási jogra van szüksége, ne adjunk neki írási vagy futtatási jogosultságot.

A fájlok és mappák jogosultságainak, azaz a CHMOD beállításoknak a helyes konfigurálása gátat szab a kártékony kódok terjedésének. Általános szabályként a mappák esetében a 755, a fájloknál pedig a 644-es érték tekinthető biztonságosnak. Kerülje a 777-es jogosultság használatát, mert az bárki számára teljes hozzáférést enged, ami hatalmas biztonsági rést üt a védelmen. Emellett felejtse el a hagyományos FTP kapcsolatot. Az FTP titkosítatlanul továbbítja az adatokat, így a jelszava könnyen lehallgatható. Használjon helyette SFTP (SSH File Transfer Protocol) kapcsolatot, amely biztonságos, titkosított csatornán keresztül mozgatja az állományokat.

Az elavult szoftverek jelentik a támadások legfőbb bemeneti pontját. 2026 augusztusában a PHP 8.5 a legfrissebb stabil verzió, a régebbi változatok használata pedig komoly kockázatot hordoz. A rendszeres frissítés nemcsak a teljesítményt javítja, hanem befoltozza azokat a biztonsági réseket is, amelyeket a támadók automatizált eszközökkel folyamatosan keresnek.

WordPress biztonság: a legnépszerűbb CMS védelme

A WordPress népszerűsége miatt a hackerek elsőszámú célpontja. A védekezés alapja az automatikus frissítések bekapcsolása mind a magrendszer, mind a bővítmények esetében. Egy jól konfigurált biztonsági bővítmény, mint a Wordfence vagy az iThemes Security, képes blokkolni a gyanús IP-címeket és monitorozni a fájlok módosításait. Ha professzionális alapokra szeretné helyezni oldalát, olvassa el a WordPress tárhely: A teljes útmutató a gyors és biztonságos weboldalhoz 2026-ban cikkünket a további részletekért.

A biztonsági mentés: az utolsó védvonal

Nincs százszázalékos védelem, ezért a tárhely fiók biztonság elengedhetetlen eleme a rendszeres mentés. A mentés akkor ér valamit, ha a tárhelytől fizikailag és logikailag is független, külső helyszínen tárolja. A cPanel felületén könnyen beállíthatók automatizált mentési folyamatok, amelyek napi vagy heti rendszerességgel archiválják az adatokat. A legfontosabb lépés azonban a mentések rendszeres tesztelése. Egy mentés csak akkor létezik, ha bizonyítottan vissza is állítható belőle az üzleti adat. Ne várja meg a bajt, válasszon stabil és biztonságos webtárhely csomagjaink közül, ahol az automatizált mentés a szolgáltatás része.

Biztonságos tárhely az aWh-nál: ahol az adataid jó kezekben vannak

Az aWh több mint 10 éves piaci jelenléte során a biztonság iránti elkötelezettség vált szolgáltatásaink legfőbb védjegyévé. Megértettük, hogy a tárhely fiók biztonság nem csupán szoftveres beállítások sorozata, hanem egy folyamatosan fejlődő technológiai ökoszisztéma. Infrastruktúránkat úgy alakítottuk ki, hogy az a legkifinomultabb támadásokkal szemben is stabil maradjon, miközben a felhasználó számára egyszerű kezelhetőséget biztosít.

Minden webtárhely csomagunk mögött professzionális hardveres háttér áll. Az NVMe alapú tárolók nemcsak a weboldalak villámgyors betöltődéséért felelnek, hanem a hagyományos meghajtókhoz képest magasabb fokú adatbiztonságot és stabilitást is garantálnak. A szervereinket ért fenyegetéseket folyamatos, 24 órás monitorozással szűrjük, az automatizált DDoS védelem pedig minden ügyfelünk számára alapértelmezett, így a hálózati szintű támadások már azelőtt elhárulnak, hogy elérnék az ön webhelyét.

Szakértő, magyar nyelvű ügyfélszolgálatunk nemcsak technikai kérdésekben segít, hanem aktív támogatást nyújt a biztonsági beállítások optimalizálásában is. Legyen szó egy gyanús tevékenység kivizsgálásáról vagy a jogosultságok finomhangolásáról, csapatunk tapasztalatára bármikor támaszkodhat.

Automatizált biztonsági funkciók az aWh tárhelyeken

A manuális védekezés ideje lejárt, ezért rendszereinkbe számos automatizált megoldást integráltunk. Minden nálunk regisztrált domainhez ingyenes SSL tanúsítványt biztosítunk, amely titkosítja a látogatók és a szerver közötti kommunikációt. Ez alapfeltétele a bizalomépítésnek és a modern keresőoptimalizálási elvárásoknak is.

Rendszeres biztonsági mentések: Automatizált rendszereink napi szinten készítenek másolatot az adatairól, így egy esetleges hiba vagy támadás után minimális idő alatt visszaállítható a korábbi állapot.
Intuitív vezérlés: A könnyen kezelhető cPanel felület segítségével ön is teljes körű rálátást kap a biztonsági beállításokra, a kétfaktoros azonosítástól kezdve az IP-alapú korlátozásokig.
Aktív vírusvédelem: Szerveroldali szűrőink folyamatosan ellenőrzik a fájlrendszert, hogy azonosítsák és semlegesítsék a kártékony kódokat.

Válts biztonságosabb környezetre zökkenőmentesen

Sokan tartanak attól, hogy a költözés bonyolult folyamat, de az aWh szakértői leveszik ezt a terhet a válláról. Segítünk a teljes weboldal és a levelezés zökkenőmentes migrációjában, miközben elvégezzük az elsődleges biztonsági auditot is. Megvizsgáljuk a meglévő rendszereit, és javaslatot teszünk a tárhely fiók biztonság további erősítésére, hogy vállalkozása a lehető legkisebb kockázat mellett működhessen.

Személyre szabott tanácsadásunk keretében segítünk kiválasztani az üzleti igényeihez leginkább passzoló konfigurációt, legyen szó egy induló blogról vagy egy nagy forgalmú webshopról. Ne bízza a véletlenre digitális értékeit. Válaszd az aWh biztonságos webtárhelyeit, és élvezd a nyugodt munkavégzést egy stabil szakmai háttérrel!

Legyen a biztonság az üzleti sikered alapköve!

A tárhely fiók biztonság nem egyetlen beállításon múlik, hanem a tudatos hozzáférés-kezelés, a naprakész szoftverkörnyezet és a professzionális email hitelesítés együttes erején. A kétfaktoros azonosítás bevezetése és a titkosított SFTP kapcsolat használata olyan alapvető lépések, amelyekkel a támadások jelentős része már az induláskor semlegesíthető. Ne feledje, a biztonság egy folyamatos folyamat, ahol a megelőzés mindig kifizetődőbb, mint az utólagos kármentés.

Ha nem szeretné a véletlenre bízni digitális értékeit, válasszon olyan partnert, aki technológiai hátterével és szakértelmével is támogatja önt. Az aWh több mint 10 éves szakmai tapasztalattal, díjmentes SSL tanúsítvánnyal és magyar nyelvű szakértői támogatással segít kiépíteni a legmagasabb szintű védelmet. Modern NVMe infrastruktúránk és automatizált mentési rendszereink garantálják, hogy adatai minden körülmények között elérhetők maradjanak.

Fokozd weboldalad védelmét az aWh biztonságos tárhelyeivel!

Kezdje el a védelmi rétegek kialakítását még ma, és építsen stabil jövőt vállalkozásának egy valóban golyóálló digitális környezetben.

Gyakran Ismételt Kérdések

Hogyan választható ki a legbiztonságosabb email szolgáltató?

A biztonságos email szolgáltató kiválasztásakor az alábbi technikai szempontok a legfontosabbak:

SPF, DKIM és DMARC protokollok támogatása a hitelesség megőrzéséért.
Szerveroldali spamszűrés és folyamatos vírusvédelem.
Titkosított IMAPS és SMTPS kapcsolatok biztosítása minden eszközön.

Egy profi szolgáltató nemcsak tárolja a leveleket, hanem aktív védelmet is nyújt a fenyegetések ellen. A dedikált email tárhely használata azért előnyös, mert megbízhatóbb kézbesítést és tisztább IP-reputációt tesz lehetővé, mint az ingyenes megoldások.

Milyen gyakran kell megváltoztatnom a tárhely jelszavamat?

A jelszót azonnal módosítani kell, ha felmerül a gyanú, hogy illetéktelenek kezébe került, egyébként a jelszókezelővel generált, komplex kódok használata a célravezető. A modern biztonsági ajánlások ma már nem a gyakori váltást, hanem a jelszó hosszát és egyediségét hangsúlyozzák. Ha legalább 16 karakteres, véletlenszerű karaktersort használ, elég évente egyszer frissítenie azt. A legfontosabb, hogy soha ne használja ugyanazt a belépési kódot több különböző webes felületen.

Tényleg szükséges a kétfaktoros azonosítás minden fiókhoz?

Igen, a kétfaktoros azonosítás (2FA) használata elengedhetetlen, mivel ez jelenti a leghatékonyabb védelmi vonalat a jelszólopással szemben. Még ha egy támadó meg is szerzi a belépési adatait, a telefonjára érkező kód nélkül nem tud bejutni a rendszerbe. Ez a megoldás drasztikusan növeli a tárhely fiók biztonság szintjét, és minimálisra csökkenti az automatizált feltörési kísérletek sikerességét. Minden üzleti szempontból kritikus fióknál kötelező elemként kell tekinteni rá.

Mi a különbség az ingyenes és a fizetős SSL tanúsítvány között?

Az ingyenes és a fizetős SSL tanúsítványok ugyanazt a titkosítási szintet nyújtják, a különbség a hitelesítés mélységében és a kártérítési garanciában rejlik. Az ingyenes megoldások, mint a Let’s Encrypt, 90 naponta frissülnek, és csak a domain tulajdonjogát igazolják. A fizetős tanúsítványok viszont szervezeti hitelesítést is kínálhatnak, ami nagyobb bizalmat ébreszt az ügyfelekben. Emellett a fizetős verziókhoz pénzügyi garanciavállalás is tartozik, ami egy esetleges biztonsági incidens során anyagi védelmet nyújthat a vállalkozásnak.

Hogyan ellenőrizhetem, hogy feltörték-e a tárhely fiókomat?

A feltörés jele lehet a weboldal váratlan lassulása, ismeretlen fájlok megjelenése vagy a keresőmotorok által küldött biztonsági figyelmeztetés. Érdemes rendszeresen ellenőrizni a cPanel naplóit, ahol láthatja, ha valaki ismeretlen IP-címről vagy idegen országból próbált belépni a fiókba. Ha a látogatókat gyanús, idegen oldalakra irányítja át a böngészőjük, vagy ha a tárhely erőforrás-használata hirtelen megugrik, nagy valószínűséggel kártékony kód fut a rendszerében, ami azonnali technikai auditot igényel.

Mit tegyek, ha gyanús tevékenységet észlelek az emaileimnél?

Gyanús email tevékenység esetén az első lépés a jelszó azonnali megváltoztatása és a kétfaktoros azonosítás bekapcsolása. Vizsgálja felül az üzenetküldési szabályokat és a továbbítási beállításokat, hogy ne kerüljenek másolatok idegen címekre. Ellenőrizze az elküldött levelek mappáját, és ha ismeretlen üzeneteket talál, értesítse a partnereit a lehetséges visszaélésről. Vegye fel a kapcsolatot a szolgáltató ügyfélszolgálatával is, hogy segítsenek a belépési naplók elemzésében és a fiók teljes körű megtisztításában.

Hogyan segít a cPanel a tárhelyem védelmében?

A cPanel számos beépített eszközzel segíti a tárhely fiók biztonság fenntartását, ilyen például az IP-blokkoló és a ModSecurity tűzfal. Ezekkel a funkciókkal szűrhetők a rosszindulatú kérések és korlátozható a hozzáférés a kritikus fájlokhoz. A felületen egyszerűen kezelhetők az SSL tanúsítványok és a kétlépcsős azonosítás is, így technikai mélyvíz nélkül is professzionális védelmet állíthat be. A rendszer segít abban is, hogy folyamatosan monitorozza a fájlok épségét és a hálózati kéréseket.

Mennyire biztonságosak az aWh szerverei a támadásokkal szemben?

Az aWh szerverei többrétegű védelmi rendszerrel rendelkeznek, amely magában foglalja a hardveres DDoS védelmet és a folyamatos szerveroldali monitorozást. Infrastruktúránkat modern NVMe tárolókra és naprakész szoftveres környezetre építettük a maximális biztonság érdekében. Több mint 10 éves tapasztalatunkkal folyamatosan auditáljuk rendszereinket, így ügyfeleink adatai védve vannak a támadásokkal szemben. A magyar nyelvű szakértői támogatásunk pedig bármilyen incidens esetén gyors segítséget garantál, biztosítva az üzleti folytonosságot és a nyugodt munkavégzést.

2026-08-22

Github + Hugo + Vercel

Sat, 29 Aug 2026 16:38:00 +0000

我上一篇博客介绍了几种托管一个小型静态网站的方法。本文专注于一种目前我认为的最佳配置，详细介绍如何做一个个人博客，确保资料安全，保护访客的个人隐私，没有人打广告，或者删你的帖，而且完全免费。概括而言：

你在本机使用文本编辑器用markdown 格式写作文章
你的博客使用Github来做源代码管理，确保一切历史得到妥善保护
然后通过Vercel 自动生成发布并托管

本地工具安装

首先确保你本地有需要的工具。

字符终端

某些朋友对字符终端有畏惧心理。但是，字符终端是最好的教学工具，它可以让你用最小的代价来传达一步步的指导。敲什么命令，预期什么样的返回，不会有任何模糊不清的情况。当然，这里命令行操作中的很大部分，甚至可能是全部，可以用图形界面操作来取代，但这是后话，等待你自己主动去发现。

Mac OSX 和 Linux 用户可以跳过这一段，你的电脑已经有可用的字符终端了。Windows用户请安装msys2, 并按照首页指示操作直到 pacman -S git

Hugo

Hugo是我们要使用的静态网站生成器。静态网站生成器有很多种，Hugo既不是最简单易用的，也不是功能最强大的，但综合两方面考虑我郑重推荐Hugo。Hugo 使用Go 语言开发，但你今天甚至未来都不需要懂一点点 Go 语言，在未来你可能需要修改一些模版文件来定制化自己的博客。

严格来说，你甚至不需要安装运行Hugo就可以发布博客，这一点我后来会提到。Hugo的安装非常简单，下载后只有一个可执行文件，把这个可执行文件拷贝合适的地方，在命令行直接运行就是了。安装说明有点长，但你只需按照文中第一种方法就好。

文本编辑器

文本编辑器我不愿意做推荐。任何像话的文本编辑器都支持markdown文件编辑，例如Notepad++, Sublime Text, Textmate, VS code, Emacs, VIM, … 通常而言软件工作者对文本编辑器都有很强的偏好，例如我，不能忍受使用任何非Emacs 工作超过十分钟。

如果你完全没有概念，也不知道可以用什么，可以尝试使用Atom. Atom 来自Github，可以和Git工作流程紧密结合，界面也比较新潮，对新用户相对友好。

补充：我现在建议初学者使用zettlr, 这是一个对Markdown 专门优化的编辑器，和Atom一样也是用跨平台的Electron框架写成。

加入 Github

你需要在Github注册账户。这个过程是免费的，而且仅需要一个邮箱信息。你的代码库会存在这里。之后你和guthub的交互主要是通过命令行工具，其他图形界面工具或第三方工具完成，网页交互不会太多。注册完用户之后你需要开通SSH public key访问，Github这里有详细步骤，我这里不再详述了。Windows用户的本地git工具在上面步骤已经安装完成，Linux请使用本机git，OSX用户第一次使用git的时候命令行会有提示如何安装git。

你在github网站的操作暂时告一段落，之后本文所有操作都是在外部完成的。

加入 Vercel

其实Github本身就可以做发布，但今天我不介绍，因为有更好的方法。请到Vercel 网站，无需注册新用户，直接点 Continue with github 按钮：

continue with github

填写一些基本信息后，请点击 import Template 按钮：

import Template

然后注意选择hugo模版，排的不是太靠前，注意不要选错了。之后请一切照提示，把模版安装到github，并做首次发布，一个空白的，完全自主的博客就上线了。

如何加入自己的内容

首先，为简化起见，你的博客上自己提供的内容只有两种：

文章，就是 .md 文本文件
图片，可以是 .png 或 .jpg 文件，注意大小不要太大，最好不超过250KB，否则请自行缩小或降低分辨率。

请使用git工具把生成的模版工程克隆到本地，Github上有明确指示。hugo 网站上有相当详细的文档，但你暂时不需要看。你需要干的几件事如下。

配置

工程根目录下有个极简的配置文件 config.toml, 内容大致如下：

baseURL = "https://xxx.xxx.xx/"
languageCode = "en-us"
title = "XXXX"
theme = "ananke"

请把 baseURL 改成自己需要的域名。没有域名的话，可以使用 Vercel 提供的临时域名，你在Vercel网站上有，形如 xxx.vercel.app.

请把 title 改成自己想要的样子。没了。

第一篇文章

你的博客文章会放在 content/posts 目录下，每篇文章是一个 .md 文件。目前目录中只有有一篇基本空白的范例。文件分两部分，第一部分是一个简单的前言，包含本文的一些简单信息，例如：

---
title: Send My Own Emails
slug: send_my_own_emails
date: 2020-08-06
tags:
- email
description: Sending your own email by yourself is suprisingly hard.
---

含义不言而寓。这个格式是一个简单的yaml格式。

之后就是你的文章了，一个较简洁的格式介绍在这里:

你的图片放在 static 目录里，在你文章引用的时候请使用绝对路径, 但从static 目录开始算。例如，如果图片存成: static/pics/mypic.jpg 则网页引用路径是: /pics/mypic.jpg.

Hugo 预览

Hugo 包含本地动态预览功能。请在工程根目录下键入命令：

hugo server

然后打开你的浏览器指向：http://localhost:1313/ 你就看到你的博客预览效果了。你用文本编辑器每次存盘浏览器都会自行刷新。

发布

发布其实和Hugo无关，而是通过git通知github，再从github通知vercel，vercel会自动从github抓取最新工程，自己生成再发布。

你需要做的是在git里加入你新增的文件，记住不要加入生成文件 (public/) ，然后 commit 再 push。

git add posts/*.md static/*.jpg static/*.png
git commit -a
git push

之后如果顺利的话，不到一两分钟，你的内容就上网了。有兴趣的话可以到vercel 上观察过程日志。

模版订制

这一部分暂时超纲，你需要对hugo的模版机制有一定了解。模版文件都在 themes/THEME 目录下，其中THEME是你配置文件中配置的。如果没改过的话是ananke. 有兴趣的话可以进去看看。

还有一种可能是从网上下载全新的theme，目前有几百个之多。

结束语

你的自主博客之路才刚刚开始，还有很多值得你去探索。别的好处我暂时不谈，这里我谈一谈资料安全性。在本文介绍的方法下，每一个部分都可以更换：

Vercel不能用了还有别的托管公司，例如Netlify
Github不能用了还有Gitlab，Bitbucket, …
Hugo不能用了还有很多很多静态网站生成器，都支持markdown，最多前言部分需要小修改
你电脑坏了，你所有的文章，图片，包括所有历史在Github有备份
如果网络都没有了，你所有的文章，图片，包括所有历史都在本地有备份

从数据量来说，你的文章微不足道。从意义来说，除了对你自己，对别人的意义未必很大。但是这是你自己的言论自由，什么人都管不着。

荣誉，隐私，言论自由。假如你自己都不在乎，不会有人在乎你的。– 周溱

State of the blog – 2024. – S-Config

Sat, 29 Aug 2026 01:32:02 +0000

Although late to the party. Here's to 2024!

This New Year's Eve we spent at home and by ourselves. It was super uneventful really. Didn't go to the Barcade like the year prior. Nor did we go to the lakeshore. Or to a warehouse listening to speed metal cooking 36lbs of meat in a 55-gallon drum while only having a single packet of hamburger buns sitting on the makeshift picnic table looking incredibly sad for most of the night.

But hey, let's review what all happened this year, shall we?

Events in 2023.

We went to a few events that are within the Midwest region, and the attendance numbers of these events were rather large. However, we will not be talking about these events directly as it goes against a personal rule that we've set up for blogging here. That rule is

"No convention talk"

Why? Because Fandom is fanatical. Criticism even if it's constructive will be met with violence because there is nothing wrong in the mind of the delusional.

Furry events:

Furry in us all.

To what has been mentioned above. Back in 2016, we wrote up this article about being furry and how no one leaves because there is no such thing as 'goodbye' which is why instead people simply fade from a fandom. Also, how things aren't what they once were when it comes to communities. Occasionally we try to go to events to prove this article wrong.

In 2023, It's as solid as ever. I'm just going to say that the event in question does not need my money. Their attendance will be perfectly fine until it isn't. When that event cross that threshold it will be too late AND not my problem! Okay! moving on!

Gaming events:

Do avoid getting all debbie downer in 2023; If there is one thing we did enjoy in 2023 is going to Midwest Gaming Classic which typically happens around April. I like this picture because of the Ouya. Now, there will be some readers that are going to explode on us with the following:

You just said you're not talking about conventions!! You asshole S!

If you go over to their website the very first sentence on their homepage tells you they are not a convention. But a Trade Show. To some, this is splitting hairs. But there's a distinct difference.

Trade shows typically are events set to encourage businesses to buy products. Trade Shows typically are more commercial than a convention. However, Midwest Gaming Classic kind of goes a little above and beyond with hosting panels at their Trade Show which is not too common. They've even reached out to the roleplaying and board game community too.

In the pinball world, the convention fits this category perfectly. Stern, American, and Jersey Jack all come down with their latest machines and take orders from bars restaurants, and collectors to have that new pinball machine delivered to their home. Sometimes buying the machine right off the convention floor and into their home.

I also posted a link on Odysee for the 2022 expo-hall walkthrough for those who want to see that. It's over there mostly because we were testing Odysee in a previous article.

Unlike a convention. A trade show feels super neutral. There are fans of certain products there of course! But it's not to the level where you feel you're being alienated from going.

Never thought we'd see the day of a game having a $2,199 price tag on it.

The picture above is just one vendor in the hall and there are so many styles of vendors it ranks from the "I know what I got" vendor like the picture above. To the "What's in the box? I dunno. It's yours for $10! I need this out of my attic!" which are the vendors we like. Thank god for emulators where people can maintain their unopened boxes while the price goes to the moon right?

Anyhow, it was good last year. I'll probably go back this year. Also, this isn't the only gig in the world. There are a few pinball and arcade shows like this throughout the states and each of them of course has its vibe to it. So if you do have one in your city. It's worth checking out at least once.

How will you find me at Midwest Gaming Classic? I'll be one of those nerdy types, with a video game shirt. Walking up and down the halls.

Glad we narrowed it down for you.

Best 2023 article.

I'd say one of my best articles for 2023 is the Intel Arc A380 video encoding demo. I should probably revisit that and drop that card into a box with a legit bridge to use it correctly. But it's great because we're entering the world of GPT-generated content on the internet and We don't want it to stop. We want it to get worse! So much worse that Google can't even function anymore. Turn all of the major search engines into grey fucking goo for all we care! Because of how we do our blog entries. How can an AI not only perform the tests we did in this blog but also show the video result using video samples? Now, we're sure someone with enough GPT could generate a workflow to do all of this. But most of these guys want easy money. Which is to use a cookie-cutter GPT to make an article that 'copies' other people and moves on.

The website itself.

We've both improved and regressed at the same time. That is, our site is moving faster because we got rid of all Javascript. By getting rid of all Javascript our website may also feel a little dated.

Respectfully on Marginalia's search engine (one of those few clear-near search engines we legitimately respect because they deal with small hosting content instead of going for the conglomerates right away.) Those Javascript warnings are going away slowly. We suspect by the end of next year most of the ones that are still warning of javascript will be cleaned up too because of how cache settings on this site are set yearly for static page content.

Webrings.

They were too unwieldy to keep in the cellar door. Too many change requests. So we put webrings into a new LNK section over here. Looking back at Webrings we question its use throughout 2023. Because when you think of webrings back in the day it was focused on a particular subject. Is putting a button on a page enough for the reader to click on it? Or is it better to stick with my cellar door methodology of promotion where we write a paragraph as to WHY it exists and WHY it's respected? Then, the reader can decide after explaining a graphic/link its existence if this is someplace they want to go. If the experiment gets too stupid I'll pull the plug and reconsolidate each webring network as a single mention instead of going image-spam crazy.

The enimic Tor / I2P

This might be changed a lot quicker. Lainchan attempted to include these addresses but they don't seem to be replicating all that well. I might revert to my classic listing structure where it's just a site that I have found and have worked on throughout the years.

Mastodon.

The experiment is still ongoing on core.

The timeline was 401'ed to prevent a bunch of scabs from indexing anything here. But it's still online for me to use. Outside of the technical hells of updating it from time to time, it's been far less stressful for me to be on Pleroma/Mastodon than it is on Twitter. In a sense, because we're using the Pleroma engine to hook up to Mastodon it sort of leaves our instance in the reaver territory of the fediverse where some of the bigger ones would ignore any contribution I may have for their timeline. However, in the past being that we were on the primary mastodon instance we think this is a good thing to be excluded from that level of crap.

Of course, clicking about you see lots of love for Threads attempting to join my instance. But overall. It's been a good experience because social networks like twitter/X TURNED into television. With ads being everywhere and people you don't know telling you how you should live your life. To which they deserve all of the bags of dicks to chew on.

Final thoughts.

looking at 2023, we did fail on a lot of things we wanted to do. We wanted to do more art. Maybe even a comic. Get some 3-d shit done. But you see. When you're adulting hard through life. RL has a way of destroying all of the things that you want to do. Perhaps it's being too much of a workaholic to focus on anything really fun. Or living in a world where the possibility of not being under the thumb of a landlord that jacks your rent by forty percent is turning savings and ownership into a laughable dream because you exchange that thumb of oppression with another thumb which is a supposed bank with a 30-year mortgage. Fun fact, a life sentence in jail is 25 years.

Of course, you get those that argue that the debt is 'good'. Just like college debt is 'good' because the education helps further your career and ability to get jobs. For every person, we know where that is true. there are 20 that have gone through college, have received their degrees, and are essentially back at working for Home Depot this time with 40-120k of debt over their head. Now, those who are working in the careers required for college are just barely breaking even. Living check to check. So even when you do get the career you want. Throw the wrench of inflation into the mix and now you spent 4 years being back where you started.

So what is a person to do? Well, since we're all not stacking mad eddies in this cyberpunk dystopia making six-figure incomes every year. Does one decide to save up just enough for a foreclosed house and live the fight club dream while trying to slowly rebuild the place from the inside out? Even when that's accomplished the average homeowner is still dancing madly upon the lip of a volcano because all it takes is a serious medical bill or an accident. And the house as an asset can be liquidated. Because if they see a run-down shack for a house they may decide it's not even worth the legal hassle to pull the asset.

These are some of the stresses we think about. We know we're not alone on this. Many are going through the same shit. Life was never given the 'easy' button but damn a little bit of a break can go a long way in any generation.

Anyhow, that's what server said

END OF LINE+++

htmx 4.0.0 has been released! ~ htmx

Fri, 28 Aug 2026 19:30:48 +0000

htmx 4.0.0 Release

The htmx team is very happy to announce the release of htmx 4.0.0! This is the culmination of 8 months of work (plus a game) and we are very happy with the results.

The idea of htmx 4 started to germinate when I decided to create fixi and, in doing so, got more familiar with the fetch() API and async programming in JavaScript. (htmx had always used XMLHttpRequest due to backwards compatibility issues.)

One chance evening I was contacted by Christian, who had some interesting ideas around streaming HTML that got me thinking that moving the internals to fetch() would simplify things for him and for the library in general.
After a bit of work I managed to get Michael and Alex on board, and we were off to the races.

Development has been very smooth. We started a port of fixi + the htmx test suite. Over time, we rediscovered why htmx did many of the things that it did and moved our new implementation closer and closer to the old one. At this point the behavioral differences between 2.x and 4.x are relatively small and where they do diverge we have made explicit choices that we feel will put htmx-based applications in a good spot for being 100-year web services

Note that we are not marking 4.0 as latest in NPM because we do not want to force-upgrade users who are relying on non-versioned CDN URLs for htmx. Instead, 2.x will remain latest and the 4.0 line will remain next until some point in early 2027. The website, however, will reference 4.0.

Major Changes

As mentioned above, htmx 4, from a user’s viewpoint, is almost identical to htmx 2. There are three major changes:

Attribute inheritance is now explicit by default rather than implicit by default (this is the biggest upgrade item)
The htmx event names have been standardized & cleaned up. Some advanced users may need to change the events they listen for.
History support now does not use localStorage by default (which was a cause of many support headaches). Most people won’t notice this at all.

Internally, we migrated from XMLHttpRequest to fetch() but that should be transparent for most users of htmx.

Attribute Inheritance

In htmx 2 many attributes were “inherited” by default. This allows you to place attributes on parent elements and their behavior will apply to child elements. This behavior, which came from the intercooler.js days, was inspired by CSS and, unsurprisingly, worked out about the same as CSS: powerful but difficult to understand at times.

In htmx 4 attributes are not inherited unless you explicitly say so by adding an :inherited after the attribute name:

This will be the largest upgrade burden in migrating from htmx 2 to htmx 4. To make things easier, we have provided a command line tool to find places you need to mark as inherited.

Note that attributes like hx-disinherit, etc. are no longer required and should be removed.

Events

The events triggered by htmx 2 had grown organically over the life of the library and were not particularly well organized, making it difficult to know exactly which event was fired when.

In htmx 4, all events now follow htmx:phase:action[:sub-action]:

htmx 2	htmx 4
`htmx:beforeRequest`	`htmx:before:request`
`htmx:afterRequest`	`htmx:after:request`
`htmx:beforeSwap`	`htmx:before:swap`
`htmx:afterSwap`	`htmx:after:swap`
`htmx:configRequest`	`htmx:config:request`

In addition, the following changes were made:

The full table is in What’s New in htmx 4.

The command line upgrade checker flags old event names in hx-on attributes and in your JavaScript where it can find them.

History

History support has always been included in htmx, allowing you to implement back-button aware actions with simple attributes. In htmx 2, a cache in localStorage was used to snapshot pages for restoration. Unfortunately a large source of issues was that this snapshot could include DOM mutations by 3rd party JavaScript libraries. When the page was restored, those mutations remained but the underlying JavaScript logic was not.

htmx 4 does not cache pages in localStorage. On back navigation htmx re-fetches the page and swaps it into <body>, or into the [hx-history-elt] element if one is present. This allows 3rd party JavaScript libraries to “just work” in most cases and, with good request caching, is very fast.

If you want local caching instead, we now ship a very complete hx-history-cache extension that restores history from sessionStorage and is designed to integrate well with scripting solutions like Alpine.js, etc.

New Features

There are two big new features in htmx 4, both of which we are really excited about:

Morph Swaps

We now support morphing swaps out of the box with htmx. I created idiomorph and nearly included it in htmx 2.x but decided against it. In htmx 4, Michael has done great work improving on that algorithm and integrating it seamlessly into htmx.

`<hx-partial>`

Another major new feature is the <hx-partial> tag. This tag is similar to out-of-band swaps, but is much clearer when you want to do something beyond just replacing a single element with a new version of itself:

Extensions

Much of the excitement in htmx 4 is in the extensions. Switching to fetch() internally let us rethink how extensions can and should work, and sparked the creation (and recreation) of many new extensions, for example:

hx-preload - preload content (e.g. on mouseover) to speed requests up
hx-download - native, fetch-based file downloads
hx-alpine-compat - smooths over compatibility issues between htmx and Alpine.js
hx-history-cache - caches history in sessionStorage, provides Alpine.js compatibility

Additionally, there are three new or updated streaming HTML extensions:

hx-sse streams over text/event-stream.
hx-ws streams and sends over WebSockets.
hx-multipart streams over multipart/mixed

Finally, we decided it was time to try our hand at our own small front-end scripting solution that tightly integrates with htmx. hx-live is inspired by Alpine.js, jQuery and hyperscript, and makes front end scripting pleasant and fun. It even supports what we are calling DOM-based, HATEOAS-friendly reactivity.

There is a new htmax.js bundle in the distribution which packages htmx with the most popular of these in a single file if you don’t want to think about which ones you want to pick.

Upgrading

For a complete upgrade guide see What’s New in htmx 4.

As mentioned earlier, we are providing an upgrade tool to help you:

$ npx htmx.org@4.0.0 upgrade-check -- ./templates

File extensions: .html, .php, .js, .ts, .jinja, .jinja2, .j2, .erb, .hbs
Use --ext to add more (e.g. --ext .vue --ext .svelte)

Scanning 1 file(s)...

Found 8 issue(s) in 1 of 1 file(s).
templates/index.html:1: [inheritance] hx-headers needs :inherited suffix (descendant on line 3 has hx-delete) (this looks like a CSRF token; without :inherited the header does not reach child elements and the server rejects the request)
templates/index.html:2: [inheritance] hx-target needs :inherited suffix (descendant on line 3 has hx-delete)
templates/index.html:2: [inheritance] hx-confirm needs :inherited suffix (descendant on line 3 has hx-delete)
templates/index.html:3: [renamed-attr] hx-disable -> rename to hx-ignore (hx-disable now means 'disable during request')
templates/index.html:4: [removed-attr] hx-vars is removed -> use hx-vals with js: prefix
templates/index.html:4: [removed-attr] hx-prompt is removed -> load the hx-prompt extension to keep the same syntax
templates/index.html:9: [old-event] old event name "htmx:afterRequest" -> "htmx:after:request"
templates/index.html:9: [old-api] htmx.addClass() is removed -> use element.classList.add()

We are also shipping an agent skill to assist in upgrading

Installing

htmx 4.0 can be installed via a package manager referencing version 4.0.0, or can be linked via a CDN:

<script src="https://unpkg.com/htmx.org@4.0.0/dist/htmx.min.js"></script>

or Downloaded

LLMs

Like it or not, a lot of people are using LLMs and we are providing the following skills files for LLMs:

htmx-guidance - core htmx skills for developing with htmx 4
htmx-debugging - diagnosing htmx issues during dev
htmx-extension-authoring - writing and debugging htmx 4 extensions
htmx-upgrade-from-htmx2 - migrating a codebase from htmx 2.x to 4.x

(Let’s leave aside if releasing a new version of a library in the LLM era is a good or bad thing!)

Conclusion

We hope you enjoy htmx 4. htmx 2 will continue to be supported indefinitely so don’t feel any pressure to upgrade.

I’d like to thank the following people for all their help with this release:

Michael West - Incredible teammate & grug-brained developer
Christian Tanul - Inspired htmx 4 & led the streaming & live extensions
Alex Petros - For keeping the ship on an even keel
Stephen Mitchell - The genius behind the game
Stu Kennedy - Our WebSockets expert
André Ahlert Jr. - Providing IDE & Editor Support
Dien Hoa Truong - For kicking the tires on early htmx 4 and helping fix many bugs

Upgrade Music

Wouldn’t be an htmx update without upgrade music:

Nobody Argued For Your Stack - DEV Community

Fri, 28 Aug 2026 19:30:48 +0000

Last week, it came to light Cursor had mostly finished migrating from SolidJS to React. This migration happened about seven months ago. But it became a central focus of discussion following the Solid 2.0 RC release. Then yesterday, a week later, it came to my attention that the Anthropic docs example command for their large-scale migration feature is:

I admit that my gut reaction was not great. Out of all the examples they could have chosen... Years of my work became a canonical example of the thing you migrate away from — in the same week we shipped the biggest release in the project's history — stung in a way I won't pretend it didn't. My second reaction was to assume that, like the other trickle-down posts I'd seen this week, this rode the same week-old news cycle.

Then I checked the Internet Archive and realized this has been there since at least April 2026. Four months before the Cursor story broke. At this point, the whole public footprint was a mention of an experiment sandwiched between bigger updates in a Cursor blog post posted in January. The kind of thing that no one outside the industry would even really pick up on. No reasoning, no benchmarks, no argument.

Stop to think about what that means. I should be careful here because I can't prove anyone at Anthropic ever read that Cursor post. Nobody can. Maybe a docs writer saw the experiment. Maybe Claude drafted its own example. But think it through. Either it traveled from a buried line in one company's release notes into another company's official docs, or it needed no origin at all. It was already assumed before any public migration existed.

Our industry has quietly started broadcasting conclusions where it used to transmit arguments. We couldn't have picked a worse time, because — as I'll get to — arguments are the only source that still matters.

Why This Matters More Than It Used To

It would be fair to ask, hasn't it always been like this? Teams cargo cult large players. Netflix or Facebook uses this predates AI by decades. Optics and politics have always beaten pure technical merit. The weight of Facebook definitely helped React's early propagation.

But a narrative used to come with friction. It was always in the race, but it couldn't outrun the argument. This has changed for two reasons:

First, execution cost has collapsed. Bun's rewrite from Zig to Rust — about a million lines — was executed almost entirely by Claude agents in days, not months. And before you start thinking "lock-in", going the opposite way, while not as easy, has never been easier. Migrating from Rust to Zig or React to Solid has never been easier.

That sounds like good news. And it is. When migrations took years of human effort, cost put a damper on fashion. Now execution is a lot cheaper in all directions. The only thing left is the reason. Which suggests, on the surface, these decisions should be rooted in technical merit. But when narrative is what sets the direction, you start to see how a line buried in documentation is worth an essay.

Second, verdict production has been industrialized. Cognition just migrated its marketing site from Astro to Next.js. A content site. Astro's home turf, by near-universal consensus, including from people with no stake in the fight. The migration was performed by Devin itself and published as a case study: the agent made the changes, tested them, recorded its own verification runs. No repository, no before-and-after numbers, no benchmark. The output wasn't the site. It was the story.

And believe me, there is no shortage of these stories. Migrations are now the demo genre of the agent industry. Theo Browne was trying to tell me this a couple weeks back with some very good advice. But it hits a lot harder when you feel it firsthand. Migrations that demo flawlessly are, by definition, the ones moving toward what the agent writes best today. Marketing departments are generating "X → dominant library" verdicts at a rate organic engineering decisions never would.

So you see the tension. Stacks have never been more sensitive to circulating verdicts, and verdicts have never been produced faster or with less reasoning attached.

What an Argument Looks Like

These aren't unheard of. They are just becoming rarer.

When Bun moved from Zig to Rust, Jarred Sumner made the case in public, with receipts. He talked about bug classes and memory management issues. You can disagree with the argument. People have, point by point, in public. That's the value. An argument can be engaged, checked, narrowed, refuted, or strengthened. A verdict can only be repeated.

Or look at TanStack's journey with React Server Components on tanstack.com. They spent the year almost arguing with themselves. When tanstack.com adopted React Server Components, they wrote it up and measured it. When they stopped using them, they did the same: What changed, what replaced it, why the tradeoff flipped for their specific case — while TanStack Start went right on supporting RSC as an opt-in primitive for everyone else. The reversal post calling the decision "uneventful" is a tell. A public reversal on React's flagship architecture, and it generated insight instead of heat. Because they delivered analysis instead of verdict.

That's what evaluation entering the public record looks like. jQuery didn't lose to React because a training set said so. It lost an argument, in public, on merit over several years. Every library you respect got where it is by winning that kind of fight. The flow of events I described earlier doesn't hold fights. It holds direction, and compounds on it.

The Argument Nobody Published

In all fairness, Cursor never issued a verdict. An experiment that "still needs careful review", then a congratulatory post on the Solid 2.0 RC release. But that post still characterized signals as "perf footguns" and "accidental fan out" — no numbers, nothing to engage — and reached straight for the React Compiler as the cure. No bad faith required. The diagnosis and the cure just came from the same place.

When I tried to reconstruct the case Cursor could have made, it turned out to be interesting. Far more interesting than "perf footguns."

The post obviously highlighted agents were "quite bad at writing good Solid code," everything "ended up being accidentally tracked." While my "Solid-brain" struggles a bit to imagine what they were doing to get there, I don't doubt it for a second. An agent that has internalized React's mental model will write Solid like React, and Solid written like React is bad Solid. I've also seen the reverse. The difference is when the agent fumbles React, the training data catches it. When it fumbles Solid, the training data shrugs. This is a pure numbers game.

But the same post contains a decision in the opposite direction. They're also moving from Tailwind to StyleX. This is a migration against volume. What StyleX offers instead is that agent mistakes get caught. Styles are typed with deterministic merge order, so a hallucinated class is a build error.

Put side by side, one conclusion can be made: make agents' mistakes cheap. Two ways to achieve that. Volume and verification. React (with its compiler) wins on volume and arguably on verification. StyleX loses on volume and wins decisively on verification. I won't pretend under this lens with Solid 1.0 this is a particularly comfortable place for signal-based reactivity. But it's also, not coincidentally, where Solid 2.0's design attention has gone.

That analysis, volume and verification as two axes, is concrete, checkable, and useful. It implies testable claims and gives every framework author a design target. It might also be wrong. I reconstructed it from a benchmark-free post and my own inferences. Cursor's actual reasoning may be entirely different.

The StyleX decision is even more interesting. Agent-driven development can move against volume when verification wins. There is a second angle that small technologies can embrace. To me, this isn't a new revelation, but one where practice confirms theory.

What Happens If Nothing Changes

If you follow this thinking to its logical conclusion, outside of a few exceptions, each layer collapses on its most popular solution today. Frontend converges on React. Systems converges on Rust. Scripting converges on Python. Even the sites that are just pages converge on Next, fit be damned. That's a monoculture, arrived at not by anyone deciding libraries on their merits, but by a system that can no longer distinguish "abundant in the training data" from "better."

If you are a React fan, you should still be concerned. React was good because it had competition. Hooks arrived in a world where composition patterns were being explored. The React Compiler exists, in part, as an answer to the question signals-based frameworks spent years forcing: Why should the developer pay for re-rendering the world? React's greatest strength has always been its ability to metabolize pressure from outside. A monoculture doesn't just kill the alternatives. It kills the pressure. An ecosystem without pressure doesn't stay good. It stays stuck.

There is a path back. Teams publish analysis, not verdict. Model vendors evaluate what they ship in public. Libraries learn from StyleX's example and bank on verification. And the rest of us learn to distinguish output from argument before we amplify it. The last one we've been struggling with since the dawn of social media.

In the meantime, we can keep generating our rules files, llms.txt, docs over MCP, curated examples. We do all of it for Solid 2.0, and it helps a lot. But context is borrowed, not owned. It has to be injected into every session, by every tool, forever, while the inertia works against you for free.

Where Does the Next Idea Come From?

I want to leave you with a more probing thought. The question this all comes down to isn't whether Solid survives. We're fine. We are shipping the biggest release in our history, with a community that chose this framework on purpose and, more importantly, knows why.

The question is where the next idea comes from.

Every paradigm that has mattered started as something the establishment couldn't write. React was mocked for almost a year over JSX. Markup in JavaScript? Are you insane? What about separation of concerns? If today's machinery had existed in 2013, models trained on a web that was all jQuery and Backbone, docs canonizing migrations everyone was already making, verdicts circulating months ahead of their arguments, do you think it could have gotten past that stage?

It didn't win because the defaults favored it. It won because people made a verifiable case in public. And I don't think the mechanisms are gone. Migrations have never been cheaper, in every direction. The door out of any monoculture has never been more open. We just need to keep analysis as part of the conversation even as we distance ourselves from the implementation. That's being informed. That's taking responsibility.

Next.js fixes two critical RCE flaws, including a Windows-only attack

Fri, 28 Aug 2026 12:13:08 +0000

Vercel has patched two critical unauthenticated remote-code-execution vulnerabilities in Next.js, including a Windows-only path-traversal flaw rated CVSS 9.0 and an AVIF image-processing bug rated CVSS 9.5. Administrators should upgrade immediately: no workaround is available for affected Windows deployments, while AVIF-enabled sites may be exposed to malicious image files.

Source

Claude Cowork adds a browser for web tasks—with new admin and login risks

Fri, 28 Aug 2026 12:13:08 +0000

Claude Cowork can now open a separate browser inside the Claude Desktop app, allowing it to navigate websites, read pages, click links, fill forms, and collect data without an extension. The built-in browser is rolling out to Pro, Max, and Team users, while Enterprise administrators can manage it for their organizations.

Source

In defense of two-state theme toggles - Josh Collinsworth blog

Thu, 27 Aug 2026 06:13:09 +0000

In defense of two-state theme toggles

Published: August 21, 2026
Last updated: August 22, 2026

In case you haven’t kept up on the most recent ~~bikeshedding~~ discussion in frontend: there’s a lively debate going on over the merits of a simpler two-state theme toggle (light/dark), vs. a more explicit three-state toggle (with dark and light, plus a third “system” option), and whether the clarity of that third option is worth the additional complexity it introduces.

But let’s back up to where this discussion started, and talk a little bit more about the details and tradeoffs those two approaches, before I start weighing in on what I think is (and is not) ideal, and why.

The origins of the debate

A couple of weeks ago, Lea Verou published an excellent post titled Dark mode toggles: two states are enough. (Evidently, this discussion had been ongoing for a good while prior.)

The post is thorough and insightful. Dr. Verou lays out her case that a two-state is enough most of the time, in the case of a switch that’s part of the main site UI. That last part’s important:

In most cases, users aren’t looking for that third “system” option, and aren’t likely to find it useful. They’re just looking for the light switch.

There are, of course, exceptions. For example, in a dedicated settings page, where the mental model is less “what do I want right this second” and more “what do I want this app to be like in the future?” a three-state toggle makes more sense. Dr. Verou’s post makes this abundantly clear, and I tend to agree.

Aside from the binary vs. trinary discussion: I find Dr. Verou’s two-state implementation particularly clever. Under the hood, rather than explicitly toggling between “light” or “dark”, it toggles between falling back to the system setting, and the opposite of the system setting.

That is: rather than saving either a light or dark theme preference permanently in localStorage, Dr. Verou’s implementation stores your preference only if that preference is different than your device setting. In that case, the site saves whatever theme that happens to be.

Otherwise—or should the user toggle the theme once again—rather than storing the newly selected theme (which now once again matches their OS preference), the saved preference is simply deleted, causing the site to once again default to the device preference. This is important, because a common criticism of binary light/dark controls is that they lock you into one or the other, with no way to get back to your system preference; this two-state toggle neatly avoids that lock-in.

A couple of other points made in the post:

With a three-way toggle, at any given time, two of the three options will do the same thing. This is a bit redundant, and creates at least some complexity by offering users more choice than they might want (or even understand; more on that in a bit).
This is not a one-size-fits-all implementation. I know I’m already repeating myself here, but many seem to overlook this point. The argument for two-state is subject to context.

I keep harping on that because it seems like it gets lost in the conversation. 1

The pushback against a two-state implementation—despite the aforementioned caveats and nuances—has seemed loud and severe, at least in my circles of the web. Some in the frontend community seem to feel denying users that third option is something akin to malpractice; a choice that nobody who truly cares about users could possibly make. 2

Perhaps the most visible rebuttal is Bramus’s The Case for Tri-State Dark Mode Toggles. That post does a serviceable job making its titular case (despite the irony that the site that post is published on offers no theming or theme toggle at all), so it’ll serve as my focus for addressing the dissenting opinion.

Addressing the case for tri-state theme toggles

Almost all arguments against the two-state toggle and in favor of a three-state option boil down to one of two concerns:

Favoring clarity over simplicity; or
Accounting for users who might have a dynamic system theme, which changes between light and dark mode based on time of day.

The first point is valid, even if I personally believe the tradeoff is worthwhile in most cases (with the caveats already mentioned). It’s possible some users might want that choice, and it’s nice for them to have it if they do. Reasonable cases can be made both ways here, and—once again—context should affect the answer.

Dynamic themes, however, seem like a bit of an extreme edge case to me.

I say “edge case” because, while we don’t have data directly from Apple or other device vendors, what little we do know from independent surveys suggests a very small minority of users favor a dynamic theme. There’s good reason to think it’s likely a low single-digit percentage of users. 3

But remember: the two-state approach isn’t automatically an issue for those users. A two-state toggle doesn’t actually become a problem for users with a dynamic OS theme, except in the following case:

Somebody with a dynamic theme enabled visits the site and decides to change the site’s theme manually
They come back to the site later, after their dynamic theme has shifted between light and dark, and
Upon that change, the theme is not what the user wants, and they want to change it again

That’s a lot of conditions to build a UI around, and a user has to get through all of them before we’ve maybe got a problem. Even if we assume 10% of all users have a dynamic OS theme (which, again, is almost certainly an extreme overestimate), some portion of those users are dropping off at every step above. What we’re left with is quite likely very close to zero.

And even in that case, let’s remember: the problem in question is literally one extra click, for whatever vanishingly tiny percentage of users remain at the end of all those logic gates.

Now, to be clear: I do not advocate for ignoring a group of users simply because they’re in the minority. (That’s how a lot of accessibility failures happen, among other terrible outcomes.) That’s not what this is; don’t take this out of context.

Some people have theme preferences for important reasons, like vision. One mode or the other simply doesn’t work for them. We should absolutely respect that.

The difference in this case is: we’re not talking about something like ability, bandwidth, device power, or any other factors a user might not be able to control; we’re talking about a choice they made freely and independently.

Further: we can safely assume this choice is not accessibility-related, as any user whose vision allows them to opt comfortably into both light and dark mode at varying times of the day clearly isn’t hindered by either one. (More likely, they’re merely concerned with screen brightness, or just variety.)

And in a case where a small minority of users has explicitly opted in to an unusual experience, and, as a direct result of that uncommon choice, in certain circumstances, might make further choices that could cause them to encounter unexpected behavior, depending on what their expectations were to begin with—none of which is actually an issue for them, but merely a preference, resulting, worst-case, in a single extra click—

Well, I have a very difficult time adding extra complexity for the other ~95% of users, based solely on that deep hole of what-ifs those users dug for for themselves in the first place.

Personally: I suspect a user who wants their machine to alter the theme for them probably isn’t picky enough to change it in the first place. But even if they do, I have a hard time imagining that person being terribly surprised or interrupted simply by encountering one or the other, when they’re already used to both.

Or, to put it more bluntly:

I’m not sure real users actually have this problem. I think we’ve mostly invented it.

Which actually brings me to my next point…

“System” is unclear to many users

It’s a common pitfall of human psychology that we imagine everyone thinks like we do. Finance people think everyone understands interest and investments; car people think everyone knows how to change their oil; developers think everyone obsesses over color themes.

But I see little evidence of non-computer-nerd users caring nearly as much as we seem to. Many users have a preference, certainly, but I severely doubt most users think even a tiny fraction as much about theming as we do.

Our curse of knowledge makes us forget not everyone knows everything we do about color themes. Many users likely don’t have any understanding of them at all.

To test my theory, I asked my wife (who is not a developer, but who regularly uses a smartphone, an iPad, and a laptop) what color theme her phone is set to; light or dark.

She had absolutely no idea.

Despite spending hours a day looking at her phone, she literally had to check it to find out what her default color theme is; it’s that invisible to her. (Interestingly: she herself was surprised to find out she’s actually been looking at dark mode this whole time without even realizing it).

I asked whether she has the same preference set for her other devices; she didn’t know that, either.

Then I asked whether she’s ever pressed the button on a site or app to change to another color theme.

She said no. Literally never.

Basically: she knew light mode and dark mode both existed, and that was the entirety of her knowledge and experience on the topic, even as it pertained to her own preferences.

Now, I acknowledge this is only one singular data point. I don’t for a moment pretend this is meaningful research, or imagine my wife happens to represent the majority of any user base. Users undoubtedly exist on a wide spectrum between her and, well, nerds who think about this stuff enough to write blog posts about it. (Ahem.)

But still: this unavoidably indicates that some number of users don’t even know what their system theme is—or might not even understand what “system” means in the first place!

I suspect a non-trivial number of users probably aren’t even aware they have a default theme, simply because they’ve gotten so used to whatever is currently set on their device they forgot they ever set anything at all. They think things just look the way they look.

A “system” setting is actively unhelpful to those users. To provide that option is to throw extra complexity at them, which could very well be confusing (especially because, again: two of the three options look exactly alike, and a user might not understand what the difference is, or might even think one of the three is broken).

And that’s all assuming the word “system” (or “OS” or “device” or whatever) is present to begin with; many three-state toggles simply show a little computer-like icon, which could quite easily compound the confusion.

Bramus at one point asserts a tri-state toggle makes users think less (with a nod to the Steve Krug book), which, as I hope I’ve made clear by now, is very likely not the case for a significant number of users. So that appeal to authority is misplaced, in my opinion.

You and I know what that computer icon means, but would everyone you know immediately understand it, without thinking? I suspect not.

“System” is only useful in highly specific situations

It’s worth noting that because the “system” option is the default anyway, it’s only important if somebody switches away from it, and then wants to switch back.

So in order for the “system” option to be useful, a minimum of four conditions must first be met:

The user must be aware of what their system theme is;
The user must also understand what that little computer icon represents (or otherwise, the option must clearly be labeled);
The user must have already switched away from their system theme, since it’s the default, and
The user must want to switch back to their system theme—and explicitly not just to whatever the opposite of the current theme happens to be

I suspect few users regularly, if ever, check all of those boxes.

I further suspect most who do are either already highly knowledgeable in this area, or are just deliberately running every setting through its paces for the sake of testing. (Personally, testing scenarios are the only times I can ever remember clicking the “system” option.)

Regardless, because people seem to skip over this point, I think it’s worth reiterating once more: this doesn’t mean we should never use a three-state toggle. They have their place, and context is important. I (and Dr. Verou, and others who favor two-state toggles) are completely in favor of three-state where it makes sense.

I just don’t think that’s in the main site UI.

The push to make tri-state the default is mostly in the name of accommodating an extreme minority of users that probably doesn’t even need accommodation in the first place, at the expense of likely confusing or slowing down at least as many more.

Questionable data

In The Case for Tri-State Dark Mode Toggles, linked above, Bramus points to a survey he conducted on social media, asking his followers whether they preferred a two- or three-state toggle. The survey closed with the overwhelming preference being three-state, but there are several issues with this approach to data collection:

First: people will always say they want more options. Psychologically, we imagine ourselves to prefer choice, even when we don’t actually use it or even want it in practice. The higher number pretty much always wins in a survey like this, regardless of topic. (Ask me how many options I’d like to have for dipping sauce, and I’ll probably say five or ten. But ask me how many I actually use, and I’ll probably say just one or two.) 4

Secondly: Bramus hints there’s an option he prefers, which could further skew the results; respondents might be compelled to guess what Bramus thinks the right answer is, rather than supply their own.

But most importantly: this audience is likely to be heavily comprised of developers. The result is therefore bound to reflect the opinions of developers, rather than the preferences of users. It means we’re probably hearing almost entirely from those with uncommonly deep knowledge of the topic (and uncommonly strong opinions on it), rather than from a representative group of users, whose own understanding and preferences could very well be different.

The Vale approach

In his post, Bramus also points to a tri-state implementation by Vale (AKA Declan Chidlow) that he feels may be the ideal middle ground, but I can’t say I agree it’s worthy of consideration. Here’s an embedded CodePen demo:

See the Pen Light/Dark/System Theme Setting by Declan Chidlow (@OuterVale) on CodePen.

It’s certainly clever; it appears to be a two-state toggle, but defaults to system preference by having neither option selected. If you do pick either theme, you can click it again to remove it, which causes the toggle to once more fall back to the system default.

I get why that feels nice. If somebody wanted to use this on their personal website or a small app, I’d say go for it. It’s neat.

But I would personally advocate against this approach at any meaningful scale.

My main issue with this implementation is: there is no existing affordance like this. There’s no common user control anywhere I’m aware of that matches this toggle or works like it; it’s novel, invented behavior, which users are unlikely to have ever encountered before. That’s bound to be unavoidably confusing, regardless of how clever it might be or what feature it’s actually manipulating under the hood.

It’s effectively a three-state toggle masquerading as a two-state, with properties of both checkboxes and radio buttons intermingled. Neither its true nature nor the option to deselect the current theme is at all apparent or discoverable, except by trial. (It’s ironic, then, that this approach is favored by some who critique the Verou approach over its lack of clarity and transparency.)

I suppose you could argue the Vale toggle functions as a two-way toggle frictionlessly enough, with a nice secret third option some users might learn about and use. But if you’re actually concerned about the system option being easily accessible, it makes for a strange choice.

[Edited 8/22/2026] Sara Joy pointed out on Mastodon that one advantage of Vale’s approach is: it makes what state you’re switching to abundantly clear. I agree that’s one very nice thing about it, and about tri-state, for that matter. This also brings up the question of what should be shown on a two-state toggle; the current state, or the new state the toggle will switch to if pressed, which I don’t think I have a strong opinion on at this point, but which I suspect could spark an entirely new lively debate all on its own.

So what’s the right approach?

After all of this, we we circle back once again to the original post, because despite all the pushback, Dr. Verou got it right in the first place. As always: it depends.™

If a toggle is a part of the main UI, make it a two-state toggle. This serves users who simply want to change the theme from whatever it happens to be at the moment, which will be the overwhelming majority of users, and the main purpose of any control that’s featured in the main user interface. Don’t give somebody configuration when they’re just looking for the light switch.
If it’s in a settings or account page, an explicit three-state toggle is probably better. If a user is in the mindset of setting up an app how they prefer, or choosing for their account, the choice is warranted. In those cases, users are deciding what experience they want to have in the future, and not just at this specific moment. (And, we have the space to dedicate to labeling each option clearly.)

Further, I’d say any app or site a user might be looking at all day long, or multiple times a day—Slack or GitHub, for example—probably warrants a three-way toggle. Most sites and apps won’t fall into this category, but some will.

But here I’m mostly just repeating what’s already been written quite clearly by Dr. Lea Verou.

Who is a woman.

With a PhD.

In usability.

From MIT.

So, ya know…maybe she knows what she’s talking about, dudes of the internet.

Knowledge Catalog: KI-Agenten sicher nutzen

Thu, 27 Aug 2026 00:41:05 +0000

Ein Knowledge Catalog macht Unternehmenswissen für KI-Agenten auffindbar, verständlich, überprüfbar und kontrolliert nutzbar. Genau darum geht es: Nicht jede KI soll alles lesen dürfen, sondern die richtigen Informationen im richtigen Geschäftskontext nutzen — mit klaren Zugriffsregeln, Verantwortlichkeit, Datenqualität und menschlicher Kontrolle.

Ich sehe bei KMU immer wieder dasselbe Muster: Die Begeisterung für KI ist groß, aber das Wissen darunter ist verstreut. Angebote liegen in alten Ordnern, Produktdetails in Word-Dokumenten, Website-Texte in WordPress, Kundendaten im CRM, Projektwissen in E-Mails, Entscheidungen in Chatverläufen und Kennzahlen in Excel oder BigQuery. Für Menschen ist dieses Chaos mühsam. Für KI-Agenten ist dieses Chaos ein Risiko.

Ein Knowledge Catalog ist deshalb kein reines Enterprise-Thema. Für kleine und mittlere Unternehmen ist ein Knowledge Catalog ein pragmatisches Ordnungssystem: Er erklärt, welche Informationen existieren, was diese Informationen bedeuten, welche Quelle vertrauenswürdig ist, wer zuständig ist und was ein KI-System damit tun darf. Das ist praktisches Wissensmanagement für Unternehmen, die KI nicht nur testen, sondern verantwortbar einsetzen wollen.

KI ist kein Shortcut. KI verstärkt das, was im Unternehmen bereits klar, gepflegt und verantwortet ist — oder das Chaos, das schon vorhanden ist.

Wenn Du KI-Agenten sinnvoll einsetzen willst, brauchst Du nicht zuerst das größte Tool. Du brauchst zuerst Klarheit über Dein eigenes Wissen. Genau hier beginnt KI-Readiness: nicht bei der Software, sondern bei der Frage, ob Dein Unternehmen weiß, was es weiß.

Warum ein Knowledge Catalog für KI-Agenten wichtig wird

Ein KI-Agent ist mehr als ein Chatfenster. Ein KI-Agent kann Ziele verfolgen, Aufgaben planen, Werkzeuge nutzen, Informationen abrufen und einzelne Prozessschritte selbstständig vorbereiten oder ausführen. Je mehr ein KI-Agent darf, desto wichtiger wird der Datenkontext.

Roher Datenzugriff beantwortet nur eine technische Frage: „Wo liegen die Daten?“ Ein Knowledge Catalog beantwortet die unternehmerisch wichtigeren Fragen:

Was bedeutet diese Information? „Umsatz“ kann brutto, netto, bezahlt, gebucht, prognostiziert oder storniert bedeuten.
Welche Quelle ist verbindlich? Die Website, das CRM, die Buchhaltung oder die letzte Angebotsvorlage?
Wie aktuell ist die Information? Ein veralteter Preisbaustein kann ein Angebot falsch machen, auch wenn die KI technisch sauber arbeitet.
Wer ist verantwortlich? Ohne klare Zuständigkeit korrigiert niemand falsche Definitionen, doppelte Dateien oder widersprüchliche Aussagen.
Welche Nutzung ist erlaubt? Eine interne Notiz darf vielleicht analysiert, aber nicht in eine externe Kundenmail übernommen werden.
Welche Daten sind sensibel? Kundendaten, Mitarbeiterdaten, Margen, Beschwerden und Verträge brauchen besondere Schutzregeln.

Ohne diese Klärung entstehen nicht nur technische Fehler. Es entstehen falsche Angebote, uneinheitliche Kommunikation, schlechte Reports, Datenschutzrisiken und automatisierte Entscheidungen, die niemand sauber verantwortet.

Das eigentliche Risiko: KI beschleunigt falsches Wissen

Viele Unternehmen fragen zuerst: „Wie können wir KI schneller nutzen?“ Ich frage meistens zurück: „Welche falschen, alten oder widersprüchlichen Informationen würde die KI dann schneller verwenden?“

Ein paar typische Beispiele aus KMU-Projekten:

Falsche Umsatzdefinition: Das Vertriebsteam spricht von Angebotswert, die Buchhaltung von bezahlten Rechnungen und die Geschäftsführung von geplantem Jahresumsatz. Ein KI-Agent erzeugt daraus ein Reporting, das plausibel klingt, aber drei Logiken vermischt.
Veraltete Angebotsbausteine: In einem Ordner liegen fünf Versionen derselben Leistungsbeschreibung. Die KI findet die alte Version mit einem nicht mehr gültigen Preis und baut daraus ein neues Angebot.
Uneinheitliches Markenwissen: Die Website spricht anders als die Verkaufsunterlagen, Social Media nutzt andere Begriffe und interne Präsentationen enthalten alte Positionierungen. Die KI schreibt dann formal passend, aber nicht markenklar.
Sensible Kundendaten: Ein Agent fasst Projektinformationen zusammen und übernimmt interne Bemerkungen, die niemals in eine Kundenkommunikation gehören.
Support ohne Freigabeprozess: Ein KI-System beantwortet Anfragen mit alten Garantiebestimmungen, weil niemand den gültigen Stand als Single Source of Truth definiert hat.

Das Problem ist nicht, dass KI grundsätzlich ungeeignet ist. Das Problem ist, dass ein KI-Agent ohne Geschäftskontext nicht wissen kann, welche Information verbindlich, aktuell, erlaubt oder riskant ist.

Data Catalog, Knowledge Catalog und Owned Knowledge einfach erklärt

Ein Data Catalog beschreibt vor allem Datenbestände: Tabellen, Spalten, Dateien, Systeme, technische Metadaten und Herkunft. Das ist wichtig, aber für KI-Agenten oft zu wenig.

Ein Knowledge Catalog geht weiter. Ein Knowledge Catalog verbindet Datenquellen mit Bedeutung, Geschäftskontext, Verantwortlichkeit, Datenqualität, Freigabeprozess und erlaubter Nutzung. Aus einer technischen Datenliste wird eine verständliche Wissenskarte für Menschen und KI-Systeme.

Der Unterschied lässt sich praktisch so beschreiben:

Data Catalog: „Diese Tabelle existiert, diese Spalten sind vorhanden, diese Datei liegt dort.“
Knowledge Catalog: „Diese Quelle ist verbindlich, diese Kennzahl bedeutet genau das, diese Person ist verantwortlich, diese Daten dürfen für interne Analyse verwendet werden, aber nicht für externe Kommunikation.“

Für KMU kommt ein weiterer strategischer Begriff dazu: Owned Knowledge. Owned Knowledge bedeutet, dass Dein wichtiges Unternehmenswissen nicht nur in Plattformen, Chatverläufen, Ordnern oder Köpfen einzelner Menschen liegt. Dein Wissen ist strukturiert, exportierbar, pflegbar und für Menschen sowie Maschinen nutzbar.

Viele Betriebe haben verstanden, warum Owned Media wichtiger ist als gemietete Reichweite. Die gleiche Logik gilt jetzt für Wissen: Wenn Dein Unternehmen sein Wissen nicht selbst strukturiert, werden Plattformen, Tools und einzelne Personen zur Abhängigkeit.

Was gehört in einen Knowledge Catalog?

Ein Knowledge Catalog muss nicht alles enthalten. Ein guter Knowledge Catalog enthält zuerst das Wissen, das für Entscheidungen, Kommunikation und wiederkehrende Arbeit wichtig ist.

Für ein KMU reichen zum Start meist diese Bausteine:

Quellenverzeichnis: Website, CRM, Angebotsvorlagen, Produktdaten, Projektmanagement, Buchhaltung, Cloud-Ordner, interne Dokumentation, Support-Wissen und Analyse-Tools.
Metadaten: Name der Quelle, Beschreibung, System, Format, Aktualität, Eigentümer, Sensibilität und Freigabestatus.
Begriffsdefinitionen: klare Erklärungen für Lead, Kunde, Auftrag, Umsatz, Marge, Projektstatus, Conversion, Wartung, Garantie oder Stammkunde.
Single Source of Truth: eindeutige Festlegung, welche Quelle bei Widersprüchen gilt.
Verantwortliche: Menschen, die fachlich entscheiden können, ob eine Information korrekt ist.
Zugriffsregeln: wer lesen, ändern, exportieren, analysieren oder KI-Zugriff erlauben darf.
Datenqualität: Hinweise zu Aktualität, Vollständigkeit, Dubletten, Fehlern, Unsicherheit und Freigabe.
Beziehungen: Verknüpfungen zwischen Produkten, Zielgruppen, Angeboten, Prozessen, Kampagnen, Kennzahlen und Verantwortlichen.
Testfragen: typische Fragen, die ein Mensch oder KI-Agent korrekt beantworten können muss.
Erlaubte KI-Nutzung: klare Regeln, ob ein Agent Informationen nur lesen, zusammenfassen, analysieren, vorschlagen, ausführen oder extern kommunizieren darf.

Gerade der letzte Punkt ist entscheidend. Ein KI-Agent, der interne Dokumente zusammenfasst, ist ein anderes Risiko als ein KI-Agent, der automatisch Angebote erstellt, Kundendaten verändert oder E-Mails verschickt.

Was darf ein KI-Agent mit welcher Quelle tun?

Ich empfehle kleinen Teams eine einfache Rechte-Logik. Nicht jede Quelle braucht denselben Schutz, aber jede wichtige Quelle braucht eine Entscheidung.

Lesen: Der KI-Agent darf Informationen abrufen, aber nichts verändern. Geeignet für freigegebene Wissensartikel, öffentliche Website-Inhalte oder interne Prozessbeschreibungen.
Zusammenfassen: Der KI-Agent darf Inhalte verdichten, etwa Projektstände oder Meetingnotizen. Sensible Aussagen müssen geprüft werden.
Analysieren: Der KI-Agent darf Muster erkennen, Kennzahlen vergleichen oder Fehlerhinweise geben. Voraussetzung sind definierte Begriffe und Datenqualität.
Vorschlagen: Der KI-Agent darf Angebotsbausteine, Antworten oder nächste Schritte vorbereiten. Ein Mensch gibt das Ergebnis frei.
Ausführen: Der KI-Agent darf Aktionen anstoßen, etwa Tickets erstellen oder Datensätze aktualisieren. Das braucht enge Regeln, Protokollierung und klare Verantwortlichkeit.
Extern kommunizieren: Der KI-Agent darf Inhalte nach außen senden. Das sollte in KMU nur mit sehr klaren Grenzen und menschlicher Kontrolle passieren.

Diese Abstufung wirkt einfach, verhindert aber viele Probleme. Denn sie zwingt Dich, zwischen „KI darf mir helfen“ und „KI darf für mich handeln“ zu unterscheiden.

Beispiele: Wo ein Knowledge Catalog im KMU-Alltag konkret hilft

Angebotsvorbereitung

Bei Angeboten wird Wissenschaos sofort sichtbar. Welche Leistung ist aktuell? Welche Formulierung ist freigegeben? Welche Annahmen gelten? Welche Referenzen passen? Welche Rabatte sind erlaubt?

Ein Knowledge Catalog kann Leistungsbeschreibungen, Preislogiken, Angebotsbausteine, Referenzen, Zielgruppen und interne Regeln so ordnen, dass ein KI-System sinnvolle Vorarbeit leistet. Der Agent erstellt dann nicht irgendein Angebot, sondern arbeitet mit freigegebenem Wissen. Wenn Du genau hier Zeit verlierst, ist der Beitrag zur KI-gestützten Angebotserstellung eine gute Vertiefung.

Interne Suche und Onboarding

Neue Teammitglieder fragen oft dieselben Dinge: Wo liegt was? Wer entscheidet was? Wie läuft ein Projektübergang? Welche Formulierungen verwenden wir? Welche Tools sind verbindlich?

Mit einem Knowledge Catalog entsteht eine semantische Suche. Semantische Suche bedeutet: Das System sucht nicht nur nach exakten Wörtern, sondern nach Bedeutung. Wenn jemand „Wie übergeben wir ein Website-Projekt?“ fragt, sollte das System Projektablauf, Checkliste, Verantwortliche, Vorlagen und Freigaberegeln finden.

Website- und Markenwissen

Als Branding-Stratege ist mir dieser Bereich besonders wichtig. Eine Marke besteht nicht nur aus Logo und Farben. Eine Marke besteht aus Bedeutung, Sprache, Haltung, Zielgruppenverständnis und wiederkehrenden Entscheidungen.

Wenn Dein Markenwissen sauber strukturiert ist, kann KI konsistenter schreiben, Inhalte prüfen und Widersprüche erkennen. Das betrifft Tonalität, Leistungsversprechen, verbotene Aussagen, Belege, Zielgruppen, Fachbegriffe und Positionierung. In unserer Arbeit rund um Branding und Positionierung wird deshalb immer klar: KI kann Markenarbeit unterstützen, aber sie darf Haltung nicht ersetzen.

Reporting und Kennzahlen

Reporting wirkt oft objektiv, ist aber in vielen KMU voller Interpretationen. Was ist ein aktiver Kunde? Wann zählt ein Angebot als gewonnen? Welche Kosten gehören in die Marge? Welche Kampagne bekommt die Conversion zugerechnet?

Ein Knowledge Catalog definiert diese Begriffe. Dadurch kann ein KI-Agent Reports besser erklären, Abweichungen einordnen und Fragen natürlicher beantworten. Google beschreibt zum Beispiel für Gemini in BigQuery Funktionen wie natürliche Sprache zur SQL-Generierung und Data Canvas zur Exploration von Datenassets. Gemini in Looker erlaubt Fragen an Datenquellen in natürlicher Sprache. Auch hier gilt: Natürliche Sprache macht schlechte Definitionen nicht besser.

Support und Kundenkommunikation

Ein KI-Agent im Support kann wiederkehrende Fragen schneller beantworten. Aber nur, wenn Garantiebedingungen, Leistungsgrenzen, aktuelle Produktinformationen und Eskalationsregeln gepflegt sind.

Ohne Knowledge Catalog kann Support-Automation Vertrauen beschädigen. Mit Knowledge Catalog kann ein Agent erkennen: Diese Antwort ist freigegeben, diese Information ist veraltet, diese Anfrage enthält sensible Daten, dieser Fall muss an einen Menschen.

Projektübergaben

In kleinen Teams steckt Projektwissen oft in den Köpfen einzelner Menschen. Wenn jemand krank ist, wechselt oder überlastet ist, entstehen Lücken. Ein Knowledge Catalog hilft, Übergaben sauberer zu machen: Projektziel, Status, offene Entscheidungen, Risiken, Ansprechpartner, Dateien, nächste Schritte und Freigaben werden auffindbar.

MCP einfach erklärt: kontrollierte Brücke statt Tool-Hype

Das Model Context Protocol, kurz MCP, ist ein standardisierter Weg, um KI-Anwendungen mit externen Datenquellen und Werkzeugen zu verbinden. Anthropic kündigte MCP am 25. November 2024 als offenen Standard für sichere Zwei-Wege-Verbindungen zwischen Datenquellen und KI-gestützten Tools an.

Für Dich als Unternehmer ist nicht die technische Architektur entscheidend. Wichtig ist die Logik: MCP kann eine kontrollierte Brücke zwischen KI-Agenten, Werkzeugen und freigegebenem Wissen sein. Ein Agent greift dann nicht unkontrolliert auf alles zu, sondern nutzt definierte Schnittstellen mit klaren Regeln.

Google Cloud dokumentiert, dass der frühere Dataplex Universal Catalog seit dem 10. April 2026 Knowledge Catalog heißt und Geschäftskontext, Governance sowie einen Kontextgraphen für KI-Agenten bereitstellen soll. Google beschreibt außerdem Knowledge-Catalog-Anbindungen mit MCP, Gemini CLI und MCP Toolbox. Für KMU ist daran vor allem die Denklogik relevant: MCP und Knowledge Catalog können zusammen helfen, KI-Agenten kontrolliert mit freigegebenem Unternehmenswissen zu verbinden.

Das ist ein aktuelles Produktbeispiel, aber nicht die einzige mögliche Umsetzung. Ein KMU kann mit Microsoft-Systemen, WordPress, CRM, lokalen Dateien, Notion, einem Wiki oder einer eigenen Datenstruktur starten. Die zentrale Frage bleibt immer gleich: Welches Wissen ist freigegeben, verständlich, aktuell und verantwortet?

Data Governance ist kein Bürokratiemonster

Viele kleine Unternehmen reagieren skeptisch auf Data Governance. Verständlich. Niemand braucht zusätzliche Bürokratie. Aber gute Data Governance bedeutet nicht mehr Papierarbeit. Gute Data Governance bedeutet weniger Risiko, weniger Suchzeit und weniger falsche Entscheidungen.

Für KMU heißt Data Governance vor allem:

klare Zuständigkeiten statt „das weiß wahrscheinlich jemand“,
freigegebene Quellen statt Dateien mit Namen wie „final_final_neu“,
verständliche Begriffe statt interner Abkürzungen, die nur zwei Menschen verstehen,
geprüfte Zugriffe statt blindem Vertrauen in jedes neue Tool,
regelmäßige Pflege statt einmaliger Aufräumaktion,
menschliche Kontrolle dort, wo eine Antwort rechtlich, finanziell oder menschlich relevant wird.

Besonders bei personenbezogenen Daten ist das nicht optional. Nach Art. 5 Abs. 1 DSGVO müssen personenbezogene Daten zweckgebunden, auf das notwendige Maß beschränkt und durch geeignete technische und organisatorische Maßnahmen geschützt werden. Für KI-Agenten heißt das: Nicht alles, was technisch lesbar ist, darf auch verarbeitet werden.

Welche Daten gehören nicht ungeprüft in KI-Systeme?

Ein Knowledge Catalog soll nicht alles öffnen. Ein Knowledge Catalog soll helfen, bewusst zu entscheiden. Besonders vorsichtig solltest Du bei diesen Daten sein:

personenbezogene Kundendaten: Namen, E-Mail-Adressen, Telefonnummern, Adressen, Kaufhistorien, Beschwerden oder Gesundheitsinformationen.
Mitarbeiterdaten: Verträge, Gehälter, Leistungsbeurteilungen, Krankheitsdaten oder interne Konflikte.
Finanzdaten: Margen, Liquidität, interne Kalkulationen, nicht veröffentlichte Umsätze oder Bankdaten.
Vertragsinformationen: Sonderkonditionen, rechtliche Verpflichtungen, Vertraulichkeitsklauseln oder laufende Verhandlungen.
Strategische Informationen: Preisstrategie, neue Produkte, interne Schwächen, Akquisepläne oder Wettbewerbsanalysen.
Ungeprüfte Notizen: Rohprotokolle, private Kommentare, nicht freigegebene Einschätzungen oder emotionale Zwischenstände.

Diese Daten können in bestimmten Fällen nutzbar sein. Aber nicht ohne Zweck, Zugriffskonzept, technische Schutzmaßnahmen, Protokollierung und klare Freigabe.

Die Minimalversion für kleine Teams

Du musst nicht mit einer großen Plattform starten. Für viele kleine Teams reicht eine einfache Minimalversion, die konsequent gepflegt wird.

Eine schlanke Startversion kann so aussehen:

ein zentrales Dokument mit den wichtigsten Quellen, Verantwortlichen und Regeln,
eine Wiki- oder Notion-Struktur für Begriffe, Prozesse und Freigaben,
ein definierter Ordner mit freigegebenen Angebotsbausteinen und aktuellen Leistungsbeschreibungen,
ein CMS-Bereich für Markenwissen, Leistungsseiten, Zielgruppen und Belege,
eine einfache Quellenliste mit Status: freigegeben, veraltet, unsicher, sensibel, nicht für KI-Nutzung.

Das klingt unspektakulär. Genau deshalb funktioniert es. Kleine Unternehmen brauchen am Anfang kein schweres System, sondern einen verbindlichen Ort und klare Pflege.

30- bis 90-Tage-Plan: So startest Du pragmatisch

Ein Knowledge Catalog wird nicht durch ein Tool eingeführt, sondern durch Entscheidungen. Ich würde den Einstieg in drei Phasen aufteilen.

Phase 1: Die ersten 30 Tage — Anwendungsfall und Quellen klären

Wähle einen konkreten Use Case: Angebotsvorbereitung, interne Suche, Reporting, Support oder Onboarding.
Formuliere das Ziel: Welche Arbeit soll leichter, sicherer oder schneller werden?
Liste die wichtigsten Quellen: maximal 10 bis 20 Quellen für den ersten Durchlauf.
Markiere sensible Quellen: Kundendaten, Mitarbeiterdaten, Finanzdaten und vertrauliche Dokumente.
Bestimme die Single Source of Truth: Welche Quelle gilt, wenn Informationen widersprüchlich sind?
Sammle echte Fragen: Welche Fragen stellt Dein Team heute immer wieder?

Nach 30 Tagen musst Du nicht fertig sein. Du solltest wissen, welcher Bereich zuerst geordnet wird und welche Quellen dafür zählen.

Phase 2: Tage 31 bis 60 — Begriffe, Qualität und Verantwortung definieren

Definiere zentrale Begriffe: Schreibe auf, was Umsatz, Lead, Projekt, Kunde, Auftrag, Marge oder Status bedeuten.
Lege Verantwortliche fest: Jede wichtige Quelle braucht eine fachliche Ansprechperson.
Bewerte Datenqualität: aktuell, veraltet, unvollständig, doppelt, widersprüchlich oder geprüft.
Definiere Zugriffsregeln: Wer darf lesen, ändern, exportieren oder KI-Zugriff erhalten?
Baue einen einfachen Freigabeprozess: Wer prüft neue Inhalte, bevor ein KI-Agent sie nutzen darf?
Entferne oder sperre Altlasten: Alte Preislisten und ungültige Vorlagen sind riskanter als fehlende Inhalte.

Nach 60 Tagen sollte Dein erster Knowledge-Catalog-Bereich so klar sein, dass ein neuer Mensch im Team die Logik versteht.

Phase 3: Tage 61 bis 90 — KI-Zugriff begrenzen und testen

Erstelle Testfragen: Nutze echte Fragen aus Angeboten, Support, Reporting oder Onboarding.
Teste Antworten gegen Expertenwissen: Stimmen Quellen, Definitionen und Schlussfolgerungen?
Begrenze KI-Rechte: Am Anfang lesen, zusammenfassen und vorschlagen — nicht automatisch ausführen.
Protokolliere Fehler: Jede falsche Antwort zeigt Dir, welche Quelle, Definition oder Regel fehlt.
Führe einen Pflege-Rhythmus ein: monatlich für operative Inhalte, quartalsweise für Begriffe und Regeln.
Entscheide den nächsten Use Case: Erst wenn ein Bereich stabil ist, kommt der nächste.

Wenn Du vorher Deinen Reifegrad einschätzen willst, kann ein KI-Readiness-Check für KMU helfen. KI-Readiness bedeutet nicht, dass alles perfekt sein muss. KI-Readiness bedeutet, dass Risiken, Daten, Prozesse und Verantwortlichkeiten bewusst geklärt werden.

Checkliste: Ist Dein Unternehmen bereit für den ersten Knowledge Catalog?

Wenn Du bei mehreren Punkten innerlich nickst, ist der richtige Zeitpunkt gekommen:

Dein Team sucht regelmäßig nach denselben Informationen.
Es gibt mehrere Versionen von Angebotsvorlagen, Preislisten oder Leistungsbeschreibungen.
Wichtige Prozessinformationen stecken in einzelnen Köpfen.
Kennzahlen werden unterschiedlich interpretiert.
CRM, Website, Buchhaltung, Projektmanagement und Cloud-Ordner enthalten jeweils einen Teil der Wahrheit.
Du willst KI-Agenten für Angebote, Support, Reporting oder interne Suche nutzen.
Es gibt sensible Kundendaten oder vertrauliche Projektdaten.
Niemand kann spontan sagen, welche Quelle verbindlich ist.
Neue Teammitglieder brauchen lange, um interne Abläufe zu verstehen.
Du möchtest KI nutzen, ohne Verantwortung an ein Tool auszulagern.

Wann ist ein Knowledge Catalog gut genug für den ersten KI-Agenten?

Ein Knowledge Catalog ist gut genug für den ersten KI-Agenten, wenn fünf Bedingungen erfüllt sind:

Der Use Case ist klar: Der Agent hat eine begrenzte Aufgabe, keine Allzweckrolle.
Die Quellen sind freigegeben: Der Agent nutzt nur geprüfte oder bewusst markierte Informationen.
Die Begriffe sind definiert: Zentrale Kennzahlen und Fachwörter sind eindeutig beschrieben.
Die Rechte sind begrenzt: Der Agent darf am Anfang eher vorbereiten als ausführen.
Der Mensch bleibt im Freigabeprozess: Kritische Ergebnisse werden geprüft, bevor sie Wirkung nach außen oder in Systeme hinein entfalten.

Das ist der Punkt, an dem KI praktisch wird. Nicht perfekt. Aber kontrolliert, lernfähig und verantwortbar.

Warum das auch eine Markenfrage ist

Ein Knowledge Catalog klingt zuerst nach Datenmanagement. In Wahrheit ist er auch Markenarbeit. Denn jede automatische Antwort, jedes Angebot, jeder Support-Text und jeder Report prägt, wie Dein Unternehmen handelt und wahrgenommen wird.

Wenn Dein Unternehmenswissen unklar ist, kommuniziert auch Deine KI unklar. Wenn Deine Marke sauber positioniert ist, Deine Website verständlich strukturiert ist und Deine Prozesse nachvollziehbar sind, kann KI diese Klarheit verstärken.

Deshalb denken wir bei Berger+Team Branding, Website, Marketing, Automation und KI nicht getrennt. In unserer Arbeit rund um KI und Digitalisierung geht es nicht darum, ein Tool einzubauen. Es geht darum, ein System zu schaffen, das Deinem Team Arbeit abnimmt und bessere Entscheidungen ermöglicht.

Mein Fazit: KI braucht Klarheit, nicht nur Zugriff

Ein Knowledge Catalog ist die Brücke zwischen Unternehmenswissen und verlässlichen KI-Agenten. Der eigentliche Wert liegt nicht im Katalog selbst, sondern in der Klarheit, die dadurch entsteht: Welche Daten sind relevant? Was bedeuten diese Daten im Geschäftskontext? Wer ist verantwortlich? Was darf ein Agent tun? Was muss ein Mensch freigeben?

Für KMU ist das eine echte Chance. Kleine Unternehmen können schneller entscheiden, pragmatischer strukturieren und näher am eigenen Wissen arbeiten als große Organisationen. Aber nur, wenn KI nicht als Abkürzung missverstanden wird.

Mein Rat: Baue zuerst Dein Owned Knowledge auf. Starte klein, aber verbindlich. Wähle einen Use Case, kläre Quellen, definiere Begriffe, lege Verantwortliche fest, begrenze KI-Zugriffe und prüfe Ergebnisse menschlich. Dann wird KI nicht zum unkontrollierten Experiment, sondern zu einem Werkzeug, das Klarheit verstärkt.

FAQ: Knowledge Catalog, KI-Agenten und Unternehmenswissen

Was ist ein Knowledge Catalog?

Ein Knowledge Catalog ist eine strukturierte Wissens- und Metadatenkarte Deines Unternehmens. Er beschreibt, welche Daten, Inhalte und Prozesse existieren, was sie bedeuten, wer verantwortlich ist, welche Qualität sie haben und wie Menschen oder KI-Agenten sie nutzen dürfen.

Was ist der Unterschied zwischen einem Knowledge Catalog und einem Data Catalog?

Ein Data Catalog zeigt vor allem technische Datenbestände wie Tabellen, Dateien, Spalten und Systeme. Ein Knowledge Catalog ergänzt diese Sicht um Geschäftskontext, Begriffsdefinitionen, Verantwortlichkeit, Datenqualität, Freigabeprozess und erlaubte KI-Nutzung.

Warum brauchen KI-Agenten Geschäftskontext?

KI-Agenten brauchen Geschäftskontext, damit sie Informationen richtig einordnen können. Ohne Kontext kann ein Agent alte Preise, falsche Umsatzdefinitionen oder sensible Notizen verwenden und daraus scheinbar plausible, aber riskante Ergebnisse erzeugen.

Wie klein kann ein KMU starten?

Ein KMU kann sehr klein starten: mit einem Use Case, einer Quellenliste, einem Glossar für zentrale Begriffe und klaren Verantwortlichen. Für den Anfang reicht oft ein Wiki, ein strukturiertes Dokument oder ein freigegebener Ordner, wenn Pflege und Zugriffsregeln verbindlich sind.

Was kostet der Einstieg in einen Knowledge Catalog?

Der Einstieg hängt weniger vom Tool als vom Umfang ab. Wenn Du mit einem klaren Anwendungsfall startest, entstehen die größten Aufwände meist durch Sichtung, Bereinigung, Definitionen und Freigaben — nicht durch Software.

Welche Tools brauche ich für einen Knowledge Catalog?

Für den Start brauchst Du nicht zwingend ein spezialisiertes Enterprise-Tool. Ein Wiki, Notion, SharePoint, ein sauberes Ordnersystem, ein CMS-Bereich oder ein internes Dokument können reichen; wichtig sind Struktur, Verantwortlichkeit, Aktualität und klare Regeln für KI-Zugriff.

Wer sollte im Unternehmen verantwortlich sein?

Die Verantwortung sollte nicht allein bei der IT liegen. Fachverantwortliche müssen entscheiden, ob Inhalte korrekt sind, während Geschäftsführung oder Projektleitung Regeln für Zugriff, Freigabe und Nutzung festlegen.

Welche Daten dürfen nicht ungeprüft in KI-Systeme?

Personenbezogene Daten, Mitarbeiterdaten, Finanzdaten, Vertragsinformationen, interne Strategien und ungeprüfte Notizen dürfen nicht ungeprüft in KI-Systeme. Diese Daten brauchen Zweckbindung, Datenminimierung, Zugriffsschutz und eine klare Entscheidung, ob ein KI-Agent sie überhaupt verarbeiten darf.

Was hat MCP mit einem Knowledge Catalog zu tun?

MCP steht für Model Context Protocol und kann KI-Anwendungen kontrolliert mit freigegebenen Datenquellen und Werkzeugen verbinden. In Verbindung mit einem Knowledge Catalog hilft MCP, dass ein KI-Agent nicht beliebig auf Daten zugreift, sondern definierte Quellen, Regeln und Grenzen nutzt.

Wie hilft ein Knowledge Catalog gegen KI-Halluzinationen?

Ein Knowledge Catalog reduziert Halluzinationen, weil KI-Agenten auf geprüfte Quellen, definierte Begriffe und freigegebenes Wissen zugreifen. Der Katalog ersetzt keine menschliche Kontrolle, aber er gibt dem KI-System eine belastbare Grundlage.

Wann darf ein KI-Agent automatisch handeln?

Ein KI-Agent sollte erst automatisch handeln, wenn Quellen, Regeln, Verantwortliche, Tests und Protokollierung stabil sind. In KMU ist es meist sinnvoll, zuerst mit Lesen, Zusammenfassen und Vorschlagen zu starten und kritische Aktionen durch Menschen freigeben zu lassen.

Wie oft muss ein Knowledge Catalog gepflegt werden?

Operative Inhalte wie Preise, Leistungen und Support-Regeln solltest Du mindestens monatlich prüfen. Begriffe, Zugriffsregeln und Datenqualität kannst Du in vielen KMU quartalsweise überprüfen, solange es bei wichtigen Änderungen einen direkten Freigabeprozess gibt.

Quellen

OpenAPI für Unternehmensservices: vom Prozess zur Agent API

Thu, 27 Aug 2026 00:40:57 +0000

OpenAPI macht Unternehmensservices maschinenlesbar und als API-Vertrag überprüfbar. Der Leitfaden zeigt KMU, wie sie Prozesse, Daten, Berechtigungen und menschliche Freigaben kontrolliert in eine Service-Schnittstelle übersetzen.

我讨厌红点

Wed, 26 Aug 2026 21:27:04 +0000

不知道从什么时候开始，各种应用的用户界面都出现了红点这个东西。有红点的地方，通常是内容有更新，鼓励用户点进去。点进去再出来，红点自动消失。短信如此，微信如此，这种用户界面元素已经普及到生活中方方面面的应用，我想大家都已经熟悉并不假思索地去点有红点的地方了吧。我不否认它合理有效，但今天我偏要挑一挑它的毛病。

从用户角度

首先，它很丑。红点点在那里，我想大多数人都觉得不是很爽吧。我没有什么洁癖，但我可以观察到有点洁癖的人，常常会努力地去把所有的红点点掉，从而还给应用界面一个清净。当点红点已经不是实现目的的手段而是目的本身的时候，它的意义也就不大了，反而它的负面作用就越来越显著：让用户焦虑，降低用户的注意力时长，把用户训练成为一个点红点的机器。

再者，红点这种用户界面元素有被滥用的趋势：应用有更新来个红点，有小功能想向用户推荐也是红点，再往后是不是有广告也会是红点呢？这个问题其实是上个问题的延申，当用户已经被训练成不假思索地去点红点的时候，应用作者和用户的角力就进一步失衡，应用作者在资本的影响下更可以为所欲为，挤压用户的注意力，让用户成为应用的奴隶。红点虽然不是罪魁祸首，但它确实是一个奴化圈养用户的重要手段。

最后，我想说的是点或不点什么，看或不看什么，是用户的自由，也是用户的隐私。诚然，你点了什么，看了什么，应用有本事知道，并能搜集数据到后台丰富你的用户绘像，有没有红点它们都做的到。但是，红点给了它们一个光明正大的理由来搜集这种数据：我们本不想记录用户什么看过什么没看过，是为了实现红点这种用户需要的功能勉为其难嘛。当一个卑劣的目的披上了合理的外衣，用户也就见怪不怪了。

从应用开发者角度

我不仅是个用户，我自己也做一点互联网应用。从应用开发者角度，这个功能实现也是给我不少困扰的。

已阅状态应该是什么时候标记的呢？我能想到的有下面三种可能：

点的这个动作触发
第一次呈现给用户时触发
当用户从呈现页面点到别处的时候触发

深究下以上三种方法都有问题。在第一种方法下，用户点了可能未必看，而且内容入口可能有多个，每个入口都要做动作吗？在第二种方法下，用户仍然可能看0.1秒或者1分钟，应用端无法区分，甚至无法区分是人还是机器。最后一种方法貌似最精确，可惜用户想离开的话可能直接关窗口，应用来不及动作。所以，已阅与否永远是不精确的，应用的状态通常和用户的期望有相当差距。

另一个问题就在于我完全不想对用户做绘像，所以，实现已阅与否的状态存储和及时切转对我来说没有好处，只有负担，而这个负担还不小：我可能有很多内容，我也可能有很多用户，这是个 MxN 的问题，如此大的状态空间，存储和维护对我都有不小的压力。

没有红点行不行

没有红点，应用作者还是有不少方法和用户沟通：需要用户立即反应的时候可以弹窗，这种需求应该很罕见，所以动用弹窗这种强硬手段不会引起用户不满。需要用户延时反应的时候可以推送消息，给用户时间自主反应。这种需求比第一种需求多些，也不是天天都有。以上两点都是红点时代之前就常用的方法，现在也没有过时。

红点有一定意义的地方就在于告诉用户哪些内容有更新，这样防止用户点进去发现没更新导致失望，或者忽略了更新导致错过了。没有红点，应用还是可以对内容根据更新时间排序，有心思的用户可以从头一个一个点，直到自己觉得无聊为止。失望或错过是上网不可避免的遭遇，我不觉得我有必要给我的用户营造一个假象。

说到底，红点是当一个页面内容太多太繁杂，为了给用户提供一个视觉上的优先级提示而应运而生的。我觉得问题的核心不是该如何提醒用户什么可以先点，什么可以不着急点，而是该如何精简内容，解放用户。这样不仅解决了用户界面问题，还可以让用户早点放下手机，合上电脑，这才是双赢。

可惜，双赢通常不是商业应用的目的。

Nobody has reached the bottom (yet) · Ata Kuyumcu's Blog

Wed, 26 Aug 2026 20:33:33 +0000

Update, 2026-08-13
The title lasted eight hours. Four sessions have reached depth 13, and all four walked back out through the arch with their gold: 178, 252, 273 and 635. The rest of the post is left as it was.

The dungeon under this blog has a bottom now. Depth 13, with a sensible end to the gameplay loop. The rest of this post is three-ish days of analytics from the dungeon, and the caveats are at the end because they matter more than usual.

The door

1,040 entries against 4,216 visits in the same window. A quarter of the people who came to the blog got in, which sounds better than it is, because most of them came for a post that lists the ways in.

The ranking is what I didn’t predict:

pie showData
    title Ways in
    "tapped" : 575
    "konami" : 251
    "dungeon" : 95
    "xyzzy" : 75
    "iddqd" : 26
    "delve" : 16

Tapping the footer was the afterthought. It exists because the Konami code needs a keyboard and a lot of readers might not have one, and it took about as long to write as this paragraph. It beat every other path, surprisingly.

Most players did meet somebody

The first post ended by saying I had modest expectations about two strangers finding each other down there. 530 sessions saw another living player. There were 1,040 entries, and 893 sessions the close event managed to catch.

I want to be careful about why that happened, because it isn’t the netcode. Everyone joins a room named after the UTC date, so the only thing standing between two readers is whether they were reading at the same time. For three days they usually were. The blog served 4,216 visits in that window against 15,171 in its entire history, which is to say the dungeon has spent its whole life inside one spike.

When the spike flattens, the meeting rate goes to about zero, and no amount of WebRTC changes that. A multiplayer easter egg on a personal blog is a party that works while people are still arriving. I knew that in the abstract before I built it. The number makes it specific: the feature I’m fondest of has a half-life of a few days.

One thing in here I didn’t expect at all. Graves started holding the dead player’s purse yesterday, so walking over somebody’s death pays. Three graves have been robbed. Two of them belonged to a stranger.

Where people die

Depth 2 kills more people than depth 1 in raw count, on 43% fewer arrivals. That isn’t tuning. It’s the monster table climbing faster than ten hit points can absorb, and depth 2 is where a player who’s still pressing arrow keys politely finds out.

The bigger drop is earlier, and it isn’t deaths. 996 people arrived at depth 1. 144 died there. 568 went deeper. The other 284 stood in a stone room, took no damage worth dying to, and left. The first floor is where people decide whether they’re playing.

The whole funnel, floor by floor:

---
config:
  sankey:
    nodeAlignment: left
    labelStyle: outlined
    height: 420
---
sankey-beta

entered,d1,996
entered,stayed in the village,44
d1,d2,568
d2,d3,389
d3,d4,262
d4,d5,164
d5,d6,115
d6,d7,59
d7,d8,48
d8,d9,24
d9,d10,14
d10,d11,3

Every step is the arrival count from the table, so the gap between one floor and the next is everyone who died there or stopped. Depth 11 is the one step that isn’t measured: the arrival event recorded nobody down there, and the three deaths are people a fall trap dropped out of depth 10, by a route that never fires an arrival. Falls feed the floors above it too, which is why the descent counts run low and every per-depth rate in this post is a ceiling.

Traps sprang 1,110 times, 872 gas and 238 falls. 258 chests turned out to have teeth. The dark came for someone 82 times, all of them on depth 5 or deeper, which is the only place it lives.

What’s down there that nobody has used

Zero sessions have reached depth 13. Zero have walked back out through the arch, which is the only exit that isn’t dying and the only way gold survives a run. The deepest anyone has been is 11, twice.

The rest of the tail is about as thin. 437 of 893 sessions killed nothing at all; one killed 114. 702 ended holding no gold; two ended holding 224. The median session is 31 seconds.

That last number is the honest shape of an easter egg. Most people open the door, look at the room, and close it.

So I built a farm

319 of 893 sessions never went down the stairs. 36% of the people who find a secret dungeon do not want a dungeon. They wanted to find something, and they did.

The village used to be a well, a signpost and an arch. Yesterday it got a farm: a farmer with three lines about the hole under the arch, and a cow, a sheep and chickens that wander a tile at a time and say something when you walk into them. The talk event fires once per speaker per session, so it counts sessions that found the cow rather than how many times somebody walked into a cow.

Eight sessions found the farmer, five the chickens, four the cow, four the sheep. Twenty-one bumps, one day up, on the wrong side of the spike. That’s a baseline, not a verdict.

What the numbers can’t say

More of this than I’d like.

Falls didn’t count as descents until this morning. A fall trap drops you a floor by a route that never fired the arrival event, 238 times, which is why the table above has three deaths at depth 11 and nobody arriving there, and why depths 5, 7 and 9 read as deadlier than they are. Every per-depth rate in this post is a ceiling.

The session event rode pagehide until yesterday. Mobile browsers kill hidden tabs without firing it, which is where the missing sessions went. It fires on first background now, and that trades one bias for another: a reader who tabs away and comes back is measured up to the moment they left, so long sessions read short.

The trap event carries the kind and the depth as two properties of the same event, and I can’t join two properties through a share link. I know there were 872 gas traps. I have no idea where any of them sprang.

Umami derives its session id from IP and user agent and resets it daily, so “did anyone come back the next day” isn’t a question I can ask.

Some of it is coarse because I made it coarse. The session event carries four numbers about the run and nothing about the person: no input method, no step count, no path through the floor.

I’ve stopped adding rooms. Depth 13 is the end and the few floors above it stay deliberately empty so the final approach is a walk rather than a fight, and at some point somebody is going to get there.

WebSockets vs. SSE should be about ordering and correctness - Dashbit Blog

Wed, 26 Aug 2026 16:45:14 +0000

WebSockets vs. SSE should be about ordering and correctness

A couple days ago, Andros, the maintainer of Django LiveView, wrote an article called HTML over WebSockets: real-time SPAs with barely any JavaScript. While the article does an overall good job of outlining the pros and cons of WebSockets and the LiveView architecture (reduced payloads, simplified stack, etc.), the top comment in the Hacker News discussion for said article says:

For most apps just use SSE and the built-in code for making HTTP requests (Fetch) instead of hacking up your own client side JS to make requests over a WebSocket. The latency is the same because modern browsers multiplex HTTP requests over a single TCP connection that is left open.

To begin with, while Fetch will indeed reuse existing connections, requests are still stateless and therefore every request has to do the same work of decrypting session information, fetching the user from database or cache, and so on. With WebSockets, the connection is authenticated once and the user data is in memory, avoiding all this extra work. Furthermore, in the case of Phoenix LiveView, it actually sends diffs over the wire, rather than HTML, which reduces payload sizes drastically.

However, I’d say those benefits are secondary. The discussion around delivering HTML over WebSockets vs. Server-Sent Events (SSE) with Fetch should really be about event ordering and correctness. When using different data streams, it is very easy to receive and render events in the wrong order, resulting in confusing user experiences or misleading users into making the wrong decisions. As we will see, attempts to fix this typically mean more client complexity, increased latency, or both!

The ordering issue

Imagine you have an article with three tags: “erlang”, “clojure”, and “javascript”. Then, at the same time, you decide to add the “elixir” tag, while another user decides to remove the “javascript” tag. Here is what most people expect to happen:

Loading event sequence…

In the example above, the database ends up with a list of “erlang”, “clojure”, and “elixir”. And your UI shows the exact same list, with “erlang”, “clojure”, and “elixir”. All is good!

However, thanks to the network, garbage-collectors, proxies, and other factors, the following is also a possible ordering of those events:

Loading event sequence…

In this new version, the delete operation executed first, but its update with the list of tags arrived later. This means your interface will briefly flash a list with “erlang”, “clojure”, and “elixir” as tags, but ultimately display only “erlang” and “clojure”. Basically, your interface will act as if the “elixir” tag was not added at all. And it won’t fix itself unless you refresh or a new event is sent over the wire.

At this point, some people like to yell, “that’s fine, it is eventually consistent.” Except that’s not what eventually consistent means. Generally speaking, an eventually consistent system guarantees that, if no new updates happen, all copies of the data will eventually converge to the same value. That won’t happen here. The interface can remain stale indefinitely, until you refresh the page or another event happens to bring it back in sync.

The root cause of the issue above is data being delivered over two different streams, it is not really intrinsic to SSE. For example, any application using WebSockets + Fetch to deliver different streams that update the same UI components would have the same race. The difference is that WebSockets are bidirectional, so you can do both reads and writes over the same connection:

Loading event sequence…

In the example above, the WebSocket connection is responsible for processing user events and recomputing updates, ensuring the correct tags list is delivered regardless of the order of events.

Making concurrent requests work

As we have seen above, when using SSE + Fetch, we may have two concurrent requests. If both deliver data, we can have data races as there is no causal ordering between them.

The simplest solution is to make it so only one of those streams deliver updates. For example, you could make it so Fetch only performs the update but doesn’t deliver or render the tags list. Instead, the client waits until the update is delivered via SSE. The trouble with this approach is increased latency, as you need to rely on a queue system to deliver your own updates between servers:

Loading latency sequence…

The above is actually similar to how the long polling transport works in Phoenix. Except that we can skip one hop in Phoenix, as the nodes can communicate directly with each other via Distributed Erlang:

Loading latency sequence…

Using a bidirectional connection can skip those additionals hops altogether:

Loading latency sequence…

Because WebSockets are bidirectional, they provide a cheap way to preserve ordering between client operations and their responses, without the need to route your own operations through a separate delivery channel.

Another alternative is to use the SSE channel to simply tell the client, “hey, refresh, you have new data.” Then you don’t need additional hops on the server for your own writes. However, it will most likely lead to increased server load, as you must do additional requests to fetch the latest data instead of them being delivered over SSE. Also, you must be careful not to perform multiple fetches concurrently, instead queue operations on the client and give higher priority to user interactions.

You could even make multiple streams work by receiving the events out of order and ordering them on the client. This unfortunately sounds much simpler than it actually is. For example, you may have no guarantee that an event creating a resource arrives before its deletion, or that the order of updates matches the database operations. That’s why there are whole platforms, like Electric, designed to solve those issues for you.

Summing up

Next time you are debating WebSockets versus SSE, ask yourself: how will I guarantee events are delivered in the right order, and avoid confusing users with stale or incorrect data?

Whenever you have multiple streams of data, they can race each other, regardless if you are using WebSockets or SSE. WebSockets give you a bidirectional channel that can act as a simple foundation for preserving causal ordering between user actions and server updates. SSE + Fetch can be made to work, but it often comes with additional latency from routing data internally. And regardless of whether you pick WebSockets or SSE, Phoenix gives you the best bang for your buck, as you can simplify your operations and reduce latency thanks to Elixir and Distributed Erlang.

This article was fully written by a human and proof-read by LLMs. The interactive examples were fully produced by a coding agent under adult supervision.

Migrating from Codeberg Pages to an OpenBSD VPS - Nemin's Blog

Tue, 25 Aug 2026 17:05:50 +0000

Background
- Picking my provider
- SSH config
  - Be careful with MIMEs
- Upgrading OpenBSD to 8.0-beta
- Firewall
- TLS certificates
- Web server
German bureaucracy
Setting up my VPS
Findings; or, Bots Love Your Obscure Content!
Conclusion
Footnotes

In this post I'd like to explain the "how"-s and "why"-s of moving from forge-based static site hosting to a full on VPS.

This isn't really a tutorial, mostly because there are far better texts out there how one would do these things, but I do link to many of them and point out stuff I found confusing or surprising.

Also, if you're reading this post, you're reading it served by the VPS, say hi!

1 Background

I've been blogging for almost eight years now and for those eight years, I've always relied on some sort of free host for my content. This seemed fine for a pretty long time, especially considering neither this nor my other site is monetized at all. However, recent-ish changes in my needs and financial situation finally got me to break with the status quo and actually experiment a little.

Originally, I relied on Github Pages, which was for a site like mine almost perfect. It was free and required nearly zero setup, it built almost immediately, it had impeccable uptime (something Github famously started to struggle with), and I could super easily place a cheap domain in front of it to make it a little more appealing than the factory-default nemin32.github.io address.

However, due to the, ehm, recent trends and emboldened by the rallying cries of the people who had enough, I too took the dive and moved my presence over to Codeberg. This, of course, meant my two websites had to move too. Thankfully the process wasn't particularly painful (the article linked above pretty much gets you up to speed in 10-15 minutes) and so I quickly had everything set up.

While I thought I was done, sadly I quickly realized that though the two services were similar in design, their quality of service was very different. Codeberg Pages really struggled at times. My pages are rarely over a couple hundred kilobytes (most of which being a couple AVIF-encoded pictures) and yet there were times where loading my sites took 10-15 seconds, while the browser just hanged.

Before anyone gets the wrong idea, I'm not blaming Codeberg for this in any shape or form. In fact I'm very grateful, that the option exists in the first place. After all, they are a (relatively) small non-profit, who have to serve not just my silly little webpages, but sites for far more serious projects too. With this in mind, it's no wonder they can't always afford the computing power for me.

However, as much as they have my sympathies, I was still stuck with this problem and had to figure out some solution. And said solution was joining something useful with something pleasant: Enter VPS-es.

1.1 Picking my provider

A VPS is a managed virtual machine, that one may rent from cloud provider companies. The userbase is very wide, you can find people using them from all areas of life, from students and hobbyists, to very serious and large companies, who don't want to bother with on-prem solutions.

These days, if one happens to fall into the former category and only really needs a machine that has some minimal RAM and a reasonably fast few (perhaps even one) core CPU, they have a plethora of providers to pick from, who specialize in pushing down prices and lending you such VMs for literal peanuts.

An example of a site that collects such cheap deals.

For a striking example, just take a look at LowEndBox's $1 per month VPS list, the name tells you what to expect. But if you're willing to shop around for more obscure providers and can contort your needs even further (for instance by not requiring an IPv4 address), I've found a company, who'll rent you a VM with 5Gb of storage and cca. 400MB of RAM for $4.5 per year, not month, year. I don't think you can go much lower than that.

However, figuring that it's not like I'll be spending fortunes either way, I decided to stick to a well-known and trusted option, netcup. While their cheapest option is closer to 2€ a month, in return you get an unmetered, 100Mbps connection (as long as you use it in good faith), 30Gb of storage space, the option to make a snapshot of your VM for backups, and the assurance that your money is going to a bunch who know their stuff.

Sounds all great… if only it wasn't so unexpectedly convoluted to do business with them.

2 German bureaucracy

As explained earlier, my choice fell on the VPS Pico G11s. At first the process was as one would expect:

I put the VPS in my cart, entered my address and personal data, then clicked through the pages, until I noticed that there is a Netcup newsletter and if you sign up for it, you get a voucher for 5€ off. I figured "Hell yeah, that's almost three months" and signed up. The voucher arrived almost instantly and I happily saw that after entering it, the price of the VPS dropped from 24€ to around 19€. Everything seemed fine, so I pressed on the big, friendly "Order" button…

And was thrown back with an error.

Apparently the VPS I picked was too cheap for the voucher to be applicable for, so I begrudgingly removed it and proceeded with the full price. At the end of the day, 24€ is the cost of two fancy lunches, so I wasn't going to throw everything away just because I couldn't be even more of a cheapskate.

Having corrected my deal and pressed "Order" again, I expected to be redirected to a payment portal. Instead, I was simply informed that an actual human being will verify that my order is legit and that I must wait until that happens. Considering this was very late in the afternoon (way past the usual European working hours), I sighed and resigned myself to wait until the next day or however long it'd take.

In the meantime I received an email, which I found really interesting. It was written in a very serious and legalese way, with long paragraphs of dry text describing my rights and responsibilities, and that, by placing an order, I now have two weeks to refuse entering into the contract with Netcup, after which it becomes binding.

I found this both quite refreshing, a lot of companies hide their nasty details deep into Terms of Uses or other such texts, but not here. Sure, it makes the communication towards their customer less bombastic, but I absolutely didn't mind that.

Then, to my biggest surprise, not ten minutes later my inbox pinged me again: My inspection was successfully finished and I'm ready to log into the portal. So I did just that, expecting to be finally able to pay… only to be hit with a huge interface, where I was ordered to declare my handling of user data according to GDPR.

Sadly, I didn't make a screenshot of this and I'm no longer able to access it, but more or less I was just asked what sort of data I intend to handle. Considering I was making a simple static site, I declared that I'm not handling any personal data and that was that.

At this point, finally, I was able to add my credit card and pay for my server. Five minutes and another two emails later, I received a link to yet another completely different page, which (to my great relief) did indeed allow me to access my machine.

3 Setting up my VPS

The VM came with Debian 13, which is a fine system otherwise, but having had a recent interest in the various BSDs and stumbling on httpd.rocks through Lobste.rs, I decided to ditch it and try my luck with OpenBSD 7.9 instead.

A list of images provided by Netcup. All the BSDs and some nice distro choices… also Windows, I guess, if you're into that…. weirdo.

To my delight netcup provides the newest OpenBSD ISO on their interface. One simply just has to click on it and the VM automatically gets the disk loaded and the boot order changed to boot from it. Power-cycling the VM is a little slow (taking around an entire minute), but I don't expect to do it much, so whatever.

Installing OpenBSD was a breeze. Hands down one of the easiest processes when it comes to putting an OS on your machine. I disabled the X windowing sets and the games set, but kept the rest. Apparently this is a bit of a faux pas, but worst case I'll just reinstall the machine, no biggie.

The default filesystem I went with. /var is woefully small.

The only true error I think I made during installation was accepting the default partitioning scheme, which wastes around 6GB of storage on /home, which I won't be using anyway, while /var (arguably my most important folder, as it contains the code for my website and my logs) ended up being a measly 2GB. It is a bridge that I'll eventually have to cross, but for now it's fine.

Note from the future: I did end up reinstalling while troubleshooting an unrelated issue and made /var into a far bigger partition. Thankfully with how fast and easy the installation of OpenBSD is, this was an entirely painless process.

3.1 SSH config

While the Netcup interface does provide a remote desktop, it's not super pleasant to use. Not only is it excruciatingly slow, it is also very particular about when it accepts input (you need to click into the screen and it seems to occasionally lose focus on its own), so I quickly decided to look into setting up SSH instead.

I didn't have to look too far, this blogpost was perfect for my needs. It describes both how one can bring a system up to speed and also how to set up SSH in a way that's secure, by disabling dubious ciphers.

I generated a brand new keypair for the VPS, because reusing the same key for all your projects is a great way to be pwned. And after quickly logging in with my password and issuing the right ssh-copy-id call, I disabled password login.

Afterwards I added the a new entry to my ~/.ssh/config file, so I only need to issue ssh vps and it handles the rest. Much more handy than needing to do things manually:

The first three lines aren't strictly necessary, but they make long connections a lot more tolerable.

AddKeysToAgent yes
ServerAliveInterval 15
ServerAliveCountMax 3

Host vps
  HostName [IPv4 of the VPS]
  User [username]
  IdentityFile ~/.ssh/id_vps

As a final touch, I symlinked openrsync to rsync. This was necessary because my main Linux machine's rsync expects to find an executable with the same name on the VPS when I try to copy my files over. Other than this hack, it's all very clean with transparent SSH handling. I can just do rsync -av --delete source vps:destination and it handles the rest.

3.2 Upgrading OpenBSD to 8.0-beta

Note from the future: This section here is anachronistic, as it's placed before I discuss any of my server config, but was actually written after I've finished and then completely rewrote said config from scratch.

The reason for this is that, while I originally intended to go with the often-recommended relayd to handle TLS connections and attach HTTP headers to my responses (httpd.rocks has a tutorial for this too!), I stumbled upon this Reddit post while solving an unrelated issue, which mentioned that httpd was soon to receive support for setting HTTP headers itself (and it is already capable of handling TLS), making relayd pretty much overkill for my purposes.

It is considered both good practice and a painless way to enhance the performance of your site to set a couple of HTTP headers that inform the browser about how it may cache your content and that it should leak as little info as possible.

While OpenBSD 7.9's httpd provides no built-in mechanism for this (and thus requires an additional proxy service), the (currently beta) 8.0 release does in the form of the header set directive.

To be able to use this, I had to upgrade my system from 7.9-release to 8.0-beta. While this may sound difficult at first glance, it turned out to be little more than issuing sysupgrade -s, waiting until the system downloaded the newest OS release snapshot, and then automagically installed it, without me having to touch anything at all.¹

After that I only had two more super easy housekeeping tasks to do:

I needed to issue pkg_add -u to upgrade all my packages to their 8.0-compatible versions. This went through without incident.
I also needed to call sysmerge to update any system configuration files that may have changed between the two releases. In my case this was only sshd_config, which introduced post-quantum ciphers by default and changed PermitRootLogin to prohibit-password.

As neither of these affected my usage of sshd, I opted to accept them without manual intervention.

With the foundations done, it was time to actually have the machine do its intended job. Frankly, however, any sort of detailed guide I could write here would be a pale and imprecise imitation of httpd.rocks, so I'll keep things succinct and just comment on stuff I find interesting to point out. If you find my journey at all inspiring, I suggest checking the aforementioned guide out as well.

With this disclaimer out of the way, let's get into it:

3.3 Firewall

ext_if="vio0"

set limit states 100000      # Maximum state table entries
set timeout interval 30      # Interval between state purges
set optimization "normal"    # General optimization for connection tracking

set skip on lo

# Antispoof
antispoof log quick for $ext_if
match in all scrub (no-df)

# Block all by default
block all   

# Block table for abusive hosts
table <block_table> persist file "/etc/pflists/block_table"
table <ssh_naughty> persist file "/etc/pflists/ssh_naughty"
block in quick from <block_table>
block in quick from <ssh_naughty>

# Block bogus destination addresses
table <martians> {
    0.0.0.0/8 127.0.0.0/8 169.254.0.0/16 172.16.0.0/12 192.0.0.0/24 \
    192.0.2.0/24 224.0.0.0/3 192.168.0.0/16 198.18.0.0/15 198.51.100.0/24 \
    203.0.113.0/24 \
    ::/128 ::/96 ::1/128 ::ffff:0:0/96 100::/64 2001:10::/28 2001:2::/48 \
    2001:db8::/32 3ffe::/16 fec0::/10 fc00::/7 }

block in quick on egress from any to <martians>

# Allow DNS and NTP
pass out on $ext_if proto {udp tcp} to any port 53
pass out on $ext_if proto udp to any port 123

# Allow SSH
pass in on $ext_if proto tcp from any to any port ssh synproxy state \
    (max-src-conn 10, max-src-conn-rate 5/30, overload <ssh_naughty> flush global)
pass out on $ext_if proto tcp from any to any port ssh keep state

# Allow web server stuff
pass in on $ext_if proto tcp from any to any port {80 443} synproxy state \
    (max-src-conn 100, max-src-conn-rate 30/5, overload <block_table> flush global)
pass out on $ext_if proto tcp from any to any port {80 443} keep state

The firewall does the following:

Antispoofing and packet scrubbing,
block all to be better safe than sorry,
A blocklist to drop aggressive crawlers and one to SSH brute-forcers,
And allowing some select services through for basic functionality: DNS, NTPD, SSH, and finally our webserver, with the latter two services also having anti-flood measures enabled to put malicious clients on the blocklists.

While both blocklists forbid IPs on them from connecting, they have one important difference:

I've set up my crontab so that it periodically calls pfctl -t block_table -T expire 8400. This command removes clients that have been on the block_table list for a while, because it is entirely possible that it was merely a bumbling user, who accidentally reloaded the page one too many times with their cache turned off or that it was a fake IP address, that someone used.

The other list, ssh_naughty, isn't ever cleared. I only intend to allow myself to log in, so if a client is hammering the VPS' SSH daemon, then I cannot give it the same presumption of innocence.

And to make sure the list doesn't disappear into smoke in case I restart my system, I followed the advice of this BSDHowTo article and added the following into /etc/rc.shutdown:

pfctl -t block_table -T show > /etc/pflists/block_table
pfctl -t ssh_naughty -T show > /etc/pflists/ssh_naughty
chmod 0600 /etc/pflists/block_table
chmod 0600 /etc/pflists/ssh_naughty

This ensures that if my system goes down normally (i.e. for an update or miscellaneous restart), the OS will automatically dump the block-lists into files, which are then reloaded on the next startup by the file directive in pf.conf.

I'm considering also running this script as a cronjob in case of an unexpected hard reset, but perhaps that's not something one has to actively worry about when it comes to VPS-es.

3.4 TLS certificates

authority letsencrypt {
    api url "https://acme-v02.api.letsencrypt.org/directory"
    account key "/etc/acme/letsencrypt-privkey.pem"
}

domain nemin.hu {
    alternative names { www.nemin.hu }
    domain key "/etc/ssl/private/nemin.hu.key"
    domain full chain certificate "/etc/ssl/nemin.hu.crt"
    sign with letsencrypt
}

domain oddwords.hu {
    alternative names { www.oddwords.hu }
    domain key "/etc/ssl/private/oddwords.hu.key"
    domain full chain certificate "/etc/ssl/oddwords.hu.crt"
    sign with letsencrypt
}

I use OpenBSD's built-in acme-client(1), which interfaces with Let's Encrypt to get TLS certificates for my two sites.

One thing I noticed, while still messing with my config is that having two (or more) sites on one host makes troubleshooting certificate issues quite tricky, because browsers will helpfully try to use your other site's certificate instead, which will then cause a failure as the browser realizes the name of the site you're trying to reach and the name stored in the certificate are completely different.

Therefore, if you're facing issues while hosting multiple sites and have the opportunity, I genuinely would suggest disabling all but the problem server until you figure out the solution.

3.5 Web server

types { include "/usr/share/misc/mime.types" } 
prefork 10
no banner

#
# Nemin.hu
#

server "nemin.hu" {
    listen on * tls port 443
    root "/htdocs/nemin.hu"
    hsts {preload, subdomains}
    gzip-static
    log style combined

    location "/.well-known/acme-challenge/*" {
        root "/acme"
        request strip 2
    }

    # Drop malicious requests
    location "/.aws*" {block drop}
    location "/.env*" {block drop}
    location "/*.cgi*" {block drop}
    location "/cgi-bin/*" {block drop}
    location "/*.php*" {block drop}
    location "/*wp-*" {block drop}

    # Set headers
    header set "Cache-Control" "public, max-age=86400" always
    header set "X-Content-Type-Options" "nosniff" always
    header set "Referrer-Policy" "no-referrer" always
    header set "Permissions-Policy" "interest-cohort=()" always
    header set "X-Frame-Options" "SAMEORIGIN" always

    tls {
        certificate "/etc/ssl/nemin.hu.crt"
        key "/etc/ssl/private/nemin.hu.key"
    }
}
server "nemin.hu" {
    listen on * port 80

    location "/.well-known/acme-challenge/*" {
        root "/acme"
        request strip 2
    }

    # Drop malicious requests
    # ...

    # Set headers
    # ...

    block return 301 "https://nemin.hu$REQUEST_URI"
}
server "www.nemin.hu" {
    listen on * port 80
    listen on * tls port 443

    location "/.well-known/acme-challenge/*" {
        root "/acme"
        request strip 2
    }

    # Drop malicious requests
    # ...

    # Set headers
    # ...

    tls {
        certificate "/etc/ssl/nemin.hu.crt"
        key "/etc/ssl/private/nemin.hu.key"
    }

    block return 301 "https://nemin.hu$REQUEST_URI"
}

#
# Oddwords.hu
#

# More or less the same as above, just with the URL substituted...

The httpd config is fairly simple, though it has a couple interesting notes I'll lay out below.

The second and third block simply handle redirecting www. and bare HTTP requests to https://nemin.hu. All blocks are set up to handle ACME challenges, because the client will try both nemin.hu and www.nemin.hu.

The first block is the one that actually serves content. It's also very straightforward, but there are two calls that I think are worth specifically mentioning:

gzip-static allows your server to send gzip-encoded HTML instead of uncompressed data. Notably it will not compress files itself, so you have to do that yourself, but the blog post where I learned about this feature also explains how easy it is to create these archives yourselves. (It's literally just calling gzip -k on them.)

And if that's still too much manual work, this other post describes a one-liner that allows you to recursively turn everything (but images, which don't benefit from compression) into a .gz file:
```
find public/ -type f ! -name '*.png' -exec gzip -9k "{}" \;
```
Obviously you should adapt this to your needs. For instance, for me public/ is site/ and instead of using PNG files, I use AVIF (which also don't really need zipping).
The lines starting with location match for some files crawlers like to frequent. Since this is a static website, it's not like they'd hit anything in the first place, however, by silently dropping their connections, we waste their time and resources.

These filtering blocks are repeated everywhere, because I don't want to pointlessly redirect requests that will be dropped anyway.
Finally, the lines starting with header allow us to set HTTP headers on our responses. This is the reason why I ugpraded to OpenBSD 8.0 earlier, as 7.9 doesn't yet have this feature and would've required us to use relayd or another proxy.

I'm not sure if it's strictly necessary to include these headers on calls that only redirect to the HTTPS URLs, but I figured it can't hurt and you only really have to set it up once.

I kind of wish there was a more involved macro system for httpd.conf, that would allow shortening the block lists to one definition that may be reused in all sections, but it's not that bad.

Note from the future: This kept me up at night, so I went and figured out a way to make things terser.

3.5.1 Be careful with MIMEs

Originally, when I first wrote my config, I didn't include the first line. None of the tutorials I've read mentioned it and the page loaded just fine, so I figured all is well. Except everything wasn't well, because I noticed the pictures on the webpage loading incredibly slowly. Up to 20-30 seconds, despite the fact that due to them being highly-compressed AVIF images, they were rarely over 300KB in size.

A quick googling later I was able to pin down the problem: Without informing the server about the various MIME types, it absolutely struggled to send over anything.

Fixing this is simply adding the following to your config outside any of the server blocks:

types { include "/usr/share/misc/mime.types" }

And here is where I'd like to repeat a very old and very true adage: One should absolutely read the OpenBSD man pages. It is easy to skip over them if one is used to Linux, because quite often the documentation that comes with your packages might be sub-par or simply not detailed enough to help you fix your issues without going on a wild goose chase on the Internet.

However, with OpenBSD, this is different. The manual is super easy to read and understand and even obscure things are often mentioned, including the line seen above:

Types

   Configure the supported media types.  httpd(8) will set the Content-Type
   of the response header based on the file extension listed in the types
   section.  If not specified, httpd(8) will use built-in media types for
   text/css, text/html, text/plain, image/gif, image/png, image/jpeg,
   image/svg+xml, and application/javascript. The types section must
   include one or more lines of the following syntax, enclosed in curly
   braces:

   type/subtype name [name ...]
           Set the media type and subtype to the specified extension name.
           One or more names can be specified per line.  Each line may end
           with an optional semicolon.  Later lines overwrite earlier lines.

   include file
           Include types definitions from an external file, for example
           /usr/share/misc/mime.types.

As you can see, the man page clearly states that AVIF files aren't included by default, so no wonder the server choked on them.

And with this line added, everything loads almost instantly.

4 Findings; or, Bots Love Your Obscure Content!

While I was toying around with loading my site and checking the access logs, I noticed that, beyond my own IP, there were a lot of other clients connecting too. At first I was very happy to see this. Considering I've never had analytics before, I had zero idea how many people actually click on my pages, so seeing the buzzing activity felt very validating…

That is until I actually read the user agents and realized about 40% of these were AI scrapers, another 40% crawler bots, and only 20% were clients I couldn't decisively categorize as either.

An excerpt from my access logs. All of these were credential scanner/stealer bots.

I must admit this made me a little sad, but then I really shouldn't have expected anything different. What I found really amusing is that a lot of these crawlers were trying to crack the site by scanning for files such as .aws, .env, and wp-*, which they won't find, because it's a static site.

If you remember in the earlier section I added a bunch of lines starting with location in my httpd.conf file. This is why. When the crawlers try to read files matching these paths, their requests will be silently dropped.

I also added a simple robots.txt, that disallows all the bigger AI crawlers from the site, but they don't seem to respect it. For now I've let things be, but perhaps eventually I'll add their user agents into the blocklist of my config.

Note from the future: I'm adding this comment three days later. My SSH blocklist already has 77 clients on it. The internet is harsh.

5 Conclusion

I call my main machine luna, so calling a machine that's both very far away and tiny ceres felt very appropriate.

My job title may technically be DevOps engineer, but I'm really more of an "average" backend programmer and even when I do touch infra, it's a lot different to tweak tiny parts of an already well-established stack, with several colleagues to help you and several backups to reach for if something went wrong. So I went into this project with some slight apprehension and with a feeling that any mistakes would leave me to poke around in the dark.

However, reality turned out to be far less menacing. Migrating to a VPS ended up much quicker and easier than I assumed and I also found it an excellent learning experience, with plenty of further opportunities to branch out to when I feel like it.

So if hosting your own site sounds exciting for you, nowadays it's easier than ever to try and it won't cost you much.

Thanks for reading!

6 Footnotes

From what I could find, the jury seems to be still somewhat out on whether it's "safe" to use snapshots on a server.

Proponents mention that the OS developers generally use the newest available version and are forbidden from breaking it and also that by using snapshots most of the obvious issues should be long ironed out.

Critics cite the need to update the system weekly or even more frequently and the fact that, though rare, system breakages may still happen a couple times a year.

Considering my two sites aren't mission critical in any shape or form and that the VPS contains nothing that couldn't be restored from a local backup, I decided to go with it. If you're more risk averse than me, maybe wait until 8.0 drops, which should happen about 3 months after the writing of this article (November of 2026).↩︎

Spark Interact is now a Hostinger Partner – Spark Interact

Tue, 25 Aug 2026 02:18:39 +0000

Good news for our clients: we can now offer you better hosting options.

We’ve partnered with Hostinger, which means we can match your website to hosting that suits your business, your traffic, and your budget. And when Hostinger is the right fit, you get 20% off the plan.

What this means for you

Real value in the plan. Depending on the plan, Hostinger includes things you’d normally arrange separately: a free domain, business email, daily backups, and site migration. More of your budget goes into the website itself rather than the bill sitting underneath it.

20% off, through our partner code. That covers web hosting, cloud hosting, VPS, and Hostinger’s Agency Hosting tier. Higher discounts run during Hostinger’s campaign periods, so it’s worth a quick word with us before you buy.

Isolated environments and per site access. This is the unglamorous part that matters. Your site sits in its own environment rather than sharing space with someone else’s, and we can give your team access to your site without handing over the keys to anything else.

Room to grow into. The range runs from web hosting through to cloud and VPS, with options like dedicated IPs and daily backups higher up. If your traffic climbs, you’re moving up a tier rather than moving house.

One point of contact. You still deal with us. We handle the setup, the migration, and the ongoing management, and we’re the ones you call when something needs attention.

Why we partner on our terms

We look after websites for clients across construction, professional services, finance, and government-adjacent sectors. Those businesses have genuinely different requirements, and the right answer for one is rarely the right answer for all of them.

So we assess platforms carefully and partner with the ones that earn it. Hostinger did, and that’s why it’s now part of our stack.

The value in holding several strong options is simple: it means the recommendation you get is based on what your site actually needs, and we can say “this one, for these reasons” and mean it. There are more partnerships in progress, and we’ll share those as they land.

How we choose hosting for our client

“Which host is best” is the wrong question. The right one is “best for what”:

Traffic now, and traffic in eighteen months. Hosting that suits a launch can throttle a business that grows into a real traffic load.
Where the data sits. Relevant for anyone selling into government or enterprise, where data residency questions turn up in the procurement paperwork.
How often the site is updated. A site edited weekly needs staging and backups that are easy to reach. A site touched twice a year has different priorities.
Who’s maintaining it. If your team is going to be in there, the control panel matters more than the raw specs.
Cost over three years, not month one. Worth looking at the full picture before you commit.

Most of the time the answer is straightforward. Occasionally it saves a client a few thousand dollars, or saves them from a migration they never needed to do.

Sign up and get your 20% off

Two ways to claim it.

Use our partner link, which applies the discount for you:
https://www.hostinger.com?REFERRALCODE=H2ISERVICCWZ

Or enter the code at checkout: H2ISERVICCWZ

Hostinger runs higher discounts during campaign periods, so if you’re not in a rush, check with us first and we’ll let you know if there’s a better offer running.

And if you’d rather we handled the setup, migration, and ongoing management, that’s what we normally do. Get in touch and we’ll work out together what suits the site you’re building.

Can a blog post be handwritten?

Mon, 24 Aug 2026 18:49:53 +0000

		
 ██████████     ██████  ██████████ 
░░███░░░░███   ███░░░██░░███░░░░░  
 ░███   ░░███ ░███  ░░  ░███       
 ░███    ░███ ███████   ░███████   
 ░███    ░███░░███░░    ░███░░░    
 ░███    ███  ░███      ░███       
 ██████████   ░███      █████      
░░░░░░░░░░    ░░░      ░░░░░

Can a blog post be handwritten?

2026-08-20

Can a blog post be handwritten?
Suppose I handwrite a post on my
supernote, then export it as a
webp, which supports XMP
metadata. Pretty sure I should be
able to read that with javascript.
Then, I could embed the webp on
a blog post, and write a script
that will toggle between hand-
writing and the OCR'd (and edited)
text metadata.
Worth an experiment, I reckon.
Wonder if you can read my
handwriting, though.

SVG Filter Effects: Creating Texture with | Codrops

Mon, 24 Aug 2026 07:04:16 +0000

feTurbulence is one of the most powerful SVG filter primitives. The specification defines this primitive as follows:

This filter primitive creates an image using the Perlin turbulence function. It allows the synthesis of artificial textures like clouds or marble. […]
The resulting image will fill the entire filter primitive subregion for this filter primitive.

In other words, the feTurbulence filter primitive generates and renders Perlin noise. This kind of noise is useful in simulating several natural phenomena like clouds, fire and smoke, and in generating complex texture like marble or granite. And like feFlood, feTurbulence fills the filter region with new content.

This article is part of a series on SVG Filter effects. Check out the other articles in the series:

SVG Filters 101
Outline Text with <feMorphology>
Poster Image Effect with <feComponentTransfer>
Duotone Images with <feComponentTransfer>
Conforming Text to Surface Texture with <feDisplacementMap>
Creating Texture with <feTurbulence> (this article)
SVG Filter Effects: Moving Forward

In this article, we’re going to go over how we can create noise with feTurbulence and how that noise can be used to distort images and text, much like we did with the feDisplacementMap texture in the previous article. Then, we’re going to see how the generated noise can be used in combination with SVG lighting effects to create a simple rough paper texture.

But first, let’s get an overview of feTurbulence and its attributes and see how each one affects the generated noise.

Creating Turbulence and Fractal Noise with `feTurbulence`

When I set out to write this series, I made the decision to avoid the gnarly technical details behind filter primitives as much as possible. This is why we won’t get into the technical details behind the functions used to generate Perlin noise.

After reading up on the function underlying noise generation, I found that it didn’t help me at all when I put the primitive into experimentation. After all, we are working with a random noise generator here. So, most of the times, you’ll find that generating texture will be a matter of experimenting and tweaking until you get the desired result. With time, it gets a little easier to predict what a texture might look like.

I’ve found that playing with feTurbulence and tweaking its attributes visually was the best way to learn about them and has helped me understand what each of the attributes does. So, we will be taking a visual approach to understanding feTurbulence, with a few interactive demos to help.

Now, feTurbulence generates noise using the Perlin Turbulence function. It has 5 main attributes that control the function and therefore the visual result of that function:

type
baseFrequency
numOctaves
seed
stitchTiles

We’ll go over how each of these attributes affects the visual result without going into the technical details of the function. You’ll find that, most of the times, you’ll only need to worry about three of these attributes: type, baseFrequency and numOctaves.

`baseFrequency`

In order to generate noise, only the baseFrequency attribute is required. The baseFrequency affects the size (or scale) and the grain of the generated noise.

baseFrequency’s effect is best understood when it is visualized and animated. That’s why I created the following live demo. Using the slider, you can change the value of the base frequency used and see how it affects the generated noise in real-time. You’ll notice that as you increase or decrease the value of the baseFrequency attribute, the generated pattern remains intact as it becomes smaller or larger, respectively, and looks like it’s zooming in and out of its origin at the top left corner.

See the Pen feTurbluence: baseFrequency by Sara Soueidan (@SaraSoueidan) on CodePen.

Lower baseFrequency values (such as 0.001) generate larger patterns, while higher values (0.5+) produce smaller patterns. The values start from 0 (no frequency == no pattern) and up. Negative values are not allowed. as Michael Mullany mentions, “values in the 0.02 to 0.2 range are useful starting points for most textures.”

Note that the noise generated does not have a background color. Meaning that, if you remove the white background color on the SVG, you’ll be able to see the dark body’s background through the noise.

The baseFrequency attribute also accepts two values. When you provide two values, the first one will be used for the base frequency on the x-axis and the second one will correspond to the y-axis. By providing two different values, you can generate vertical or horizontal noise that can be used to achieve some fantastic effects, as we’re going to see in a following section.

Play with the values of the baseFrequency again in this live demo and notice how it changes along the X and Y axes as you give it different values. The demo starts with a nice horizontal noise. The 0.01 x-baseFrequency value is relatively small, which makes the horizontal pattern larger (like it’s stretched out). If you decrease it further (to 0.001, for example), you’ll see the horizontal pattern become more like lines. Try it.

See the Pen feTurbluence: x & y baseFrequency by Sara Soueidan (@SaraSoueidan) on CodePen.

`type`

As its name suggests, the type attribute is used to specify the type of noise generated by feTurbulence. There are two types available:

turbulence, which is the default value, and
fractalNoise.

fractalNoise generates a more cloudy and smooth pattern and is a suitable base for creating gas-base textures like clouds. turbulence generates more lines that simulate ripples and are thus suitable as a base for liquid textures.

turbulence type noise on the left, and fractalNoise type on the right.

Change the value of the type attribute in the following demo to see how the generated pattern changes:

See the Pen feTurbluence: stitchTiles by Sara Soueidan (@SaraSoueidan) on CodePen.

`numOctaves`

numOctaves is short for the “number of octaves”, which represent the level of detail in a noise.

In music, an octave is the difference in pitch between two notes where one has twice the frequency of the other. So the higher the octaves, the higher the frequency. In feTurbulence, the higher the number of octaves, the more detail you can see in the noise it generates. By default, the generated noise has one octave, which means that the default value for the numOctaves attribute is 1.

Drag the slider in the following demo to see the effect of increasing the number of octaves on the generated texture:

See the Pen feTurbluence: numOctaves by Sara Soueidan (@SaraSoueidan) on CodePen.

You’ll notice that starting from numOctaves="5" the effect of adding more octaves becomes practically unnoticeable.

`seed`

The seed, as defined in the specification, is “the starting number for the pseudo random number generator”. In other words, it provides a different starting number for the random function used to generated our random noise.

Visually, you’ll see that it affects where and how the “ripple lines” are generated. It is also better understood when you see how it affects the noise generated in two adjacent rectangles.

When the same seed is used for the two adjacent rectangles, the function used to generate the noise across the two rectangles is continuous, and this will be reflected visually by the continuity of the “ripple lines” across the edges of the two rectangles.

The continuity of the function generating the random noise can be seen along the edges of the two rectangles using the same seed value.

Play with the value of the seed attribute in the following demo, see how it affects the generated noise, and notice how the noise is continuous across the edges of the two rectangles that are using the same seed value.

See the Pen feTurbluence: seed by Sara Soueidan (@SaraSoueidan) on CodePen.

`stitchTiles`

stitchTiles can be used to create a stitching effect between “tiles” of noise. The effect of this attribute is very similar to that of the seed, meaning that it is most evident when you have two adjacent areas (or “tiles”) of noise.

As the specification mentions, sometimes the result of the noise generation will show clear discontinuities at the tile borders. You can tell the browser to try to smooth the results out so that the two tiles appear to be “stitched” together. (I really like how the attribute and its effect are compared to stitching.)

By default, no attempt is made to achieve smooth transitions at the border of tiles which contain a turbulence function because the default value for stitchTiles is noStitch. If you want to create that stitching effect, you can change the value to stitch.

In order to compare the result of stitchTiles to that of seed, I have applied the same seed value to the noise generated in the two rectangles in the following demo. You can already see that the noise appears to be continuous between the two. Switch the stitchTiles option “on” (by changing its value to stitch) to see how the noise changes to accommodate across the edges.

See the Pen feTurbluence: stitchTiles by Sara Soueidan (@SaraSoueidan) on CodePen.

As I mentioned earlier, the only three attributes you’ll most likely be using are type, baseFrequency and numOctaves. So we’ll be focusing on these three moving forward.

Using `feTurbulence`-Generated Noise to Distort Content

This is where the fun starts. And this is where we start putting the generated noise to use. After all, just filling the filter region with the noise has no use in and of itself.

In the previous article we used feDisplacementMap to conform a piece of text to the texture in an external image. And we mentioned that feDisplacementMap uses the color information in one image to distort another. The image that is used as a displacement map can be any image. This means that it can be an external image or an image generated within SVG, such as a gradient image or a pattern… or a noise texture.

In other words, the noise we generate with feTurbulence can as well be used to distort content if it is used with feDisplacementMap. In the following demo, we used the output of feTurbulence to displace the image with feDisplacementMap. I’m using a horizontal noise pattern by providing two different values for the baseFrequency attribute similar to what we did earlier.

<svg viewBox="0 0 180 100">
    <filter id="noise" x="0%" y="0%" width="100%" height="100%">
        <feTurbulence baseFrequency="0.01 0.4" result="NOISE" numOctaves="2" />
        <feDisplacementMap in="SourceGraphic" in2="NOISE" scale="20" xChannelSelector="R" yChannelSelector="R"></feDisplacementMap>
    </filter>

    <image xlink:href="..." x="0" y="0" width="100%" height="100%" filter="url(#noise)"></image>
</svg>

See the Pen feTurbluence as a displacementMap by Sara Soueidan (@SaraSoueidan) on CodePen.

The intensity by which the turbulence distorts the image is specified in the scale attribute on feDisplacementMap. I’ve used a large value so that the effect looks more dramatic.

Now, going from this simple application, we can open a lot more possibilities when we combine the facts that:

SVG filters can be applied to HTML content, and
the values of baseFrequency are numbers and can thus be animated..

A little less than a couple of years ago, Adrien Denat wrote an article right here on Codrops in which he experimented with a similar effect applied to HTML buttons. We’re going to break down and recreate the following button click effect:

We’re going to start by creating the noise texture. We’re going to start with the final state—the state where the button is distorted, and then, once we’ve got that, we’re going to animate the initial state of the button to that distorted state and back on click.

Our aim here is to distort the button horizontally. So we will be using and tweaking the horizontal noise from the previous demo a little bit. Its distortion effect on the image is a little too strong, so I’m going to dial it down first by changing the turbulence value from 0.01 0.4 to 0 0.2:

<filter id='noise' x='0%' y='0%' width='100%' height='100%'>
        <feTurbulence type="turbulence" baseFrequency="0 0.2" result="NOISE" numOctaves="2" />
        <feDisplacementMap in="SourceGraphic" in2="NOISE" scale="30" xChannelSelector="R" yChannelSelector="R"></feDisplacementMap>
</filter>

The effect gets a little better, but the button is still distorted more than we’d like it to:

We want the distortion to be less dramatic. A useful tip to keep in mind is that we can dial the effect of the noise down instantly by switching the type of noise from the default turbulence to the smoother fractalNoise. As soon we do that, we can see that the distortion effect has also been “smoothed” down:

This looks much better.

Now that we’ve got a distortion effect we’re happy with, we will start our demo with a filter that, initially, does practically nothing:

<filter id='noise' x='0%' y='0%' width='100%' height='100%'>
        <feTurbulence type="fractalNoise" baseFrequency="0 0.000001" result="NOISE" numOctaves="2" />
        <feDisplacementMap in="SourceGraphic" in2="NOISE" scale="30" xChannelSelector="R" yChannelSelector="R"></feDisplacementMap>
</filter>

We’re going to apply that filter to our button in CSS:

button {
    -webkit-filter: url(#noise);
            filter: url(#noise);
}

At this point, the button still looks un-distorted.

Next, we’re going to use (a slightly modified version of) Adrien’s code which uses GSAP to animate the value inside feTurbulence’s baseFrequency to 0 0.2 and back on click:

var bt = document.querySelectorAll('.button')[0],
	turbVal = { val: 0.000001 },
	turb = document.querySelectorAll('#noise feTurbulence')[0],
	
	btTl = new TimelineLite({ paused: true, onUpdate: function() {
  turb.setAttribute('baseFrequency', '0 ' + turbVal.val);
} });

btTl.to(turbVal, 0.2, { val: 0.2 })
    .to(turbVal, 0.2, { val: 0.000001 });

bt.addEventListener('click', function() {
  btTl.restart();
});

And that’s all there is to it, really. You can play with the live demo here:

See the Pen feTurbluence on BUTTONs by Sara Soueidan (@SaraSoueidan) on CodePen.

The demo works in Chrome and Firefox at the time of writing of this article. It is buggy in the current version of Safari but the issue is resolved in the next version, as the Safari Tech Preview shows the demo works perfectly. It doesn’t work in MS Edge, though, but the button isn’t distorted at all which means that the lack of support does not affect the usability of the button. This is great because you can still use this effect as an enhancement.If the effect isn’t supported, the button will simply look and behave like a normal, effect-less button. Adrien’s article includes quite a few more button distortion effects that use the same principles we’ve just covered that are definitely worth checking out and breaking down. There are one or two nice tricks to learn from each.

Squiggly Text using `feTurbulence`

One of my favorite examples of feTurbulence in action is Lucas Bebber’s Squiggly Text effect. In his demo, Lucas is using multiple feTurbulence functions:

<svg xmlns="http://www.w3.org/2000/svg" version="1.1">
    <defs>
        <filter id="squiggly-0">
            <feTurbulence id="turbulence" baseFrequency="0.02" numOctaves="3" result="noise" seed="0" />
            <feDisplacementMap id="displacement" in="SourceGraphic" in2="noise" scale="6" />
        </filter>
        <filter id="squiggly-1">
            <feTurbulence id="turbulence" baseFrequency="0.02" numOctaves="3" result="noise" seed="1" />
            <feDisplacementMap in="SourceGraphic" in2="noise" scale="8" />
        </filter>

        <filter id="squiggly-2">
            <feTurbulence id="turbulence" baseFrequency="0.02" numOctaves="3" result="noise" seed="2" />
            <feDisplacementMap in="SourceGraphic" in2="noise" scale="6" />
        </filter>
        <filter id="squiggly-3">
            <feTurbulence id="turbulence" baseFrequency="0.02" numOctaves="3" result="noise" seed="3" />
            <feDisplacementMap in="SourceGraphic" in2="noise" scale="8" />
        </filter>

        <filter id="squiggly-4">
            <feTurbulence id="turbulence" baseFrequency="0.02" numOctaves="3" result="noise" seed="4" />
            <feDisplacementMap in="SourceGraphic" in2="noise" scale="6" />
        </filter>
    </defs>
</svg>

..and applying them via CSS to a piece of HTML text using CSS animations, animating from one to another:

@keyframes squiggly-anim {
  0% {
    -webkit-filter: url("#squiggly-0");
            filter: url("#squiggly-0");
  }
  25% {
    -webkit-filter: url("#squiggly-1");
            filter: url("#squiggly-1");
  }
  50% {
    -webkit-filter: url("#squiggly-2");
            filter: url("#squiggly-2");
  }
  75% {
    -webkit-filter: url("#squiggly-3");
            filter: url("#squiggly-3");
  }
  100% {
    -webkit-filter: url("#squiggly-4");
            filter: url("#squiggly-4");
  }
}

..thus creating the squiggly effect.

Once again, the text used is real, which means that it is searchable, selectable, accessible and editable (using the contenteditable attribute). Check the live demo out, but beware that this demo is resource-intensive, so you may want to avoid opening the Codepen on mobile.

So, some useful takeaways from this section are:

The noise generated using feTurbulence can be used to distort both SVG and HTML content.
The value of baseFrequency can be animated.
You can dial the amount of distortion down by tweaking the values in baseFrequency and by smoothing the noise out with the fractalNoise type.
Even though you can animate SVG filters in general, it’s usually recommended to not overdo it because they can be quite resource-intensive. Try to keep the animations limited to smaller areas; the larger the animated area, the more resource-consuming it will be.

feTurbulence is rarely—if ever—useful when used alone. It is pretty much always used by (an)other filter primitive(s) to achieve particular effects. In this section, we used it as a displacement map in feDisplacementMap. Let’s see what more we can do with it.

Simulating Natural Texture with `feTurbulence`

Another useful way feTurbulence-generated noise can be used is to simulate natural texture. If you’ve ever used the noise generation plugins in After Effects, you may have already come across this functionality and examples of doing so.

Examples of textures created in After Effects using the Fractal Noise plug-in. (Source)

feTurbulence generates noise (random values) across each of the R, G, B, and A components. You can tweak the values for each of these components to get different variations of the noise. In order to simulate a texture, we usually need to do exactly that: tweak the R/G/B/A components (canceling out components, saturating others, etc.) to get our desired result. Other times, all we need to do is shed some light on it. Literally.

In this section, we’re going to break down a rough paper texture effect created by Michael Mullany. In order to create this texture, we will need to shine a light on a noise texture generated by feTurbulence using SVG’s lighting sources.

Lighting Sources in SVG

SVG conveniently provides a few primitives that can be used to shine a light on objects or images.

There are two filter primitives that are used to specify the type of light you want:

feDiffuseLighting which indicates indirect light from an outside source, and is best used for sunlight effects, and
feSpecularLighting which specifies secondary light that bounced from reflective surfaces.

Both primitives shine a light on an object or image by using the alpha channel of that image as a bump map. Transparent values remain flat, while opaque values rise to form peaks that are illuminated more prominently.

In other words, a light source filter uses an input’s alpha channel to provide depth information: higher opacity areas are raised toward the viewer and lower opacity areas recede away from the viewer. This means that the alpha value of a pixel in the input is used as the height of that pixel in the z-dimension, and the filter uses that height to calculate a virtual surface, which will reflect a particular amount of light from the light source. (This is pretty powerful stuff!)

Both types of light accept an attribute called surfaceScale which is practically a z-index multiplier. If you increase this value, the “slopes” in the surface texture become steeper.

“Because feTurbulence generates an alpha channel full of noisy values from 0 to 1, it produces a nice variable Z terrain that creates highlights when we shine our light on it.” —Michael Mullany

After deciding on the type of light you need, you’ll want to choose a light source.

There are three kinds of light sources in SVG:

feDistantLight: this represents a distant light source which is arbitrarily far away, and so is specified in terms of its angle from the target. This is the most appropriate way to represent sunlight.
fePointLight: this represents a point light that emanates from a specific point that is represented as a three-dimensional x/y/z coordinate. This is similar to a light source inside a room or within a scene.
feSpotLight: this represents a spotlight and which behaves much like a point light, but its beam can be narrowed to a cone, and the light can pivot to other targets.

Each of these three light sources comes with its own attributes that are used to customize the light it generates by specifying the location of the source in the 3D-space. The attributes are outside the scope of this article, but you can learn more about them in the specification.

To create and apply a lighting effect, you need to nest the light source inside the light type. So, you start by choosing the type of light you want and then picking the source you want it to emanate from. And then finally you need to specify the color of your light. The lighting-color property is used to define the color of the light source for feDiffuseLighting and feSpecularLighting.

With the basics of lighting sources covered, we’ll now get to our example.

For the rough paper texture, we’ll be using sun-like light. This means that we will use a white diffuse lighting that emanates from a distant source. Translated to code, our light looks like this:

<feDiffuseLighting lighting-color="white" surfaceScale="2" in=".." result="..">
    <feDistantLight azimuth="45" elevation="60" />
</feDiffuseLighting>

The azimuth and elevation attributes determine the position of the source of light in 3D space. There’s an article by Rafael Pons that is absolutely fantastic at explaining these two concepts in a simple, easy-to-understand manner, along with beautiful and friendly illustrations to assist with his explanation. I highly recommend checking it out.

Now that we have a light set up, we want to generate our noise that we want to shine this light on. We’ll break the demo down into steps to learn how it’s made.

We gotta start somewhere, so we’ll start by generating a random, basic noise as a base for our texture:

<feTurbulence baseFrequency='0.04' result='noise' />

Our noise looks like this:

Next, we’ll shine our light onto it and then take it from there:

<feTurbulence baseFrequency='0.04' result='noise' />

<feDiffuseLighting in='noise' lighting-color='white' surfaceScale='2'>
      <feDistantLight azimuth='45' elevation='60' />
</feDiffuseLighting>

Shining the light on our noise gives us the following texture:

This isn’t the texture result we’re after just yet. The first thing we notice here is the presence of a lot of sharp lines in the texture. We want to get rid of these because a paper surface does not have sharp lines in it. We need to smooth these lines out. We can do that by changing the type of the generated noise to fractalNoise:

<feTurbulence type="fractalNoise" baseFrequency='0.04' result='noise' />

<feDiffuseLighting in='noise' lighting-color='white' surfaceScale='2'>
      <feDistantLight azimuth='45' elevation='60' />
</feDiffuseLighting>

This removes all those sharp lined edges from our texture:

We’re now one step closer to our rough paper texture.

The above texture isn’t rough enough, though. It lacks the necessary “roughness”. Increasing the amount of tiny detail in it should make it look rougher. To do that, we will increase the value of numOctaves. We’ll find that around 5 is a great place to get the level of roughness we need:

<feTurbulence type="fractalNoise" baseFrequency='0.04' numOctaves="5" result='noise' />

<feDiffuseLighting in='noise' lighting-color='white' surfaceScale='2'>
      <feDistantLight azimuth='45' elevation='60' />
</feDiffuseLighting>

And our paper texture now looks like this:

Excellent!

You can play with the live demo here:

See the Pen Rough Paper Texture with SVG Filters by Sara Soueidan (@SaraSoueidan) on CodePen.

The demo works across all major browsers, including MSEdge.

If you want, you can tweak the effect a little further by playing with the source and distance of the light. For example, decreasing the elevation of the light source from 60 to 40 should increase the contrast between the small hills in the texture. The texture would then look more like this:

I highly recommend playing with the values of the attributes of the light source and the noise and seeing how they impact the resulting texture.

Final Words

feTurbulence is one of SVG’s most interesting and powerful operations. Combined with other primitives and animated, it is capable of generating some really interesting and appealing effects, textures, and interactions.

I strongly believe that feTurbulence is one of those filters that you’d want to experiment with and break other people’s code down to learn more about it. I still find myself guessing how a texture would look like a lot of times. And since there’s so much we can do with only one texture when used by other primitives, there’s an almost countless set of possible effects that you can make with it. I highly encourage you to check out other people’s work and breaking it down to learn more.

Yoksel has been experimenting with SVG filters on Codepen since my SVG Filters talk came out a few months ago. So you can find quite a bunch of effects to break down and learn from on her Codepen profile.

One of Yoksel’s latest SVG filter experiments leveraging feTurbulence: SVG Filters are ?

I hope that this article has inspired you and opened a new door in your imagination to see what you can do with SVG Filters. In the last article in this series, I’ll be sharing some further resources and tools to help you move forward with SVG filters and to start making your own experiments. Stay tuned.