The stored list should probably be a copy of the "subscribe" list on MSN. Because the official client only unsubscribes from the other side's presence when they are removed. It does not stop the other side from receiving our presence. So in TP terms, it removes from the subscribe list, but not the publish list.

Otherwise you end up with the same state as maemo 5, whcih means that all deleted contacts show up in tp clients.

Also requested in https://bugs.maemo.org/show_bug.cgi?id=7375 .

@Andre: Actually, the maemo bug is the opposite, it asks us not to implement "stored" the way its specified in the spec. The 

(In reply to comment #1)
> The stored list should probably be a copy of the "subscribe" list on MSN.
> Because the official client only unsubscribes from the other side's presence
> when they are removed. It does not stop the other side from receiving our
> presence. So in TP terms, it removes from the subscribe list, but not the
> publish list.

Is this a protocol limitation (can't revoke permission to see our presence), or an implementation detail of the WLM client?

> Otherwise you end up with the same state as maemo 5, whcih means that all
> deleted contacts show up in tp clients.

This is problematic for the current draft of Conn.I.ContactList (Bug #21787), in which there is a "one big contact list" that is a superset of (perhaps bigger than the union of!) the old stored, publish and subscribe lists. Every contact outside that list may be assumed to have publish = No and subscribe = No.

If we exclude people without "subscribe > No" from that list, then we're basically lying - we're saying that other people aren't going to receive our presence, 

In principle, the set of contacts to display is a UI decision: it should be some filtered subset of the "one big list", either "subscribe > No" or the union of "publish > No" and "subscribe > No".

However, it might be worth having some sort of boolean hint for "this contact is potentially interesting", which UIs are expected to respect unless they have a better idea; on XMPP, we'd set it on every contact with "publish > No" or "subscribe > No", but on MSN, we'd only set it on contacts with "subscribe > No".

(In reply to comment #4)
> If we exclude people without "subscribe > No" from that list, then we're
> basically lying - we're saying that other people aren't going to receive our
> presence, 

Seems I got distracted by a bee. What I meant to say was: we're saying that other people aren't going to receiver our presence, when in fact some of them are.

(In reply to comment #4)
> Is this a protocol limitation (can't revoke permission to see our presence), or
> an implementation detail of the WLM client?

If removal cannot revoke publishing, this means the publish attribute cannot be determined reliably (or does the protocol allow you to see the list that you can only add to?). In effect, the publish attribute is unknown, because the contact may unsubscribe from us and we'll never know.

In terms of old contact lists:
- If you can unpublish, there is no problem to implement removal from "stored".
- If you can't know if you are still publishing to somebody who is not on your contact list, no need to keep them in "publish" or "stored" (there is an eminent privacy problem with leaking your presence to parties once allowed, but Telepathy cannot help it beyond defining an informative property).
- If you know, but can't unpublish, well, you have a server-side publish list that you cannot remove from, so the users should know this and express their angst towards the broken IM service.

(In reply to comment #4)
> (In reply to comment #1)
> > Because the official client only unsubscribes from the other side's presence
> > when they are removed. It does not stop the other side from receiving our
> > presence. So in TP terms, it removes from the subscribe list, but not the
> > publish list.
> 
> Is this a protocol limitation (can't revoke permission to see our presence), or
> an implementation detail of the WLM client?

I'd like a definite answer to this question from someone who understands MSNP: it blocks undrafting of sane ContactList APIs (Bug #21787) so is a high priority from my point of view.

Sjoerd suggests that the real situation might be that removing a contact in WLM unsubscribes, but also blocks them, equivalent to (deny.AddMembers(), subscribe.RemoveMembers()) in the current Telepathy API or (Unsubscribe(), BlockContacts()) in the proposed API.

If that's the case, then it's not really a lie to omit blocked contacts from the publish list even if they're on the underlying MSNP reverse list (we'd normally be sending presence to them, but because they're blocked, we don't anyway), and we have a simple solution:

* on Telepathy subscribe list = is on MSNP forward list
* on Telepathy deny list = is on MSNP block list
* on Telepathy publish list = is on MSNP reverse list, but not on MSNP deny list
* on Telepathy stored list = is on Telepathy subscribe and/or publish list

Example of usage:

* I have mutual subscriptions with A, B, C
  - MSNP forward = [A, B, C], reverse = [A, B, C], blocked = []
  - Telepathy subscribe = [A, B, C], publish = [A, B, C], stored = [A, B, C], deny = []
* I remove A using WLM
  - MSNP forward = [B, C], reverse = [A, B, C], blocked = [A]
  - Telepathy subscribe = [B, C], publish = [B, C], stored = [B, C], deny = [A]
* I remove B using Telepathy
  - MSNP forward = [C], reverse = [A, C], blocked = [A]
  - Telepathy subscribe = [C], publish = [C], stored = [C], deny = [A]

(In reply to comment #7)
> I'd like a definite answer to this question from someone who understands MSNP:
> it blocks undrafting of sane ContactList APIs (Bug #21787) so is a high
> priority from my point of view.
> Sjoerd suggests that the real situation might be that removing a contact in WLM
> unsubscribes, but also blocks them

Oliver is right about that. By default, when you delete a contact in WLM, it's only removed from the subscribe list but not from the publish list. You have  also the option to block it as well on deletion though. (so Sjoerd is partially right)

Empathy is removing the contact from both lists.

> If that's the case, then it's not really a lie to omit blocked contacts from
> the publish list even if they're on the underlying MSNP reverse list (we'd
> normally be sending presence to them, but because they're blocked, we don't
> anyway), and we have a simple solution:
> 
> * on Telepathy subscribe list = is on MSNP forward list
> * on Telepathy deny list = is on MSNP block list
> * on Telepathy publish list = is on MSNP reverse list, but not on MSNP deny
> list
> * on Telepathy stored list = is on Telepathy subscribe and/or publish list

Right, except for the publish list. There is a MSNP allow list that is exactly the same thing than the tp publish list. The only difference is that Empathy deletes the contact from the publish list and WLM doesn't.

Also when you block a contact, it's added to the Block list and removed from the Allow list. You can also only remove someone from the Allow list (without blocking him) in the Options window of WLM.

> Example of usage:
> 
> * I have mutual subscriptions with A, B, C
>   - MSNP forward = [A, B, C], reverse = [A, B, C], blocked = []
>   - Telepathy subscribe = [A, B, C], publish = [A, B, C], stored = [A, B, C],
> deny = []
> * I remove A using WLM
>   - MSNP forward = [B, C], reverse = [A, B, C], blocked = [A]
>   - Telepathy subscribe = [B, C], publish = [B, C], stored = [B, C], deny = [A]
> * I remove B using Telepathy
>   - MSNP forward = [C], reverse = [A, C], blocked = [A]
>   - Telepathy subscribe = [C], publish = [C], stored = [C], deny = [A]

The reverse list is not really an useful information (it's just a "spying" tool..."Who added me to their contact list ?", Pidgin displays "Has you?" in the contact list tooltip, etc)

What we really use in tp-butterfly is the Allow list. So, here is a more complete scenario:

*1 You have 3 contacts:
 - MSN: forward = [A, B, C], allow = [A, B, C],  block = [], reverse = [A, B, C]
 - Tp: subscribe = [A, B, C], publish = [A, B, C], stored = [A, B, C], deny = []

*2 Delete A with WLM (without checking "Block as well" box):
 - MSN: forward = [B, C], allow = [A, B, C],  block = [], reverse = [A, B, C]
 - Tp: subscribe = [B, C], publish = [A, B, C], stored = [A?, B, C], deny = []

*3 Delete A from Allow list in WLM (options window):
 - MSN: forward = [B, C], allow = [B, C],  block = [], reverse = [A, B, C]
 - Tp: subscribe = [B, C], publish = [B, C], stored = [B, C], deny = [] 

*4 Delete B with WLM (and block):
 - MSN: forward = [C], allow = [C],  block = [B], reverse = [A, B, C]
 - Tp: subscribe = [C], publish = [C], stored = [C], deny = [B] 

*5 Delete C with Empathy:
 - MSN: forward = [], allow = [],  block = [B], reverse = [A, B, C]
 - Tp: subscribe = [], publish = [], stored = [], deny = [B]

*6 Contact C deletes you from his contact list:
 - MSN: forward = [], allow = [],  block = [B], reverse = [A, B]
 - Tp: subscribe = [], publish = [], stored = [], deny = [B]

?? At step 2, should A be in the stored list ??

(In reply to comment #8)
> Also when you block a contact, it's added to the Block list and removed from
> the Allow list. You can also only remove someone from the Allow list (without
> blocking him) in the Options window of WLM.

So WLM makes it possible, but difficult, to revoke presence publication. Right.

> The reverse list is not really an useful information (it's just a "spying"
> tool..."Who added me to their contact list ?", Pidgin displays "Has you?" in
> the contact list tooltip, etc)

When would you appear in my reverse list? Is it when you add me to 'stored' (if it's possible to do that and only that), when you add me to 'subscribe', when I accept your subscription request, or at some other time?

> What we really use in tp-butterfly is the Allow list. So, here is a more
> complete scenario:
> 
> *1 You have 3 contacts:
>  - MSN: forward = [A, B, C], allow = [A, B, C],  block = [], reverse = [A, B,
> C]
>  - Tp: subscribe = [A, B, C], publish = [A, B, C], stored = [A, B, C], deny =
> []
> 
> *2 Delete A with WLM (without checking "Block as well" box):
>  - MSN: forward = [B, C], allow = [A, B, C],  block = [], reverse = [A, B, C]
>  - Tp: subscribe = [B, C], publish = [A, B, C], stored = [A?, B, C], deny = []

The goal is that A disappears from the contact list in Empathy, but without actually lying about anything in our API.

At the moment, Empathy displays the 'stored' list (if there is one), so adding a 'stored' list to Butterfly would cause A to appear on the contact list even though the user thinks they have deleted A from the contact list, violating user expectations.

(This violation of user expectations manifested itself as bug reports against Maemo 5, which basically displayed the union of subscribe, stored and publish; this was "fixed" by displaying the union of subscribe and stored, and hoping that Butterfly wouldn't gain a stored list.)

At the moment, the proposed Conn.I.ContactList D-Bus API lists the equivalent of the union of subscribe, stored and publish, so any UI that doesn't filter this contact list (to only show contacts with subscribe >= Ask, perhaps) would be considered to be buggy by WLM users.

We need to avoid this somehow, perhaps by changing the D-Bus API, perhaps by adjusting how Butterfly maps its data into Telepathy. I don't want this to result in Butterfly outright lying to its users (e.g. claiming that A is not receiving our presence, when in fact, he is).

One (ugly) possibility for the ContactList API is to have a boolean property on contacts, "...ContactList/interesting" or something, which lets the protocol-literate CM give the UI hints about who's interesting to display; on MSN, this would exclude contacts who are only on allow. To me this looks uncomfortably like encoding UI policy into CMs, though.

IRC discussion:

16:28 < Tester> lfrb: shouldnt the stored list be the equivalent of the WLM 
                contact list ... 
16:29 < lfrb> Tester: ideally...yes...but that would make it impossible to 
              remove contacts form the publish (allow) list
16:30 < Tester> does it ? I though that list was the hot mail contact list ?
16:30 < lfrb> they will be able to see your presence/status and you can't even 
              know it/ do something about it
16:30 < smcv> I don't think violating the invariant that stored is a superset 
              of (publish u subscribe) is ideal
16:33 < lfrb> Tester: WLM contact list == (Hotmail contact list) - (People not 
              in subscribe/forward list)
16:52 < smcv> lfrb, Tester: so basically the problem is that we believe that 
              telling you who can see you're online is important, but WLM 
              doesn't...
16:53 < lfrb> smcv: yes...I think we should add these contacts to the contact 
              list...they will always appear offline anyway. And if you really 
              don't want to see them, you can delete them "properly"
16:55 < smcv> I expect that some UIs will do WLM-like "subscribe-only" 
              filtering, and those that don't will have to have a FAQ entry 
              explaining why "deleted" contacts from WLM reappear?
16:56 < lfrb> smcv: yes, that seems like a reasonable solution according to me
16:56 < smcv> Tester: what do you think? you seemed to feel strongly about this
16:57 < smcv> hmm
16:57 < smcv> actually, I think I can see why this was a problem on Maemo
16:57 < smcv> abook sync and the Empathy contact list aren't the same thing
16:58 < smcv> if you're feeding your contact list into an address book, you 
              don't want people who're only there because they can see your 
              presence
16:58 < smcv> I'm not sure whether we want people with subscribe = No fed into 
              an address book either, mind
16:59 < smcv> treitter: what contacts does folks consider significant? 
              subscribe, or subscribe u stored, or what?
17:02 < treitter> smcv: it's the same as Empathy's scheme, which is subscribe u 
                  stored u publish, and when contacts are added to subscribe, 
                  they're automatically added to publish

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-butterfly/issues/5.