Oak: ONS-1: Simple Bot Interface

status:draft since:v0.3.2

Goal

The goal is to allow simple low-latency interactions with an LN Node via a bot-like interface.

Definitions

Owner: the Nostr user from whom the bot accepts commands

Pairing: the process by which the Owner info (pubkey, relays) is configured in the bot

Architecture

The bot has an LN client and a Nostr client. The LN client has sufficient permissions to query data, create and pay invoices.

NIP-04 DMs from the owner are considered commands. The bot executes the commands and returns the result as a DM to the owner.

All other Nostr events, as well as DMs from other pubkeys, are ignored.

The bot holds no state.

Supported Commands

Every command has a one-letter alias consisting of its first letter. The commands are not case-sensitive. For example, all these commands are equivalent: b, B, balance, Balance.

balance: check the LN balance
create <amount>: create a new invoice for the specified amount of sats
describe <invoice>: describe a BOLT11 invoice
help: print an overview of the supported commands
pay <invoice>: pay a BOLT11 invoice
send <lightning-address> <amount>: send the specified amount of sats to the specified LN Address
version: print the bot an LN node version

Threat Scenarios

Commands from Non-Paired Pubkeys

These not even received by the bot, because its Nostr client specifically subscribes to NIP-04 DMs from the owner.

Even if a rogue relay were to send such events, the bot re-checks the sender pubkey before processing an event.

Denial of Service from a Nostr Attacker

See above. The bot only accepts events from its owner, no other events are received or processed.

Command Replay by Rogue Relay

A rogue relay could re-send the same DM event over and over.

The bot keeps track of the processed events by tracking the event ID. This makes sure each valid command is only processed once, even if re-played at a later date.