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

Notifications and vibrations on subsequent carbon messages despite using a separate client #1275

Closed
shtrom opened this Issue Jul 6, 2015 · 7 comments

Comments

Projects
None yet
2 participants
@shtrom
Contributor

shtrom commented Jul 6, 2015

I have noticed, for a few versions of the app (thought I can't recall when it started), that I receive a lot of notifications/vibration/Pebble push from Conversations, even when using another client for that conversation.

I am using OTR and Carbons. I remember from working on #649 that there was a check for messages from me being carbonned over to Conversation recently, in which case it wouldn't notify/vibrate/push to Pebble.

This doesn't seem to be the case anymore, or has the time period been reduced?

Possibly linked to #1255

@iNPUTmice

This comment has been minimized.

Member

iNPUTmice commented Jul 20, 2015

working very fine for me. I haven't used a second client for a longer period of time and just started again recently. it does exactly what I expect it to do. the timeout has not changed either.
I'm not testing the smart watch stuff though. that's your code. and I don't have a smart watch. I'm just testing this with regular notifications.

@shtrom

This comment has been minimized.

Contributor

shtrom commented Jul 21, 2015

On Mon, Jul 20, 2015 at 04:04:01PM -0700, Daniel Gultsch wrote:

working very fine for me. I haven't used a second client for a longer
period of time and just started again recently. it does exactly what I
expect it to do. the timeout has not changed either. I'm not testing
the smart watch stuff though. that's your code. and I don't have a
smart watch. I'm just testing this with regular notifications.

That's odd. I have the vibration from the mobile as well, so I wouldn't
thing it's linked to the smart watch issue. Are you using OTR?

Olivier Mehani shtrom@ssji.net
PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655
Confidentiality cannot be guaranteed on emails sent or received unencrypted.

@iNPUTmice

This comment has been minimized.

Member

iNPUTmice commented Jul 21, 2015

OTR messages should not be carbon copied anyway.

that there was a check for messages from me being carbonned over to Conversation recently, in which case it wouldn't notify/vibrate/push to Pebble.

that check doesn't prevent notifications for carbon copied messages but stops notifications from showing for an interval x after receiving a message sent from another resource.

Maybe what is happening is that your other client properly prevents carbon copies from being sent in OTR chats thus no messages from yourself are arriving at your phone. But the other party does not prevent carbon copies on OTR messages thus the 'garbage' messages arrive in Conversations and notify you. But without messages arriving from your other resource the 'grace period' does not get triggered.

@shtrom

This comment has been minimized.

Contributor

shtrom commented Jul 21, 2015

On Tue, Jul 21, 2015 at 12:53:22AM -0700, Daniel Gultsch wrote:

that there was a check for messages from me being carbonned over to
Conversation recently, in which case it wouldn't notify/vibrate/push
to Pebble.
that check doesn't prevent notifications for carbon copied messages
but stops notifications from showing for an interval x after receiving
a message sent from another resource.

Yes, but the Pebble notification is triggered by the new notification
showing up, so the behaviour should be the same, and indeed is as far as
I can tell.

OTR messages should not be carbon copied anyway.
Maybe what is happening is that your other client properly prevents
carbon copies from being sent in OTR chats thus no messages from
yourself are arriving at your phone. But the other party does not
prevent carbon copies on OTR messages thus the 'garbage' messages
arrive in Conversations and notify you. But without messages arriving
from your other resource the 'grace period' does not get triggered.

Right. This makes a lot of sense. I think the other client generally is
Pidgin, so I guess I'll have to check there.

Thanks for the hint!

Olivier Mehani shtrom@ssji.net
PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655
Confidentiality cannot be guaranteed on emails sent or received unencrypted.

@shtrom

This comment has been minimized.

Contributor

shtrom commented Jul 21, 2015

Right, see this message [0], and the few replies.

This one [1] is interesting:

To the contrary, I think we should definitely carbon-copy OTR messages. If you don't it'd be much more likely that an OTR message ends up only at the wrong instance which can't decrypt it. The instance tag support libotr 4 should make it handle this very well.

How does Conversations deal with this? Let users do a manual refresh, or do an automatic refresh? Or something else?

There is finally that [2], but looking at the pidgin-otr / pidgin code, I don't think they have a way for a plugin to set the no-carbon. I'll need to follow that up with Pidgin on this one, I think.

I'll try to check some other clients to see if this is reproducible.

[0] https://developer.pidgin.im/ticket/15508#comment:16
[1] https://developer.pidgin.im/ticket/15508#comment:19
[2] https://developer.pidgin.im/ticket/15508#comment:24

@iNPUTmice

This comment has been minimized.

Member

iNPUTmice commented Jul 21, 2015

imho the instance tag is meant for chat protocols that do not have the ability to prevent coping the message to all connected clients. xmpp has the built in possibility to avoid the data from being sent. the instance tag only helps you to discard messages / not break things.

Conversations specifically sends messages to the correct instance.

@iNPUTmice

This comment has been minimized.

Member

iNPUTmice commented Jul 21, 2015

Oh for general reference: https://github.com/siacs/Conversations/blob/development/docs/observations.md#off-the-record

This text is now over a year old but still accurate for the most part

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment