Tracking read/unread status

[chuanqisun]

I'm not sure how strongly people feel about having such a feature. Just throwing this idea out there.

Requirements:

1. User can toggle the status of an article between read/unread.
2. Only the site owner can toggle such status, otherwise, random visitors can mess up your feed status.
3. Only the site owner can see such status, for privacy reasons.
   1. Reading activity cannot be stored in plaintext on server side, because the repos are considered public.
4. I don't want to maintain a centralized database or have other people's credentials.

Solution:

• User provides their GitHub developer token to client A, using browser local storage, for later use.
• When user marks articles as read/unread, the activity is encrypted on the client side (using GitHub developer token as encryption key) and pushed to the server side via GitHub REST API, which also requires a token for authentication
• When user opens the feed from client B, the encrypted activity is downloaded, along with feed content.
• User provides the same developer token to client B, to decrypt and display read/unread status.

Potential issues:

1. User can lose their token (github only displays it once) and hence lose the ability to add more clients.
   1. Consider allowing user to provide an alternative easy-to-remember key for encryption. This decouples the encryption of the activities from the authentication of the REST API call.
2. Reading activity can grow infinitely long, undermining performance
   1. Similar to limiting max days of articles, we can limit max days of activities
3. Read/unread activities can be changed while the browser is offline, ultimately causing merge conflict
   1. If we query the latest activities just before we upload the activities, the chance of conflict would be nearly zero.
   2. If user closes the browser, we might not have enough time to perform a query + activity upload
   3. If the browser is offline, the activities can be saved in local storage, waiting for next online session
   4. Conflicts are resolved locally, using "later write wins" algorithm. This requires tracking timestamp of each activity.