Processed MessageCard message has no topic, preventing image cards from linking to Friends.

[wir3z]

Testing from the current tip of master (and from 2.5.0 Beta-1), the message cards fail to link to the Friends. Digging into the logs/flow, the logs, when this function is called for MessageCard , message.topic is null. If I hard code a topic that matches the one displayed from a MessageLocation message, then the code functions as expected.

fun processIncomingMessage(message: MessageBase) {
    Timber.i(
        "Received incoming message: ${message.javaClass.simpleName} on ${message.topic} with id=${message.messageId}")
    when (message) {
...
      is MessageCard -> {
        processIncomingMessage(message)

Not sure where to dig further to see what was missed.

[growse]

Is this on HTTP or MQTT?

[wir3z]

Sorry, should have clarified: HTTP

I've been testing the PR "status command", and noticed the logs show that the topic is blank for MessageCmd as well. For example, this is what is showing:

• 2024-04-25 16:44:02.434 I [DefaultDispatcher-worker-15] MessageProcessor/processIncomingMessage/340: Received incoming message: MessageLocation on owntracks/http/User with id=2bed2431
• 2024-04-25 16:44:02.441 I [DefaultDispatcher-worker-15] MessageProcessor/processIncomingMessage/340: Received incoming message: MessageCmd on with id=4e523927
• 2024-04-25 17:15:00.745 I [DefaultDispatcher-worker-10] MessageProcessor/processIncomingMessage/340: Received incoming message: MessageCard on with id=eb0d5167

It seems the incoming topic isn't being mapped to those.

[wir3z]

Ok, I see the issue. The override for HTTP is structured to only check the location message:
override fun onFinalizeMessage(message: MessageBase): MessageBase { // Build pseudo topic based on tid if (message is MessageLocation) { message.topic = HTTPTOPIC + message.trackerId } return message }

In 2.4, the trackerID was a field in the message base.

[wir3z]

I created a PR to add "tid" to the MessageCard. That would restore the behavior 2.4.x had.

The current architecture is keying off getContactId() which requires a topic to link the two. The online booklet should be updated to indicate the necessary "tid" field.

[growse]

So this is a little more complex than just adding the tid to the card message. Per the booklet, the card only contains name and face, the contact association should come from the message topic it's delivered on.

Obviously on HTTP, there's no built-in concept of a "message topic", so we use a separate JSON field called topic to carry what the topic would be. The tracker id is derived from that.

How are you generating card messages to send to the app? Can you see if they've got a topic field in the JSON payload?

[wir3z]

In order to get cards to work on 2.4.12, I had added a tid field to the card JSON payload (fully appreciate that was a deviation from the booklet documentation). This is my return payload:
card = [ "_type": "card", "name": "${member.name}", "face": "${member.name}.jpg").encodeBase64().toString()}", "tid": "${member.name}" ]

Right now there is no topic in the return MessageCard payload that I am sending back to OwnTracks. I suppose the "proper" way to match the booklet would be for override fun onFinalizeMessage(...) to parse the contact list for a matching name, and then recreate the return topic from that function with whatever the members trackerID is.

[wir3z]

I ran some additional tests, and without tid in the messageCard JSON response, iOS won't display image cards either. As soon as I add that back to the JSON, images appear on the map.

[ckrey]

I can confirm cards were not supposed to work in the iOS app in HTTP mode. Using a tid in the card message creates a pseudo-topic owntracks/http/<tid> like it does for location or transition messages. So this is works though not intended to.

The apps are not designed for HTTP...

[wir3z]

Since it does currently work on the published iOS and Android versions on HTTP, is there any reason it cannot be documented that it does and add back the changes to Android?

Seems odd to restrict HTTP functionality that is working based on the premise the original architecture was designed with only MQTT in mind.

[wir3z]

Thoughts on this one? Is there a better way that you'd prefer this gets implemented (that also works with the iOS)?