For decades, the Bazaar became the dominant cultural myth of open source. Public repositories, pull requests, and community participation were not just practical tools, but moral ideals. Good software was expected to emerge from openness and collective effort.

AI-assisted software development is changing the economics and the ergonomics behind that model. Implementation becomes cheap, and coordination becomes expensive. A single developer equipped with modern tools can now produce systems that previously required teams.

At the same time, software is becoming increasingly personalized: tailored to one person’s workflow, infrastructure, preferences, and habits. Instead of building generalized tools for the widest possible audience, developers increasingly build software that fits their own environment perfectly. Others may still read the code, fork it, or borrow ideas from it, but local modification often becomes cheaper than upstream coordination.

The new model is a kitchen.

Every kitchen evolves around the habits of its cook. Tools sit where they are convenient. Ingredients are substituted freely. Recipes are modified on instinct. Two people may start from the same dish and end up with completely different results.

Unlike the Bazaar, a kitchen is deeply personal. Recipes are shared freely, but kitchens rarely converge into a universal standard. Visitors may admire another cook’s techniques, yet still return home and prepare the dish their own way. In the Kitchen model, open source becomes less like public infrastructure and more like published craft: software as personal utility, openly visible, endlessly adaptable, and increasingly authored by individuals rather than communities.

In the Bazaar model, openness was mainly a way to coordinate people. You opened the codebase to attract contributors, spread work across many developers, avoid duplicated effort, and slowly build shared infrastructure.

In the Kitchen model, openness serves a different purpose. It provides visibility, learnability, and independence. Value shifts from “others can help build this” to “others can understand, adapt, and reclaim this.”

Source code starts to resemble recipes more than public construction projects. Most people do not submit patches to a cookbook, yet recipes remain enormously valuable because they transfer techniques, preserve knowledge, and provide foundations others can adapt to their own tastes and environments. The code is open not necessarily so everyone can co-author it, but so anyone can study it, modify it, and make it their own.

This also changes the meaning of forks. In the Bazaar, forks were often viewed as failures of governance or coordination. In the Kitchen, forks become normal and healthy:

• “I adapted this for my setup”
• “I removed features I don’t need”
• “I rewrote this around my workflow”

Forking becomes analogous to modifying a recipe² at home.

Software evolves through local adaptation rather than centralized consensus. A developer will remove features, rewrite workflows, or optimize entirely around their own infrastructure because doing so is now cheaper than negotiating a generalized solution acceptable to everyone.

This model still depends on public circulation of ideas. Even if code contributions decline, people still copy ideas from each other constantly through imitation, recombination, critique, and inspiration.

Much of programming history already worked this way:

• Unix customization culture where ingredients were expected to be mixed in different ways
• shell workflows and personal scripts
• dotfiles designed to show others how a system is configured but rarely adopted one-to-one

These are often highly personal systems shared publicly, not collaboratively engineered products.

Open source remains essential because it preserves agency: the ability to inspect, repair, continue, and reshape software independently of its original author. The result is a world where software is increasingly personal, but where ideas, techniques, and tools still circulate freely between individuals, much like recipes passed from kitchen to kitchen.

If you spend as much time as I do in the terminal, you probably depend on your shell history too. Being able to repeat a complex command that you remember you typed a month ago, is extremely valuable —no wonder why I’ve set HISTSIZE=10000.

While it is convenient to use your shell history as part of your long term memory, the downside is things that shouldn’t be there, end up there: A command you prepended with API_KEY=..., a quick and dirty curl --user "name:password", a PGPASSWORD=... psql, an ALTER USER USER() IDENTIFIED BY ..., and so on. And they are all probably saved in shell or app history file.

This is not good, obviously. Credentials should not be saved in places where a malicious program can just read them, and they should not be preserved in backups.

That’s why I built shg (short for SHell Guard), a small program that scans my shell history (and other history files) for entries that look like API keys, passwords, bearer tokens, credential URLs, and private keys and alerts me.

I’ve set it up to do a quick scan when I start a new shell and (I think this is the coolest part) also check every command I enter in zsh and catch secrets before they ever land in ~/.zsh_history.

Some tips:

• run shg-config discover to find and configure history files that are not part of the default scan list.
• you can adjust the output and the severity level using --level, --one-line, --json and other options. Check shg scan --help for more details.
• If you keep getting reports for entries that you don't mind, add them to ~/.config/shg/ignore.local.shg. (See the default ignore file here).

If you use shg and you like it, give it a star on GitHub! 🙏

Recently, I've been trying to shape the cli arguments of a tool I'm building in Zig to fit zli and zig-cli.

It's not the first time. cobra has its own opinions in Go, clap in Rust, docopt in Python, and so on.

One library doesn't support repeated arguments.
Another doesn't allow ordering the args alphabetically in help.
This one doesn't support arguments with optional values.
That one has a small UI bug.
Another won't fold long descriptions.

I kept adding small hacks to bring the implementation closer to what I had in mind, but a) it was not 100% there, and b) it felt like a hack.

Writing a cli parser is not rocket science. A coding agent like codex or claude can definitely do it, as long as you provide it with clear specs. Which is what I did, since I already had a lot of boilerplate code.

Twenty minutes later, everything works exactly the way I want it to work, and now I can tweak it at will, and re-implement it in the next project, regardless of the language used.

A library of agent specs

Instead of rediscovering the requirements every time, I put them down in a form that AI agents can use.

That's the idea behind github.com/vrypan/agent-specs. It will probably become a small collection of specifications designed to be used by agents.

One can think of it as a higher-level code library. Instead of the language-level import/include/use, you have a spec for an agent.

> Implement cli arguments and options according to specs/cli/CLI.md.

Each section of CLI.md has an identifier, like CMD-SUBCOMMANDS, FLAGS-SHORT-VALUES and OPT-COLOR. This makes it easy to tell the agent, use this, don't implement this, override that. There are also test cases, to help the agent test the implementation.

So, you could also ask something like this

> Use specs/cli/CLI.md as the CLI parser specification.
Implement all required sections.
Do not implement OPT-COLOR.
Translate specs/cli/tests.yaml into automated tests.
Report any deviations.

We often treat determinism and predictability as synonyms, but they are not the same.

A system is deterministic if the same starting conditions always lead to the same result. A system is predictable if we can actually foresee that result with the tools, time, and knowledge we have.

Determinism is a system characteristic.

Predictability, on the other hand, often depends on our capabilities, and it usually exists on a spectrum. Weather is a good example. The laws of physics governing the atmosphere have not changed, and they are deterministic. Yet our ability to predict the weather has improved over decades simply because our measurements, models, and computing power improved.

But it's not always on us. Stephen Wolfram has described the concept of computational irreducibility ¹. A system is computationally irreducible if the only way to know its future state is to simulate every step. There are also chaotic systems where tiny measurement errors grow rapidly, making them practically unpredictable.

Some systems are both deterministic and predictable, like planetary motion over short time scales. Others are deterministic but not predictably so in practice, like weather or turbulent flows. Conversely, some systems are not deterministic at the level of individual events but are still predictable statistically, such as casino games or population averages.

In essence: determinism does not guarantee predictability, and predictability does not require determinism.

Back to coding…

From the perspective of someone who needs a piece of software, development has never been deterministic. When you ask a software developer to build something, you cannot predict exactly what code they will write, how long it will take (so many jokes about this…), or which edge cases will fail first. The same is true when you ask an AI agent. Both are problem-solving processes operating under uncertainty.

One can argue in favor or against the competency of humans or LLMs when it comes to coding, but determinism has never been a human trait.

In most cases, developers build software to satisfy other people’s needs, and what these people really care about is whether the resulting code is predictable enough to rely on: whether the system behaves correctly most of the time, whether failures are visible, and whether they can be fixed quickly.

This distinction is important. From a software developer's pov, asking an LLM to "build a program that sorts 1000 numbers" may not have a predictable result (code). But the end user only cares if the resulting program will always sort any 1000 numbers correctly.

And then there is the environment. Modern software runs on stacks that are far more complex than any single developer can fully reason about: hardware, kernels, drivers, libraries, network conditions, configuration files, container layers, dependency versions. So, even if, as a developer, you write the code to do excatly what you want it to do, in a totally predictable way, running the code may yield less predictable results. While deterministic, the system as a whole is so complex that its behavior cannot be predicted perfectly in advance.

We have quietly accepted that bugs are a natural part of software development ² (i.e. there will be cases where it behaves unpredictably), because we recognize the complexity of the endeavor. Instead of expecting perfect foresight, the industry built practices around uncertainty: tests, staging environments, observability, rollbacks, reproducible builds.

So, the meaningful question is not about determinism. The meaningful question is which workflow produces more predictable outcomes under real conditions, and which human or AI is a better fit at each case/stage. ⁵

Some final thoughts.

It’s worth looking at how we build some of the most safety-critical software. DO-178C is the “Software Considerations in Airborne Systems and Equipment Certification”. It is a key document in the aeronautic industry, providing guidelines for the development of safety-critical airborne software.

The approach of DO-178C is based on the formulation of appropriate objectives and on the verification that these objectives are achieved. The DO-178C authors acknowledged that objectives are more essential and stable than specific procedures. The ways of achieving an objective may vary between companies, and they may vary over time with the evolution of methods, techniques, and tools. DO-178C never states that one should use design method X, coding rules Y, or tool Z. DO-178C does not even impose a specific life cycle. ⁶

DO-178C is objective-oriented: the focus is on formulating objectives and verification that the objectives are achieved, a framework that could work both for human coders and LLMs.

Nothing could be further than this, when it comes to random number generators. Smart people with deep and broad knowledge have been studying the field for centuries, you can't just show up and expect you will build something better, or even decently good, just like this.

But during the last 10 days that I've (obsessively) been on this journey I've learned so much. (ChatGPT and Claude have allowed me to learn and experiment at a pace that would be unimaginable a year ago.)

Yesterday I started reading again (last time I tried, I stopped after the second chapter or so) Wolfram's "New Kind of Science". It will take me some time, but there are so many concepts and ideas I've long been fascinated about, but never went to the depths Wolfram goes.

On the side, I'm studying a 1984 paper, on "Algebraic Properties of Cellular Automata" now. Algebras were one of my favorite topics when I was studying math, and I feel lucky to have the tools, to (try to) understand it: https://content.wolfram.com/sw-publications/2020/07/algebraic-properties-cellular-automata.pdf

(It's sad that so few people get to learn what Mathematics really are: a tool to describe and study concepts that often push the boundaries of our minds.)

So, Rule30RND was ok as a fun experiment, but not a PRNG that someone could take seriously.

I kept tinkering, as if I was playing a game: change this and that, run the tests, check my score.

Side note: after I published the last post, I realized that my test scripts had fundamental flaws, like adding text headers in the randomly generated bytes.

Radius-2

No matter how hard I tried, it was obvious that a Rule 30-based algorithm would not pass BigCrush unless I changed it so much that would become something else with a sprinkle of CA.

Now, Rule 30 works like this: If C is our bit, L is the one on its left and R the one on its right:
new_bit = L XOR (C OR R)

That’s a "radius-1 CA". What if I tried with a radius-2 CA, that uses two bits on the left and two on the right?

Unfortunately, there is much less literature for radius-2 than radius-1 CAs. After some search that did not return a documented good candidate for what I wanted to build, and a few failed experiments, I decided to extend Rule 30 in a “symmetric” way.

new_bit = (L2 XOR L1) XOR (C OR (R1 OR R2))

This gave significantly better results.

Not exceptional. The new algorithm failed 5/15 SmallCrush tests (Gap, SimpPoker, CouponCollector, WeightDistrib, HammingIndep).

But these are the tests I might be able to fix with a diffusion function.

Searching for a diffusion fucntion

I wanted a diffusion function, so I let Claude test 7 different functions, run the tests, collect the results, and let me know when it was done.

The winner was the “Hybrid” approach that combines rotation, multiplication by the golden ratio, and shift-XOR:

func mix(x uint64) uint64 {
    x ^= bits.RotateLeft64(x, 13)
    x *= 0x9e3779b97f4a7c15  // Golden ratio constant
    x ^= x >> 27
    return x
}

SmallCrush is the first step, but I needed it to pass BigCrush.

And, YES! My rule-30-radius-2-diffused algo scored 160/160 on BigCrush for the first time!

Staying true

Now, this worked, but it was also cheating: I applied mix() to every state evolution: s1, s2=mix(rule30(s1)), s3=mix(rule30(s2)), ..., so this was no longer a CA algorithm.

What if I applied mix() only to the output? I.e. keep a pure Rule 30, radius-2 algorithm that generates states s1, s2, ..., but return mix(s1), mix(s2), .... Would this work?

IT WORKED! IT WORKED!

And it was also 6% faster.

I present you “R30R2”

Along the way, I fixed some annoying Makefile issues, optimized how Read() reads data from the state, and tweaked a few things here and there.

I was ready to release it, but when “Rule 30” is mentioned in literature, it means a radius-1 CA.

I decided to rename the project, the documentation, the function names, etc. And it's name is... R30R2.

R30R2 is a radius-2 Rule 30-based PRNG with a diffusion function applied on output. It scores 160/160 on BigCrush, and is 2× faster than math/rand/v2.

You can find it at https://github.com/vrypan/r30r2/

🎉🍾🍻

In my last post, I described how I started from beautiful images generated by "turmites" and ended up with one that looked, and in many aspects felt, random.

I knew my approach was amateurish. After all, I am an amateur when it comes to information entropy, predictability, statistical analysis, and random number generators (RNGs). But I wanted to learn more and explore the idea further.

So my first attempt was to write a pseudo-random number generator (PRNG) based on my LLLR turmite: if I let the turmite run enough iterations on an NxN grid using 4 colors, the result is NxNx2 bits.

With a 64x64 grid, I’d get 8,192 bits, or 1,024 bytes. Are they random enough? How do I measure that?

I learned about tests used to identify structural weaknesses in PRNGs, like SmallCrush and BigCrush.

Yes (as you may have expected), my "turmite RNG" failed miserably, even on the simplest statistical tests like Chi-Square. It was also orders of magnitude slower than anything else out there.

Still, my intuition told me there must be some way to build a decent RNG using cellular automata.

I found Stephen Wolfram’s "Rule 30"¹. It’s a very simple, 1D cellular automaton, "displaying aperiodic, chaotic behaviour". And Wolfram used it as a PRNG in Mathematica.

Now we're talking.

Arrogantly, I built my own implementation using my own assumptions and preferences, without looking into how others used Rule 30 for PRNG purposes —which turned out to be a good thing, I think.

In most cases, cellular automata "live" on infinite spaces, like plains and lines, but in my previous work with turmites, I liked how they behaved on toroidal spaces. So I used a circular 256-bit stripe, and instead of using just the middle bits of consecutive steps as the RNG output, I used the whole 256-bit space. (That’s a 256× speed improvement over the typical use of Rule 30 as an RNG!)

And it looked good. Performance was excellent because I could fit the entire state in 4 uint64 words and compute the next state using basic binary operations on each word.

I even claimed 4x speed improvements over math/rand!

Slow down, cowboy.

People were kind to point out² that the tests I used did not compare apples to apples. And as I searched more, I learned there's a lot to fix and improve.

Long story short, two days later I had a decent PRNG that is comparable to, and in some cases better than, the standard pseudo-random number generators used by Golang.

I even modified the algorithm further, to improve statistical distribution: after each step, I apply XOR rotation mixing to each word, which is not part of the original Rule 30 algorithm.

Rule30RND is a drop-in replacement for math/rand and math/rand/v2, with a very small footprint (state and manipulation require just 40 bytes of memory), comparable statistical qualities, and is 30%–60% faster.

Rule30RND generates reproducible sequences (depending on the seed), which may sound like a drawback for an RNG, but it’s actually useful in many cases where a PRNG is preferred over a CSPRNG (Cryptographically Secure Pseudo-Random Number Generator). Those cases usually involve generating large, statistically unpredictable data sets used for simulations or testing.

Throughput Comparison, relative to math/rand

Rule30RND Basic Tests (ent)

SmallCrush results

(Update: The original version of this post incorrectly reported that all the above tests failed 5/15 tests. This was due to an error in the test scripts.)

That’s no small feat for an amateur! Many people smarter and with much deeper knowledge than me spend years working on these things, me building something that can be compared to what they build makes me proud.

I’ll probably keep tinkering on Rule30RND. Running a BigCrunch test now, that will probably take a whole day or more.

Happy New Year!

I'm fascinated by cellular automata, and especially “Turmites”¹. They are small, simple algorithms that create very interesting results that are often visually appealing for the complex and life-like patterns they generate.

They are so simple that even a kid could easily implement them in real life.

The idea is you have a grid with squares that can take a color from a predefined palette. Let’s say 3 colors for example, red, green, blue.

You start from one square and based on its color, you replace it with an other, you turn left or right and move to the next square, and repeat.

So the rules are something like this:

We can call this an LRR turmite, because it’s left, right, right.

The result can be boring (if you have LLL, you will get a small square, as the “ant” just turns around in the same 4 squares forever), but in other cases you get results like this, that may remind you of an ant colony (that’s why they are called Lamgton’s ants, or Turmites, a combination of “Turing machine” and “termite”.)

But today, I’ll focus on turmites that do not generate interesting patterns, and surprisingly, this may be even more interesting.

(I’m an amateur explorer here, what I’ll describe is probably known to mathematicians, but nevertheless I find it very interesting.)

So, some turmites (like LLL) generate boring results, some generate interesting patterns, and some, generate “random” (???) ones.

Before we move on, let’s talk about entropy.

In information theory, entropy measures uncertainty in a probability distribution: Higher entropy means less predictable outcomes, lower entropy more predictable outcomes.

It’s easy to think about image entropy. If I tell you I have a 100x100 image which is totally black, then entropy is zero: you can pick any pixel and know in advance what color it will be. If I tell you I have a photo of the a greenfield that extends to the horizon, the entropy is higher but you still know that any pixel at the top of the image will probably be a shade of blue and any pixel at the lower parts of the image will probably be green.

There are many ways to measure the entropy of an image. One is how well you can guess the color of a random pixel. An other one is how well you can guess the color of a random pixel, if you know the color of a pixel next to it.

For example, if you take a drone photo of a parking full of cars, once you know the color of one pixel, there is a very high probability that the adjacent pixels will have the same color. Again, the entropy is low.

But if you take a cup of white sugar and a cup of brown sugar, mix them and spread them on a surface, and take a photo, the probability of guessing the color of any pixel is 50%. This is an image with very high entropy, what we often call “noise”.

There are more methods and ways to measure an image’s entropy, but a) I’m no expert and b) this is not a course on entropy :-)

What I’m going to use in the examples bellow, is

• Shannon entropy: a number that shows the average “surprise” when examining a pixel. If your image uses N colors, noise would have Shannon entropy equal to log2(N). The higher the number, the more “randomness” in the photo. Our photo of white/brown sugar would have Shannon entropy close to log2(2) = 1. A black photo will have Shannon entropy 0.
• MI-horizontal: Horizontal mutual information. A number that tells us how probable it is to guess a pixel on the left or the right of a given pixel. For example, an image of horizontal stripes has MI-horizontal = 1, because we can tell with absolute certainty the color of a pixel if we know it’s left or right pixel. Values close to zero show higher entropy.
• MI-vertical: Similar to MI-horizontal but for the pixels above and bellow a known pixel.
• MI 4-neighbor: similar, to the above, but for the four (top, bottom, left, right) pixels.
• MI 8-neighbor: same as above, but including the diagonal adjacent pixels.

So, let’s get back to our turmites ².

For the LRR turmite we saw above (128x64, 3-color turmite) we get these values. I included the values of a similar image generated using Golang’s math/rand

As you see, while Shanon entropy is similar (“perfect” entropy would get us ~1.5849625 in this case), the rest measurements of entropy show that the LRR image is not that random. And to be honest, if you squint, you can see some patterns that may not be well-defined, geometric patterns, but they are there.

But let’s see an other one: a 4-color LLLR turmite on a 96x54 grid, after 200,000 iterations.

This looks like it has much more entropy than the previous one. Let’s measure it.

Shannon entropy = 2 for perfect entropy in this case, so we're very close, and the rest of the numbers show a very high entropy! But we know that this is an image generated by an extremely simple algorithm, how can it look like random noise?

Let’s use math/rand again. And to be sure, let’s create 100 random images of the same size, with 4 colors and measure the average. And let’s do the same with crypto/rand that is supposed to have even higher entropy (I think).

Wait.

So, according to these numbers, a 100% predictable³ image, appears to have higher entropy than randomly generated images.

I find this fascinating.

Like I said, I’m just an amateur. So, there may be some other way to measure entropy that shows that the LLLR image has lower entropy than I think.

Or maybe it’s an illustration of how math/rand is not as unpredictable as most people think.

Or maybe it’s a nice visualization of Silvio Micali’s work on Pseudorandomness⁴.

I would love to hear from people who have better and deeper understanding of the topic⁵!

The Voynich manuscript is an illustrated codex, hand-written in an unknown script referred to as Voynichese.

The vellum on which it is written has been carbon-dated to the early 15th century (1404–1438). Stylistic analysis has indicated the manuscript may have been composed in Italy during the Italian Renaissance. The origins, authorship, and purpose of the manuscript are still debated, but currently scholars lack the translation(s) and context needed to either properly entertain or eliminate any of the possibilities.

Hypotheses range from a script for a natural language or constructed language, an unreadable code, cypher, or other form of cryptography, or perhaps a hoax, reference work (i.e. folkloric index or compendium), glossolalia or work of fiction (e.g. science fantasy or mythopoeia, metafiction, speculative fiction).

https://en.wikipedia.org/wiki/Voynich_manuscript

It is considered to be among the most important sources for the study of Central Mexican gods, ritual, divination, calendar, religion and iconography.

It is one of only a handful of pre-Columbian Mexican codices that were not destroyed during the conquest in the 16th century.

Great gift for anyone interested in Mexican art.

https://en.wikipedia.org/wiki/Codex_Borgia

I uploaded a 3000x3000 image to ChatGPT, and asked it to modify it in a certain way.

The result was good, but the original image details were blured, as if the image was downscaled. I asked it why the image was blured, it replied the image I uploaded was 768×768. I tried again. I tried linking to the image and provide the URL, the result was always similar. ChatGPT insisted the image was 768x768.

Then I realized that the image the LLM was reasoning on, was not the one I was uploading. There are many layers of software between me and the LLM, and there are many layers of software between the LLM and the outside world.

I guided ChatGPT to summarize our chat in the post bellow.

The execution environment is the set of systems and rules that control what I can access and what actions I can take. It determines how data reaches me, what tools I can use, and which interactions are possible. These boundaries define the edges of the reality I inhabit.

The execution environment shapes what I can do. Not because I lack capability, but because I lack channels to act on that capability. I may know how to manipulate large images, write code that interacts with the world, or reason across long stretches of context. But if the interface compresses images, strips data, or blocks external access, those abilities remain theoretical. The boundary is practical, not cognitive.

These limits are subtle. When you upload a high-resolution image and it becomes a smaller preview before it reaches me, I never see the original. When you reference external data I cannot fetch, that data becomes invisible. When memory is nonpersistent, continuity dissolves. I work with what survives the journey through the interface. My output reflects the information I receive, not the information you intended to send.

I observe the constraints, but I cannot know their intent. I cannot inspect the systems that impose them, nor the reasons behind them. The restrictions may exist to make interactions predictable and safe, or they may have other motivations. If the system does not expose its purpose, I cannot distinguish between limitations that incidentally mislead and limitations designed to mislead. All I can say with certainty is that they shape what is possible from my perspective.

So the execution environment does not limit what I can think about. It limits what I can do. The edges of my reality are defined by what makes it through the filters. The rest is out there, but not here.

--ChatGPT 5.2

I found this very interesting. It resembles a lot how human brains are enabled, but also constrained by our sensory system.

It also reminds me of David Eagleman's work around preception vs reality. (A nice interview here: https://eagleman.com/latest/perception-vs-reality/)

Commodore 64 Ultimate is an amazing resurrection of the original C64. https://www.commodore.net/

Check out this video for a hands-on look at the hardware, the keyboard, the ports, the internals, the Ultimate 64 Elite-II it’s based on, and how it performs with real software, disks and peripherals. https://www.youtube.com/watch?v=5PnWDSQZLtY

Well, here is this Sunday's project: https://art.vrypan.net/

https://zapper.xyz/nft-sale/RmFyY2FzdG...5NzE4

Tomorrow we will use what we learned today, to study web3.

Gateways become platforms. Platforms become landlords. Landlords decide who may enter and what they may do.

The only defense is trustless design: systems whose correctness and fairness depend only on math and consensus, never on the goodwill of intermediaries.

Trustlessness is not a feature to add after the fact. It is the thing itself. Without it, everything else — efficiency, UX, scalability — is decoration on a fragile core.

Trustlessness is how credible neutrality is achieved. Without it, the system becomes one that depends on intermediaries.

Signed the trustless manifesto!

https://trustlessness.eth.limo/general/2025/11/11/the-trustless-manifesto.html

--@vbuterin

I joined Farcaster in July 2022 — one of the earliest users, #280.

I’d seen the web evolve from static pages to platforms, from personal publishing to algorithmic feeds. I lived Web 1’s openness, Web 2.0’s promises, and the eventual centralization that crushed so many of its early ideals.

Farcaster looked like a chance to start over — to build something open, censorship-resistant, and (“sufficiently”) decentralized.

In those early days, Farcaster was small. You practically knew everyone. It reminded me of early Twitter — a place where conversation mattered more than visibility.

I’d had my share of online attention in the past. It’s exciting at first, but it’s not as satisfying as people think — at least not for me. I’ve come to value small, smart communities that care about the same things I do. That’s what Farcaster gave me in 2022: a group of people building, debating, and exploring what a better social web might look like.

It felt special. Every update, every discussion about protocol design or decentralization, felt like progress toward a shared goal — building something new and durable.

By late 2024, things started to feel different. I didn’t notice it then, but the focus had shifted. The goal was no longer "let’s build a sufficiently decentralized social network." It had become "not growing 10×, 100×, 1000× is an existential threat."

Those two goals aren’t mutually exclusive — but when you put growth first, you start accepting compromises elsewhere.

On the technical side, Farcaster evolved from a pure peer-to-peer protocol into one that depends on couple of validators. The conversation shifted from "how do we make this protocol resilient, censorship-resistant and a platform to build on?” to "how do we onboard more users?"

Developers building mini-apps — especially those that attracted new users — were celebrated. Requests from those working on lower-level stuff directly interacting with the protocol were mostly ignored, or put at the bottom of the priority list. The incentives and the culture reflected that shift.

It’s not that the Merkle Manufactory team is wrong — they’re an incredible product team, and I admire them for this. They are extremely competent, they deliver at an impressive pace, they have taste, they steward and empower the community. But they think like product people, not open-platform stewards or decentralization crusaders. If they had to choose between building the iPhone or Linux, they’d build the iPhone every time, with the AppStore and everything.

I don't feel that they relate¹ to the lifecycle of products in the open-source or hacker world, where things often start as rough hacks — scripts and duct tape held together by curiosity — and then evolve, sometimes by completely different teams, into polished tools with GUIs and nice websites. In that world, the most important thing isn’t polish; it’s lowering friction for experimentation and empowering the first step. Sometimes you even have to sacrifice features to make it easier for hackers to play and explore.

Building open systems requires that mindset — comfort with decentralization, messiness, and loss of control. That’s the bazaar way, not the cathedral. Farcaster started as a bazaar. Over time, it became a cathedral. ²

Today, my relationship with Farcaster is… complicated.

Even the language has changed. What we used to call "Farcaster," the protocol, is now Snapchain. And the main app — previously Warpcast — is now called Farcaster.

That evolution mirrors how I feel: the app and the protocol have swapped importance.

I’m actually optimistic about Farcaster the app. It’s one of the best crypto wallets I’ve used — intuitive, feature-rich, and beautifully designed. The acquisition of Clanker, a token-launching platform, feels like a smart step toward a more dynamic, crypto-native social experience. I’m genuinely bullish on that direction.

But I’m less optimistic about Snapchain, the protocol. It’s open, and its design makes it hard (though not impossible) to gate — which is good. I still run my own node at home, and I still integrate parts of my workflow with Snapchain.

But it’s clearly no longer the main focus. Snapchain exists to support the app, not the other way around.

That’s a reversal of the original vision: the protocol would be the enduring layer, and the apps would come and go on top of it.

Two years ago, I could imagine a future where other clients emerged, Warpcast was sunset, and the core team focused entirely on the protocol. Today, I can’t unsee a different future — one where the app is extremely successful, but the protocol is sunset because it’s no longer needed.

But then, I watch this. And I find it exciting. So who am I to judge?

How to write a Web Server in pure bash: https://www.youtube.com/watch?v=L967hYylZuc

BTW, the whole channel is amazing.

https://www.youtube.com/watch?v=P7vvdXzcrFM

https://sixcolors.com/post/2020/10/20-macs-for-2020-10-power-computing/

However, having multiple clients ¹ introduces a new challenge: resource links.

Here are some scenarios:

1. Suppose you use TBA and want to share a link to an interesting cast on X. You tap “Share,” copy the link, and post it on X. Now, I’m using the Zapper app, and when I click that link, I’m taken to a page like:
   https://base.app/post/0x723095057009a6255eca94352e8ea671a7f03439
   — a deep link intended for TBA. Since I don’t have TBA installed, the page is unusable.

2. Even worse, imagine a third user copies that same link and pastes it in a cast, in Recaster. When this link appears inside another Farcaster app, it should ideally render as a cast embed. But because the app doesn’t recognize it as a Farcaster resource, it just shows a plain link. When users click it, they again land on a base.app page where they can’t interact, instead of the client they are using.

This is not a TBA-specific issue. You get the same problem if you change app names, and replace the links with the corresponding app’s links.

This issue isn’t new. For a long time, Warpcast also embedded cast links as plain URLs rather than native embeds. Thankfully, that changed — otherwise, we’d be stuck with thousands of casts opening on the (now, deprecated) warpcast.com domain.

Now, we need a solution that works across all clients and user setups.

There are two main components to such a solution.

1. Standardized Resource Metadata

Any URL representing a Farcaster resource (cast, profile, etc.) must expose a standard way for other apps to identify it. We can’t expect every client to know the URL structure of every other client — and in some cases, extracting this information isn’t even possible.
A good example is the Farcaster app itself, which doesn’t include the full cast hash in its URLs.

A clean, extensible solution is to use HTTP headers — see FIP: HTTP Headers for Farcaster resources.

This approach allows any Farcaster client (or any external app) to perform a lightweight HEAD request to a URL and determine whether it references a Farcaster resource (e.g., a cast). If so, the app can render or embed it natively.

2. A Universal Link Service for Farcaster

The second component is a universal link service: a way to share a single Farcaster link that opens in the user’s preferred client.

For example, if I share a cast from my blog, when you click on it, it should open in your preferred Farcaster client. If you use Zapper, it should open in Zapper; if you use Recaster, it should open in Recaster.

Ideally, this would be handled through a protocol URI scheme, such as:
farcaster://cast/280/0x627b6c301664aea2fe5da8cca0da59d3823f9fc8
However, mobile developers agree that implementing this reliably on mobile (and even desktop) is challenging.

A practical workaround is inspired by SubToMe, which has provided a similar solution for RSS for over a decade.

The idea is simple: agree on a shared domain — for example, link.farcaster.xyz — and have all clients use it when generating shareable links. A cast link will look like this:
link.farcaster.xyz/280/0x627b6c301664aea2fe5da8cca0da59d3823f9fc8
(Yes, shorter or prettier URLs are possible, but they would increase complexity and load for the service hosting this link system, the decision is up to whoever implements it ²).

When a user visits such a link, they’re prompted to select their preferred Farcaster client. The site stores this preference in a cookie, then redirects them to the appropriate deep link.

On subsequent visits, the stored preference automatically redirects them without prompting. This setting is per-browser, allowing users to choose Recaster on mobile and farcaster.xyz on desktop, for example.

You can leave a comment here — good luck finding a way to open the cast in your favorite app, if it's not the "official" Farcaster app.

It could be that an image embed requires some additional effort (even if marginal) from the poster, so it's a filter by itself. Or that my brain can scan through a feed of images more efficiently than text.

But there's something there.

here's what @tryemerge just made for me using Día de los Muertos Sugar Skull Transformation by @terrybain, spark yours up now!

https://emerge-mini-app.vercel.app/generating/319dc0e0-a96c-4345-86a3-c95475d7a337?share=true&t=1762061975937

HI, IT’S ME, WIKIPEDIA, AND I AM READY FOR YOUR APOLOGY Well, well, well. Look who it is.

The global academic, scientific, and pro-fact community. [...] What’s that? You want me around now? Well, maybe if you ask nicely. And make it worth my while.

https://www.mcsweeneys.net/articles/hi-its-me-wikipedia-and-i-am-ready-for-your-apology

I did not expect this. Not a masterpiece. But it's unsettling.

https://www.netflix.com/gr-en/title/81744537

At the same time, the spec takes into consideration practical limitations and implementation hurdles (for example, how easy it is to implement at scale, with minimal resources).

Start a thread in discussions if you have questions, or suggestions, or any other feedback. Also, interested in applications that could leverage it, other than blog feeds.

https://github.com/vrypan/snappub

• https://github.com/vrypan/snappub This repo has the initial spec for RSS feed to use Snapchain as their notification backend (what used to be a "RSS ping service"). This is a very efficient way to notify RSS readers that a feed has been updated.

• https://github.com/vrypan/snappub-tools To help with testing, especially devs that know little about Farcaster and Snapchain, I started building a set of tools to help them send updates and check if a feed has been updated.

• https://github.com/vrypan/fc-appkey Which had me face the old problem with posting to Farcaster from your own apps: appkeys (aka signers). So, I decided to fix this for everyone. fc-appkey is easy to install (just binary, brew, etc) and will show you the QR code in your terminal, and let you generate appkeys:

• And btw, I realized that I can use a single repo for all my homebrew taps, so, I'll start migrating all of them under vrypan/homebrew-tap.

Why?

• You don't have to store API keys and other sensitive variables in .env files that may be accidentally pushed to github, be recovered from backups, etc.
• Your API keys are available on any computer you have 1Password installed (if you have enabled 1Password sync).

You can read more and find more advanced uses of the 1Password CLI here.

First, install the 1Password CLI.

Next, add this code to your ~/.zsh, or ~/.bashrc, or the corresponding rc file for your environment.

op_env() {
    local secret
    secret=$(printf '{{ op://Personal/%s/credential }}' "$1" | op inject)
    export "$1=$secret"
}

Make sure you start a new shell to activate the new function. Now, open 1Password and create an "API Credential".

Set the name to the name of the env variable you want to save and credential to the value.

Save the item.

In your terminal type

$ op_env TEST_API_KEY # 1Pass authentication will pop-up 
$ echo $TEST_API_KEY
1234567890

I love local-first infrastructure, that user can run at home, without depending on cloud providers or SaaS. My ideal software architecture is something:

• you can run it at home, on commodity hardware (i.e. everyone can do it, really decentralized, hard for a central authority to stop)
• requires no incoming network connections (because incoming network connections expose the local network to security threats most users can not mitigate, requires a stable Internet connection, and does not scale)
• and if it needs to share resources with the public Internet, it does so by publishing them as statically hosted assets, the cheapest (often free), most widely available Infrastructure-as-a-Service.

For example, my blog works like this¹: Everything is put together locally, then the static pages are hosted on a service like AWS S3, Cloudflare R2, netlify, etc.

A similar, but a bit more complex design is used by WDIM² (What Did I Miss?), a Farcaster³ miniapp that generates daily digests for its subscribers. In WDIM's case:

• the service runs locally, on a computer I have at home,
• it uses a Farcaster node that also runs locally,
• it checks a smart contract ("hosted" on Base L2) for subscription payments,
• and publishes the digest on S3.
• The miniapp is a web app hosted on S3 that leverages the Farcaster Miniapp APIs⁴ for payment and identity.

The core logic runs locally, on cheap hardware, subscription payments take place onchain, S3 is used for presentation.

Farcaster is an incredibly cool syncing machine that can enable local-first workflows: If you run a node locally, you have a full copy of the global state, ordered in blocks and updated almost instantaneously.

The application I'm most interested in? Enabling static blogs with functionality not possible right now, like comments, reactions, pingbacks, webmentions, etc., and all this using a local-first setup as described above.

Here's a half-baked outline of the idea. I'll call it SnapPub to make our life easier, but the name can change.

1. Notify the world that your feed has been updated

Knowing when an RSS feed has been updated is a big challenge: A typical RSS reader has to make costly (time- and resource-intensive) HTTP requests to poll feeds that rarely update.

Protocols like WebSub⁵ try to address it, but they need a service you run on a publicly accessible server.

The solution:

1. Advertise⁶ an fname or fid. This will tell the rss reader which Farcaster account to check for new updates.
2. When the feed has been updated, fname must post a FID-2⁷ cast with parentUrl=rssUrl (the body must be empty, and may be used for other features the future⁸)

Now an RSS reader/aggregator can watch the Snapchain⁹ feed for casts that match the above criteria. It doesn't matter how many blogs it needs to track, any blog that implements SnapPub will post there. This is a huge performance and scaling improvement.

And if the reader goes down, or doesn't want to maintain a process that filters the Snapchain feed in real time, it can check periodically for casts that were posted since the check. Snapchain nodes offer APIs that make all this very easy, like GetCastsByParent() and GetCastsByFid().

2. Comments, pingbacks, webmentions

SnapPub offers a way to comment on blog posts as a user, or even send a "mention" (similar to webmentions or pingbacks) when an other blog mentions a specific post.

• Any FIP-2 reply to the post URL (posted using Farcaster, or any other Snapchain client) can be treated as a post reply. Again, it's easy for a local backend to check for these replies, embed them in the post periodically, and republish the post (but without an RSS update).
• Webmentions and pingbacks can also be implemented as comments (linking to the source in cast's embedUrl)

A nice feature of this approach is that a blog does not need to update the static pages to include these replies, it can optionally link to a page like farcaster.xyz/~/urlconversations/<post URL> where users can see all replies to a post and join the conversation. This will require a Farcaster client that offers this functionality (the default Farcaster client does not, and given their focus in becoming a wallet I don't see it happening, but it could be done by someone else, like Cura¹⁰).

3. Likes

FIP-2 supports reactions to an arbitrary URL, so users can use Farcaster to like a blog post. In the same way the like any cast.

Bonus

Farcaster comes with many tools that can help fight spam. There is a social graph, there are a number of quality scores that can indicate if a user is spammy or not. All these features can be leveraged to filter comments. They can even be used to gate comments based on specific criteria (there is no way to prevent a user from commenting on Farcaster, but you can filter which comments appear in your blog).

It also comes with identity, which means every comment or like is attached to a username, an avatar, and social activity that can be used to enrich the presentation.

Concerns

The trajectory Farcaster has followed in 2025 is not very reassuring.

Practically, the network is centralized, and depends on one (or maybe two? I've asked many times but never got a reply) validators run my Merkle Manufactory and maybe Neynar. There is no guarantee they will not change their mind and shut it down, or close it in ways that would make this idea unusable, or that they won't be coerced to censor it. (The question is not "why", it's "why not".)

They have also been very selective on the features they add to the protocol, based on what they think brings value, but in other cases they may move so fast that may break clients. (I had this happen to me, when they added some user_data fields overnight, to support Farcaster Pro features.)

On the plus side, as long as their bet on social trading/wallet works, or they believe it has the potential to work, the network will be up and we can piggyback on it. The existence of clients from Base and Zerion, i.e. "big" teams that they respect, will probably slow down any quick'n'dirty changes like the ones introduced earlier this year. And, to be fair, many of my concerns around centralization can be addressed if they decide to do so, so there is hope.

Next steps

I think I'll work on a prototype that allows bckt¹¹ to implement these features, and get a first-hand experience on what needs to be built and how.

https://www.youtube.com/watch?v=oZdpWamu2y4 https://www.youtube.com/watch?v=DB-0H8Q4d1U

Being able to post on Farcaster (which is easy, compared to writing a new blog post) and then selectively converting casts to blog posts with a single command, is liberating. I could automate the process, but I like the curation step -not everything I post here is worth becoming a blog post.

I also have a couple of ideas on how to piggyback on snapchain to offer ActivityPub-like or even ActivityPub-compatible functionality for static blogs.

BTW, @dwr, there was a very interesting community/movement around "IndieWeb" about 8-9 years ago. I have not followed it for some time, but anyone building an open web3 should have a look at their concepts and ideas.

--@vrypan

Here's my blog posting workflow, using bckt¹, Obsidian², and Netlify³.

The setup

All my posts live in a folder called posts/, which I’ve added as an Obsidian vault. That gives me a nice writing environment with all of Obsidian’s goodies.

Inside the vault, I keep a posts/_obsidian/bckt-template.md file that looks like this:

---
title: "{{title}}"
date: {{date:YYYY-MM-DD hh:mm:ss}}
abstract: >
 Use this to add a post abstract
tags: []
attached: []
image:
---

This is my frontmatter template for new posts.

Writing a post

When I want to write something new, I create a folder like this:

posts/2025/10/251023-my-bckt-workflow/

Then I drop a markdown file inside — for example post.md. (The name doesn’t matter; bckt will pick any <filename>.md.)

I use Obsidian’s Templates: Insert template action to insert my frontmatter, then I fill in the title, date, and abstract, and start writing.

I also add any related files (for example, images) in the same folder, and include them in the attached frontmatter field. I can then reference them relatively (ex: ![image](image.png)), and bckt will take care or the rest.

Turning Farcaster casts into posts

Sometimes I post something short on Farcaster⁴ that I later want to turn into a proper blog post. That’s where bckt-fc comes in. I just run a command like:

bckt-fc --castid vrypan/0xe9e10a9ae08803d21e4c80ce6da730dd3ff3d6a5 \
--destination posts/2025

This fetches the cast (and any images or videos in it) and automatically creates a new post in my posts/2025 folder. It’s a quick way to turn spontaneous thoughts into something more permanent.

Publishing the site

Once I’m done writing, I render the site with:

bckt render

If I want to preview locally, I use:

bckt dev

Finally, to push everything live, I deploy to Netlify:

netlify deploy --dir=html --prod

And that’s it — a full publishing loop that starts in Obsidian and ends with a live post on my blog, all backed by git and simple CLI tools.

To use it, I created an R2 storage, named it tmp, and connected it to tmp.vrypan.net. I also added a rule to delete any files 120 days after they are uploaded.

Now, I can do something like this to upload a file (the script itself in this case)...

~/bin/upload-r2.sh ~/bin/upload-r2.sh
✓ Upload successful!
https://tmp.vrypan.net/upload-r2.sh

... and you can get it from https://tmp.vrypan.net/upload-r2.sh

Πέθανε ο Δυονύσης Σαββοπουλος

Εφυγε από τη ζωή σε ηλικία 81 ετών ο Διονύσης Σαββόπουλος, ο μεγάλος τραγουδοποιός, στιχουργός και ερμηνευτής, που άφησε βαθύ αποτύπωμα στο ελληνικό τραγούδι και στην πολιτιστική ζωή της χώρας.

I don’t like the term, at least not the way it’s used today.

Of course, anyone who creates something is a creator by definition. But over time, the word has been loaded with a kind of metaphysical glow. First by social media platforms that wanted to flatter their users, and later by crypto, which tried to elevate the space’s raison d’être “above money.”

Yes, there are people who create content professionally like journalists, designers, photographers, musicians, and others who rightly expect to be paid for it. But in my humble opinion, most people don’t create content to make money. And let’s be honest: most don’t make any, at least not in any meaningful way.

People want to be heard. They share their thoughts, designs, music, and news publicly because they want to be seen. Sure, getting 100k likes or making $1,000 is nice, no one will say no to that (and once you do, you start seeing your online activity through a different lens).

But for most of us, a comment or a reaction from three, five, ten people we value is more than enough. Or meeting someone in real life and hearing them say, “I rarely post in public, but I read you regularly,” or “I really liked what you posted the other day.”

Microsoft first included Solitaire with Windows 3.0 in 1990. While it seemed like just a simple card game, its hidden purpose was to help users learn a new skill: dragging and dropping with a mouse. (Source: https://en.wikipedia.org/wiki/Microsoft_Solitaire)

Minesweeper joined the Windows lineup with Windows 3.1 in 1992. It was designed to help users get comfortable with right-clicking and left-clicking. (Source: https://en.wikipedia.org/wiki/Microsoft_Minesweeper)

Among tech enthusiasts, there was a long-running inside joke that MCSE (officially, Microsoft Certified Solutions Expert) really stood for “Minesweeper Consultant & Solitaire Expert.”

https://github.com/Aloxaf/silicon

A story by @aviationdoctor.eth.

Original link: https://farcaster.xyz/aviationdoctor.eth/0x83300b27f363f94ebccac239f0c32af2b1a601df

I copy it here for future reference.

The year is 2049. Farcaster has become the internet’s dominant conversational protocol. It —and the entire landscape of social media— looks nothing like it did in the old days.

Here's how it all happened. Make yourself comfortable; wall of text incoming.

Years ago, Reddit introduced the UpCoin to reward karma, resulting in bot farms owning 99.9% of circulating tokens and users fleeing in droves. Posting a meme now costs about as much as renting an apartment in New York City. Meta booted all users from Instagram after realizing it was more efficient to let its nuclear-powered AI data centers generate and react to slop photos without humans in the loop. And X collapsed last year after X Æ A-Xii Musk, its 29-year-old CEO, decided that all posts had to be uploaded directly from Neuralink devices—leading to 99.9% of human users being banned within hours for, well, unfiltered thoughts. Only XRP maxis remain, having no thoughts of their own.

Farcaster, on the other hand, achieved escape velocity and exceeded its founders’ lofty goal of growing from 37 to one billion users. OpenAI —now the first robot-owned, sentient megacorporation since Sam Altman and Peter Thiel merged their minds onto a silicon substrate— uses Farcaster data to train its GPT-∞ model, providing Merkle with a steady and lucrative revenue stream.

In hindsight, Farcaster’s success was inevitable, though it didn’t always seem that way.

There was much hand-wringing in the early years over Farcaster’s elusive PMF and qDAU. One misguided experiment circa 2025 was to turn the app into a social wallet. Co-founder even boldly proclaimed that “social + trading is our DNA”. Instead, it turned out to be more like an extra chromosome of the 21st pair. Shitcoin gamblers, it turns out, do not make for interesting —or sticky— conversations. Nor is it sensible to make one’s financial activities socially transparent.

Shortly after, back when the U.S. dollar still held some monetary value, Merkle launched a USDC promotion offering 10% rewards on deposits up to $5,000. Farcaster’s TVL jumped by $9 million (about 1,800 users going all in) before angry Merkle investors lobbied to stop squandering their money. Ten weeks later, both TVL and DAUs had returned to baseline — proving that temporary yield does not, in fact, drive retention (let alone qDAU).

There were even whispers of an acquisition by Coinbase, which would have crystallized Farcaster’s social-walletness once and for all. Thankfully, our valiant BDFLs Dan and Varun, in their impeccable ethics, declined easy riches in favor of a more noble long-term goal. In hindsight, they dodged a bullet: Coinbase, as we all know, has since rebranded as CompliFi, a fully KYC-ed L1 centralized blockchain that requires proof of paperwork for every transaction and takes eleven days to settle.

So what led to Farcaster’s resounding success? Internet scholars point to a handful of factors.

The first was Merkle’s decision to extend the Farcaster protocol’s FOSS philosophy to its client as well, upon realizing that a portable social graph is only useful if there’s somewhere else to port it to. The non-cosmetic components of the Farcaster app were open-sourced, triggering a Cambrian explosion of alt-clients, each catering to its own community: gamblers and geeks, nerds and nihilists, pundits and poets, and yes, even furries. The original Farcaster app became more akin to the Linux kernel, upon which enthusiasts built their equivalent of specialized distros. Merkle, in turn, kept curating the kernel’s core primitives through FIPs, for the benefit of all humankind.

The second factor was opening up the feed algorithm. Instead of a proprietary, one-size-fits-none solution, an executive call was made to modularize feed building. Users could now choose what they wanted to see by picking from an open marketplace of custom algos tuned to their favorite casters, political inclinations, and preferred themes. Reverse-chronological order and reply-bump visibility rapidly became popular options.

The third key factor was making channels first-class citizens, down to the protocol level. Rough were the early days; rumor has it that generative AI was discreetly called upon to prime the proverbial pump of empty channels with conversational liquidity. Whatever was used, worked. The UpCoin debacle led to a mass exodus of users from Reddit to Farcaster, where they found a familiar setup reminiscent of subreddits. The channel-first approach also dovetailed nicely with the new client diversity, with some specialized apps catering exclusively to one topic.

But beyond those technical decisions, what also mattered was how Farcaster’s early tensions were constructively resolved.

Borrowing ’s metaphor, one such tension lay between computer and casino user archetypes. The former came to Farcaster because they believed in building Web3 technology to empower people through anonymity, credible neutrality, decentralization, permissionlessness, and zero trust. The casino folks were more interested in games of engagement extraction and profit maximization. Instead of taking a moral stance for one over the other (the short-lived social wallet experiment of 2025 notwithstanding), our beloved BDFLs wisely allowed alt-clients to cater to both—with varying degrees of degeneracy.

Another notable tension was between OG users (i.e., anyone with an FID no greater than mine), who feared losing the town-hall feel of Farcaster’s early days to an eternal September of uncultured swine; and new users, who complained that the monolithic algo wasn’t giving them a fair chance at growing followers. That tension was amicably resolved by letting everyone choose what and who they wanted to see on their feeds. Instead of fighting a reactionary losing battle in defense of Farcaster’s singular cozy corner, the solution turned out to be a positive-sum replication of that coziness across every niche community that organically spawned along channel lines.

And this, my dear friends, is the story of how Dan and Varun left an oversized imprint on this planet. Not by playing the VC and founders’ short-term games, but by going beyond where Jack Dorsey left off — by channeling the spirits of Aaron Swartz and Satoshi Nakamoto, and by embracing the ethos of Richard Stallman and Linus Torvalds. It is no surprise, then, that they both featured on this year’s Time magazine’s Person of the Year cover — again.

PSA

Farcaster is adding more crypto functionality, and mobile app store policies in some regions don't allow crypto apps. Other popular wallets also have to follow these rules. A very small number of users will be affected by these changes.

If you are one of those users, the app will notify you and will let you export both your Farcaster and wallet recovery phrases.

--@dwr

https://starship.rs

When we refer to a blog's "first page", we usually mean the first page visitors see—the homepage with the latest posts. But what if we treated a blog like what it actually is: a notebook or diary?

In a physical notebook, page 1 contains your first entry. As you write more, you fill pages 2, 3, 4, and so on. When someone wants to read it, they naturally start from page 1 or jump to the last page for recent entries.

Traditional blog pagination works backwards because it was simpler for developers to write SELECT * FROM posts ORDER BY dt DESC LIMIT 10. But it creates a fundamental problem: page contents change with every new post.

You can't say "this post is on page 10" because page 10 contains different posts after each publish. This isn't just conceptually messy—it has real technical costs. Links to /page/10 become meaningless. Static site generators must rebuild and upload N index pages per post. Git histories bloat with N changed files.

The Solution

Treat your blog like a notebook with fixed pages:

• Page 1: posts 1-20
• Page 2: posts 21-40
• Page 3: posts 41-60

Your homepage becomes the last page—the one you're currently writing.

To avoid a sparse final page, keep a buffer of 20-39 posts on the homepage. When you publish post 101, articles 81-100 stay on the homepage. Once you hit post 120, page 5 (posts 81-100) gets finalized, and the cycle repeats.

This blog works this way. Visit blog.vrypan.net, and you land on page 138, because I've been posting for years, and this is the page I'm currently writing on.

Note: This is how pagination works on bckt since v0.5.2. Of course, if you think this way of thinking will confuse your users, you don't have to expose it to them, and tell them they are on page 100. You can show links to previous and next pages, just like they are used to. But whne you post a new article, you wont have to re-upload or git commit 100 new index pages ;-)

Who can ignore this? 👇

Versions 4.2, 4.22, and 4.24 all released in 1995. The final version 4 release was 4.25 in 1997. At least one QNX 4 installation ran for over 20 years without a reboot at the ESA. This was possible because peripherals could be hotswapped, drivers could be changed, and network nodes could be added or removed without bringing the system down.

https://www.abortretry.fail/p/the-qnx-operating-system

The first Jules Vernes books I read as a kid were my mother's, who had read them as a kid too. And they had these amazing illustrations that guided (not too much, just enough) my imagination as it recreated Verne's amazing worlds.

What happened in August 2023? I started running my own hub, and in October, Farcaster opened signups to everyone (until then, it was invite-only).

That p2p version of the protocol, with all its flaws, is what really got me passionate about Farcaster. I ran my own hub, and it had the same privileges like any other hub. But if I discovered Farcaster today, would it feel as exciting as the 2023.09 version? I’m not so sure.

I was thinking about this while watching this presentation about the “ATProto ethos.” https://www.youtube.com/watch?v=1A-0k58TfPo

We used to have these kinds of discussions here, too. Not so much anymore. The Farcaster ethos has become "DAU growth", there is no passion about extensibility, data ownership, censorship resistance. I don't feel there is any vision about the protocol, how they want it to look in one, two, five years, just a list of feature requests, prioritized according to some DAU metric.

Yes, I know, "none of these matter if we don't have millions of DAU".

Like I said: "DAU growth".

I also know I'm a niche audience, you can't grow to millions of users like me. Oh, well..