search

xmppjs / hubot-xmpp

XMPP adapter for Hubot
181 stars 103 forks source link

Handling of repeat messages at xmpp login in persistent chat room #104

Closed krutaw closed 8 years ago

krutaw commented 8 years ago

When using a persistent chat room for xmpp, there is a global setting that determines whether or not the last x messages are re-sent. This is obviously a big win feature for actual users. That being the case, those last x messages are then consumed by hubot as new messages.

I would like to request a feature to handle the incoming messages so that duplicate events are not fired off for Hubot. One idea of how this could become a reality would be to store the last say 20 messages that were received in the brain and roll them automatically as a new message is received if it's not already in the brain. That's just one idea, I have no doubt that you fine folks are smarter than I and probably even have a better idea on how it could be handled.

As a side note, thanks so much for all of your hard work and for taking the time to read this.

markstory commented 8 years ago

@krutaw Is the jabber server replaying the last 20 messages in the channel as people join, causing the bot to think the messages are new? Or is the replay happening when the bot rejoins?

krutaw commented 8 years ago

@markstory You had it right on the latter. The issue happens when the hubot rejoins the channel after having restarted.

markstory commented 8 years ago

So how would it know what messages had been seen? By default hubot doesn't have persistent storage.

krutaw commented 8 years ago

Too true, however, if this is a feature that can be enabled if and only if a brain is present, then the idea that I mentioned actually determines that. If Hubot has seen the message in order to store it in the brain (and knock a message out of place by result), then it's been seen. Otherwise, if there's not a brain the entire logic loop could be skipped. Crazytalk?

markstory commented 8 years ago

Well there is always a brain, its just not always durable.

krutaw commented 8 years ago

Good point. Would it make sense to have that as an option so that you can enable ignoring of the repeat messages if you're using a durable brain?

markstory commented 8 years ago

I think tracking the last N messages can be controlled by a config setting. It would require documentation to mention that the setting only is useful when a durable brain is used.

krutaw commented 8 years ago

Too right! The problem is that it's a global setting on the XMPP implementation that my firm is using.

markstory commented 8 years ago

I meant that the bot could have a config setting for how many messages it should track.

jonfreedman commented 8 years ago

How about if on joining the bot ignores all messages until it can observe a quiet period of a few seconds at which point it should send it's own message with a GUID announcing it's now connected. Only once it receives that back via XMPP would it be 'online'...

Having looked at the code I see 1 sec of history is requested, it might be better to request maxchars: 0 as here: http://xmpp.org/extensions/xep-0045.html#enter-managehistory

jonfreedman commented 8 years ago

You can now set HUBOT_XMPP_UUID_ON_JOIN=true in 0.2.3 and the bot will sent a uuid on join and ignore any messages until it hears itself.