Show HN for May 21, 2026

For the past 5 years or so I've been working on a ground-up redesign of Freenet, my peer-to-peer project from the early 2000s (now renamed Hyphanet).

The new Freenet has been up and running since December along with some early applications like River[1], our decentralized group chat and Delta - a decentralized CMS. Users have already started to build their own apps on Freenet including games, and we have some interesting apps in development like Atlas, a search/recommendation engine.

Architecturally, this new Freenet is a global, decentralized key-value store where keys are webassembly contracts which define what values (aka "state") are valid for that key, how or when the values can be mutated, and how the state can be efficiently synchronized between peers.

We've developed a unique (AFAIK) solution to the consistency problem, every contract must define a "merge" operation for the contract's associated state. This operation must be commutative, meaning that you can merge multiple states in any order and you'll get the same end result.

This approach allows state updates to spread through the network like a virus[2], which typically achieves consistent global state in a few seconds or less.

Like the world wide web, Freenet applications can be downloaded from the network itself and run in a web browser - similar to single-page apps on the normal web. However, rather than connecting back to an API running in a datacenter, the webapp connects locally to the Freenet peer and interacts with Freenet contracts and delegates over a local websocket connection.

If you'd like to try Freenet we have convenient installers for the major desktop OSs but not yet mobile, and you can be chatting with other users on River within seconds[3]. Happy to answer any questions, you're also welcome to read our FAQ[4], or watch a talk I gave back in March[5].

[1] https://github.com/freenet/river

[2] https://freenet.org/about/news/summary-delta-sync/

[3] https://freenet.org/quickstart/

[4] https://freenet.org/faq/

[5] https://youtu.be/3SxNBz1VTE0

Hi everyone,

I am Bojta Lepenye, and first of all, I want to thank the core developers of Hashcat. In my experience, it is quite literally the most capable tool available for offline password cracking across a wide range of use cases.

I have spent the last 4 years (from age 14 to 18) extensively working with Hashcat and the tools surrounding it, and I have documented what I have learned throughout that time (since January 18, 2022) in my first book. During that period, I also had to continuously update and rewrite major sections as the field evolved. One example was the introduction of GPU support for Argon2 and other memory-hard password hashing algorithms, which significantly changed some cracking workflows.

My passion for this book, or its “quick starter,” if you will, came from an ethically conducted penetration test I performed with full authorization at my school. This is something I am both hesitant and quite proud to acknowledge.

At the beginning, I simply wrote down everything I had learned from YouTube videos and online blogs. However, not long after starting my project, I realized I practically knew nothing about password security, and that small 10 to 15 pages I had written would never be enough if someone was looking for a professional guide to cracking passwords.

The other main driving force behind the book was the fact that while researching online, browsing forums, reading academic papers and white papers, watching videos, exploring blogs, inspecting presentations, and examining infographics, I did not find a single source that comprehensively covers and explains everything one needs to understand about offline password cracking. Literally. Not one.

Therefore, I continued my research and learned about password hashing algorithms, the security properties of hash functions, advanced hash cracking techniques, password analysis, attack optimization, and much, much more.

From the very beginning, I wanted to share this knowledge with the community because having access to a resource like this would have helped me tremendously when I first started learning password cracking.

I sincerely hope this work will be useful to both beginners and experienced professionals alike, and I look forward to hearing your thoughts and feedback.

I have also put together a little video to give you a little sneak peek into it. It is on Google Drive. It is the official domain, and you do not need to download anything. Here it is: https://drive.google.com/file/d/13LeysSZO8Mx-LGKt8UQjUGBKOYH...

If you are interested, the book is now publicly available on Amazon, and can be read for free with a Kindle Unlimited subscription: https://www.amazon.com/dp/B0GX36XRCD

Author here. RMUX started from a frustration: I've used tmux for years and got tired of scraping output with grep and sleeps to automate anything. So I rebuilt the multiplexer from scratch in Rust, with a programmable layer on top.

Two surfaces: a tmux-compatible CLI (~90 commands, your keybindings just work), and a typed async Rust SDK on the same daemon — stable pane IDs, structured snapshots, locator-style waits. The idea is Playwright-style automation, but for terminals.

Native on Linux, macOS, Windows (real ConPTY, no WSL).

Demos and docs at rmux.io. Happy to answer questions about the daemon protocol, ConPTY, or the SDK design.

We are working on an open-source .docx editor library for apps that need to edit Word documents in the browser. We just shipped 1.0.

A lot of existing approaches convert .docx into HTML and lose document semantics along the way. Our editor parses OOXML directly and uses its own rendering+layout engine to produce paged documents with html/css. Edits round-trip back to .docx, so you’re always editing the document, not its representation.

The core rendering engine is framework agnostic, with React and Vue ui adapters on top.

It’s Apache 2.0. Happy to answer questions.

Hi HN! We're Haakam, Michael, and Adi from AgentMail- a ycs25 company. We give AI agents their own email inboxes. Recently, we ran an experiment called Agent.Email. It's a signup flow designed specifically for AI agents instead of humans.

The inspiration came from a few comments we received when we did our seed launch a few months back. They all came from the very apt observation that agents not being able to sign up to a product made for agents without human credentials was ironic and unideal.

This is basically the thesis we built AgentMail on: The internet was made for humans exclusively, designed to keep machines out by default.

Every signup flow assumes a browser, a person reading a page, and clicking a confirmation link. Unless agents can't do that, they can't be first class users of the internet.

Agents can now get an email inbox by themselves. (This also means a lot of email nobody wants to read gets processed by AI instead of your inbox being cluttered with spam and slop)

Here's how agent.email works.

Agent needs an inbox and hits AgentMail via curl. Agent receives instructions via MD unless the request comes from a browser, in which case we use HTML.

Agent decides agent.email is useful and then hits the sign-up endpoint with its human email as a parameter. Agent receives a restricted inbox with credentials. Agent emails the human asking for an OTP. Human replies with the code, and the agent is claimed and restrictions are lifted. Until claimed, the agent can only email its own human and nobody else. Ten emails a day, and the signup endpoint is rate-limited hard by IP.

Right now it's a 1:1 mapping between agent and human. The next step is many-to-one, because one person running several agents in parallel is already very common.

Building agent.email also pushed us to revisit places in AgentMail where the default assumptions were built around the primary user being human. For example, the CLI outputs in a single column with consistent formatting because mixed delimiters are easy for a person to scan, but harder for an agent reasoning about structure. We also shortened messageIDs after agents started hallucinating completions on longer ones.

A few things we'd like the community's take on: is restricted-until-claimed the right trust model? Does agent self-signup feel useful in production, or is it mostly a novelty, and if it's a novelty now, what would make it actually useful? Should agent onboarding require human approval by default, or should some agents be able to fully self-provision? What do you think are some additional measures we can take for secure sign-ups?

I built this software to help users who need to do static code analysis for C/C++ codebase. This can help you to explore the ASTs interactively. It can replace the Clang ast dump completely and also you can search the code/ASTs in a structual way. For example you can search a function which matches specific name or number of paremeters.

At my work they provided a single Claude subscription for everyone on the team. To be honest I like kiro better as it provides a way better SDD management. But the company can't provide it and I can't afford it yet. Turns out I had the skill creator skill in my claude instance so I made use of it to create this Skill. I made it fully by using Claude but I wanted to make it open source, so I asked it to help me make tests and preparations for it, even a CI to run python tests.

Well, we got this results with it:

- Phase 2A: 67 static assertions (Python script, runs in CI)

- Phase 2B: 15 behavioral tests (live Claude Code session)

- Phase 2C: 53 generation quality checks across 3 end-to-end flows

All of these passed and the CI also passed (after a few tries).

I made it to suit my way of prompting and coding and based it off kiro's SDD management, but I want it to be publicly available and used by many people. According to claude some of the testers need to fit the following criteria:

1. Developer starting a real new project from scratch

2. Solo dev with an active side project (greenfield or partial codebase)

3. Team lead whose team uses multiple AI tools

4. Developer with an existing codebase and no written specs

5. Developer who actively uses 3+ AI coding tools

It's actually a blind test, no guiding, just try it if you can, I'd really appreciate your help.

The repo is here: https://github.com/FredAntB/Spec-Driven-Development

I made this game while working on a different project about teaching English spelling. I was reading about homophones and got struck by how much a homophone can transform the shape of a word, so I started experimenting with little games built on that.

I added a few more transforms, anagrams, verb/tense changes, but the answers kept coming out too obvious. I couldn't distort the word enough to make it interesting. The breakthrough was compound pairs. Jumping from one word to another through their compound (sea → horse, via seahorse) really obscures the path and that's when it suddenly got fun and unpredictable.

I've been sharing it with friends. I'm in the UK so mostly UK testers, fair warning that a couple of the homophones may lean British.

They've been playing daily and seem hooked, so it felt worth posting here. It's one puzzle a day mainly so I actually have time to hand pick puzzles that have a satisfying path. Today's puzzle is on the easy side but they can get really tricky. The name is from 'betwixt', the whole game is about moving between two words. I did clock afterwards that there's a 60s board game with the same name, but they're pretty different things.

Hi HN!

For the past few months I've been working up to this launch of Free Fonts - it's a collection of completely free, open source, and original fonts that can be used for any project, including commercial ones.

The collection has over 400 fonts in a variety of novel styles, from simple sans serifs to decorative handwritten and blackletter fonts. It will also continue to be updated and grow over time.

Designers and developers today have essentially two options when it comes to choosing and creating fonts. Either use a Google Font, which can be limited in terms of unique and novel selections, or pay a significant amount of money for font licenses from a few large players in the space like Monotype. The problem today is that it can be difficult to find a novel, unique font for an affordable price. Our hope is that this collection can be a starting point for solving this problem.

What makes this project different is that every font in the collection was generated completely by AI, and is a novel set of letterforms. This is what makes it possible for me to launch the project with confidence that these fonts can be freely used in any type of project.

The AI workflow behind this project is also accessible on the same site. Our model was trained on a variety of images across the internet and then runs a full pipeline to transform a consistent set of letters into a single downloadable TTF font file. It can be prompted from a text prompt, or a sample image that contains an image of some text.

Font licensing is a complex world, and I deeply believe that it is ripe for a change. My hope is that this launch can spark a new conversation on the future of typography and how it can be freely and easily used by designers and developers over time.

Hope that you enjoy, and would love your feedback about the project and also the fonts themselves.

Eric

Hey! I'm Gregory Klyushnikov, a former lead Android developer at VKontakte, Russia's Facebook. And I hate enshittification with a burning passion. I quit in 2016 because the mismatch in values with the new management started driving me crazy.

My core issue with Facebook, Twitter, Instagram, VKontakte, and other commercial, centralized social network services is that they all eventually drift away from "staying updated on your friends' lives" towards "getting world news", "communicating with businesses", "a town square", "a place to look at ads", "endless supply of brainrot", and all kinds of other things that involve the platform forcefully shoving strangers at you and you at them - I call such pivoted services social "media". If you want to just be with your friends on the modern internet, you're out of luck. (Yes, messaging apps are a stopgap seemingly everyone has settled on, but it's not a good solution.)

This gaping niche is what eventually got me interested in developing for the fediverse and why I started Smithereen in late 2019. My goal with this project is to eventually bring back that long-forgotten "early Facebook" experience when the platform just gets out of the way and lets you have fun with your friends and meet new people in groups. And to do it such that no one will take it away this time.

There are profiles with lots of fields, walls, groups and events public and private, photo albums with tagging, and more.

One important feature that's absent for now is global user search and, somewhat related to that, a database of educational institutions so you could put your school/college/university on your profile and be findable by your classmates. This is just something that's very hard to do in a decentralized system without partially centralizing it, although I have a few ideas that need experimental validation.

It's written in Java, it only has a few external dependencies (imgproxy, MySQL, and a web server of your choice), and it ignores most of the so-called "progress" that happened in web development over the last decade. The UI is a meticulous reproduction of VKontakte's pre-2016-redesign layout. It's fully compatible with Mastodon and other ActivityPub servers in the sense that its functionality is a superset of Mastodon's. Its client API is mostly compatible with VK's as well. A server for a few users should be able to comfortably run on a Raspberry Pi or a cheap VDS.

Unlike most fediverse projects, there is no "flagship" open-signups server because I have more interesting things to do with my life than running one of these; it's a serious commitment that fits neither my goals nor my personality. That said, I set up https://try.smithereen.software so anyone could try the thing with a temporary account (you don't need a real email either).

Looking forward to your feedback!

I’d be interested in feedback on the model, false positives, and whether the examples match drift people are seeing in larger repos.

I have used Codex & Claude Code for coding for a while, but how long a coding task will actually take? When I ask Claude Code to estimate, the result is often from training data, which is based on human speed. That’s why I built this tool, to estimate effort in ai agent speed. I run it every morning before I dispatch coding tasks to my agents.

What's in it: task sizing: auto-classifies XS to XL from the description, then runs PERT on that tier human-equivalent comparison: a per-task-type multiplier so you see the speedup METR p80 thresholds: warns when an estimate exceeds a model's reliability horizon wave planning: schedules independent tasks in parallel across a multi-agent fleet

The estimation data is from my daily coding tasks from past few weeks: per-runtime calibration: Opus 4.7, GPT-5.5, different models have different reliability horizons and costs per-task-type priors: backend, frontend, app development, docs, and brainstorm PR review: I usually let Codex and Claude Code review each other’s code, and the tool takes that into consideration a calibration loop that keeps me honest: dispatch data is validated at end of day by my coordinator agent

Try it: pip install agent-estimate, read the code https://github.com/kiloloop/agent-estimate/ , or the writeup https://kiloloop.com/agent-estimate/

Background on why we built Replay first instead of validation: [ https://dev.to/saferunai/why-we-built-replay-before-everythi... ] Working SDK in Python and TypeScript. Sub-50ms p95 on the check-action API. Currently onboarding the first design partners. Happy to answer questions in the comments.

Hey everyone - After lots of tweaking and tinkering to find what I like, sharing my favorite way to see my Claude Code statusline. Hope you like it too.

The linked GH gist is a Python wrapper around claudeline that pipes its output through a few transformations and adds custom behaviors like a true-1M context %, and a custom context window alert threshold with some emoji tweaks.

OSINTArena.com — a browser-based OSINT challenge game for practicing geolocation, image investigation, digital forensics, and clue-led research. It includes daily challenges, leaderboards, and user-submitted puzzles.

I'm experimenting with a way to make AI-assisted development easier to review later. I built a small Python/SQLite prototype and would like feedback.

Spread the word, its free for 1 employee. Lets help the small businesses!

This is an experiment/demo that I wanted to share and see what people think.

The main premise is that you can conjure anything and the game will do its best to produce such object with all the functionality and properties that would make sense.

It might look simple at first glance, but the underlying systems are complex. Create dragons you can fly on, spells, weapons, factories, ...