Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Confusing handling of unsupported message types #238

Open
mi5o opened this issue Nov 1, 2022 · 4 comments
Open

Confusing handling of unsupported message types #238

mi5o opened this issue Nov 1, 2022 · 4 comments

Comments

@mi5o
Copy link

mi5o commented Nov 1, 2022

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
Copy link
Owner

ouchadam commented Nov 5, 2022

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

0d0c3d5

@mi5o
Copy link
Author

mi5o commented Nov 7, 2022

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
Copy link
Owner

ouchadam commented Nov 7, 2022

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
Copy link
Author

mi5o commented Nov 7, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants