Relatr 0.2.x has been a long time coming.

This release is the result of a real engineering effort: not just shipping features, but stepping back, questioning assumptions, and redesigning one of the most important parts of the system until it matched the principles we care about. The center of gravity in this release is the plugin system, and with it, Relatr takes a major step forward.

In Relatr, plugins, or validators, are a big part of its essence. The core algorithm is based on two main components that each account for 50% of the final rank. One half is social graph distance. The other half is a set of validators. From the beginning, the idea was to make those validators configurable so anyone could decide what trust means for them and craft their own algorithm by composing that set.

Before this iteration, in the 0.1.x family, plugins in Relatr were written in TypeScript. That approach was powerful in theory. Anyone could write their own validator, extend the system, and adapt it to their own trust model. But in practice, the experience was not where it needed to be.

Writing a plugin meant navigating the codebase, understanding Relatr’s internal capabilities, and implementing logic directly in TypeScript. That is possible, especially today with LLMs helping people bridge gaps faster than ever. But the deeper questions remained unanswered.

How do you install a plugin from someone else?

How do you share one cleanly?

How do you publish a validator so others can discover it, evaluate it, and adopt it?

There was no satisfying answer. And because the plugin system lived in TypeScript, it also left the door open to bad tradeoffs: messy ergonomics, dependency creep, more attack surface, and a design that could easily become over-engineered in the name of flexibility. Every path forward seemed to point toward a solution that was heavier, more fragile, and less portable than what we wanted.

So we kept the problem in the back of our minds.

The goal was clear: build a validation plugin system for Relatr that would let anyone write plugins easily, share them easily, install them easily, and distribute them natively through Nostr itself. We wanted plugins to be portable. We wanted curation. We wanted the Web of Trust and Nostr’s distribution model to work together instead of living in separate worlds.

Then we found elo-lang.

Elo is a simple, well-designed, portable, and safe data expression language. It is purely functional, originally designed for no-code tooling, and excellent at describing data transformations in a concise and understandable way. When we discovered it, the first reaction was immediate: this could be the foundation for Relatr’s new plugin system.

It checked almost every box.

Portable. Safe. Expressive. Small enough to travel. Predictable enough to trust.

But once we started experimenting, we found an important limitation. Elo’s normal execution model is linear, and that is often exactly what you want. For Relatr, though, we needed something more expressive. We needed a way to describe multi-step processes. We needed plugins to declare when host-provided capabilities should be invoked: a Nostr query, a social graph operation, an HTTP-based NIP-05 resolution, and similar actions. We needed a clean way for the host to orchestrate those requests while keeping the plugin language itself safe and understandable.

That is what led us to fork Elo.

From there, we introduced two core operators: do and then.

The idea is simple.

Do declares that the host should execute a capability. For example, a plugin can say: perform a Nostr query, resolve a NIP-05 identifier, or inspect the social graph.

Then defines ordering. It lets authors compose multi-step logic in a natural sequence, where later steps can depend on data gathered earlier.

What we like most about this design is how little it feels like a bolt-on. The new operators fit naturally into Elo’s style. They feel close to the language that already existed. They preserve the elegance of the original while giving Relatr the expressivity it needed.

More importantly, the model is safe.

A plugin cannot just execute arbitrary code or invent arbitrary powers for itself. The capabilities available to a validator are defined by the host. In this case, by the Relatr instance that chooses to run it. Relatr ships with a built-in catalog of capabilities like nostr.query, graph.are_mutual, or http.nip05_resolve. If a malicious plugin tries to invoke something outside that catalog, such as an imaginary evil capability, nothing happens. The host simply does not provide it.

That design changes Relatr fundamentally. It turns Relatr into a framework.

Plugins become portable programs that are compatible depending on the version and capability surface of the host. The host decides what powers exist. The plugin can only ask for those powers, never exceed them.

A useful way to picture the flow is this: first collect, then execute, then provision, then result.

A plugin might say: first do a Nostr query to fetch kind 0 profile events; then extract the NIP-05 field from the returned metadata; then do an HTTP NIP-05 resolution; and finally return 1 or 0 depending on whether the resolution matches the target pubkey.

Notice how naturally that reads. We can explain the execution model using the same words as the operators themselves: do this, then that. That was intentional. We wanted plugin authoring to feel as natural and comprehensive as possible.

This architecture gave us more than safety and readability. It also unlocked performance wins.

Because plugins declare their required data statically, the host can understand the work up front. It can group similar capability calls, deduplicate requests, and avoid redundant executions. That improves synchronization and validation throughput without making plugin authors think about low-level orchestration. Authors describe what they need. Relatr decides how to fetch and provision it efficiently.

The result is a plugin language that is portable, safe, multi-step, expressive, and efficient enough to live comfortably inside a Nostr event.

That last point matters.

Once we had the plugin model, the next logical question was: how should these plugins be packaged and shared?

The answer was refreshingly simple. A plugin is bundled as a Nostr event.

The Elo expression goes in the event content. The metadata lives in tags: title, description, stable identifier, compatibility range, and other manifest details. The result is a regular Nostr event of kind 765, purpose-built for portable Relatr plugins.

This is where things start to get really exciting.

If plugins are Nostr events, then distribution becomes native to the same ecosystem Relatr already lives in. Plugins can be published to relays. They can be mirrored. They can be discovered. They can be curated. They can be forked. They can be grouped into packs. They can evolve through new versions. They can travel through the same open network that Relatr already uses.

In other words, plugin distribution stops being a side problem and becomes part of the protocol surface.

That opens the door to a plugin marketplace, and that is exactly where we went next.

But shipping a portable format was only part of the job. We also had to think seriously about the authoring experience.

A portable language is only as useful as the tools people have to write it well.

One of Elo’s original strengths is that it already works nicely in the browser. It compiles to JavaScript, and the upstream project includes a playground where people can learn the language, write expressions, and validate their syntax. That gave us an excellent starting point.

Still, there was a missing piece.

Elo by itself has no reason to know what Relatr is. It does not know Relatr’s capabilities. It does not know the host’s plugin constraints. It does not know what a valid Relatr plugin should look like. And we did not want to solve that by tightly coupling Relatr into Elo. We liked the separation. We wanted Elo to remain a general-purpose expression language and Relatr to remain its own system. Keeping them decoupled makes both easier to understand, easier to maintain, and potentially more useful across the broader Nostr ecosystem.

But decoupling alone does not solve authoring UX.

Writers still need confidence. They need validation. They need feedback before publishing.

That is why we built Relo.

Relo is both a library and a CLI. It bridges the authoring gap between Elo and Relatr without collapsing the two into one project.

On the web, it powers the publishing interface on the Relatr website, where users can write, validate, and publish plugins directly from the browser.

Locally, it works as a CLI, so plugin authors can write validators on their own machines, validate them, build artifacts, and publish them from the command line. That matters for regular publishers, but it also matters for LLM-assisted workflows. If you are iterating quickly with local files, prompts, and terminal tools, the full plugin lifecycle is available without having to leave your environment and move to a website every time.

And now there is another important piece in that authoring story: skills.

We wanted plugin writing to be accessible not only to experienced developers, but also to people working with AI-assisted tooling. So we created installable authoring skills that package the right context, concepts, and lifecycle knowledge into a form LLMs can use effectively.

That means a user who wants to write Relatr plugins with AI assistance can install the Relatr authoring skill as simply as running npx skills add contextvm/relatr. From there, they get a structured understanding of the plugin model: how to think in terms of bounded capabilities, how to structure multi-step programs, how to validate a plugin, and how to move from draft to a publishable Nostr event.

This matters because authoring is not only about syntax. It is about having the right mental model. A good plugin is not arbitrary code with network access. It is a bounded scoring program. It collects data safely, scores it clearly, and fits into a portable lifecycle that includes validation, packaging, publishing, installation, and tuning.

That is the real role of skills in this release. They turn the authoring experience into something teachable, repeatable, and much more accessible to people working with modern AI tools.

Two interfaces, one contract: web and CLI. And now, a third layer of support for AI-assisted authoring.

That made Relo, together with the new skills, the missing piece of the puzzle. The authoring loop is now much closer to end to end, while still preserving the elegance of the overall architecture.

And this release is not only about internals. The website has been upgraded to reflect the new reality of Relatr as a plugin-driven framework.

The documentation now covers the new plugin system, including writing, publishing, tooling, and specification. There is a new plugin marketplace where users can discover available plugins and install them directly into their Relatr instances from the website. The new home for all of this is relatr.net.

That is a major shift.

Relatr instances are no longer opaque boxes you configure indirectly and hope for the best. Now operators can manage plugins directly from the website: install, uninstall, enable, disable, and adjust weights to shape the algorithm their instance uses.

That last point is central.

Trust metrics should not be a black box.

With this release, it becomes much easier to see what algorithm is actually behind a Relatr instance. You can inspect the plugins, their weights, and the individual components contributing to a score. You can understand not just the output, but the composition behind the output.

Transparency for trust means no black boxes.

Looking back, this release was a genuine engineering journey. We designed a new plugin system for Relatr. We turned plugins into portable Nostr events. We discovered a remarkable expression language, then forked it carefully to meet the real needs of host-orchestrated validation. We created Relo to make authoring practical, ergonomic, and complete across both web and CLI. And we added skills so that even AI-assisted authors can work with the right concepts and constraints from the start.

None of this happened quickly, and that was the point.

At every stage we stopped to reconsider the tradeoffs: technical design, UX, safety, ergonomics, integration, and performance. We did not want to solve one problem by creating three worse ones. We also remained committed to one of Relatr’s original constraints: this software should still be able to run on modest hardware.

That remains true.

Relatr is still fully open source. It still aims to be efficient. It still aims to let people run their own Web of Trust engine without requiring a pile of infrastructure or a mountain of specialized expertise, especially when paired with ContextVM. And for people who want to run it themselves, all the details are available in the GitHub repository at https://github.com/ContextVM/relatr.

What has changed is the degree of freedom available to users.

Now anyone can compose an algorithm more like Lego than like a monolith. Anyone can write plugins. Anyone can publish them. Anyone can share them. Anyone can browse a marketplace, install validators, curate sets, and assemble trust models that reflect their own values and communities.

That is what this release is really about.

Not just new features, but a stronger answer to an old question: who gets to define trust?

Our answer remains the same. Not a platform. Not a hidden algorithm. Not a single authority.

Let a thousand trust algorithms bloom.

That was one of the earliest premises behind Relatr, and with the 0.2.x family it is more true than ever. The engineering is there for people to use, inspect, fork, and build on. The system is more transparent, more portable, and more shareable. The black box has been opened.

Relatr is now closer to what it always wanted to be: a tool for sovereign trust computation in an open network.

This release gets us materially closer to that future.