Escargot and YMSG (Yahoo! Messenger)

nice find
will be helpful when needed to push update logs to users

I think system messages would be more suitable. :wink:

did i say server shutdowns?
not really, i meant like “here’s what is now supported” type of thing.

I never said you meant server shutdowns. :confused:

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.

UPDATE 4

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. :stuck_out_tongue:

That’s really good news! What about the invisible mode has you borked up?

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. :stuck_out_tongue:

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.

See packet handler @ https://github.com/TheGibletInitiative/Giblet/blob/master/Protocols/YMsg/src/Server/Processors/Mock/SetAway.cpp

See packet builder @ Giblet/ContactOffline.h at master · TheGibletInitiative/Giblet · GitHub

1 Like

I can only presume that a LOGON packet is sent by the server when someone returns from an invisible state. :stuck_out_tongue:

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.

1 Like

Just to clarify, do contact status notifications apply to Busy states after being set to Invisible (“Be Right Back”, “Out to Lunch”, etc.)?

Yes, It applies to busy states and FYI idle states as well.

1 Like

Good to know. :stuck_out_tongue:

UPDATE 4.5

Great. Now initial contact details don’t work anymore. :expressionless:

in the end

you always just go back

:<

Body seems unclear, is it a full sentence?

Copypasta aside, what I meant are the status details of each contact in your contact list after Yahoo! Messenger has successfully authenticated. :stuck_out_tongue:

In The End, it doesn’t even matters

UPDATE TO UPDATE 4.5

Found a temporary fix for that initial contact detail stuff by explicitly setting the length of contacts regardless of whether it’s 1 or not, but then there are parenthesis next to an actually offline contact’s name, as if a blank custom status message was sent (just want to emphasize that this is ONLY after someone logs in and passes the authentication successfully).