I’ve come to the conclusion there is no packet to accept the add request. When you added the user they were added and the only action to take was to remove them. This is likely why Deny-A-Buddy tools worked after ac contact was added because it was actually a remove me from their contact list.
Looking at libyahoo2 0.7.5 there is no accept add functionality. Kind hard to imagine they would omit that particular feature but support all other contact related functionality including accessing and modifying the address book.
Depends on how many concurrent users you are servicing. As the concurrent number grows it may be more advantageous to replace the updater app or direct the request to your own non-essential web server.
Everything is going well. Got contact presence implemented, even though I can’t really wrap my head on how Invisible mode specifically works, and I plan to implement contact deletion, moving/copying contacts to groups, contact ignores, and “finish” up some already implemented services.
This really is going well, and I can’t wait for this Yahoo! server to be finalized and live.
Whenever an ISAWAY/ISBACK packet is sent by the server to someone with the status specified as Invisible (0x0000000c/decimal 12), the receiving end just gets a blank custom status message ("()").
I’m not an expert on the YMSG protocol in any sense of the word, so I’ve probably screwed up something on that.
Yeah that’s not going to work. When the user sets their status to invisible you need to send a contact offline packet (service id 2) instead of the online status packet you’re sending now. I had a problem with the offline notification showing up in the lower right hand corner but the state of the contact in my list didn’t change. I managed to fix this last night with the correct key pairs so in addition to the offline notification the buddy list now updates to the correct state.
Here’s the keypair map
Service Id = 2, Attribute = 1 (must be 1)
7 => Contact Id
10 => Unknown (observed as "0". Appears to be required)
13 => Unknown (observed as "0")
47 => Unknown (observed as "2". Including this but omitting 10 and 13 causes crash)
According to my notes the values were observed in 6.0.1922. If I apply the keypair matrix 10 is probably the online status and 13 is probably the client type (game, chat, mobile), but 47 probably isn’t a busy state as that’s assumed to be a boolean. I need to feed some other values to messenger to see what happens.
You’ll send contact online status update (service id 1) with attribute 1 and omit the client id’s. It appears that unlike the packet sent during login with attribute 0 you can only include one contact in the packet otherwise Messenger gets a bit wonky. The attribute also seems to determine whether the notification in the lower right hand corner is displayed, 0 will always skip the notifications even after a successful login.
