#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 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. @ #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

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

Been heads down on yunohost-mcp since the last update and this one's a milestone for me: your AI agent can now request a signature for high-risk operations and it actually reaches your phone. No copy-pasting a confirmation ID into a terminal, no clicking through a config panel. The agent asks, your signer prompts, you tap approve, done. Took a fair bit of digging to get there (turns out ASCII QR codes and webadmin panels do not mix, and nostr-sdk had a quiet bug hiding in the relay discovery this whole time), but the NIP-46 pairing flow is solid now: scan a link, paste a bunker URI, whatever your signer supports. This is the piece that was missing to make agent-driven server administration actually feel safe rather than just fast. Owner approval was always the point. Now it works the way it was supposed to from the start. https://github.com/imattau/yunohost-mcp #nostr #nostrdevs #yunohost #selfhosted #AI #agents #nostrblog #yunohostmcp