indieweb / indieweb/microsub

A way to detect skipped posts

Open
#14 4 comments 0 reactions 0 assignees View on GitHub
brainstorming
Dominant language
No language data
Stars
23
Forks
1
PR merge metrics
No merged PRs in 30d

Description

Over here (https://github.com/EdwardHinkle/indigenous-ios/issues/73#issuecomment-361597999) you mentioned the idea that a user that hasn't opened a Microsub app in a week might have 500 posts sitting in a channel and that it would be a lot of data to load.

This is actually a very realistic scenario, and one I would like to be able to tackle in Indigenous. My favorite current approach is Tweetbot's "Load Missing Tweets"
![tumblr_inline_n9yt8wvi0t1qz4hbm](https://user-images.githubusercontent.com/786014/35573765-fac71688-05a5-11e8-945d-4a949ea16fd6.png)

How this would work is I would have the last posts I fetched when they previously opened the app (with it I would have that batches "before" token). When the channel is opened a week later, I do the standard timeline fetch with no modifiers, getting the current front posts as well as a before and after token.

What I would like to be able to do is to provide the "before" token from the previous group of posts, and the "after" token from the latest group of posts, and get an integer that provides how many posts exist in-between those two tokens. This would enable me to then provide a "load missing posts" button by using either the before token to get older posts or the after token to get newer posts. Eventually, removing the "Load Missing Posts" button when there are no more posts left. (I'm thinking it would technically load 10-20 posts for every click and provide some metric letting them know how many more posts are missing.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by reviewing the proposed before and after token behavior in this issue and the linked Indigenous discussion. Define how the API reports posts between two tokens, how clients load missing batches, and when no more posts remain; the specification should make these semantics and response data explicit.

Written by the indexing model from the issue text.

Assessment

Domain
api
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.