Yes, that's coming at some point soon.
When this feature goes live, in addition to our native and popular alternative realtime protocols, we will provide a dead simple streaming protocol which includes a unique message ID for each frame (message) delivered that is also a cursor. This cursor can be used to keep track of your position in the message stream for theoretically a limitless amount of time (this is only constrained by the TTL of your app history).
For example, consider an example HTTP stream as follows:
GET /channel/stream => message with ID: 123456 => message with ID: 123457 => message with ID: 123458 => message with ID: 123459
-- connection closed by client --
A few hours later, you wish to resume the stream and have persisted the cursor / message ID:
GET /channel/stream?from=123459 => message with ID: 123460 => message with ID: 123461 => message with ID: 123462
However, for the purposes of this example, we assume that when processing message with ID 123462, the backend server crashed. As such, the last successfully stored cursor would in fact be 123461. The server when restarted would now send a new streaming request as follows:
GET /channel/stream?from=123461 => message with ID: 123462 => message with ID: 123463
And the failed message will be delivered again.
See https://www.w3.org/TR/2011/WD-eventsource-20110310/#last-event-id for an example of how a last event ID is used for SSE (Server-Sent-Events) to achieve a similar thing.