[Feature request] "Save for Later" button below "Mark as Unread" in sidebar #2271

Save for later only applies to notifications, which means that it could only appear if the current thread is already in the /notifications?all=1 page, which is a hit or miss. Can't.

Okay, long thread alert!

A while back (probably a month) I was frustrated on how RGHs "Mark as unread" worked. I thought that GitHub would've implemented a mark as unread for sure that we can somehow exploit. And then I found that clicking the dot that appears after marking a notification as read does unmark it on GitHub's end.

I then tried to find the request that GitHub was making to mark the notification as unread. And it looks like they do have an endpoint to do that:

The next question was what is this mysterious id? I was sure that I've seen numbers like these somewhere. And to my curiosity, these numbers were thread ids used in GitHub API to manage notifications.

The next thing would be to just use this thread ids, steal an auth token from the page and make a POST request to the endpoint to mark that notification as unread. But that's where we hit a roadblock. The main issue is to gain access to these thread ids in the first place.

One way is to load the user notifications (all notifications, including read) for that repository using the v3 api, finding the respective notification matching the issue id and get the thread id from there. But this solution has limitations, if there are no notifications from that repository, we cannot get that thread id. (For example, if the issue happens to be something from 2014 and you try to get a thread id for that, then you don't get any).

GitHub seems to create a thread id for each issue/PR in a repo that you are subscribed to based on some conditions:

1. For every issue/PR created after the user is subscribed to the issue (not readily accessible though, can access from only notifications)
2. If you have interacted with any issue/PR from the stone ages, then a thread is created and you get notifications
3. If you use the subscribe button (thread is create but you cannot access it immediately)

The "cannot access thread id immediately" is the issue where GitHub creates a thread id on the server side for the user to manage, but we cannot access this id until there is a notification in that thread. These ids are so inaccessible that for each thread created, GitHub doesn't even list that thread as a subscription on the subscriptions page, until there is a notification.

I got to know that GitHub does create these thread ids on the backend because I could see that thread when fetching notifications, but it was not listed on the subscription listing page.

And to make this even more weird, GitHub uses completely different ids to identify each thread in its UI, which is IMO what they use in api v4. The reason for me to think of this is because the base64 encoded object ids that GH returns in its v4 api decode to regular ids that can be seen on a GH page (issue/PR, "view source" FTW).

I couldn't find a v4 object for threads though, but my gut says that GH does have that implemented without any docs available (ala, the subscriptions listing page).

Finding a way to get these thread ids (that are consistent with the v3 api, not the v4 api) would make "Mark as unread" feature robust and work across devices too.

I've been trying to find undocumented v3 endpoints to make this work, and I could swear that I found a way to make this feature work (as mentioned before, this happened a while back and I forgot most of it). I'll keep posting stuff if I recall anything from my memory.