Condensing updates that appear in digests

In the previous post, I claimed to be "finished" my exploration of handling updates.

Ha!

I don't like how my update notifications appear in digests — in e-mail newsletters that gather up all the posts over a period of time.

There are two problems:

1. Update notifications appear in digests as separate, cookie-cutter posts, which bury and dilute "real" posts.

   On websites, we can make synthetic update posts visually distinct to help guide visitors past them. We could do that in HTML mail digests too, but I think update posts will still put people off actually reading new material when they are going quickly through their e-mail, particularly when updates are more recent and therefore come before the "real" posts.

2. Updates appear even for posts that are included in the current digest.

   feedletter digests always include the most recently seen version of a post, so from the digest reader's perspective, the "update" notification tells them about nothing that isn't already in the post.

To address this, I mean to do a bunch of things.

1. I'm going to modify the definition of iffy:synthetic, reversing course on my my current admonition that

   Applications that include iffy:synthetic as a direct child of channel SHOULD NOT also mark individual items as iffy:synthetic, unless there is some meaningful sense in which some items are more synthetic than others. It serves no purpose to mark every item of a feed iffy:synthetic when the channel is already so marked.

   Never mind.

   Until now, iffy:synthetic has been basically just a marker, so there was no point in marking posts twice. Marking at the channel level implied the syntheticness and the types at the item level.

   But now we'll reconceive of iffy:synthetic as also the carrier of the data on which the item content (in description, content:encoded, or atom:content) is based.

   The item content, of course, remains the post's HTML, whether it is a synthetic post or not. But we'll want the information we used to compose synthetic posts to be available, in an iffy:type-dependent way, inside item > iffy:synthetic. So even when a channel is marked synthetic, with a type that implies the type of elements, we will want explicitly to include an iffy:synthetic element in each item.

   For synthethic items of type UpdateAnnouncement — the relevant case here — we've already defined an element that carries most the relevant data, iffy:update.

   We'll also need the guid of the post updated. So we'll bring back iffy:original-guid, with a slightly modified role.

2. I'll define a feedletter content Customizer that

   1. filters away upates to items already in the post;
   2. combines the remaining updates into a single notification post; and
   3. places that notification post at the end of the digest.

So. We have a plan!

Let's see if it works.