Skip to content
This repository has been archived by the owner on Jan 27, 2024. It is now read-only.

Self sent messages won't display on non-Pidgin clients #382

Closed
EionRobb opened this issue Apr 21, 2017 · 12 comments
Closed

Self sent messages won't display on non-Pidgin clients #382

EionRobb opened this issue Apr 21, 2017 · 12 comments

Comments

@EionRobb
Copy link
Contributor

Clients such as Adium or bitlbee won't display self-sent messages from other devices in group chats. This is due to how the PURPLE_MESSAGE_SEND flag is handled, that its not possible to know whether a message was sent from the same device as where libpurple is running or whether it's from a different one.

A new PURPLE_MESSAGE_ flag was added in 2.12.0 to support this, PURPLE_MESSAGE_REMOTE_SEND

This flag is supported in recent versions of bitlbee, but not Adium (or other clients) yet. Instead, they look for the PURPLE_MESSAGE_DELAYED flag.

Consider adding flags for both PURPLE_MESSAGE_DELAYED and PURPLE_MESSAGE_REMOTE_SEND when displaying self-sent messages in a group chat.

@dequis
Copy link
Contributor

dequis commented Mar 19, 2018

So I was looking into this because it turns out no self-messages work in bitlbee, not even private ones (you can mark #427 as a dupe of this). Sadly this isn't as easy as adding some flag.

For private messages the mechanism may be slightly different to PURPLE_MESSAGE_REMOTE_SEND but the concept is the same, just signal that this message is displayable and not an echo of something the user wrote locally. The problem is that all local and remote self-messages in telegram look the same.

Attached four backtraces for each situation. That was going to be part of this comment but it's verbose and redundant, just shows that all types of messages, even those written from pidgin, are actually displayed when received back from the server.

I don't know, is there a reasonable way to flag only messages written by clients other than ours?

@spacepluk
Copy link

I get self-messages on bitlbee with purple-hangouts.

@BenWiederhake
Copy link
Collaborator

Should be fixed by v1.4.2, specifically 38d6ac2, credit goes to @himselfv. Feel free to reopen if it doesn't work.

@dequis
Copy link
Contributor

dequis commented Aug 31, 2019

That doesn't seem to be using PURPLE_MESSAGE_REMOTE_SEND at all though

@BenWiederhake
Copy link
Collaborator

You're right, my fault.

PRs welcome.

@BenWiederhake BenWiederhake reopened this Aug 31, 2019
@dequis
Copy link
Contributor

dequis commented Aug 31, 2019

I still don't really know how to determine that this flag should be set, AFAIK tgp_our_msg() returns true for both messages sent from this instance and messages sent from remote instances.

And I don't really understand what is being improved by the linked commit - extending the existing flags to encrypted chats i guess?

@dequis
Copy link
Contributor

dequis commented Aug 31, 2019

Actually reading my older comments here, this may have fixed the problem for groupchats (but not for private messages), need to run it and test

@arcadedroid
Copy link

I just tested this, I don't see my own messages on Bitlbee.

@dequis
Copy link
Contributor

dequis commented May 9, 2020

In groupchats or private messages? The latter didn't change at all.

@arcadedroid
Copy link

Group chats.

@BenWiederhake
Copy link
Collaborator

If anyone feels like implementing this enhancement, it might be a better idea to direct your energy to tdlib-purple, which might already have this enhancement. For now, there seems to be nobody who implements any enhancements for telegram-purple, so I'm closing all "enhancement" issues.

Didn't someone say that it's just about adding PURPLE_MESSAGE_REMOTE_SEND somewhere?

@dequis
Copy link
Contributor

dequis commented Sep 27, 2020

Didn't someone say that it's just about adding PURPLE_MESSAGE_REMOTE_SEND somewhere?

Yeah but with the way telegram-purple is written and routes messages internally, that's non-trivial

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

No branches or pull requests

6 participants