A Chronological Feed That Preserves Reading State

1. Chronology depends on identity

A chronological feed appears simpler than a ranked feed: show articles in time order. Yet ingestion introduces several different times and several imperfect ways to identify an article. A publisher can correct a title, update a timestamp, change a link, or include an older entry in a newly fetched document.

If the application treats each fetch as new content, old stories repeatedly reappear. If it identifies entries by title, a correction can create a duplicate. If it stores read state on a disposable fetched row, refreshing the feed can erase a reader's progress.

The design question for theFeed is how to preserve a dependable reading sequence as source documents change. The proposed solution separates source identity, content revision, ordering, and user state. These are architectural recommendations; this edition does not claim an implementation audit of the reader.

2. Keep source identity distinct from presentation

For Atom, the specification defines an entry identifier independently of its title and links, and distinguishes publication from update timestamps. [1] A reader should use the format's identity semantics when available rather than inventing identity from display text.

The proposed ingestion model records a feed's internal identity and its publisher-provided entry identifier. Namespacing by the subscribed source is a conservative application choice that avoids merging unrelated sources solely because they provide the same malformed identifier. Cross-source story grouping, if desired, is a separate feature with its own confidence and reversal rules.

A content revision belongs to that source entry. Reader actions such as read, saved, or dismissed belong to the durable entry identity rather than a particular fetched copy. This allows an updated body to coexist with the reader's earlier decision.

1. 1. FetchRetrieve a source representation.
2. 2. NormalizeResolve entry identity and revision.
3. 3. StorePreserve content and user state separately.
4. 4. ReadOrder entries with a declared rule.

3. Worked example: a corrected headline

Assume a synthetic publisher releases an article at 09:00. The reader fetches it at 09:05, and the user marks it read. At 11:00 the publisher corrects the headline and updates the article while retaining its entry identifier.

A title-based deduplicator sees a new item. A fetch-time sort places the correction among the latest discoveries. The proposed model instead records a new revision of the existing entry and preserves the read action. The interface may show that the article changed, but it should not silently claim that the reader never encountered it.

Some sources omit identifiers or change them incorrectly. The fallback needs to be documented and conservative. A normalized link can be useful, but stripping arbitrary query parameters can merge distinct articles. A suspected duplicate should be reversible; uncertain identity is preferable to permanently combining unrelated reading history.

4. Choose and disclose the ordering rule

The proposed default sorts by a usable publication timestamp and uses a stable internal key to break ties. When publication time is missing or invalid, it uses a recorded discovery time and identifies that fallback in the article metadata. A future-dated entry should not occupy the top of the feed indefinitely without a declared policy.

Changing the ordering rule is a user-visible behavior change. Sorting by update time emphasizes corrections and live stories. Sorting by first discovery keeps a stable arrival sequence when publisher timestamps are unreliable. Neither is universally correct, but mixing them silently makes chronology difficult to understand.

Pagination must use the same ordering identity as the visible list. Offset pagination over a changing feed can skip or repeat entries as new items arrive. A stable cursor with a declared refresh behavior makes it easier to preserve the reader's position while allowing newly discovered stories to appear deliberately.

5. Fetch freshness is not reading history

HTTP caching defines freshness and validation behavior for stored responses. Conditional revalidation can avoid transferring an unchanged representation, but a successful validation does not mean a new article was published. [2] The reader should track source-check time separately from entry publication and read state.

A failed fetch should leave previously retained articles readable and record the source's current error state. A feed returning no entries does not necessarily mean that previously saved stories should be deleted. Source retention, application retention, and user-saved retention need distinct policies.

External article content also crosses a rendering boundary. Feed markup, links, and media should be treated as untrusted input. Remote images can create network requests even when the reader's own storage is local. A meaningful privacy design accounts for those requests and offers a clear media-loading policy rather than treating local persistence as a complete privacy guarantee.

6. Storage alternatives and evaluation

A browser-local store supports low-latency personal use and avoids requiring an account. Its tradeoffs include device loss, storage eviction, backup, and cross-device continuity. A server-backed account can synchronize state, but introduces operational access to subscriptions and reading actions. A hybrid design needs explicit merge rules when devices disagree.

The first verification corpus should contain repeated fetches, unchanged identifiers with revised titles, reused identifiers with incompatible entries, missing dates, equal timestamps, malformed markup, and temporary source failures. Assert both normalized content and user state after each sequence. A parser test alone will not catch a refresh that clears saved articles.

For pagination, insert new entries while a reader moves between pages and check for unintended gaps or duplication. For caching, verify that revalidation updates source health without manufacturing new entries. For retention, remove an article from a fetched document and confirm that saved-state behavior follows the stated policy.

This edition reports no ingestion success rate or performance measurement. A production evaluation would need a representative source corpus, documented exclusions, and separate measures for parse failures, identity conflicts, freshness, and state preservation.

7. Conclusion

A reliable chronological reader preserves the distinction between an article, a revision, a timestamp, and a reader's action. That separation prevents a corrected headline from becoming a false new story and allows source failures to coexist with uninterrupted access to retained content.

For theFeed, the most useful next proof is a repeated-ingestion test that preserves read and saved state across the difficult source changes described here. A dependable reading experience begins with that continuity, before adding more ranking, summarization, or discovery features.

References

1. IETF. RFC 4287: The Atom Syndication Format, 2005. Entry identity and date constructs discussed in Section 2.
2. IETF. RFC 9111: HTTP Caching, 2022. Freshness and validation behavior discussed in Section 5.