Add slash commands

[staab]

No description provided.

[alexgleason]

@JSKitty added slash commands to Concord. Might be worth comparing notes.

[JSKitty]

Aye aye, both Vector and Armada support this proposal: Bot Commands & Manifests:
https://gitworkshop.dev/soapbox.pub/relay.ngit.dev/armada/tree/main/NIP.md#nip-xx

This is designed to port the vast majority of Discord-like Slash Command functionality to Nostr in a modular and cross-client standardised way, I also have plans to extend it with optional enhancements, like Discord and Telegram's "Components System" for building mini composable UIs.

Highly encourage taking a look, I will probably propose this if we're fully happy with it.

bot-manifests-demo.mp4

[staab]

Thanks guys! It would be nice to converge. I've read the spec, and the core behavior is pretty much the same, with only one critical difference (see below). Here are some things I don't like, just to get them out of the way:

• json in json 😩
• The text is incredibly long (6x) and contains a lot of unnecessary stuff
• I don't think the bot attribute on kind 0 solves anything. If you publish a manifest, that's an indication that you support commands right? I think it also precludes interesting hybrid manual workarounds — for example, a community organizer could post a command, use a special purpose interface to surface them, and then respond manually. They don't have to be a bot to participate in the flow.
• A single manifest instead of an event per command means that all commands by a given person have to be published to the same places. But some commands might make sense in different contexts (see the end of my PR for two examples).
• Disambiguation is via tag, not included in the command itself, which undermines the claim that commands are human writable without assistance. Also, behavior tags often end up ambiguous (that's the justification the draft nip itself gives for not using p). In this PR, disambiguation is in the command itself (and likewise optional).
• Since bot is not single-letter, there's no way to listen for commands without scanning everything (this PR doesn't do that either, see below for a nice middle-ground solution that doesn't require the composer to add a tag).
• A lot of the prose doesn't exactly prohibit creative use cases, but they are pretty coupled to the concord use case. For example, a bot reply might not be a message (it could be an email, a task, a reaction, there may be multiple, etc). Leaving this commentary out would allow implementers to get crazy.

I will admit that these are mostly nitpicks. The main gap is that the armada nip has no targeting. This is important both for users and for executors.

For executors, the only affordance in armada's version for filtering messages is to subscribe to everything in a given context and filter by parsing the content (this is at least wasteful; in broadcast social media contexts this is prohibitively expensive). This PR allows the bot to publish a scope in its manifest (it only listens to a particular kind, certain authors, a particular room, on a certain relay), which allows the bot to maintain a much narrower filter without requiring users to publish a particular tag.

Just as important, publishing command scope in a machine-readable way allows clients to hide or show commands depending on whether the event it's about to publish actually will match a command. This allows us to have different commands show up in different contexts.

This could easily be added to Armada's NIP, but in any case would require an update to existing implementations. I'm not in a position to dictate anything here since I'm just starting my implementation, but given the limitations I've pointed out, would you all be willing to consider migrating to something more nostr-ish?

[JSKitty]

json in json 😩

Fair enough, but we are using Nostr, a protocol based on JSON. If it were my decision, the protocol wouldn't use JSON at all haha, I prefer minimal compact binary constructs.

The text is incredibly long (6x) and contains a lot of unnecessary stuff

Improvements are welcome! My clanky wrote the documentation, I was more focused on the functionality itself, which is now deeply proven in multiple clients and loved by many users, used by many bots, etc.

I don't think the bot attribute on kind 0 solves anything. If you publish a manifest, that's an indication that you support commands right?

By integrating the Metadata NIP's bot tag, clients have a very clean way of determining which profiles support Commands (which, obviously, should only be bots), this massively reduces the amount of REQs needed to synchronise the Bot Manifests of the bots within a given defined space (let's say, Communities, DMs, etc), in most cases, a very large community may have <1% of total members as Bots, as such, you only need to request for potential Bot Manifests from that <1% of Bot accounts, since most clients should be syncing that tag anyway, this effectively makes it free to "know which accounts may resolve bot commands" and to fetch them in bulk upon Slash invocations on a debounce.

I do not believe a regular (non-bot) account should be permitted to use Bot Manifests, this would be a serious vulnerability enabling deeper phishing possibilities, as well as presenting a generally awful and confusing UX. Users would not know what is truly a Bot or simply scam/spam accounts submitting manifests that look like a genuine bot. By forcing bots to use the bot tag, clients can at least display a clear distinction between "Humans" and "Bots" for the vast amount of circumstances.

A single manifest instead of an event per command means that all commands by a given person have to be published to the same places. But some commands might make sense in different contexts (see the end of my PR for two examples).

This is true, and something I've planned as a future addition for our spec, but this can be added to the existing spec. The current spec is based on "public-yet-space-scoped commands", but ideally, some kind of bi-directional commands negotiation could be added which allows bots to return specific commands and parameters / options / choices based on specific circumstances (perhaps using a Bot Command in the context of a thread reply could yield different options, same for the difference between DMs and a Community, or the difference between a Roleless user and an Authoritative user, etc), very much welcome ideas towards achieving this, though, it's a great addition. 🙏

Disambiguation is via tag, not included in the command itself, which undermines the claim that commands are human writable without assistance.

This is interesting, I suppose there's no real issue with adopting your approach with putting bot pubkeys in-command when a targeted command is necessary.

I think this should remain optional, as not every context requires stuffing a bot's npub within the text (in DMs or in certain Communities).

Since bot is not single-letter, there's no way to listen for commands without scanning everything

In the current usage of our spec, this is by design (it's mainly used in encrypted communities/groups, where there is no relay-level filtering of commands), but for fully public plaintext commands, I can see your point, I think we can extend the spec to fully support relay-level scoping and filtering, then we have a single unified framework for bots across all communications NIPs, very ideal! 🙏

[fiatjaf]

Don't you mean the inboxes of the service provider?

[staab]

No, but I should clarify this. By command I mean command definition, so outbox. But invocations should go to the executor's inbox.

[fiatjaf]

This is great.