Send messages with mentions (tagging users)

[Noorquacker]

Hello, is there any way to send messages with tags in them (like @Noorquacker) and receive those messages?
I notice that in dbus, when someone is tagged, the message contains the Unicode object replacement character. I did notice that Android signal backups show this, too, but I see no way to send and receive tags, I only get the object replacement character

[exquo]

These are called "mentions" in Signal's parlance.

Looks like dbus output does not currently contain info about them, see #491. Mentions info is printed out in JSON and regular output though.

I think sending a message with a mention from signal-cli is not currently supported either.

[AsamK]

Exactly, could be implemented like this:

• Find indices of each object replacement char in message and create mentions for them (would require number of OBJ chars to match number of --mention arguments)
  signal-cli send +xxxxx -m 'Hi , bar' --mention +NUMBER_MENTION
• Alternatively more in line with the underlying signal protocol, which specifies start index and length for each mention
  signal-cli send +xxxxx -m 'Hi , bar' --mention 3:1:+NUMBER_MENTION
  I'm leaning more to the second option.

[Noorquacker]

How would this work in dbus? Would a separate string argument (forgive me, I'm not a dbus expert) be provided that lists all that out?
To be honest, as someone that just makes Signal bots with signal-cli, all I'd need is a single string passed to and from dbus containing everything wrapped up in JSON, but that'd break literally every dbus tool that uses signal-cli. I'd be open to using JSON for mentions in dbus, though

[exquo]

I'm leaning more to the second option.

• Con: the index is redundant - it can be inferred automatically (like in the first option); the length is even more redundant - it's always 1, IIUC.
• Pro: "more in line with the underlying signal protocol" :)

The latter might be a good reason to choose it though: if the meaning of e.g. 'length' changes in the underlying protocol sometime later, signal-cli would not have to make backwards-incompatible syntax changes. If not for that, the first option is certainly more logical. Given that signal-cli is probably mostly used by other programs / tools (i.e. not by people manually typing the commands), it's probably not a big deal to let those tools handle the redundancies automatically.

[exquo]

@Noorquacker JSON refers only to signal-cli's process output, not its output through dbus. You can provide input (i.e. commands) to signal-cli through dbus. You can also get signal-cli's output through dbus, but it won't be in JSON format; it's in dbus's own format. I know, this might be confusing when you're just starting to use it. See this comment for clarification on input/output formats, and, of course, the docs on the project (readme, wiki, etc).

You can already get the mentions in signal-cli's JSON output. Sending mentions (either through dbus or not) or printing out mentions in dbus output is not yet available.