[0x3b0b]Further anecdotal information for the thing [tantek] and [snarfed] were dealing with: After what I presume were some edits and re-federating, Tantek's profile on my instance now shows posts that were missing before, and MBP does _not_ bubble the updates to the top
[qubyte], GWG, thegreekgeek, sp1ff, thegreekgeek_, [KevinMarks] and ttybitnik joined the channel
pcarrierany technical reason why one would want to avoid creating feed entries with dates in the future? I'm trying to post "daily" and running ahead, wondering if I might break stuff doing this
aaronpkand because of that, defensive coding of feed readers suggests they might rewrite the date to the date the post was discovered in the feed instead, defeating your entire goal
sebbu(and i can see a perfectly valid example of future-dated post : talking about / organizing an event (even if you could or should use a calendar for that), including when it opens, close, the map, the different events inside the events, where they are (on the map), with who (guests), if you need to register beforehand, etc...
pcarrierOr rather, I would guess? Anyway not so with my static site generator, it's there on next publication. I could filter and automatically deploy every hour or something, but I won't.
Loqischeduling in the context of the indieweb, refers to the feature of setting a specific time for a post to be published in the future https://indieweb.org/scheduled
jimw[tantek] I'm not sure I see how noticing new URLs are redirects of existing ones would even work for a feed reader. If it sees `https://example.com/original` and then `https://example.com/new` it has no way to know if `/original` is redirecting to new unless it's hitting every old feed URL to notice. And since it's a feed reader, it's probably not
jimwYeah, even just pulling new URLs found in the feed could be pretty rough if most feeders did that because it would multiply a poll of your feed into multiple requests for full pages whenever there was a new post.
jimwNot quite the thundering herd of Mastodon link preview requests because the polls are more staggered, but still not how most feed readers work, I think.
[tantek]as in when a feed consumer sees a rel=alternate link on a new item, if the feed consumer already "knows about" the alternate link (as in, has seen it before), then it can do a HEAD retrieval of the alternate link to see if it returns a redirect to the new item
jimwYou're also assuming that the feed consumer is loading the page for each entry, unless you mean the rel=alternate should be in the feed entry somehow.
jimwSo on tantek.com, you should have added rel="alternate" links to the h-entry with the old slug, and a feed reader should have seen that, checked that it redirected to the u-url for the h-entry, and thus known the h-entry with the new u-url was an update to the old h-entry it had seen earlier?
jimwwhy isn't it a problem for HTML consumers? if my feed reader is using h-feed, presumably i'm going to get duplicate entries if the u-url for an h-entry has changed between retrievals.
jimwok, so what i'd call traditional feed readers that accumulate their own database of entries from feeds don't consume h-feed, so it's not a problem.
[schmarty]aaronpk's aperture consumes h-feed and accumulates its own database of entries from those feeds. it should suffer from this same duplication issue i think.
Loqijf2 is a W3C Note and a JSON Post Serialization Format of microformats2 for that is optimized for h-entry consuming code, as compared to the standard microformats JSON representation https://indieweb.org/jf2
gRegorJust tried XRay HTML input with a different u-url and u-uid property, it only returned the u-url. So I think Aperture would have the duplication issue
Loqi[preview] [Tantek Çelik] Twenty years ago this past February, Kevin Marks and I introduced #microformats in a conference presentation.
Full post: https://tantek.com/2024/044/t1/twenty-years-microformats
Aside: This is an even shorter summary of that post from ~200 days ago...
[0x3b0b]There's a small group that's set up a github org recently to try to take over further development of a fork of microblogpub; one of them has a rudimentary version of post editing working. I'm looking forward to trying to merge in some of the accumulate changes and then making pull requests for them to pull in some of mine. But I digress (as is my wont.
[KevinMarks]If you are migrating urls and use 301 that's an explicit instruction to remember the new url in future. If you use 302 it means remember the old one and recheck.
jimwfinally implemented a Webmention receiver on my site. all it does is email the mention to me, but that's better than the old stub that just threw them away.
jimwopen source, technically, but not quite to the point where anyone else could use it without having to hunt down references with my name. https://github.com/jimwins/talapoin
[tantek]this would allow me to repair and redirect any past plain @-names in my past posts that used to mean people's Twitter handles back in the day, but may be deleted or sold as of today, to that person's personal site or other preferred @-contact
[schmarty] If a feed reader shows posts chronologically by post date they'll likely float atop others until their publish time passes.
sebbu (and i can see a perfectly valid example of future-dated post : talking about / organizing an event (even if you could or should use a calendar for that), including when it opens, close, the map, the different events inside the events, where they are (on the map), with who (guests), if you need to register beforehand, etc...
Loqi scheduling in the context of the indieweb, refers to the feature of setting a specific time for a post to be published in the future https://indieweb.org/scheduled
[tantek] Hmm looks like I have Unicode problems on my http://micro.blog/t (as well as a duplicate post every time I changed a slug)
pcarrier [tantek]: https://tantek.com/updates.atom looks good in miniflux except plenty of dups.https://srv.us/ukd52f37ksovcp5yiv3nkftazojpiakd
jimw [tantek] I'm not sure I see how noticing new URLs are redirects of existing ones would even work for a feed reader. If it sees `https://example.com/original` and then `https://example.com/new` it has no way to know if `/original` is redirecting to new unless it's hitting every old feed URL to notice. And since it's a feed reader, it's probably not
gRegor I think https://tantek.com/2024/247/t2/twenty-years-microformats-shorter2 from the screenshot
[0x3b0b] There's a small group that's set up a github org recently to try to take over further development of a fork of microblogpub; one of them has a rudimentary version of post editing working. I'm looking forward to trying to merge in some of the accumulate changes and then making pull requests for them to pull in some of mine. But I digress (as is my wont.
[KevinMarks] If you are migrating urls and use 301 that's an explicit instruction to remember the new url in future. If you use 302 it means remember the old one and recheck.