In 2024, Farcaster was the most decentralized it had ever been: a peer-to-peer network of hubs that were, at the protocol level, peers. My hub running on a Raspberry Pi at home, your hub on a VPS, Merkle’s hubs powering Warpcast, Neynar’s hubs powering various independent apps — they were all peers. Not equal, because network position, capacity, reliability, and importance mattered, but peers.

A year later, in spring 2025, Farcaster migrated to Snapchain.

Snapchain introduced globally ordered blocks, consensus, and, most importantly, higher throughput. Throughput was the weak point of the hub approach, and Snapchain fixed it in order to allow Farcaster to grow from tens of thousands of users to millions of users. But it sacrificed the one unique feature Farcaster had: decentralization.

The core team’s North Star was simple: grow 1000x or die. In pursuit of high growth, they introduced a number of additional client-side features: Frames and Mini Apps, wallets, and Sign in with Farcaster. What used to be a principle — that protocol changes should not be introduced unless a feature has matured — was forgotten, and protocol changes were introduced overnight to support things that looked attractive product-wise, like Farcaster Pro. Fees were reduced to practically zero, despite the original thesis that fees are the friction required to fight spam and abuse of network resources.

All these features made building alternative clients harder and harder, not to mention that the lines between “the protocol” and “clients” were blurred: Farcaster is not the protocol anymore; it’s the client.

These were good features. Fun to use and build for. But the expected growth never came, and all we are left with is a relatively small social network of nice and interesting people, operated by a company.

It’s a nice place to be, and it’s where I prefer to hang out, but it’s no longer something I’m passionate about. I wouldn’t wear a Farcaster T-shirt today. I wouldn’t try to recruit new users. I removed “I’m on Farcaster” from my X account.

Can we go back?

Which brings me to Jack Shephard’s words in the Lost Season 3 finale: We have to go back!

What if Farcaster went back to a hub-based architecture: simple, peer-to-peer, truly decentralized, where it’s easy to run a peer, easy to build self-hosted bots, and easy to build a client?

No bells and whistles. No Mini Apps. No assumption that every client must become a wallet, browser, app host, and social feed at the same time. Strip the network back down to the basics: identity, casts, replies, follows, reactions, and low data retention that makes home hosting feasible.

Then we can rethink Sign in with Farcaster, long-term archiving, scaling, storage fees, app embedding, and everything else. Maybe growth will come at some point in the future, maybe not, but as long as there are a handful of people running a hub at home, the network will be there.

This is not 2024. We know more now. We have seen what worked and what did not. We are not after 1000x growth at any cost. We have new tools for building software, especially when the protocols involved are simple. We can do better than the last time.

Personally, I would be very enthusiastic about this prospect.

The most notable change is the installation bundles come with a nice set of themes, as well as some demo content:

# Install
brew install vrypan/tap/bckt

# Create a test directory and initialize a new blog
# with the demo microblog posts and the micro theme
mkdir test && cd test
bckt init --theme micro --demo microblog 

# Start the local http server to preview it
# (the static pages are in the html/ directory)
bckt dev

Use --demo microblog to test how it looks with short, titleless posts and --demo articles to see a version with longer articles, closer to a typical blog post. But all themes will work nicely with both types of content.

You will probably want to use an AI agent to create your own theme. There is an AGENTS.md that will make this very easy.

For example, let's use Max Böck's blog, which has a really nice design.

cd in your blog directory and try prompt like this:

- Read https://github.com/vrypan/bckt/blob/main/themes/AGENTS.md
- Check themes/* to see how the existing themes are structured.
- create a theme inspired by https://mxb.dev/blog/ 

This is a great example why the EU must try not to depend on AI developed/operated outside of its borders, even if it's inconvenient at times.

That extra line could be hidden, used by the terminal itself, or made writable by the host. In its normal “indicator” mode, the terminal used it for local state: cursor position, printer status, modem status, and similar information. But in host-writable mode, software on the host side of the terminal connection could write directly to that line. ²

The two relevant control sequences are DECSSDT and DECSASD. ³

# Make the status line host-writable
printf '\e[2$~'

# Send subsequent output to the status line
printf '\e[1$}Build running…'

# Return subsequent output to the main display
printf '\e[0$}'

DECSSDT selects the status-display type:

CSI 0 $ ~   no status line
CSI 1 $ ~   indicator status line
CSI 2 $ ~   host-writable status line

DECSASD selects which display receives subsequent characters:

CSI 0 $ }   main display
CSI 1 $ }   status line

It's a surprisingly elegant primitive. A program could use it for progress, mode, host name, current job, debug state, deployment environment, or a persistent “you are in production” warning, without stealing a row from the application, rewriting the prompt, or relying on a terminal multiplexer.

I wasn't able to find a good historical screenshot of a real application writing to the host status line, but you can see it displaying status info in this Capo's Tech video ^{4 5}

Can we bring it back?

The idea feels familiar even if these particular CSI sequences are rarely supported today. We have reinvented the same feature in tmux status lines, Zellij bars, and prompt frameworks because the shape makes sense.

But those are all tool-specific solutions.

It would be great to see modern terminals support DECSSDT/DECSASD again. I think many apps like starship, build environments, package managers and so on would take advantage of the feature if terminal emulators supported it.

Image sources:

• Jason Scott: https://commons.wikimedia.org/w/index.php?curid=29457452
• Tom Page: https://commons.wikimedia.org/w/index.php?curid=98843032
• Capo’s Tech: https://youtu.be/EjJTog15Izs?si=aotLJ8Sb1QGcx2_H&t=426
• LGR: https://www.youtube.com/watch?v=RuZUPpmXfT0

This is the "chilling effect", baked into a product.

As a side-note, if you go IMSLP, you will learn a) that the site is powered by mediawiki and CC, and b) you have to pay to download anything.

I hate copyrights. Copyrights limit creative people.

I'm using a Raspberry Pi 3B with a UnicornHD HAT. Both outdated, but fine for what I'm building, and I like the limitations they impose.

The clock works. The color scheme changes from bright white-ish at noon to dim blue at night. The location is determined by looking up the gateway's IP. Then, based on lat,lon and time, it calculates the position of the sun, and adjusts the color/brightness.

There is also an indicator on the right, showing day/night/dawn/dusk hours which also adjusts automatically.

It can rotate, but I'll have to connect a gyrometer for this to work automatically. Todo.

Works as an AirPlay receiver using SharePlay, and will display artist/title when a track starts. Will add Spotify support too.

I asked codex to parse all my blog posts and get quotes that I have or I could have said, and I'll display them on random times. Needs work, and more personalization, these are intended to be from me to her. Will add some internal jokes, things we say to each other, and may also make some depend on day/time/season/weather. At first it looked like a cool idea, not sure if it will make it to the final version.

I don't want to rely on cloud services, this has to be self-sufficient. I'm currently looking up the network gateway's IP to determine the location using ipinfo.io but I'll find a way to either manually input it, or add a GPS module or something.

While doing various experiments, I got down the rabbithole of music boxes. It would be nice if it also worked as a music box, right?

And I found this amazing project I had no idea about, called Muro Box. Wow, so cool and so beautiful. This is the type of smart devices I would love to build some day, not consumer electronics, but things that are hand crafted, with character andattention to detail and beauty.

Muro Box lets you compose, play, and schedule your favorite melodies. With MIDI control and a patented mechanical design, a single music box can now perform unlimited custom songs—not just short loops.

Anyway, with this and that, I spent the last two days building a music box player. It's a program that will read a MIDI file, and play it as if it were a real music box, with a drum and a comb. I knew nothing about MIDI and sound engineering, but a learned quite a bit, and the result is not bad at all. I'll put it on GitHub once it's a bit more polished.

Years ago, I built a digital desk clock using a Pi Zero and a Micro Dot pHAT. Probably an overkill to use a whole computer as a clock, but it has turned out to be very convenient, it’s easy to read day and night, and I like the style.

Lately, it started freezing. No idea why, my guess was the OS needed to be updated, or even better re-installed —I don’t have a clear log of what this Pi Zero has been through all these years, but for sure it was also used as a DNS (pi-hole) at some point, and as a tailscale gateway at some other.

The problem is my clock was a Python script using a library that has not been updated for at least 4 years. Would it work with a much newer version of Pi OS?

It did not. I could not even install it.

So, I cloned it, and used Claude to port it to Zig. I picked Zig because the resulting binaries are small, and I can also cross-compile on my MacBook Pro (waiting for Pi Zero to compile would not be fun). It took me an afternoon, a couple of manual interventions, and I had my Zig port. The examples compiled, and run perfectly on the latest Pi OS (32-bit).

And since I’m not the one writing the code, why not add some flavor? Let’s have the digits scroll up when they change.

Not bad for a project that took an afternoon. I love it how I can make and fix little things that wouldn’t be worth the time and effort without AI-assited coding.

Eric Raymond’s “The Cathedral and the Bazaar”¹ described two fundamentally different ways of building software. The Cathedral represented centralized, carefully planned development directed by a small group of maintainers. The Bazaar represented open collaboration: large communities, public iteration, distributed labor, and software evolving through many contributors.

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.

Update (15-May-2026): Other people have described the same or a similar mental model:

Drew Breunig calls it "the Winchester Mystery House":

The ideas crystallized in "The Cathedral and the Bazaar" helped kick off a quarter-century of open source innovation and dominance.
But just as the internet made communication cheap and birthed the Bazaar, AI is making code cheap and kicking off a new era filled with idiosyncratic, sprawling, cobbled-together software.
Meet the third model: the Winchester Mystery House.

—The Cathedral, the Bazaar, and the Winchester Mystery House³

And Thomas H. Ptacek, calls it "the Emacsification of Software":

First, it's personal software. Most of it will be useful only to its creator, and then forgotten, just like the dozens of obsolete little elisp programs littering my .emacs. Personal software defines the ethos of Emacs, which was carefully designed over decades to nurture these kinds of tools. "Emacsification" clocks that everything now works this way, not just baroque text editors.

—The Emacsification of Software⁴

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