Many sites have "infinite scroll" where pagination doesn't make sense with just "skips". Instead, people usually have "after ID" or "from ID1 to ID2". This report is for this feature, but I am pushing more for the "after" feature.

Currently, this can all be done very easily on the client, but it costs extra network bandwidth and CPU. It would thus be much better if done on the server.

The database should check to make sure the `after`, `from`, and `to` parameters are valid (ie those documents exist in the collection). If they don't, it is an invalid query. I'm not sure whether it should return "no documents found" or an actual error. Since most likely these parameters are just `_id` parameters, it should not be expensive. This is a check that is relatively more costly on the client.

There should be a "seek limit" option, meaning if you have both an `after` and `seek` parameter, if `seek` documents have been checked and skipped for one that matches `after`, give up. This is so the query doesn't check the entire database, specifically when the `sort` parameters are not indexed.

Thus, a query might look like so:

db.things.find({
  deleted: false,
  type: 'great'
}).sort({
  'date.created': -1
}).after({
  _id: ObjectId("123412341234123412341234")
}).seek(1000).limit(15)

Where `.after` could just take `ObjectId()` as well.
In fact, an `ObjectId`-only restriction is welcome.

Thus, for the aforementioned query, all "things" will be sorted by newest, and the next (at most) 15 documents created after (but not including) ObjectId("123412341234123412341234") will be returned.

Hopefully I covered the specifications pretty well. Let me know if you want clarification.