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
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
❤️1