Andrew Kelley is one of my all-time favorite technical speakers, and zig is packed full of great ideas. He also seems to be a great model of an open source project leader.
I would say zig is not just packed full of great ideas, there's a whole graveyard of ideas that were thrown out (and a universe of ideas that were rejected out of hand). Zig is full of great ideas that compose well together.
Zellij has interesting ideas, but it has a ways to go. You can arbitrarily rebind the base modes and their actions, but you're F'd if those conflict with a plugin's, which seem to all have hardcoded key binds.
A few months back I built a cryptographic alternative to CAPTCHAs called Ghost Keys[1] that uses a small donation as proof-of-humanity. For donating you get an anonymous keypair that works across services without repeated CAPTCHAs. The economic friction doesn't scale for bot operators, and donations fund our non-profit[2].
Keys embed approximate timestamps, so services can set age limits. The system was designed for Freenet integration where reputation can be attached to keys - repeat abuse would degrade a key's public reputation over time.
In the event ticket situation, how does this change the economics compared to just adding $1 to the ticket price? (or whatever your minimum donation threshold is)
It would add $1 to the ticket price, the goal is more to replace CAPTCHAs (which cost essentially nothing to defeat these days), but you're right that it wouldn't be a silver bullet in the ticket scalping scenario.
I've been working on a decentralized group chat called River[1], which will be the first truly decentralized group chat and the flagship application on Freenet[1], a general purpose platform for decentralized apps.
Just 2 or 3 bugs remaining before people can start playing with both River and Freenet which hopefully means we're days away (touch wood).
The article makes great points about why distributed programming has stalled, but I think there's still room for innovation—especially in how we handle state consistency in decentralized systems.
In Freenet[1], we’ve been exploring a novel approach to consistency that avoids the usual trade-offs between strong consistency and availability. Instead of treating state as a single evolving object, we model updates as summarizable deltas—each a commutative monoid—allowing peers to merge state independently in any order while achieving eventual consistency.
This eliminates the need for heavyweight consensus protocols while still ensuring nodes converge on a consistent view of the data. More details here: https://freenet.org/news/summary-delta-sync/
Would love to hear thoughts from others working on similar problems!
Haven't read the post yet (I should, I have been vaguely following y'all along but obviously not close enough!) How is this different from delta-based CRDTs? I've built (admittedly toy) CRDTs as DAGs that ship deltas using lattice operations and it's really not that hard to have it work. There's already CRDT based distributed stores out there. How is this any different?
Good question! Freenet is a decentralized key-value store, but unlike traditional KV stores, the keys are WebAssembly (WASM) contracts. These contracts define not just what values (i.e., data or state) are valid for that key but also when and how the value can be mutated. They also specify how to efficiently synchronize the value across peers using summaries and deltas.
Each contract determines how state changes are validated, summarized, and merged, meaning you can efficiently implement almost any CRDT mechanism in WASM on top of Freenet. Another key difference is that Freenet is an observable KV store, allowing you to subscribe to values and receive immediate updates when they change.
This is the problem we're working on with https://freenet.org/ - a general purpose platform for building entirely decentralized services.
Our thesis is that the client-server architecture is a fundamental flaw in the world wide web's design, which inherently concentrates power in the hands of a few. Freenet aims to be a general purpose replacement for this in which all services are entirely decentralized.
The first non-trivial app we're building will be a group chat system called River[1].
I like the new Freenet! I interviewed your founder, Ian Clarke, 2 years ago on my channel — discussing the original freenet, probably the first truly decentralized content network in the world. Here is the 2-hour discussion:
Look around the 12 minute mark when I start to discuss how “the capitalist system” produces centralized monopoilies that extract rents for their shareholders.
The original Freenet had over 6m downloads over the years - and pioneered ideas like cryptographic contracts which later formed the basis for bitcoin, but it was always a very experimental project, while the new Freenet is designed for mass adoption.
They key differences between old and new Freenet are:
Functionality: The previous version was analogous to a decentralized hard drive, while the current version is analogous to a full decentralized computer.
Real-time Interaction: The current version allows users to subscribe to data and be notified immediately if it changes. This is essential for systems like instant messaging or group chat.
Programming Language: Unlike the previous version, which was developed in Java, the current Freenet is implemented in Rust. This allows for better efficiency and integration into a wide variety of platforms (Windows, Mac, Android, MacOS, etc).
Transparency: The current version is a drop-in replacement for the world wide web and is just as easy to use.
Anonymity: While the previous version was designed with a focus on anonymity, the current version does not offer built-in anonymity but allows for a choice of anonymizing systems to be layered on top.
Good question - computationally expensive contracts will be removed automatically as part of a mechanism that keeps track of cost/benefit to the peer for each contract.
