[Standards] Message Mine'ing

Matthew A. Miller linuxwolf at outer-planes.net
Tue Dec 2 21:34:30 UTC 2008

On Dec 2, 2008, at 14:10, Kevin Smith wrote:
>>> 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.
> It's not that I mind changing presence - what I wonder, though, is
> that if some user interaction is required, couldn't the user set their
> priority instead? I wonder how far that would get us.

Presence priority gets us mostly there if the user is proactive.  Mine- 
ing gets us more there if the user is reactive.

Human beings are already wired to be reactive, and mine-ing exploits  
that (-:

NOTE:  I am not suggesting we do away with presence priority.  I think  
there's still value there as a rough passive indicator to a user's  

>>> 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.
> As long as it is possible to sanely represent the protocol in the
> client, I'm happy - it would become a protocol issue if there was no
> reasonable way to present it to the user, I think.

Within the first 60 minutes of reading this spec, there were about  
half a dozen ways I could see to implement this in the clients I work  
on regularly.  Some prototyping has shown that the protocol's got what  
I need (so far), it's just a usability/implementation issue to resolve.
> /K

Matthew A. Miller
linuxwolf at outer-planes.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2238 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20081202/c66009bd/attachment.bin>

More information about the Standards mailing list