[Standards] Message Mine'ing

Joe Hildebrand hildjj at gmail.com
Tue Dec 2 20:55:22 UTC 2008

On Dec 2, 2008, at 12:40 PM, Kevin Smith wrote:

> On Tue, Dec 2, 2008 at 7:25 PM, Jonathan Schleifer
> <js-xmpp-standards at webkeks.org> wrote:
>> I wouldn't want that, I really wouldn't want that. I have an mcabber
> That's ok - when it's not the only online resource, mcabber will know
> (through mine-ing) that it's not being talked to, so there's no reason
> for it to be logging the messages.

I would suggest that it could remove them from the log when another  
client Mine's them, if that's the behavior you're after.

> Now I understand it a bit better, I think it probably does solve the
> problem it's setting out to solve, mostly (although it can't help in
> the case where someone leaves one machine to go to another, and the
> now idle client continues to receive a conversation unless we mandate
> that you must go Away (or similar) when leaving your machine, and if
> we did that we may as well stick with priorities.)

Hopefully, adding the XEP-146 interaction section will make this more  
clear.  If we think this important to do without changing presence, we  
can either reuse XEP-85 "gone", or add a new state of "moved" that is  
an unlock hint.

> What's not clear to me is how a client knows that it's the active
> client in order to Mine the message - should it be displayed to the
> user on all clients, and then withdrawn from view after it's been
> Mined elsewhere (Client UI question), with a client only mineing it
> when the user is known to have read it somehow?

That was the intent.  The "known to have read it somehow" bit has some  
suggestions in the implementation notes.  I look at that as mostly a  
UI issue, not a protocol issue.

Joe Hildebrand

More information about the Standards mailing list