Skip to content

Add onBuddylistOverlay method - #273

Closed
2FWAH wants to merge 3 commits into
fbchat-dev:masterfrom
2FWAH:master
Closed

Add onBuddylistOverlay method#273
2FWAH wants to merge 3 commits into
fbchat-dev:masterfrom
2FWAH:master

Conversation

@2FWAH

@2FWAH 2FWAH commented Mar 23, 2018

Copy link
Copy Markdown
Contributor

Handle Buddylist Overlay messages #260
At the moment only status and last active timestamp are parsed.

@madsmtm

madsmtm commented Mar 24, 2018

Copy link
Copy Markdown
Member

Haven't tested it, but I think your implementation looks good. It seems kinda pointless to add this to the API, before we figure out how to make Facebook return the data all the time.
I'm going to leave this open until we do ;)

@2FWAH

2FWAH commented Mar 24, 2018

Copy link
Copy Markdown
Contributor Author

I'm still looking why FB does not return overlay messages if the browser is closed...
Don't hesitate to update #260 if you find some clues ;)

@2FWAH

2FWAH commented Apr 29, 2018

Copy link
Copy Markdown
Contributor Author

It may be useful to merge the PR to allow a large number of users to test it, thus we could have more feedback to understand how it works.
What do you think about that?

I can add a warning message in the doc: "This is an experimental feature, feedback are welcome".

@madsmtm

madsmtm commented May 8, 2018

Copy link
Copy Markdown
Member

I did some more research, seems like Facebook sends multiple requests to https://[X]-edge-chat.facebook.com/sub with GET parameters like sticky_token, uid, viewer_uid, sticky_pool, and clientid

I'm guessing that these requests are tied to the specific sticky_token, and allows different clients to subscribe to different Facebook events.

My theory on the reason we're seeing the different events when facebook.com is open in the browser, is that it's probably at Facebook bug or a limitation in their implementation. A kind of side effect, so that when a user is utilising a sticky_token (that has requested to see specific events), the events are sent to all the user's sessions, regardless of whether the individual sticky_tokens have subscribed to that event or not.

I don't think adding it to the API will help yet, since without the permanent subscription, it's kinda useless, but I think the steps to proceed are just to analyze the /sub request, and make them ourselves in startListening. Maybe they need to be made more often than that, too?

@madsmtm

madsmtm commented Jan 31, 2019

Copy link
Copy Markdown
Member

I'll close this since neither of us really investigated the issue any further, and @kapi2289 ended up implementing it in #338 (and the issue with the subscription was fixed in #327). I'm sorry I didn't follow up on this sooner, or at least got your PR merged before #338, I just kinda forgot. Thanks a lot for your work though! 👍

@madsmtm madsmtm closed this Jan 31, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants