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/ 

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

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.

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⁵!

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/)

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.

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.

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

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.

The blind spot of much of today’s SV-based and SV-adjacent tech leadership is that they were shaped by, and succeeded during, the 1990s—one of the rare moments in history when the world was converging toward homogenization and globalization.

In computer terms: the US was the "standard". Countries, companies, and people that wanted to participate in global business aligned with US rules—legal, financial, trade, regulatory. Compatibility meant access.

That world is gone. Today we live in a highly interconnected yet increasingly fractured landscape. Trust is scarce. There is no global arbiter of what is “right.”

If you’re a large company or financial institution in India, Canada, or Europe, would you confidently settle disputes in US courts? Would you feel secure knowing your funds could be frozen by a unilateral decision from Washington? Likely, less and less every day.

And fracture isn’t just global—it’s local. US states grow more polarized. The UK left the EU. EU members are divided on existential issues.

In this reality, technologies built on credible neutrality, decentralized governance, and censorship resistance will have an unmatched advantage.

Comment here

Snapchain is a simple blockchain where Farcaster social activity takes place. Every cast, reaction and follow is stored as a Snapchain transaction.

A snapchain transaction is a social action like making a new post. Alice says “Hello World” by making an add-post transaction, signing it with her app key and broadcasting it. Nodes verify that every transaction is correctly signed according to the specification. Common actions like deleting posts or following other users have their own transaction types. Snapchain transactions are self-authenticating and anyone trace the authenticity from the message to the app key to the wallet to the farcaster id. (snapchain whitepaper)

Snapchain transactions were not designed to transfer monetary value, but recently, we see more and more cases where snapchain transactions trigger (directly or indirectly) onchain transactions.

For example, NOICE and Tip’n Earn users allocate an amount of ERC-20 tokens and the apps send small tips whenever the user likes, recasts or comments: In addition to its inherent social value, my “like” is now worth $0.1 —and I’m sure we will see cases where much more value is transferred by Farcaster activity (I know of at least one such case that will be announced in the next few days).

This creates attack vectors that the design of Snapchain did not have to worry about.

The first attack vector is miniapps designed to be used as marketing tools, like amps.fun.

These apps allow users to “sell” their social reactions. For example, I can pay a user through amps.fun and automatically get a like or recast from them.

If an amps.fun user has also set up noice or tipn, and the cost of getting a social reaction from them is lower than the value I get from the tips, then I can pay them $x and get more than $x back as tips, draining their allowance.

Sure, no one would set these apps in such a way that I can steal their money (though, users are often careless).

But what if their like is used as a vote that affects how a retro funding round worth >$30k is distributed? Or if social activity (especially actions with a tip attached to them must be genuine, right?) is used to define an airdrop distribution?

The second attack vector is app keys.

This is a breach of trust, or even an actual hack.

Every Farcaster application (even Farcaster.xyz) that you use to cast, like, recast, follow, will ask you to sign an appkey. Then, they use this key to sign Snapchain transactions (casts, likes, etc) on your behalf.

If one of these apps go rogue, or get hacked, the attacker can create a cast, and then comment, like and recast as any of their users, in order to collect tips triggered by these social transactions.

What can we do?

The most important part is awareness. Many of these attacks can be averted if users and developers are aware of the risks described above.

An other “soft” measure could be an “advisor” app that checks known combinations and alert users: “Warning: You tip $0.6/like using noice, $0.6/like using tipn, and you set your like value to $1 on ampsfun”.

Apps should also encourage users to set low allowances (if you tip $.1/like, do not set the app allowance to $200), and notify them when they are running low.

Tipping apps can also check the appkey used for a social interaction, before sending the tip. An appkey associates the application FID with the user FID, so you could request additional confirmation when you see a new app used: “You used ampsfun/coinbase/opencast, is it ok to trigger tips when this app is used”? Whitelisting well-known clients like Farcaster.xyz in advance will make this invisible to 99.99% of the cases and add minimal UX friction.

In some cases, appkeys can be checked retroactively. If you use social activity to define the distribution of an airdrop or a grant, make sure you analyze the app keys used in each case and act (for example ignore some of them) accordingly.

Finally, when Snapchain implements appkey freezing (app keys are frozen and can’t be used, but are not revoked), we should put in place the tools and habits that will let users easily freeze unused appkeys.

Farcaster Pro is launching next week, and at some point it will introduce features like 10,000-character casts and up to four images per cast. These enhancements will require a protocol upgrade.

While I believe in the core idea of a Pro subscription, for me, this reopens a (friendly!) long-standing debate I have with the Merkle Manufactory (MM) team: I believe new types of content should be stored outside the protocol.

The Core Idea

I believe that we should store as little content as possible on snapchain, and design the standards that will allow Farcaster content to be stored externally.

Instead of baking support for content types (such as long-form text, code snippets, MP3 playlists, photo reels, geo-tagged casts, etc.) into the protocol, we should treat these as external resources, referenced by the protocol, but hosted elsewhere.

There are many ways to implement this, ranging from quick-and-dirty hacks to clean, modular solutions. I would argue for a new type of embed urls that point to a well-defined json, but I don’t want to focus on the technical details here.

Instead, I’ll explain why this approach deserves serious consideration, and why it should serve as a guiding principle for protocol development.

1. Permissionless Development

By moving new types of content outside the protocol, we allow anyone to introduce new experiences without needing approval or access to the protocol maintainers.

Take 10k-character casts or photo reels, for instance. These could have been implemented without touching the protocol, if we had a standard for embedding external content into casts.

MM often argues that we should “wait for demand” before introducing new primitives. Now that they themselves want longer casts and more images per cast, the answer is suddenly: “Let’s change the protocol.” Could they have used an approach like lemon3 enclosures? Sure. But it feels “hacky” and inelegant, I agree.

Ironically, longer casts (1024 characters) were added a year ago as a quick change, in response to my proposal for external cast data. Back then, the promise was: “We’ll revisit the approach if there’s demand for it.” Well, now there is demand for even longer casts, but again we just change the protocol to fit a specific use case.

I'm critical to MM here, but I think they would benefit too. Actually, they would be the first to benefit, because they want to be flexible to try new features fast, and any snapchain change, no matter how small, adds a significant overhead. Their experiments would go to market much faster if they did not have to implement snapchain changes.

Side-note: External content doesn’t mean any content type will be supported by every client. For example, I can introduce a type of content (let’s say m3u playlists) that the Farcaster app does not support. But a well-defined standard will allow a fallback representation, and proper indexing.

2. Decentralization

Storing more and more content on the protocol means that the storage requirements to run your own hub go up, and fewer people can run their own hub. Offloading (new types of) content reduces the storage burden on Farcaster hubs.

Yes, relying on external content introduces some complexity. But that’s a fair tradeoff if it means more people can run hubs, and client (not just user-facing clients, but also agents, bots, analytics, etc.) developers can choose whether they need these external data.

After all, if no one is able to run their own hubs because of increased hardware requirements, and end up using Neynar APIs, what’s the difference if the API results come from the snapchain or other sources?

3. Storage Costs Separation

External content storage allows apps to charge for storage and bandwidth without affecting the protocol.

Want to build a photo reel app offering 1TB per user? Go for it—no protocol changes needed. Casts can simply embed a pointer to a JSON file listing the images. You can even ask users to pay for storage, and it makes sense to everyone. Want 8 or 10 images per cast? Sure.

Thinking of video uploads up to 2 hours? Build it. Host the video. Charge for hosting and bandwidth. No need for protocol-level intervention.

Wait. Are We Already Doing This?

Ironically, Farcaster already supports this model, but only for a very specific type of content: miniapps.

Miniapps are externally hosted, protocol-referenced applications. Developers love them, users love them. One could argue that the new Pro features could be built as miniapps that get special treatment by the Farcaster client -or any other client wants to do so.

We don’t need to cram every new content type into the protocol. Let’s use an extensible, permissionless architecture where innovation and experimentation is easy.

We are already familiar with the mental model of storing miniapps externally. Why not do the same for content and get all the benefits mentioned above?

In the world of crypto, we’ve seen coins created for just about everything — from memes to celebrities.

Developers, the one group that probably makes more sense to have a coin, did not use it.

So, let's talk devcoins.

A devcoin is a personal token for a developer.
It’s a way to back the value a developer can create over time.
Instead of betting on hype, you’re supporting the people building real things.

Devcoins make sense. Developers are always shipping projects, tools, services, and infrastructure.

But it’s not always easy for them to get paid — especially when they build open-source software or tools that aren’t easy to monetize.

A devcoin gives people a simple way to support a developer directly.

Holding a devcoin can mean:

• Backing the developer and believing in what they will build next and indicating that you want to keep working on and maintaining their projects.
• Unlocking utility — like using the devcoin to pay for services, or access to features.
• Getting early access to new projects, beta features, or private tools.

It’s a simple relationship: If you believe in a developer’s work, you hold their devcoin. If you want to support them even more, you can buy more —or even send the coins back to them as a tip.

An indie developer building many small projects could tie all of them to the same devcoin, creating a mini-ecosystem around their work.

The tools are already here, we don’t need to invent anything new to make devcoins happen.

Platforms like clanker.world already let anyone launch a token, set up a liquidity pool and make it trivial for users to buy and sell it in seconds.

Everything that works for memecoins can be used for devcoins too — just with more purpose.

It would be even better if we could link devcoins to developer identities more formally — for example, showing them on GitHub profiles or Farcaster accounts.

Imagine being able to discover new developers, check out their projects, and back them immediately through their devcoin.

The tools exist, the need is clear, the idea is simple.

As a side note:

I launched $lemon3 about a month ago, as a way to support the development of lemon3. But as I was building pingem.xzy I realized that $lemon3 could become my personal devcoin, so if you want to use pingem, you need to hold (not pay, just hold) 10M $lemon3 (that’s about $5 worth of tokens). I’ll keep playing with the concept to see how it works.

Leave a comment here.

Decentralized infrastructure (DePIN) has solved core problems like peer-to-peer networking, distributed consensus, and trustless storage. But one question remains: how do these systems decide what matters?

In this article, we introduce the concept of Socially-Scoped Infrastructure, where systems use social signals to decide what to act on. Farcaster becomes a real-time intent layer, guiding infrastructure like IPFS to respond.

Coordination Without Central Control

When the decentralized system is a blockchain, it is easy to prioritise transactions, allocate resources and decide what matters using global logic built around financial incentives.

But global, financial incentives may not be ideal for other types of decentralized infrastructure. In some of these cases, social signals may be the answer.

• Which files should be pinned?
• How should compute be allocated?
• Where should mesh networks expand?

Core Idea: Social Signals Trigger Infra Actions

Example: Pinning IPFS CIDs from Farcaster

The following example is inspired by lemon3:

You follow someone on Farcaster. They share an IPFS CID. Your client checks if the post is from a followed user. If yes, your IPFS node pins the content.

No consensus. No token. Just trust-based automation. Farcaster provides the intent. IPFS executes. Social attention becomes an input to decentralized infrastructure.

Broader Use Cases

This pattern works well in storage-based systems like IPFS, Filecoin, and Arweave, where resource allocation (storage) is simple and flexible. It can also apply to decentralized compute where tasks are parallelizable and scoped to a social subgraph.

In geographically distributed hardware systems, like Helium or WeatherXM, applying social scoping may be more complex or not feasible, because the network can not easily react to social signals -but if you have ideas on how to use these patterns there, ping me!

Conclusion

Combining decentralized infra with open social layers like Farcaster creates a programmable stack, where infrastructure responds to social signals.

These social signals can provide an alternative way for decentralized infrastructure to prioritize and allocate resources based on what matters to each one of the participants —locally, socially, even temporally.

Comment of farcaster

lemon3 is an open source program that uses IPFS and Farcaster to allow decentralized file hosting and sharing.

The name is a tribute to iPodder Lemon, the original podcast aggregator, because it is intended to be a web3-friendly version of the original idea.

lemon3 uses cast.Embeds to embed a special enclosure+ipfs://<CID> link in casts. The link points to a json payload hosted on IPFS. The json payload is intended to make up for the fact that Farcaster Embeds are plain links with no additional information that is required in this case (and could be very useful in other use cases too), and provides: file name, file type, file size and the IPFS CID of the file that was shared. This is the equivalent of the RSS <enclosure> tag used in podcasting.

lemon3 is a mini Farcaster client, that connects to a hub: It will show casts containing enclosures from users you follow, and it allows you to share files by uploading them to IPFS and casting the corresponding enclosure. It also contains an embedded IPFS server, so you don’t have to run your own.

Status and next steps

Version 0.1.1 is the MVP: You can upload and share files, and you can find and download files shared by others.

But there’s a lot to be done to get to a version that “just works”: various bug fixes, UX streamlining, a decent user onboarding flow, and features such as keeping track of already downloaded files, support for standalone IPFS servers and a download manager. Maybe a web interface (similar to how Transmission works), too. Probably an RSS gateway that exposes these feeds as RSS for compatibility with existing podcast clients.

Even the core protocol design may need some updates, like replacing the JSON payload with IPLD.

But once everything is more stable, there are new opportunities that we did not have with RSS, like reactions and comments: For example, if you are producing a podcast, your listeners could reply, like and share your episodes, natively, within their social network.

I’m very excited with the possibilities!

A month ago, Coinbase announced their plans for the next itteration of Coinbase Wallet. Check out the announcement.

One of the exciting points is Farcaster integration: The evolution of Coinbase Wallet will have a full social feed and mini-apps powered by Farcaster.

Integrating a crypto wallet with Farcaster opens up new possibilities. For example:

• Checking if a recipient's address is tied to someone in your network.
• Seeing if trusted people have interacted with a smart contract or left comments.
• Viewing on-chain activities from your social circle.
• Minting/claiming tokens based on social activity.
• Notifications about time-sensitive events (e.g., ENS domain renewal).
• Fun games!

I can’t be sure what the Coinbase team will build, and some of these already exist either as stand-alone apps or as app features, but Coinbase has the power to bring these features to a much larger audience.

This is a fundamentally different mental model for Farcaster: Warpcast is a social app with a wallet (added recently), Coinbase Wallet will be a wallet with social features (I guess).

Bonus: An old cast of dwr 👀

Neutral economic areas are geographical or conceptual zones characterized by a lack of strong economic dependence or dominance by a single state, company, or interest group.

These areas are often governed by principles that encourage equal access and opportunity for multiple participants without favoritism. Such areas can exist in various contexts, including international trade zones, shared natural resources, or collaborative spaces for innovation.

Common characteristics of neutral economic areas are

• Equitable Access. All participants have equal opportunities to engage in economic activities.
• Non-Dominance. No single party exercises disproportionate control over the area’s resources or decision-making.
• Shared Governance. Decisions are made collaboratively, often involving multiple stakeholders or international entities.
• Regulatory Framework. Clear rules exist to ensure neutrality and fair competition.

These zones aim to foster cooperation, reduce conflicts, and promote balanced economic development.

The world is entering an era of deepening conflict and mistrust. Old allies are turning into rivals, new barriers are emerging between nations, and economic tools like export controls, tariffs, and asset freezes are being weaponized to a degree we haven't seen for many decades. In this increasingly fragmented and hostile environment, the concept of neutrality in economic zones is more critical than ever.

In this emerging environment, Ethereum is the largest, neutral, economic activity zone, and Ether (ETH) is its base currency.

You can be sure that your Eth funds can’t be frozen or seized. That your transactions can’t be stoped. That the contracts you sign will be executed to the letter. That you can pay, get paid, trade, borrow, lend, get dividends, vote and make trusted commitments that can’t be canceled by third parties.

This is why it is important to keep Ethereum neutral, decentralized and unstoppable. We must avoid core dependencies on technologies like TEEs (that can be controlled through legislation and export controls). And we must work towards making Ethereum safer to use in adversarial environments, with technologies that protect privacy.

Ethereum, as the largest, neutral, economic activity zone is our hedge against a fragmented and hostile world that is starting to treat prosperity is a zero-sum game.

Before you read

I often consider casts to be a special "Farcaster application": I could see an alternative universe where Farcaster launched without casts, and casts were an application leveraging Farcaster identity and social graph ¹.

A Farcaster without protocol-level casts may sound crazy, but think of what Direct Casts are today: An application that leverages the Farcaster identity and social graph, without being part of the protocol.

This is not an FIP: I find the idea interesting, but it comes with a number of technical, architectural, business and social implications. Adopting this architecture could change what Farcaster is —I'm not even sure if I'd like a Farcaster that moved in this direction.

That said, I also think it’s a space we should explore, discuss and debate, so here’s my contribution.

Problem

Every technical design has its limitations, and so does Farcaster. One of them is the speed that messages propagate throughout the network. An other one is storage limits. And of course, there are a number of widely accepted norms, for example, we expect a cast to be readable text.

An other problem is disk space required for hubs: We know that if Farcaster grew 100x or 1000x, storage requirements for hubs would probably grow to a point that hosting a hub would require very expensive hardware, inevitably leading to centralization.

Specification

Bundles are Farcaster messages that contain references to messages stored externally (not in hubs).

A Bundle message can be added with a BundleAdd message and removed² with a tombstone BundleRemove message.

A new UnbundleMessages RPC endpoint allows a client to submit the bundle data to a hub and get the messages back. The hub will validate each message included in the bundle and return only the messages that are valid.

Only Cast add/remove and Reaction add/remove messages can be part of a bundle.

message MessageBundle {
  // Only CastAdd, CastRemove, ReactionAdd and RecationRemove 
  // messages are allowed in messages.
  repeated Message messages = 1; 
  bytes data_hash = 2;  
}

message BundleAdd {
  string url = 1;
  bytes data_hash = 2;     // Hash of the data stored at url
  bytes parent_bundle = 3; // Message.hash value of the previous bundle
}

message BundleRemove {
  bytes target_hash = 1;  // Message.hash value of the bundle being removed
}

rpc UnbundleMessages(MessageBundle) returns (MessagesResponse);

Rationale

The high-level idea of this proposal is (is some ways) similar to an Ethereum Validium L2: Messages are bundled and they are stored externally, and hubs store references to these bundles, instead of the messages themselves. In this context, hubs are "Farcaster L1", and the bundles submitted by a specific FID form a "Farcaster L2".

Hubs remain the authority for identity (FIDs), social graph (Links), user profiles and signers.

A bundler bundles multiple messages in a bundle, stores them and posts BundleAdd messages to hubs. A bundler can be centralized (a typical web2 application) or decentralized (for example, a group of hubs running a modified version of Hubble). If bundles are used to create an L2, then the bundler’s FID defines the L2.

This is the typical flow:

• The application allows its users to send Farcaster messages such as CastAdd and ReactionAdd, but these messages are not submitted to a hub.
• The application/bundler packages these messages as a MessageBundle blob, and stores them somewhere online. The storage location can be public (for example, a public URL or IPFS) or even private (for example, the app database or a protected S3 bucket).
• The application/bundler submits a BundleAdd message to hubs. The message states the location of the blob and its hash. It may also reference a parent bundle from the same fid.
• If an other application wants to retrieve these messages, it has to fetch the blob, and call UnbundleMessages() to unbundle them.

Notes:

• Messages are expected to be valid messages, that comply to message rules imposed by hubs (size, signatures, signer validity, etc)
• Users of the application have to trust that the application will actually include their messages in the bundle. They also trust that the application will not delete a bundle that contain their messages.

Cross-layer architecture

In interesting property of this architecture is that messages can be moved between layers:

A message posted on a L2 is a valid message that can be posted at any time to a hub (L1), or copied to any other L2. And a message that was posted to a hub (L1) can be copied to an L2 -even after it’s been purged.

Why would an app use this and not build something from scratch?

The design has a high level compatibility with existing tools and patterns used by developers. For example, shuttle ³ could be extended to support Bundles (developers could also configure their shuttle instance to accept only specific bundlers, using their FID) and make bundles messages available to apps that use it. Similarly, services like Neynar could support bundles from specific FIDs and make their messages available to devs using the existing APIs.

The design also takes advantage of the Farcaster identity infrastructure, social graph, and everything that comes with Farcaster.

Depending on the implementation (this is the case with any “layer 2”), users can have strong assurances that once a message is bundled and submitted, it will be available to others. In any case, users could “move” their messages to L1 if they like.

Farcaster scalability

Farcaster could decrease storage unit limits to push users to use bundles (L2s).

An extreme scenario that would force most users to use a L2 (but would also make it even cheaper for them to use Facraster):

• The first storage unit for each FID could have 0 (zero) casts, 0 bundles, 2500 Links, 50 Verifications and 50 User Data and cost even less than today.
• Storage units after the first one, cost 10x more than today and allow 5000 casts or bundles.

Do we need an FIP for this?

The truth is someone could implement most of what’s described here by using CastAdd and setting embed.url to the location where messages are stored, in some custom format.

However, this would be a hack. The protocol gets no benefit, its messy, and the lack of standardisation limits interoperability between tools, layers and services.

Possible use-case examples

The default use case is an app like Warpcast has it's own L2, and posts a bundle every few seconds. All users of the app see the messages instantly, and everyone else who tracks the specific L2 sees them with a small delay of a few seconds.

Other, possible use cases:

• A sports app that allows users to comment in real-time during a game, offering a chat-like experience. The app also uses a special pattern for each cast, where the first characters are reserved for the minute/second of the game, and the user’s favorite team. All messages are stored in a RDBMS during the game. At the end of the game, they are bundled, stored on IPFS and a BundleAdd is submitted to Farcaster.
• A Farcaster archiver keeps track of pruned casts and reactions. Every day, it stores them on IPFS and submits them as a bundle to Farcaster.
• An app designed to preserve privacy encrypts casts, without worrying that they will appear as noise to the rest of the users.
• An L2 that hosts content not allowed in Warpcast, such as adult content.
• A "private" L2: Messages are stored in a non-public location that requires authentication and are not available to the public.
• A bundler can be open (for example, Warpcast could maintain their own bundler that exposes an open API to be used by other apps), or closed (for example one that can only be used by a proprietary app, and requires users to pay to use it.)

Concerns/TBD

An assorted list of concerns and points that need further discussion:

• A malicious user can copy all messages of an FID from a bundle (L2) and post them to L1, consuming all of FID’s storage space. Is this really a problem?
• Could this design lead to Balkanization of Farcaster, with multiple, isolated L2s that don’t interact or are not even aware of each other?
• Do we want to allow bundlers that do not store bundles in a publicly accessible storage? If not, how can this be prevented other than by social norms?
• How will an app handle bundled messages when a signer used to sign some of them is removed? Where does this logic reside?
• To which extent UnbundleMessages performs tests? Should it reject duplicate messages in a bundle? Should it reject a cast that is already on L1?
• Are apps expected to mix bundled messages and “normal” messages? Is it either L1 or L2 and messages are not mixed? Or is it L1 + a single L2?
• How can someone reference a message included in a bundle in such a way that a third party knows it should fetch the bundle first?
• What happens if a CastRemove message is submitted to a hub, that refers to a message included in a bundle?
• How can this model be abused?
• Set a limit on the size of MessageBundle.
• App guidelines to avoid user confusion?
• UnbundleMessage will be a resource-intensive call. Hubs must be able to restrict it to specific users or IPs.

Nakamoto is orthogonal to Moore

If you think about it, crypto is orthogonal to Moore's Law.

Crypro is designed to add friction to the things that Moore's Law made frictionless or trivial.

For example, Bitcoin is designed to countermeasure the addition of computing power by increasing block difficulty, and NFTs are the answer to frictionless media replication enabled by computers.

Running the current version of Microsoft Office, or even Chrome on a computer built 15 years ago is painful if not impossible. A typical 15 years old computer is not powerful enough to handle today's programs because they depend on 10x more power than was available back then. (Just take a look at Geekbench Benchmarks for Macs comparing Apples to Apples.)

On the other hand, the Bitcoin codebase has not changed much since 2008 -not in ways that require additional processing power. Similarly, the exponential increase in Ethereum transaction bandwidth thanks to L2s was not a result of increased compute power.

The Moore-Nakamoto plain

We can consider a two-dimensional plain, where one axis indicates the impact of compute improvements and the other the impact of crypto technology. I'll call this the Moore-Nakamoto plain.

Where do various projects and technologies go on this plain?

For example, traditional video games are not impacted at all by advances in crypto, but CPU/GPU power increase or efficiency has a dramatic impact on them. Compare this to a game like Axie Infinity, where the quality of graphics obviously depends on the available computing power, but advances in crypto technology, like L2s or wallet abstraction are also very important.

Here is an other example comparing Uniswap, DePIN and OpenAI.

• OpenAI depends 100% on the cost of compute and advances in crypto have no effect on it.
• Uniswap is not affected by advances in compute power, but advances in crypto have a huge impact on it.
• DePIN projects are affected by both.

I think that the Moore-Nakamoto plain is a great tool to map and compare projects, and to analyze how advances in compute and crypto will affect them in the future.

"|" is the pipe symbol (character 0x7C), but when the pipe symbol can't be used (ex. domain names or Farcaster usernames) the lowercase L is used: l--o--l.

|--o--| is a collection of 10,000 ASCII art spaceships represented as ERC721 tokens on the Base chain.

Each spaceship will have:

• A blueprint: The ascii characters that represent it, for example |-x--0--x-|. Each character is called a part.
• An engine (a smart contract used to convert the blueprint to artwork).

During mint, the the available parts will be |-:o@bd8x0()=\/, but the smart contract is designed to allow new parts to be added in the future. It also allows a holder of two spaceships to rearrange their parts to build two new ones.

The basic engine, that will be available from day zero, generates an onchain SVG representation of the ship, and will look something like this. The artwork is generated dynamically, based on the ship's blueprint, which means that if the blueprint changes in the future, so will the artwork.

More engines can be added in the future. Some may use a different design style (I'd love to see artists create alternative engines!), and some may even allow complex functionality, like altering the artwork based on game rules or actions. The ship's holder will always be able to change the engine used back to the basic engine.

Each ship has one more property that could be useful for future onchain integrations: Captaincy. This is the number of days a ship has remained in the current wallet. I'm not 100% how captaincy can be used, but it's there if you want to build some mechanics on top of it.

I want users to be able to modify their spaceships, play with them, have fun. This is why I like to think of |--o--| as "onchain toys".

A nice way to experience how |--o--| ships will look like is this Farcaster frame.

Minting

Minting phases I and II will only be available through Farcaster. Please consider this if you plan to participate.

It's not finalized yet, but most probably, this is how minting will take place.

Phase I: The first 100-200 "OG" tokens

This phase will be reserved for Edition holders. A snapshot will be taken, and holder FIDs will be whitelisted, and allocated a number of mints equal to the number of Editions they hold.

Minting will take place using a frame that will allow whitelisted users to create their ships using their own "blueprints" (characters). Minting will be free (probably no gas cost either).

Ships minted using this method will also have an "OG" flag set, and will be visually distinctive (probably have a glitch effect, like the Editions).

At the end of this phase, the collection will have 100-200 carefully crafted OG ships that will be used as blueprints for the rest of the collection (see next phases).

In total, 88 Editions were minted. I may manually mint some more to get to 100 or slightly more OG blueprints.

Phase II: Airdrop of 1000 tokens

I intend to whitelist 1000-2000 FIDs. Not sure about the criteria yet, probably based on other NFTs they hold, or social graph (Farcaster).

During this phase, each whiltelisted FID will be able to mint for free (but pay for gas) one ship. They won't be able to create their own, ships minted during this phase will be copies of OG ships (but without the OG flag and the OG visual effect).

Phase III: Open Mint of ~9,000 tokens

During this phase, the rest of the collection will be minted (up to 10,000). This will be an open mint, at 0.005 + gas per NFT.

The price tag is there to make sure that ships are distributed to many holders, and prevent someone from minting 1000s of them.

Like in Phase II, ships minted during this phase will be copies of the OG ships, without the OG flag.

Dates and final details to be announced. If you want to stay up-to-date, follow |--o--| on Farcaster.

Let's talk about hubs and how they sync.

The Farcaster network is a network of hubs that exchange messages between them. Each hub holds the entire "global state": every cast, reaction, follow, every user's profile data, everything.

The farcaster app you are using, only has to connect to one of the hubs to read and post messages. Then this hub syncs with the rest of the network and every other hub receives your activity.

Hubs exchange messages between them in two ways:

1. The first one, is practically real-time: The hub that receives a message uses a protocol called gossipsub and sends the message to the hubs it's connected to, then they do the same and in just a few seconds all hubs have received the message.

2. The second is an out-of-band sync. This one is slower and only happens every few minutes (or whenever it's feasible, more on this later). During the out-of-band sync, two hubs practically compare their databases, and exchange deltas in order to get to the same status (exchange deltas to reach the same state).

If you are interested, there is a video describing the concept in more detail.

Advantages

This model has a number of advantages:

• It's developer friendly, because a developer can have a full copy of the network, locally, to work with
• It's decentralized and censorship resistant because there's no single point of entry to the network
• It's very resilient because you can take away any number of hubs (a recent count of Farcaster hubs brings them to ~150) and if there is at least one left, spawn new ones and reconstruct the network as if nothing happened.

These characteristics make Farcaster ideal for a number of environments where other social networks (centralized or federated) would fail.

When the office ISP went down

Imagine you are at work, using Farcaster by connecting to the office Farcaster hub that runs locally, and you are using a Farcaster client that connects directly to the hub ¹. At some point, your ISP goes down.

Here is what happens during the period you have lost connection to the rest of the Internet:

1. You continue to have access to everything that was posted on Farcaster up to the moment the Internet connection went down.

2. You can also cast, like, recast, follow and unfollow as if nothing changed.

3. You can also see new casts and reactions from your colleagues that use the same hub, and you can reply and react to their casts.

The most important thing that changes during the period the ISP is down, is that you don't see any activity that happens outside your office (your office farcaster hub). But as soon as the ISP is up again, your hub will connect to the other hubs, it will propagate any activity that happened (in the office) during downtime, and receive all activity that happened outside your hub!

There are a few things that wouldn't work while the ISP is down:

1. Any Farcaster activity that requires an onchain transaction, such as creating new accounts, approving and removing signers, or purchasing storage units.

2. Of course, any content referenced or embedded in casts will not be available, such as images -but that's not Farcaster's problem and if someone really wanted to, they could fix it by using a caching proxy or something similar.

Social media on the Mars colony

One of the challenges a crew of a future the Mars colony will have to overcome is staying connected with Earth. Radio signals take 4-22 minutes to get from Earth to Mars, and it will take as much for a response to come back. There's not much we can do about this, unless we find a way for the radio signals to travel faster than light.

One more problem is that the available bandwidth is nothing compared to what we are used on terrestrial communications. I expect that all available bandwidth, will be used to support the operations of the station, and to exchange asynchronous messages between the station crew and Earth command center and their families.

One thing is for sure: The Mars crew will not be able to use X/Twitter, because it's built on HTTP, a synchronous protocol. However, our astronauts could use Farcaster!

An other cool thing is that Earth-March syncing could also be performed entirely off-line: Every mission to Mars could also carry a Earth-synced hub, that would sync with Mars when it gets there and every mission from Mars to Earth could carry the Mars state back to Earth.

Astronauts will have full access to everything discussed on Farcaster on Earth, interact between them, share their thoughts, and when their hub syncs with Earth, we will all be able to see their activity, react to it, etc., and vice versa.

We may have to create an FIP to introduce some small changes to support the Mars colony use case, but I'm optimistic that space settlers count as qDAUs and it will get the full support of the devs.

So, yes: Farcaster is a better match for SpaceX than X!

Most users know "Signers" as "this thing you have to pay for when you connect a new app". One of the first articles in Purple Sumbarine, was about Farcaster Signers, but my understanding has evolved since then, and we also have new tools and advances since then.

In order to understand signers, you have to keep in mind that all interactions with hubs take place by sending hubs a "message" that has a specific structure. So, when you cast, like, or recast, the app you are using sends a message to a hub saying "@vrypan.eth casted Hello World", or "@vrypan.eth liked this cast".

Messages look something like this under the hood:

As you can see such messages have two parts.

• The data part: this is more or less what we usually consider the content, like the text of the cast, the date it was casted, the user who casted.

• The metadata part which has a hash of the data, a digital signature of the hash, and the key that produced the signature: the signer.

(What you see in the signer filed is not the actual signer, but the public key of the signer.)

Why we need signers

In a centralized network such as twitter or facebook, you usually have a username and a password. You use your credentials to connect to a server, and then the server knows that you are who your credentials say you are. There is no other way to post something to the service, and the centralized server is the absolute authority of what was posted by whom.

Farcaster is an open, p2p network. Anyone with some technical knowledge can create a program that sends messages to the Farcaster network. The only way to verify the authenticity of these messages, is by their digital signature.

Each Farcaster user has their own keypair, a private and a public key. If you signed up using Warpcast, your recovery phrase can be used to generate this pair. This keypair also corresponds to an ethereum address, what is often called in Farcaster the custody wallet.

So, you could actually sign your messages using your private key. But users rarely create these messages on their computer using a program they wrote. They connect to a service or app, like buidler and after authenticating with it, it posts on their behalf. The problem is you don't want to give them your private key. This would be the equivalent of giving a gmail integration your username and password (and to some extent, not even being able to change the password).

Here is where Farcaster Signers come to play: Instead of giving an app your private key, the app creates a new random key, and asks you to approve it. You approve it using your private key and you register your approval onchain (gas cost!). From this point on, any hub that receives a message signed by this Signer, can check the blockchain to verify that you have approved the signer and accept it as authentic.

Warpcast and meta-transactions

When you make a call to a smart contract, the caller has to pay the gas for its execution. This is why adding or revoking a signer (onchain transactions) have a cost.

Normally, your Farcaster custody wallet would need to have some OP ETH to perform these transactions.

But wait. There's a workaround: KeyGateway, the smart contract used to approve Signers, allows meta-transactions. You can think of meta-transactions like this:

• The user who wants to perform a transaction signs the transaction or an authorization to perform the transaction using his wallet. This is an offline action.

• The signed transaction is not sent to the smart contract, but it is shared offchain with a third party, usually called the "relayer".

• The relayer performs the transaction and pays the required gas.

Warpcast takes advantage of this feature to hide the added complexity of using a blockchain: It will ask the user to pay them $1, and then they use a meta-transaction and they pay for the gas.

This is roughly the equivalent of them saying "Just sign this paper, give me $1, and I'll take care of the rest."

The actual gas cost for adding and removing signers is usually well bellow $1. Warpcast now allows users to also pay using Warps, an in-app credit system: You can buy 500 Wraps for $5, and approving a signer will usually cost around 40-50 Warps (depending on gas cost at the time of the transaction).

(Warps are an interesting experiment that deserve a separate article.)

Revoking a signer

Obviously, a user must be able to revoke a signer, and they can do so using their private key and posting the revokation onchain to let everyone know that the signer is no longer authorized to act on their behalf. This was the whole point of not giving away our private key in the first place.

But, when a signer is revoked, hubs see messages that are no longer signed by a valid signer. Most people's first thought is OK, but these are old messages signed when the signer was valid. But you have to keep in mind that Farcaster is an open, p2p network. Hubs are added and removed all the time. You could spin up your hub right now (it's actually quite easy) and your hub would receive messages from other hubs it discovers in order to get its history (aka state) up to date. How can your newly created hub know when a message was signed?

This is why hubs have a simple way of "thinking": not a valid signer, not a valid message. And, as a result, when you revoke a Signer, all messages signed using it, are pruned by hubs!

This looks bad. The truth is there is a simple solution that no app (to my knowledge) has implemented (yet). Remember the message example we used earlier? What if you signed the same message with a different signer?

Signing the message with new signer will create a new signature, but the message data and the message hash will stay the same: Same user (fid), same content, same timestamp.

• To any client, this new, re-signed message is the same as the original one.

• To any hub, this is a valid message, provided that the original (same hash) is not in the hub's database.

So, an app could:

1. Download all your messages (your Farcaster history)
2. When you remove a signer, and some messages are pruned, re-sign these messages (from your download) with a new signer.
3. Post the re-signed messages to a hub.

Using fario

You can perform the above steps using https://github.com/vrypan/fario if you are comfortable working in the command line. You will have to:

Backup your data using fario-out --all.

Use fario-grep to select the records signed by the signer you want to remove.

Remove the signer using fario-signers remove and create a new signer using fario-signers add

Re-sign the messages using fario-signers sign

Upload the re-signed messages using fario-in

Final thoughts

Signers are an elegant approach to delegating permissions. It allows users to easily let an app act on their behalf, but at any point in time, they can revoke this permission.

The lack of a simple, user-friendly app that allows users to revoke a signer without deleting all activity performed using it, is definitely a pain-point looking for solutions: Right now, using a signer means that you are stuck with it, since revoking access will delete any casts, likes, recasts and follows you have performed using it. (Unless you are one of the few users who understand the technical details of Signers, and have the skills to use something like fario or put together a script by yourself.)

Looking forward to try the first apps that will give a user-friendly solution to this!

I wanted to use the farcaster icon, just like other app icons in my web pages.

For example, at the top of this page, you see a twitter icon. This icon is displayed by using Font Awesome¹ and then something like <i class="fa-brands fa-twitter"></i>. In this case, the icon is a font character, which means it scales with the rest of the text, it changes color with the rest of the text, and so on.

I wanted something similar for Farcaster.

So, I converted the Farcaster logo outline to SVG using Pixelmator², and the used Icomoon³ to turn it into a web font. Then, I manually cleaned up the result, and added some instructions on how to use it.

You can find the result at github.com/vrypan/fc-font.

After downloading the files, you use something like

<link rel="stylesheet" href="farcaster/style.css">

and then you can use the icon:

<i class="fc fc-farcaster"></i>
<i class="fc fc-square-farcaster"></i>

and you'll get something like this:

On October 11, 2023, Farcaster opened its doors to everyone (a.k.a "went permissionless").

Farcaster is a lot like and a lot unlike other social networks. There's so much to learn and explore, but if you are new, this article will help you find your way around.

Warpcast is to Farcaster, what Firefox is to Web

Farcaster is a protocol, and Warpcast is a Farcaster client, much like Firefox, Chrome, Safari and Edge are HTTP clients. There are many other clients and applications. You can find an (incomplete!) list of applications that use Farcaster here.

If you don't have a Farcaster account, the simplest way to create one is to install Warpcast.

You own your Farcaster identity.

Everything you do on Farcaster (casts, likes, recasts, follows, etc.) is tied to your Farcaster Identity (fid). No one can take away, suspend or cancel your Farcaster identity: it is controlled by an Ethereum address only you have the keys for. Don't worry, if you loose your keys, there is a way to recover your identity.

Open, Decentralized

Farcaster is an open protocol. This means than anyone can build applications on top of it, without asking permission and without paying fees. Compare this to using Facebook, Twitter/X, or Reddit APIs: Each one of these companies has changed policies, requirements and pricing, often pulling the rug under developers' feet.

Farcaster is decentralized. At the core of Farcaster are the Farcaster hubs. Every hub keeps a complete copy of everything there is on Farcaster. Hubs talk to each other and sync their status to reach consensus. Anyone can run a hub. If you like experimenting, you can run your own hub, even from your home (hardware requirements are minimal, your previous PC or laptop is probably more than adequate).

Why do I have to pay?

Because there is no Twitter or Facebook to pay the costs.

In exchange, you own your Farcaster identity, data and network.

There are two costs to using Farcaster.

Storage space on hubs. For most users, this will be a cost between $0.6/month and $1/month, depending on the payment method. The easiest way to pay is through Warpcast's in-app purchase ($12/year including AppStore fees and USD-to-ETH conversion). But you can also use a service like caststorage.com, pay in ETH and avoid the AppStore tax.

Both methods bellow, will have the same result. Warpcast purchases are converted to ETH and used to perform the onchain transaction.

The cost of identity-related transactions (remember, your Farcaster identity "lives" onchain, and onchain transactions have a small cost), such as the initial signup or giving permissions to apps. This cost is small, and in some cases apps may pay it on your behalf to make your life easier, but occasionally you may be asked to pay something like $0.99 (the actual cost is much less, and there will be ways and tools to pay much less in the future).

Where can I learn more?

1. farcaster.xyz is the home of the Farcaster protocol.
2. thehubble.xyz is Hubble's homepage. Hubble is the software run by Farcaster nodes.
3. Farcaster Overview: short videos explaining the core concepts of Farcaster. (Keep in mind that the videos were created some time ago, and some of the details may have changed through Farcaster Improvement Proposals.)
4. Check out the articles on Purple Submarine.

How it works

Varun has created a video that explains everything in a very simple way:

• Every Farcaster account is owned by an Ethereum address (often called “wallet”).
• Every Farcaster account can also set a recovery address. The only thing the recovery address can do is to move your Farcaster account to a new address.

Moving your account to a new address is quite a power to give to someone. The owner of the recovery address can save you if you lost your “secret phrase” (think of it as your password), by moving your account to a new address you control. But if they go rogue, or get hacked, they can also steal your Farcaster account!

Failsafe, no failsafe

If you watched the above video, you may have noticed that there was a fail-safe: Between the initiation of the account transfer and the actual transfer there was a 5-day delay during which you could cancel it and even change/revoke the recovery address.

I’m writing in the past tense because this fail-safe was removed by FIP-5: Instant Recovery: The recovery address can now instantly move your account to a new address and there’s nothing you can do about it.

While this may seem a bad thing, it’s not that bad, and there’s good reasoning behind it:

1. 99 % of the users, especially new users that will join once signups are open for everyone, are used to Web2 platforms: I lost my password, I use my email to recover it.
2. When a new user signs up, Warpcast (that most of them will use to sign up) sets the recovery address to one Warpcast controls. This way they can hide the complexity from users, and provide them with what most users expect: Being able to instantly help them recover their account.

Where did decentralization go?

If you are here because of the Web3 ethos, decentralization and sovereignty, you’re probably disappointed. What I just described is a way for a centralized entity (Warpcast) to take away your decentralized Farcaster identity. If that’s the case, what’s the point of all the decentralization, web3 and the costs that come with them?

There are a couple of good answers.

• First of all, you can set your own recovery address: You can use another address you control, a good friend’s address you trust, or your lawyer’s Ethereum address (yes, there are some that know what this is).
• You could also set it to an M-of-N multisig wallet, controlled by N people you trust.
• I can also imagine more exotic implementations of a recovery address.
  • For example, all Farcaster accounts a company uses can have a recovery address controlled by their IT, which has a dual purpose:
    1. Being able to support users who lost their secret phrase
    2. Being able to take away a corporate account.
  • Or a smart contract that implements the time-delay feature removed by FIP-5.
  • Or even create a valet service that users pay annually and in order to recover their account, users have to do a video call, prove their identity, and then the service helps them recover their account.

Takeaways

1. If you sign up to Farcaster using Warpcast, Warpcast can recover your account if you lose your keys, but they can also take away your account, or be compelled to do so. Keep this in mind if you think that someone may want to censor you in the future.

2. If you are an experienced Web3 user, you may want to consider some of the options mentioned above, like setting the recovery address to one controlled by your hardware wallet, or a multisig.

3. There is a wide range of services to be built that help users recover their Farcaster accounts. You may want to build one of them.

Twitter is now X.

"Ex", "ten", "ex-twitter", or "the service formerly known as Twitter", it doesn't matter much. What matters (to me), is that this feels like the end of an era —from now on, it will be something else.

I feel that there is a whole Internet generation with a special place for Twitter in our hearts.

I signed up for twitter in December 2006. This was the time when the first wave of podcasting was getting traction. This was the time of Dave Winer's Morning Coffee Notes and Adam Curry's Daily Source Code ("we don't need no stinking transmitters!") which was my inspiration for my own podcast.

Much like every other podcaster at the time, I was trying to understand how this new format works, and I was eager to try every new tool and service that promised to make podcasting better. One of them was ODEO. I loved Odeo, and the people behind it, the co-founders of Pyra Labs, Noah Glass and Evan Williams, made it even more special to may eyes. Pyra Labs was the company that built blogger.com which is fair to say that made blogging accessible to everyone and transformed the Web from a read-only medium to read-write one for most.

In 2006, Odeo (actually Obvious Corp, the company that was formed to hold Odeo and other products the team would develop) launched Twitter, and since I was following what Odeo and Ev were doing, I had to try it. I was user #74233.

A sketch, c. 2006, by Jack Dorsey, envisioning an SMS-based social network ¹

For a few years, Twitter was a public place where "Internet geeks" would "gather". The Internet was much smaller than today (not small, but much smaller), and the first Twitter users were the people we already knew from blogs and podcasts. The most followed accounts were not brands, politicians or pop stars, but bloggers, podcasters, developers and tech entrepreneurs.

To me, and I think for many people like me at the time, twitter's appeal was twofold:

1. It was an open system, with a simple, open API, true to the ideas of Web2.0 at the time: A service we could integrate with our own services, write scripts for, build tools and applications on top of.
2. I did not have to find a title for my content. Before Twitter, "publishing to the web", was synonymous to blog posting and blog posts have titles which add a huge overhead when you want to write something casual —it just did not feel right to have blog post containing a single sentence and find a title for it. Blogs were not designed with this "casual posting" in mind, and Twitter's simplicity was liberating.

Twitter was home of many innovations and some of them originated came from their users.

It introduced the @username namespace. Until then, you either had a username or an email. The @username namespace is still a huge part of Twitter's brand equity.

The (initially small) scale allowed for features that have long been gone. Like the track command: You could tweet track pizza and you would get notified whenever someone posted a tweet containing the word pizza. You could also use it to track usernames, which allowed you to get all mentions of a specific username.

There was no "retweet": Users would copy paste a tweet and add rt @username in front of it (like this). Which meant that if you wanted your tweet to be retweeted with credit, you had to make sure there was enough space to add rt @yourusername and still be under the 140 characters limit —and short usernames had a nice advantage.

And there were no hashtags. Hashtags were Chris Messina's "invention" that were later adopted by Twitter.

Oh, and there was also a SMS gateway. (Remember, in 2006 the iPhone was not yet released.) So you could text 40404 (if you were in the US) with your tweet, and get SMS notifications when people you followed tweeted.

We also had "FF", for "Follow Friday": Every Friday, we would tweet FF: followed by usernames that posted interesting content, to help them be discovered by other users.

Twitter also popularised "URL shorteners": Shortening a long link left you more characters to write your comment (and in some cases, it was the only way to make a link fit in 140 characters).

It was the first social network that grew to scale. The problem with scaling a social network with x users (the algebraic symbol as in x+y, not as in "ex-twitter"...) who follow one another is that complexity grows exponentially. So, after a point twitter would go down. And we would get the Fail Whale.

Since then, Twitter grew in scale, solved their technical issues, closed their API, integrated organically hashtags and retweets, expanded beyond 140 characters. A wider audience joined. It became a place for political debate, public discourse, and civic mobilisation, a customer relationships management tool, a sales channel, the breaking news channel. Internet hackers and geeks were hugely outnumbered by celebrities, politicians and their followers together with armies of bots and anonymous (and sometimes, professional) haters.

All this is not good or bad. I've been part of some of these changes, I ran political campaigns using Twitter, I advised companies on how to leverage twitter as a CRM tool, I promoted my work, I joined polarised conversations and received my share of anonymous hate. Things change. It just is what it is.

My original intention was to end this post by saying that Elon killed Twitter. But the Twitter I have in mind has long been gone. I guess that changing the name when everything else has already changed is an honest decision, after all.

(A delayed) Goodbye, Twitter and thank you for the memories.

Based on what was presented yesterday at WWDC, VisionPro is an amazing product. But what I'm really fascinated about is EyeSight. Here is why.

EyeSight is an outward display. It's (intended? initial?) use will be to display your eyes while you are wearing the VisionPro in order to let people around you know if you're looking at them, or at someone else, or if you are immersed in an experience on your own.

This is obviously very important, because it retains the communication bandwidth provided by facial expressions. We all know that eyes and eye contact are an important, high-bandwidth communication channel for humans.

"I saw it in her eyes", "Eyes don't lie", "Let the eyes do the talking" —others have said it better than me.

But I have the feeling that EyeSight can be more than this. In addition to preserving the existing communication bandwidth, it may also increase it! If Apple allows it, I can see a future where the outward display shows more than your eyes.

Imagine being able to do some hand gesture, or even eye gesture, like blinking your eyes in a specific way that change the display, and show emojis (I'm really bad at design, I'm sure any designer could make these look much better). Or even animations like fireworks or any animated meme gif!

I know that the idea may sound silly to many, but there is a generation of people who are really good at communicating ideas and feelings using visual clues when they are in front of their keyboard but have no way of doing it IRL. (Just visit any discord server.) Being able to express themselves IRL, with images that are displayed exactly where the person they are talking to is looking can be a killer feature.

And the most interesting part is that if this turns out to be a killer feature, it's one that will drive adoption because it has built-in virality: when I use it, other people see how cool it is and they want it too.

So, OpenSea announced they are releasing a tool "that allows creators to enforce fees on chain"¹. Here's why this tool is much more, and why it's scary.

How it works

OpenSea offers a solidity library that creators can include in their NFT contracts. This library allows a creator to blacklist an address (the address of a marketplace) from being able to list and trade their NFTs. So, I can only sell the NFT at a marketplace only if it is not a blacklisted one.

@0xCygaar has a great in-depth analysis of the details on twitter. ²

Subscription lists

Now, 99.99% of the creators do not know how to identify the addresses (and contract hashes, an other check provided), but OpenSea offers a solution for them: they can subscribe to a blacklist maintained by someone else who knows how to do these things and is willing to spend the time to maintain the list up to date as marketplaces deploy new contracts, they change their policies on royalties, new ones are launched and so on.

The scary part

This all sounds great. As a creator, I can block marketplaces and services that allow users to trade my NFTs without paying royalties, how cool is this. And I don't have to do much, my smart contract is subscribed to the OpenSea's blaclist and they make sure they update it. Of course I could subscribe to a blacklist mainteined by someone else, but why bother, I know OpenSea, they are the experts.

Wait.

This is great until a government asks all marketplaces to implement something. KYC for example. And then demands from OpenSea to add the ones that did not comply to their blacklist.

Or until OpenSea has a dispute with an other marketplace over something. Over copyrights, over patents, over policies. Businesses get into these debates every day. And OpenSea decides to add this marketplace to their blacklist.

I can think of many scenarios where something like this happens. And I can see the competing marketplace trying to reach out to creators and explain to them with detailed hoots and videos how to use etherscan to go to the contract code and sign a transactions to unsubscribe from OpenSea's blacklist. Which most won't do, because it will seem scary, complicated, and in any case, "why go through all this if 90% of their sales are on OpenSea, anyway"?

I can also see how this could lead to a place where no one even tries to launch an other marketplace, because OpenSea has all the power: They have the biggest share of the market, they are deeply integrated with the ecosystem, and if everything else fails they can find a reason to blacklist competitors.

OpenSea will probably swear: "We would never do something like this!"

But remember? We created crypto and web3 because we did not want to rely on promisses, we wanted the rules to be written in code.

It's the email story, all over again.

A couple of days ago, Jameson Lopp published a great article³ explaining how email started as a completely decentralised protocol and ended up being one where 90% of email users are captured by 5 companies.

It is said that those who do not learn from history are doomed to repeat it. I believe it is of utmost importance that proponents of decentralized protocols learn from the failures of those that have come before. The following is a review of 40 years of history for the protocol that is the foundation of email.

It's amazing how we are about to do the same mistakes all over again.

What OpenSea released is not a royalties protection system. It's a blacklisting infrastructure. Yes, it can be used by creators to protect their royalties. This is how these types of centralised control have always been introduced: to protect us from "something bad".

But what they are actually asking is to give up control, and give them more power.

This is about a small ERC721 contract I wrote, but let me give you the context first.

I think of NFTs as a new data pointer. Much like filesystems (file path + file name), and URLs (protocol + server + path + filename), NFTs (contract address + item Id) provide us with a way to point to data.

If you think of an ERC721 contract as a bucket of "files", we have developed ways to present, query and organise these "files": We can refer to a specific one by Id, but we also have tools like NFT marketplaces that allow us to filter by trait.

The problem is that filtering by trait is based on the decisions that the smart contract developer did: If the contract creator added a colour trait, we can easily filter by colour for example.

But what if we want to create a different grouping? What if I want to create a way to group together my favourite items of a NFT collection, or the ones that have a characteristic not explicitly described in the NFT metadata? The most common example of this is ENS clubs: .eth domains that follow a pattern that some users find valuable or interesting (all digits, 4 digits, palindromes, English names, Arabic numerals, all emojis, etc.) We do not have a tool to do this grouping on-chain.

This is where my smart contract comes in. I call it "ERC721 Subset" and I tried to implement it in a way that conforms with the ERC721 standard, but:

• It does not allow approvals and transfers (all related functions revert with an error.)
• All tokens are owned by the contract and (based on the above) can't be transferred or traded.
• The contractor needs a ERC721 contract address (the "original collection") to be passed to.
• There is an add(tokenId) and remove(tokenId) that add a token from the original collection to the subset. They are implemented as mint and burn functions to allow services like NFT marketplaces to track the addition and removal of tokens in a way that they understand.
• There is an exists(tokenId) function that allows an other service or contract to check if a token is part of the subset.
• tokenURI(tokenId) is proxied to the function of the original contract, so the sub collection NFT looks exactly like the original one.

To illustrate how this works, I created an ERC721 Subset of the OnChainBirds collection that contains what their community call "greyscales": These are birds that happen to use only black, white and grey traits. There is no specific trait that describes grayscales, but a user went through the whole collection and identified 17 of them.

So, I deployed A ERC721 Subset called "OnChainBirds: Grayscales". If you look at the etherscan page of the contract, you will see the contract creation and the add() calls to add the specific token Ids. If you go to the OpenSea page (or any other marketplace) you will get a nice gallery of these tokens.

This is a first take on the idea. There are probably ways to make the smart contract more efficient, or more secure or add some features that will make it more useful. It would be nice for example if there was a way to programmatically manifest that this is not a normal ERC721 contract. Or a more efficient way to add multiple items. What are the implications for services (wallets, marketplaces, etc) that deal with ERC721 tokens? Would it make sense to make this an ERC standard?

If you have any suggestions or ideas, ping me @vrypan.

/// @title ERC-721 Non-Fungible Token Standard, optional metadata extension
/// @dev See https://eips.ethereum.org/EIPS/eip-721
///  Note: the ERC-165 identifier for this interface is 0x5b5e139f.
interface ERC721Metadata /* is ERC721 */ {
    /// @notice A descriptive name for a collection of NFTs in this contract
    function name() external view returns (string _name);

    /// @notice An abbreviated name for NFTs in this contract
    function symbol() external view returns (string _symbol);

    /// @notice A distinct Uniform Resource Identifier (URI) for a given asset.
    /// @dev Throws if `_tokenId` is not a valid NFT. URIs are defined in RFC
    ///  3986. The URI may point to a JSON file that conforms to the "ERC721
    ///  Metadata JSON Schema".
    function tokenURI(uint256 _tokenId) external view returns (string);
}

And the Openzeppelin implementation or ERC721 implements it like this (practically, it returns "baseURI + tokenId")

    function tokenURI(uint256 tokenId) public view virtual override returns (string memory) {
        require(_exists(tokenId), "ERC721Metadata: URI query for nonexistent token");

        string memory baseURI = _baseURI();
        return bytes(baseURI).length > 0 ? string(abi.encodePacked(baseURI, tokenId.toString())) : "";
    }

For NiftyWalls, is decided to implement tokenURI as a separate contract.

So, the NiftyWalls implementation looks like more or less this

interface ITokenURI {
    function tokenURI(uint256 tokenId) public view returns (string memory) ;
}

contract NiftyWalls is Ownable, ERC721 {
    address public metadata;
    
...
...

  function tokenURI(uint256 tokenId) public view override(ERC721)returns (string memory) {
    require(_exists(tokenId), "NiftyWalls: URI query for nonexistent token");
    IToknURI meta = ITokenURI(metadata);
    string memory json = meta.idToJson(tokenId);
    return string(abi.encodePacked("data:application/json;base64,", Base64.encode(bytes(json))));
  }
  
...
...

  function setMetadataContract(address _metadata) public onlyOwner {
    metadata = _metadata;
  }

A very simple implementation of the TokenURI contract would be something like this.

contract TokenURI {
    string private baseURI = 'http://mysite/' ;
    
     function tokenURI(uint256 tokenId) public view returns (string memory) {
        return string(abi.encodePacked(baseURI, tokenId.toString())) ;
    }
}

The nice thing with this approach is that it allows you to upgrade the TokenURI contract to do interesting things in the future, without touching the NFT contract. For example:

• You may use setMetadataContract() to "activate" metadata only after all tokens are minted.
• Or you could make the TokenURI contract return different metadata after a date or a block number is reached.
• Or deploy a new TokenURI contract (and use setMetadataContract() to point your contract to it) that implements on-chain metadata.
• Or deploy a new TokenURI contract that holds the metadata on-chain and allows for changes (for example, the owner of a token can change the name of the token).
• Or even use on-chain events or an oracle to update metadata.

The cost of implementing tokenURI as a separate contract is minimal, and the advantages are significant, so I expect more ERC721 contracts to implement it this way.

Obviously, every individual NFT image can signal something: Good taste, love for retro gaming, girl power, unconventional thinking, etc. But a 10k pfp are becoming brands that signal more than what the design of an individual item can.

Using a CryptoPunk is a signal by itself –which punk is secondary, especially if you don't own one. CryptoPunks signal OG status, (usually crypto-originating) wealth, someone who can spend 60ETH ($180,000) for a NFT.

Costing at least 80ETH each ($240,000), Bored Apes signal "rock-star". You are part of an exclusive yacht club, only accessible to millionaires. Not the "old money" type, these are degen millionaires, eating pizza, wearing silly hats and having fun at parties.

My personal experience with a couple of other projects:

Hashmasks (floor is close to 1ETH, or $3000), "a living digital art collectible created by over 70 artists globally", signal art. (They focus a lot on their OG status as this was one of the very first PFP NFT projects, but I think that the main signal is art.)

Some of their subcategories have evolved to carry additional signalling. For example, users renamed clown Hashmasks as part of a "banks are clowns" campaign (which btw, seems like a thing a contemporaty art project would address).

An other project I follow, Chubbies (floor is about 0.07ETH or $210), created by a single, laid back developer called... solazy, signal geek zen: "no roadmap, no team, no grand vision - just a mission to learn, experiment, and make fun projects".

Solazy writes in the project's discord server:

I want to think of Chubbies as my lifelong project but there's a reason I named myself @solazy.eth. I'm just one person (and sometimes my wife), with a finite amount of time, and many interests. I like the idea of working solo and I put on many hats: backend dev, frontend dev, artist, community manager, marketer, founder etc.

I can't and won't do most of the things you probably expect from other projects. Thus, I've decided to set clear boundaries and expectations for this to be sustainable and fun for me to continue.

I think that once we understand that the main utility of these NFTs is signalling, projects will start to focus more on their brand identity and brand values and less on other things like "roadmaps" and "utility".

So, I have this old iMac "Early 2009" Aluminum iMac Core 2 Duo. I decided to make something usefull out of it, so I upgraded the RAM to 8GB, replaced the original HDD with 1TB SSD and installed Ubuntu 20.24.

Important note: Bellow, I describe how I configured autologin and how I changed permissions to /sys/. These are NOT are not good security practices. However, given that the machine is sitting on my desk, and behind a well configured firewall, my assesment was that it is safe for me to do them. Please do your own security assesment.

Installing Ubuntu

Intalling Ubuntu was straight forward with two exceptions:

• The nouveau video driver seems to freeze when X does something intensive (and by intencive I mean opening Firefox). But I did not care about it as I intended to use this on console mode.
• The wifi driver is a commercial one, and you have to have newtork connectivity to install it. So, I had to use Ethernet, use ubuntu-drivers to identify the driver I needed and install it. From that point on, I could configure wifi and Ethernet was no longer needed.

Booting in console mode.

First stem, was to disable X from starting on boot.

systemctl enable multi-user.target
systemctl set-default multi-user.target

/etc/default/grub

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

GRUB_DEFAULT="Ubuntu"
GRUB_TIMEOUT="3"
GRUB_DISTRIBUTOR="`lsb_release -i -s 2> /dev/null || echo Debian`"
GRUB_CMDLINE_LINUX_DEFAULT="text"
GRUB_CMDLINE_LINUX=""

# Uncomment to disable graphical terminal (grub-pc only)
GRUB_TERMINAL="console"

GRUB_GFXMODE="640x480"
# Uncomment to disable generation of recovery mode menu entries
GRUB_DISABLE_RECOVERY="false"

# Uncomment to get a beep at grub start
GRUB_INIT_TUNE="480 440 1"

GRUB_DISABLE_OS_PROBER="true"
GRUB_SAVEDEFAULT="false"

Configuring tty1

This would be a keyboardless system, so I would like to make sure that tty1 starts with some things on it.

$ sudo systemctl edit getty@tty1.service

This (creates and) openes file /etc/systemd/system/getty@tty1.service.d/override.conf for editing. I entered:

[Service]
ExecStart=
ExecStart=-/sbin/agetty --noissue --autologin vrypan %I $TERM
Type=idle

To enable the service and starts an auto-login session on tty1:

$ sudo systemctl enable getty@tty1.service; sudo systemctl restart getty@tty1.service

To automatically run some useful stuff on tty1, I added the following lines to $HOME/.profile:

if [[ "x$XDG_VTNR" = "x1" && "x$SHLVL" = "x1" ]] ; then
    # Sometimes fbterm failed to start immediately, it seems that
    # the framebuffer needs a couple of milliseconds to initialise.
    # Or maybe it's something else, but waiting a second or
    # two fixed it.
    echo Waiting 2 secs... 
    sleep 2
    /usr/bin/fbterm -- tmuxp load -y $HOME/custom/tmuxp.tty1.yaml 
fi

tmuxp.tty1.yaml will start a tmux session with all the panes arranged like I want them and run the corresponding processes in each one of them.

#  tmuxp.tty1.yaml
session_name: tty1
windows:
  - window_name: status
    focus: 'true'
    layout: 0774,240x75,0,0{91x75,0,0[91x10,0,0{45x10,0,0,1,45x10,46,0,7},91x64,0,11,2],148x75,92,0[148x38,92,0,3,148x36,92,39,4]}
    options:
      automatic-rename: 'off'
      pane-active-border-style: fg=black
      pane-border-style: fg=black
      status: "off"
    panes:
    - tty-clock
    - while true; do clear; ncal -M ; sleep 1m ; done
    - while true; do clear; calendar -A 2 ; sleep 1m ; done
    - glances -1
    - colortail -f <(docker exec pihole pihole -t )
    start_directory: /home/vrypan
  
  - window_name: lights_on
    panes:
      - shell_command:
          - tput setab 7
          - clear

And this is the result:

The services

I also installed docker, and then configured a couple of containers (that replaced rasperrypis I used for this purposes):

• pihole
• an ipfs server
• and homebridge

I also configured syslog-ng to receive logs from my Unifi Dream Machine:

# /etc/syslog-ng/conf.d/remote.conf 
source t_src { tcp(port(514)); };
source u_src { udp(port(514)); };
destination r_all { file("/var/log/$HOST"); };
log { source(t_src); source(u_src); destination(r_all); };

Using the iMac as a (sort of) LED panel light

You may have noticed there is a second tmux window, called ligths_on. I find this kind of cool. It's a window that is all white (tput settab 7 sets the background to white). So I can ssh to this machine, do tmux next -t tty1 and the screen will turn on white.

And since this is placed on my desk, I use it as a light panel (!!!) that makes me look better when I'm on a video call on my laptop. Then tmux next -t tty1 will switch back to my normal "control center" view.

Of course, don't expect a thousand nits from this display. But it makes a difference when there's low light.

Turning on and off the iMac screen using Siri

I don't want my iMac screen to be on all the time. So I use the following over ssh

$ echo 0 |sudo tee /sys/class/backlight/nv_backlight/brightness # turn off
$ echo 100 |sudo tee /sys/class/backlight/nv_backlight/brightness # turn on

But since I have already homebridge running, why not use Siri for this?

I order to easily allow the homebridge docker container to access /sys/class/backlight/nv_backlight/brightness I changed the permissions

$ sudo chmod 666 /sys/class/backlight/nv_backlight/brightness

and I also mount /sys/class/backlight/nv_backlight/ as a rw docker volume, so my docker-compose file looks like this:

version: '2'
services:
  homebridge:
    image: oznu/homebridge:latest
    container_name: homebridge
    restart: always
    network_mode: host
    environment:
      - TZ=Europe/Athens
      - PGID=1000
      - PUID=1000
      - HOMEBRIDGE_CONFIG_UI=1
      - HOMEBRIDGE_CONFIG_UI_PORT=8581
    volumes:
      - $HOME/data/homebridge:/homebridge
      - /sys/class/backlight/nv_backlight:/backlight:rw

Next I installed the homebridge-shell-switch plugin, and configured like this:

{
    "accessory": "ShellSwitch",
    "name": "Monitor",
    "onCmd": "echo 100 > /backlight/brightness",
    "offCmd": "echo 0 > /backlight/brightness"
}

Now, I can turn on and off the monitor by saying Hey Siri, turn the monitor off. I can also schedule the monitor to turn off during the night for example, or turn it on/off using the Home.app on my iPhone.

(If you haven't done so, read Part 1 of this series.)

The next morning, when Christina woke up, she found the above note.

This is what Tips-and-Tricks-1.txt said:

Hello, Christina!

Try the following commands!

$ bb

$ fortune

Every time you run fortune, you get a new fortune cookie. Try it.

Now, try this:
$ echo "Hello, Christina!" | boxes -d santa
$ echo "Hello, Christina!" | boxes -d boy
$ echo "Hello, Christina!" | boxes -d girl
$ echo "Hello, Christina!" | boxes -d cat

If you want to see all available "boxes", type
$ boxes -l

You can always pipe the output of one command to an other!

$ echo "Hello, Christina!" | boxes -d cat | lolcat

or...

$ fortune | boxes -d cat | lolcat

or even.....

$ fortune | cowsay | boxes -d cat | lolcat

Remember, you have already used the following commands:

ls
ls -l
pwd
cd
asciiquarium
cowsay
lolcat

You can see your terminal history by typing 
$ history

After she tried all the above, I heard what every geek dad wants to hear:

Is there a way to make this fortune cookie appear every time I log in?

Yes!!! She has questions!!! Now, we are in business.

We edited .bashrc and added fortune | boxes -d cat | lolcat at the end.

An other thing she tried was a box, within a box, within a box, something like fortune | boxes -d mouse | boxes -d cat | boxes -d dog

She spent a big part of the day trying various combinations of the commands she knows.

Our day, ended with this.

Dad, I think the terminal is my favourite app.

One of Christina's Christmas presents was an old MacBook (Late 2008 Aluminum), that had not been used for years. I cleaned it, formated the disk and installed Linux Mint. ¹

Before we presented it to her, I had already created an account for her, so I just had to give her the password and she logged in.

Christina is quite experienced with computers and electronics (as most of the kids her age), but she mostly lives inside her iPad, and I realised that the desktop environment looked strange to her. Especially the trackpad gestures like tap-to-click, or two-fingers-click, etc.

Not surprisingly, the first thing she wanted to know is how to change the desktop background 😆. Which turned out to be a good opportunity to use right-click-save, after she googled for backgrounds. We also installed Skype, and tested OpenOffice Writer.

Next stop was the terminal (and to be honest, this was my goal, what we had done so far she could do much better and easier on her iPad).

She had already seen a terminal a year ago, when I tried and failed to introduce her to Python on an old iMac (where almost nothing worked without tweaking). I also took the opportunity to explain to her that the application is called "terminal" because it's a software that works just like... a terminal. Yes, we have one of these in the house.

This time, I decided to start with something fun. ²

$ sudo apt install sl
$ sl

Next we tried asciiquarium³,

and cowsay⁴

I also installed aalib, aview and jp2a which allowed us to view the pokemon image she downloaded in the terminal.

What turned out to be a great hit, was lolcat⁵, which also provided a nice intro to using Unix pipes. Once she got to know lolcat, she had to pipe the output of every command she knew through it.

As we went through these commands, we also had to learn ls, pwd, even sudo ("it's like 'please', for Linux"). I tried to let her do most of the typing, and let her get the expected errors when she did not leave a space or when a file was not found because of an uppercase letter, etc.

Overall, she got really excited with her new laptop, and especially with the command line.

Trademarks + Web3. 1/🧵 // @vrypan→

Web3 will bring new identity systems, like @domains_ens. Your ENS domain will be the way for others to verify it's you, it will probably be the way social networks will verify the identity of your brand, it will be the address where your clients will use to pay you. 2/ // @vrypan→

The thing is that Web3 is decentralised and to a large extent, anonymous. Which means that your trademark will be really hard to claim.

What can you do against the ETH address that holds your companyname.eth? Sue them? Good luck. 3/ // @vrypan→

Maybe ask ENS to take the domain away?

"[...] the root key holders have locked control of the .eth registrar contract, which means that even keyholders cannot affect the ownership of .eth domains." docs.ens.domains/frequently-as... 4/ // @vrypan→

So, here's the obvious advise: make sure you claim your brand-related .eth domains now, before someone else does. Smart companies already did.

Or buy them if someone else claimed them already: Most probably it will cost you less now than in the future. 5/5 // @vrypan→

Of course, all this may make no sense to you. ENS, .eth, web3, wtf are they?

Remember: Domain names made no sense to you or the people that were in your shoes back in the 90s, when the web was starting. But a couple of decades later, we got to this: The top 25 most expensive domain names.

So, find someone who knows about these things and pay them to handle it for you.

There's one thing you can be sure of: When all this is common sense, when your kids will have their own .eth address, then your brand/corporate .eth domain will cost much much more to buy back. And this time, it won't take decades to get there.

Today I'd like to introduce you to my latest passion: Planet LRR. // @vrypan→

Planet LRR is actually a mathematical object, disguised as a painting. It's the result of a very very simple process called "cellular automata". This is where it got its name from: Left, Right, Right. // @vrypan→

The actual process to generate Planet LRR took 2 million steps but you can see the genesis of Planet LRR (the first 30-something thousand steps) here: videos.files.wordpress.com/fFp... // @vrypan→

The reason I find it fascinating is that all this complexity comes from such a simple rule. Which is actually an existential or cosmological question: is our universe with all its complexity the result (or governed by) some very simple rules/laws? // @vrypan→

To my knowledge, there are no (or at least very few?) pieces of art that try to explore these questions. My turmites.art project is an effort to make works (of art?) about these great questions. I hope you like it. :-) // @vrypan→

You can find more about Planet LRR here: turmites.art/gallery/planet-lr... // @vrypan→

I'm no art expert, my only criteria is how much I like a piece, and these three spoke directly to my heart, so I went ahead and bought them.

I looked up Lisa, found her Instagram account and messaged her that I liked her work, and suggested she should add a link from her Instagram profile to her Mintable profile to prove that she is her on both sites.

Since then, she has joined twitter (@NftLisa, follow her!), she got deep into NFTs and her works are sold at significantly higher prices than the early ones I bought 8 months ago. (links: https://linktr.ee/LisaFogarty)

Some days ago, I reached out to her again, to ask her something technical about these early NFTs, and as we were chatting, she was very kind to offer to send me the original works as a gift for the early support.

So, today I got these! Thank you so much Lisa!

It turns out that stable coins are a fascinating subject. You may say, what's so fascinating about something that's stable by definition? Thread 👇 // @vrypan→

For one, the various implementations. Take DAI, USDT, USDC, SUSD, TUSD, BUSD, GUSD and the rest. In theory, they are 1-1 to USD. But you get algorithmic vs centralised implementations, each one with its pros and cons. // @vrypan→

And then, even for the centralised ones, you get to have different jurisdictions. You want a stable coin backed by a company regulated/audited in the US or not? How much do you trust the backer (if centralised) or the algorithm (if decentralised)? // @vrypan→

Also, you have to consider liquidity and integration with marketplaces, exchanges and other services. Will you be able to convert your stablecoin to the desired price? Which one(s) are supported by the services you are interested in? // @vrypan→

I think that nothing illustrates these differences than this. This is the current deposit/borrow APY on aave. In theory they are all the same, but the APYs differ based on demand. app.aave.com/markets // @vrypan→

You may think that stablecoins are second class citizens compared to the reference currency. But in some cases they are better. For example, there is no KYC. Remittances are a breeze and you don't have to convert to the local (usually much weaker currency). // @vrypan→

Sidenote on remittances: This is a huge and critical economic activity for a very big percentage of the global population. For example, in Nigeria official remittances have exceeded oil revenues for multiple years. See www.pwc.com/ng/en/pdf/the-econ... // @vrypan→

I'm looking forward to stablecoins pegged to other currencies. I for one, would love to have one (or more) EUR stablecoins. Is someone working on this? // @vrypan→

I got to work in a truly multicultural company, with people from Europe, Africa, Asia, Latin America, the Middle East. I got to travel to places I'd never been before: Ghana, Zambia, Saudi Arabia, India, Brazil, Kambodia, Bangladesh, Nepal, Surinam, Trinidad and Tobago, Curacao, Sri Lanka, Tanzania, Tunisia, Algeria, UAE (I'm probably forgetting some), and worked with even more, like Benin and Uganda. I made some good friends, and I worked with great people from around the world.

When I joined, the telco tech stack was a black box to me. 5.5 years later, after working with something like 20 mobile operators and their vendors and the peculiarities of each country and region, you could call me an expert on some parts of this stack, especially the IN and billing systems and various CDRs. But I also got to understand how the various product offerings work in all these operators and countries -and the similarities and differences.

So, I learned a lot, I traveled to places I'd never been before, I met and worked with great people and made some good friends.

But ChannelVAS has grown up, the team is 10x bigger, processes have been put in place, things have become more structured and well defined. And even if this sounds good for most people, it's no longer the startup mess where I can give my best.

Cheers to all the people I worked with in these 5.5 years! We'll be in touch.

For job openings, checkout https://apply.workable.com/channelvas/.

I think of trading activism in the same way as consumer activism.

Consumer activism is a process by which activists seek to influence the way in which goods or services are produced or delivered. Kozinets and Handelman attempt to define the broad concept as any social movement that uses society's drive for consumption to the detriment of business interests. -- wikipedia: Consumer activism

In the same way that an activist consumer may boycott a product that is cheaper, better or even essential to them in order to apply pressure to a producer or a distributor to change their policies (for example using sweatshops, destroying palm trees, or lobbying for a specific politician), an activist trader may buy or sell stocks or other financial instruments in order to make an ideological point by driving out of buisness or causing significant financial damage to a company, an institution, or a fund that is considered to have negative social impact.

For example, the some individual traders kept buying $GME stock at any price, in hope of buncrupting hedge funds because they consider that these funds are bad for society. They knew that they may loose their small investment, but they did not care, as the expected profit for them was to bring down a hedge fund. [1]

Activist trading has become feasible by services like Robinhood that allow retail traders invest small amounts and social networks like reddit that allows the coordination and aggregation of these activists.

Much like activist consumers, activist traders do not act in their best financial interest.

This may be a new reality that shakes the fundamental assumption behind financial markets that all parties act in their best financial interest. Publicly traded companies, individual and institutional investors, brokers, funds and other parties like banks that are part of the financial system will have to take this into account.