Confusing handling of unsupported message types

[mi5o]

One would expect unified handling of unsupported messages (until they are eventually handled). But this is not the case.

I would suggest to display something like "message type not supported" in a way clearly distinct from standard user messages.

Example 1

message: opinion poll (org.matrix.msc3381.poll.start)

displayed as:

Encrypted message.

Example 2

message: shared geo-location (m.location)

displayed as:

(not even hint of existence of such message)

---

(seen in foss-signed-31.10.2022-V1.apk running in LineageOS)

[ouchadam]

agreed :+1: for now I've applied a quick fix to simply ignore the unsupported events instead of providing a misleading "encrypted message"

https://github.com/ouchadam/small-talk/commit/0d0c3d55fe9a1e7c7dee7d4b319e1a2d4805c1b1

[mi5o]

my humble suggestion:

I've seen those "deleted" message surrogates in recent release. They look great. My idea is that in the same manner you could also indicate a reception of some not-yet-supported type of message. The same implementation class, the same look and feel, just different words.

If I am not wrong, with a very little effort you could decrease users' confusion. Also it is future-proof attitude, in case any future version or extension of Matrix protocol, or any bridging gate, spits out something unexpected by your app.

And if you manage to include the message type in the announcement, then users can request for new features, naming explicitly the type of message they would like to see implemented. Or vote for that.

[ouchadam]

having a dedicated message type with the ability to reveal the original raw content was my initial plan but there's a little bit of extra thinking needed to do it in a clean way

definitely still planned though!

[mi5o]

IMHO, for few nerds, like you and me, both JSON and XML (the "raw content") is quite a readable stuff. But for most users, it is just a messy blob, which they cannot interpret meaningfully. So I thought they perhaps just need some kind of indication, that the other side has sent them something they cannot read, so they can ask for resending the same, but in a less advanced form. Or they can decide, that it is not worth the effort (and, for example, skill the public opinion poll). In such case, displaying timestamp along message type (which is a simple and short string) might be sufficient. Or sufficient to start with, before you can put together your, more ambitious, solution.