Mastodawn

clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛Apr 30, 2020

@klaatu I was listening to gnuworldorder.info/#12x31

It's funny how you mention getting tips from d0dddummy about dd, and then wondering what "dd" stands for. It's funny because the nickname and the command name are connected. 🙂

"dd" in the nickname comes from the IBM Job Control Language statement "dd" for "data definition". I'm sure @Jason_Dodd can tell us the significance of "d0" in particular, as he knows a thing or two about mainframes.

The "dd" command in coreutils (and in POSIX and Unix) takes its name from the same JCL statement even though it doesn't quite do the same thing, apart from making data from a place appear in a place.

www.ibm.com/support/knowledgec… (requires JS)

archive.is/wip/AN7AA (pre-renders the JS output for you, but instead relies on CloudFlare)

Gnu World Order

GNU World Order Oggcast

Show thread

clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛May 1, 2020

Also brought up on GWO#12x31: Should you have a big-ass Atom/RSS feed with All The Things, or a smaller one with just the latest bunch of episodes/posts?

Theoretically, you can have the cake and eat it too!

tools.ietf.org/html/rfc5005#se…

A paged Atom feed (I hear people do this for RSS 2 too) has the smaller feed document at the feed URL, but it contains <link> elements with `rel` first/last/previous/next and `href` to the other steps in a chain of documents that describe the whole logical feed.

In practice, I don't know e.g. which podcatchers actually follow the chain to reconstruct the whole logical feed.

The reason you would want to do this is that polling a multiple-MB document is just bad practice. A new show comes out? Here's all the other 99% of shows you already know about!

RFC 5005 - Feed Paging and Archiving

Show thread

clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛May 1, 2020

The RFC distinguishes subscription feeds and archive feeds, where subscription feed documents are expected to be unstable and archive feed documents are expected to be immutable -- if you encounter a URL in the chain that you already visited once, you're done fetching.

How (and if) people actually use subscription feeds and archive feeds in practice, I don't know. If an entire logical feed, all page documents, needs to be either subscription or archive, then an archive feed can't have a current head? If I sort the document chain in reverse chronological order, is a document describing older entries "next" or "previous"?

It seems to me a good HTTP citizen would make any document immutable when possible, but a conforming Atom client needs to check every document in a subscription feed to be sure. Time stamps and ETags would make it unnecessary to literally fetch all the document contents, it could get 304s when accessing them, but not having to even check would be even better. I guess HTTP cache headers would make this even less an issue -- if you have a subscription feed with most pages being in practice immutable, you could have a `Cache-Control` with a high `max-age`, or if you have hashes in your URLs you could even be brave and use `immutable`.

Sounds like all of this is fodder for an #HPREp . I seem to remember there is someone on the Fediverse that scours feed-related projects out there and files issues for them to please handle paged feeds correctly, would be cool to interview that person.

Show thread

clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛May 1, 2020

Hey Fediverse RFC 5005 zealot: If you exist outside my imagination, why haven't you tagged any of your posts #rfc5005 ?

Show thread

clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛May 1, 2020

Pleroma full-text search helped me locate @jamey , @kensanata , @alcinnz , @fluffy who have talked favorably about RFC 5005 paged Atom feeds some time in the last year or two. Jamey might possibly be the RFC 5005 zealot I had in mind, but the level of zealotry seems to have been overstated by me. 😀

I've had good interactions with all of you, so I hope you're ok with me roping you in like this.

It sounds to me from reading the convos that paged feed support was really abysmal across the producer and consumer software spectrum back in 2018 (for a 2007 RFC that to me sounds simple and obviously important!), and I get the impression that not much has happened in the last two years. Do you have the same impression?

Show thread

Jamey Sharp May 1, 2020

@clacke @alcinnz @kensanata @fluffy Oh hi! Somebody called this my "white whale" so "zealot" might be fair I guess 😅

Other responses have covered a lot but I think it was running this unconference session that really helped me solidify my take on why #rfc5005 didn't catch on before: https://indieweb.org/2019/BeyondMicroblogs

I'm frustrated by my inability to get people to care. The WordPress ticket I filed in January has had absolutely zero response even though I have a working plugin that shows how to do it efficiently while getting the immutability requirements right. The PR I opened on jekyll-feed went silent as soon as I'd fixed all the code style things they asked for; they agreed I'd done so, then didn't merge it. I don't know how I can make this any easier for people.

Not an exaggeration to say this is the one thing I've wanted from the internet for three years now and I have no idea how to make it happen. 😭

Show thread

Jamey Sharp May 1, 2020

@clacke @alcinnz @kensanata @fluffy There is one issue I have with the #rfc5005 spec: it doesn't cover rationale so you have to read carefully between the lines to realize that everything in it is important and not just weird arbitrary choices. And that there's only one interpretation of section 4's prev-archive and next-archive which is fully consistent with both the text and the examples, because otherwise it's definitely ambiguous which temporal direction should be "previous" and which should be "next". I don't think section 3 manages to disambiguate that at all.

Meanwhile I don't tend to use hashtags because I've never learned how to make them useful 😅

Show thread

clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛May 1, 2020

@jamey I did see that archives can only have one direction, as the spec defines when a reader can terminate. 🙂

So I guess by extension, section 3 attributes should follow the same semantics (which are my intuitive semantics reversed).

I guess the authors, just like me when approaching it, figured the rationale self-evident. Apparently web society disagrees with that view.

@alcinnz @kensanata @fluffy

Show thread

Jamey Sharp May 1, 2020

@clacke @alcinnz @kensanata @fluffy Exactly, it's the termination thing that clinches it. 😁

I'd have sympathy for an argument I don't think I've ever heard anybody make: perhaps section 3 should go the opposite direction, because it's for a fundamentally different purpose. The text talks about search results and similarly transient sequences IIRC. In that case it makes sense that the initial document would be "first" and you'd follow "next" links to find more. The authors might even have expected different applications to make different choices here according to the semantics of the collection. I don't think this is clear in the corresponding HTML link relations either.

I think it's funny that Mastodon actually implements #rfc5005 section 3, but I've wondered if that's an accident motivated by using the same link relations that HTML does, rather than anyone having been aware of this spec.

Show thread

clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛

@jamey

> I think it's funny that Mastodon actually implements #rfc5005 section 3, but I've wondered if that's an accident motivated by using the same link relations that HTML does, rather than anyone having been aware of this spec.

Could have also been cargo-culting how GNU Social did it (which was probably on purpose, as Prodromou tried to fit every standard he could into it).

Looks like Mastodon ripped out the Atom feeds when it ripped out OStatus, so this is no longer true. 🙁

github.com/tootsuite/mastodon/…

The RSS feeds, which remain, don't have paging links.

Remove stream entry model by Gargron · Pull Request #11247 · tootsuite/mastodon

Remove Atom feeds Remove old URLs in the form of GET /:username/updates/:id Remove StreamEntry model and stream_entries table This PR is centered around the removal of the StreamEntry model. That ...