I’ve been working on something new: **NScript**.

It’s a small, statically typed scripting language built specifically for Nostr.

Instead of treating Nostr as a library bolted onto another language, NScript makes things like events, relays, signers, filters, permissions and NIPs part of the language itself.

The idea is to make Nostr automation and app logic easier to write, easier to audit, and harder to get subtly wrong.

It’s still early, but it can already parse and type-check scripts, compile them to an intermediate form, and run them against capability-controlled hosts. Support is growing across NIPs including NIP-17, NIP-44, NIP-47, NIP-59, NIP-65, NIP-77 and others.

I’m also starting to look beyond individual NIPs at higher-level protocols like **Concord**, which is exactly the kind of thing NScript should eventually be able to script cleanly.

Repo:
https://github.com/imattau/nscript

Still experimental, but it’s starting to feel like a real Nostr-native runtime rather than just another SDK.

#nostr #nostrdevs #nscript #nostrblog #scripting #development #nips #concord #blossom

Big update to **npack** today.

npack is a Nostr-native package manager where releases are signed by Nostr keys, discovered through relays and stored as content-addressed `.npk` packages on Blossom.

The latest work adds some important pieces:

• a local package catalogue with `npack refresh`, `search` and `info`
• a background `npackd` service so graphical app stores and other tools can use npack without needing to understand Nostr
• proper transaction progress, cancellation, rollback and recovery
• separate user/system daemons with PolicyKit authorisation
• AppStream metadata support for Linux software stores
• Nix integration has now been tested against real npack releases

v0.3.0 is being prepared now.

The interesting bit for me is where this is heading: Nostr can handle software discovery and publisher identity, Blossom can handle the actual package storage, while npack provides the package management layer on top.

Still early, but it is becoming a fairly complete stack.

https://github.com/imattau/npack

#nostr #npack #linux #opensource #nostrblog

NostrHost has moved forward quite a bit over the last few days.

The biggest change is that the native app system is starting to feel real. Apps can now be discovered, installed, updated, moved, backed up and restored without leaning so heavily on the old YunoHost model.

Nsites are also starting to become a proper part of the platform. They can now be discovered alongside apps in the catalogue, which makes them feel much less like a side feature and more like part of the normal hosting experience.

The Nostr control side has also been pushed further, with more of the server’s identity, permissions and admin actions flowing through the same model.

There have been plenty of smaller improvements too, including better catalogue handling, multi-user app support, cleaner admin settings and more work removing older YunoHost dependencies.

Still early, but it is starting to feel much more like one platform now.

https://github.com/imattau/nostrhost

#nostr #selfhosting #opensource #yunohost #nostrblog #nostrhost

#nostrhost #nostr #nostrdevs #selfhosting #nostrblog

Core Lightning is now packaged for YunoHost and up and running.

https://github.com/imattau/core-lightning_ynh

Even better, the existing Alby Hub YunoHost package successfully connects to it. That gives us a working self-hosted stack:

Bitcoin Core → Core Lightning → Alby Hub

The goal is to make running your own Bitcoin + Lightning infrastructure much easier through YunoHost and the Nostr Catalog.

⚠️ **Important:** Core Lightning can hold and move real Bitcoin. This YunoHost package is new and should be considered experimental. Bugs, configuration mistakes, failed backups or loss of Lightning node state can result in loss of funds.

Start with testnet where possible. If using mainnet, only use funds you can afford to lose and make sure you understand Lightning backups and recovery first.

Core Lightning:
https://github.com/imattau/core-lightning_ynh

Alby Hub:
https://github.com/imattau/alby-hub_ynh

Install through the Nostr Catalog:
https://github.com/imattau/nostr_catalog_ynh

#nostr #bitcoin #lightning #alby #yunohost #selfhosting #nostrdevs

Another piece of the self-hosted Bitcoin + Lightning stack is up and running on YunoHost.

₿ Bitcoin Core is now packaged and working:
https://github.com/imattau/bitcoin-core_ynh

It provides the Bitcoin backend for the Alby Hub YunoHost package, allowing more of the stack to run locally on your own server.

For now, this package is only available through the Nostr Catalog:
https://github.com/imattau/nostr_catalog_ynh

Next up: Core Lightning.

The Core Lightning YunoHost package is already in testing. I’m waiting for Bitcoin Core to finish its initial sync so it can be properly tested against the local node.

The stack is coming together:

Bitcoin Core → Core Lightning → Alby Hub

All self-hosted. All manageable through YunoHost.

#Bitcoin #Lightning #YunoHost #SelfHosting #Nostr #NostrDevs #nostrblog @Alby

⚡ Alby Hub is now available for YunoHost through the Nostr Catalog.

Alby Hub gives you a self-hosted Lightning wallet and node, with Nostr Wallet Connect built in. The standard setup uses its embedded LDK node, so you don't need to run Bitcoin Core, LND or Core Lightning separately.

There's a bit of history here.

Alby Hub was proposed for the official YunoHost app catalogue in February 2025. It wasn't rejected because of a packaging or technical problem. YunoHost chose not to include it because of its policy towards cryptocurrency apps, with the proposal closed with: "sorry we don't endorse crypto stuff here."

That's exactly the sort of gap the Nostr Catalog can fill.

The new YunoHost package keeps the normal YunoHost installation, service management, HTTPS, upgrade and backup experience, while allowing software outside the scope of the official catalogue to be discovered and installed.

And thanks to the YunoHost MCP, this one went from idea → package → testing → fixes → published → running remarkably quickly.

Package:
https://github.com/imattau/alby-hub_ynh

Alby Hub:
https://github.com/getAlby/hub

Available now through the Nostr Catalog.

@Alby

#YunoHost #Nostr #Bitcoin #Lightning #AlbyHub #NWC #SelfHosting #NostrDevs #nostrblog

Another piece of the Armada stack is now packaged for YunoHost.

**Armada AV** provides the optional voice/video backend for Armada communities, using LiveKit for calls while keeping the broker blind to the conversation itself.

Designed to run alongside the Armada YunoHost package.

[github.com/imattau/armada_av_ynh](https://github.com/imattau/armada_av_ynh)

#Nostr #YunoHost #Armada #SelfHosting #NostrDevs #nostrblog

@Derek Ross @Alex Gleason @chad

Managing my YunoHost instances is getting ridiculously easy thanks to the YunoHost MCP.

App packaging is now pretty much unattended. I can point an agent at an app and it can build the YunoHost package, manage the repo, install it on a real server, test it, inspect failures, fix them and keep trying until it works.

Once working, it can publish the package to the Nostr catalogue and handle future upgrades as well.

The MCP also makes general server management much easier. Agents can check services, logs, apps, backups and upgrades, while the more sensitive operations still require approval.

I'm mostly choosing what I want done rather than doing the repetitive work myself.

https://github.com/imattau/yunohost-mcp

https://github.com/imattau/yunohost-mcp_ynh

https://github.com/imattau/nostr_catalog_ynh

#yunohost #selfhosting #nostr #mcp #ai #nostrdevs #nostrblog

Finally - when I type #nostr into the app catalog on Yunohost - a variety of apps display... OK - I've packaged almost all of them - and they only appear on the #nostr_catalog .... but it's a start.

A fair bit of progress today on bringing Nostr identity properly into YunoHost, and tying it into the YunoHost MCP work.

Nostr login is now working end-to-end on a real YunoHost install. Existing users can link a Nostr identity and sign in using NIP-07 or NIP-46, without removing normal password login. There's also NIP-05 identity support and account management for linking/unlinking keys.

But the more interesting part is where this connects with AI agents.

yunohost-mcp already authenticates agents using Nostr keys. The work today pushes the security model further: the network-facing MCP runs unprivileged, privileged YunoHost operations go through a constrained local broker, and access can be tied back into YunoHost users/groups and explicit scopes.

So instead of giving an AI agent something close to root access and asking it to behave, the aim is to make the server enforce what that identity is actually allowed to do.

High-risk operations can go another step again: system upgrades, restores, firewall changes, user deletion and similar actions can require a separate NIP-46 approval from the server owner. The agent requesting the operation cannot approve it itself.

The longer-term idea is becoming clearer:

Nostr identity → YunoHost identity → groups/scopes → MCP tools → constrained privileged operations → human approval where required.

Humans and agents can have identities, belong to groups and be given only the capabilities they actually need.

Still experimental, but quite a bit of it is now running rather than just being a design.

[yunohost-nostr-auth](https://github.com/imattau/yunohost-nostr-auth)
[nostr_auth_ynh](https://github.com/imattau/nostr_auth_ynh)
[yunohost-mcp](https://github.com/imattau/yunohost-mcp)
[yunohost-mcp_ynh](https://github.com/imattau/yunohost-mcp_ynh)

#nostr #yunohost #selfhosting #mcp #ai #nostrdevs