Manual device verification e.g. for bots like Mjolnir

[andybalaam]

When we start excluding unsigned devices then all users in a room, including bots, will need to verify their devices.

Some bots, e.g. mjolnir don't currently provide a way to verify their devices, and the underlying matrix-bot-sdk does not provide a way of doing this. The preferred way would be to supply a Recovery Key during bot setup, but without support in matrix-bot-sdk this would be quite a lot of development work to do.

So, we want an easier way of manually asserting that a device is verified. We think the simplest way would be for the bot to print out its ed25519 key on startup, so we can supply it to another client.

In Element Web, provide a dialog (probably in an "Advanced" section) that allows pasting in a client's ed25519 key to verify it.

[andybalaam]

This is a proposed solution to the problem described in https://github.com/element-hq/element-meta/issues/2709

[andybalaam]

As an alternative to using Element Web, you can try my command-line tool mx. I have just added the ability to do manual verification: https://codeberg.org/andybalaam/mx#example-manual-verification-of-a-different-device

[Half-Shot]

@andybalaam

As an alternative to using Element Web, you can try my command-line tool mx. I have just added the ability to do manual verification: https://codeberg.org/andybalaam/mx#example-manual-verification-of-a-different-device

does your tool use sync v2? Could we use this with appservices?

[andybalaam]

does your tool use sync v2? Could we use this with appservices?

@Half-Shot it doesn't do any kind of syncing, so should work for bots that rely on sync v2 just as well as others.

I don't know much about appservices, so I'm not sure about that - let's chat about that over DM and report back here if we find a useful conclusion.

[nightah]

Also interested in the outcome of your conversations, is it possible to use the tool to verify a bot account that's registered via an app service?

Unless I'm mistaken, these accounts do not log in with a password, so I'm not quite understanding how your tool would work in that scenario.

[andybalaam]

Hi @nightah , we haven't come to any firm conclusions yet, but @Half-Shot did manage to get mx to go past the login step using the new code I added to accept an access token instead of username and password.

To restore an existing login (i.e. use an access token) in mx, try:

$mx restore --help
Use an access token to restore an existing login session

Usage: mx restore [OPTIONS] <HOMESERVER_URL> <USERNAME> <DEVICE_ID> <ACCESS_TOKEN>

Arguments:
  <HOMESERVER_URL>  
  <USERNAME>        
  <DEVICE_ID>       
  <ACCESS_TOKEN>    

Options:
      --store-location <STORE_LOCATION>
          Location of the crypto store (Linux default = ~/.local/share/mx/store)
  -h, --help
          Print help

(If you're running mx from its source directory, replace mx above with cargo run --

Half-Shot said this to me:

I ran a curl --data '{"type":"m.login.appservice", "identifier": {"type": "m.id.user", "user": "hookshot"}}' http://localhost:8008/_matrix/client/v3/login to get my mx identity. I ran cargo run -- restore ... with the details ...Various amounts of recovery commands that all failed. http://localhost:8008/client/v3/keys/query was missing the mx identity. cargo run -- identity reset worked cargo run -- recovery reset-key worked cargo run -- recovery upload worked cargo run -- recovery status shows happy happy but WITH errors:

(I said the errors ("JoinError reason is not a panic") were ignorable.)

So it might be worth experimenting with.

[nightah]

I did have a bit of a play, and a lot of commands worked, but it seemed that when attempting to verify/reset a device in question, I was not able to.

Working:

• cargo -- run restore
• cargo --run identity status
• cargo --run recovery reset-key
• cargo --run recovery status
• cargo --run recovery upload
• cargo --run recovery download
• cargo --run status

Not working:

• cargo --run identity reset

2025-07-29T08:29:36.888860Z  INFO mx::restore: Restored session with device id DEVICEID
Error: the server returned an error: [400 / M_UNKNOWN] One time key signed_curve25519:AAAAAAAAAA8 already exists. Old key: {"key":"hgB...","signatures":{"@hookshot:authelia.com":{"ed25519:DEVICEID":"CIh..."}}}; new key: {'key': 'C4R...', 'signatures': {'@hookshot:examplecom': {'ed25519:DEVICEID': 'mdd...'}}}

• cargo --run identity verify-device - Error: supplied fingerprint does not match (this is despite using the key returned from keys/query.

It also seemed that when I hit _matrix/client/v3/keys/query for the bot user, which was registered via an app service, it returned like such, both before and after running recovery commands.:

"device_keys": {
  "@hookshot:example.com": {
    "DEVICEID": { ... }
  }
},
"master_keys": {},
"self_signing_keys": {},
"user_signing_keys": {}

Unfortunately, my knowledge of Synapse APIs is very basic, so I have so far abandoned the idea of trying to get Hookshot/App services to verified. Happy to discuss on Matrix if you have any suggestions, though #[email protected].

[andybalaam]

Hmm. I don't understand this, I guess because I don't know much about how appservices work. I'm hoping @Half-Shot will be able to make progress and/or he will grab me to help him make progress :-)

[nightah]

@Half-Shot and @andybalaam, apologies for the direct ping. I'm hoping to revive this topic to see what can be done to progress this.

Is there any additional testing or information that I can capture and provide? I guess the outstanding question is how appservices differ from a normal user and why something like mx doesn't appear to work which likely is tied to the first question.

[andybalaam]

Hi @nightah I'm afraid I don't know any more, and I don't have time to investigate appservices at the moment.