💾 Archived View for gemini.circumlunar.space › ~solderpunk › gemlog › gemini-hearts-atom.gmi captured on 2022-06-03 at 22:59:25. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
I'm really pleased that I've been able to find the time and energy this week to get two new small Gemini projects off to strong starts:
Gemfeed, a tool for generating Atom feeds of Gemini content
and
CAPCOM, a tool for aggregating Atom feeds into a Gemini document
I plan to make it easy for people to use CAPCOM the way Gopher readers use
Alex Schroder's Moku-pona tool
to maintain their own personal set of aggregated feeds, but alongside that I am already using it to power an early and experimental
which is heavily inspired by
logout's Bongusta aggregator for Gopher.
I think it would be difficult to overstate the importance of the role that Bongusta has played in nurturing the recent expansion of the phlogosphere as a close-knit community and in facilitating the decentralising diaspora away from SDF as the one big host of everything. Without an equivalent, the nascent Geminispace has been trapped in a very poor usability position, where keeping tabs on everything involves manually checking every server every day, which is a very difficult habit to maintain, especially when updates are infrequent. I doubt anybody does it. Of course, because nobody is doing this, to some extent it removes the incentive to produce frequent updates. I hope that CAPCOM can help lift us out of this position and, in combination with the current spec freeze, motivates people to start writing.
The very notion of wanting to keep tabs on everything that happens in Geminispace is, of course, only a sensible and viable thing in the early days when the space is small and everybody knows everybody. Nobody could, and no sane person would want to, follow everything that happens on the web, not even 30 years ago. Maybe Geminispace will never outgrow a single "firehose" feed of everything, but even if it does, I would kind of like to see the combination of Gemini and Atom to remain "a thing". Atom feeds are just a super nifty bit of technology, one of the things I think the web got right (and then largely abandoned, because distributing content via feeds reduces ad impressions and gives people no incentive to register an account at a silo). Some quick thoughts:
First, some of you may be wondering - "why not RSS?". I have no beef with RSS at all, but at the end of the day life is easier, even if only marginally, for everyone if there's just one kind of feed to think about, produce and consume. Both RSS and Atom will get the job done, that's an empirical fact, but why not pick the slightly newer one, which has an IETF RFC and a few technical advantages: less restrictive licensing, an IANA-registered MIME type and URI scheme (to pick a few from:
Wikipedia's "RSS compared with Atom").
Second, compared to HTML, Gemini has a small feed discovery problem. A webpage can use a <link/> element in its <head> to tell a browser that there's an associated Atom feed. Gemini has no way to signal that explicitly. The lightest solution to this I can think of is simply to impose a convention - that Atom feeds always have a particular name (Gemfeed produces `atom.xml` by default, which seems as good a name to me as any) and location relative to any item included in them. The next step up would be a well-known endpoint for any domain which returns, say, a JSON object listing all the feeds associated with that domain, but let's try the convention first?
Third and finally, some thoughts on including content in feeds. While writing Gemfeed, I made use of
The W3C's Feed Validation Service
to make sure the resulting feeds were valid. They were valid, but induced a few small complaints. One, fair enough, was that gemini:// is not an IANA-registered scheme. The other was that none of the <entry>s contained any textual content. This is not required by Atom (and, in fact, clients are required not to fail in its absence), but the validator says:
"Experience teaches that feeds which contain textual content are in general more useful than those which do not. Some applications (one example is full-text indexers) require a minimum amount of text or (X)HTML to function reliably and predictably. Feed producers should be aware of these issues. It is advisable that each atom:entry element contain a non-empty atom:title element, a non-empty atom: content element when that element is present, and a non-empty atom: summary element when the entry contains no atom:content element. However, the absence of atom:summary is not an error."
I'm not really convinced by this. Including content in CAPCOM feeds would make the public firehose feed a lot larger than it currently is. If you fetched it once per day, the majority of what you downloaded would be content from the past which you'd already read. Some of what was new might be part of a gemlog that you're just not interested in reading. It's not currently an explicit goal of Gemini to minimise network activity, but it seems to me to be common sense to do precisely that. I may write more on this in future. But suffice it to say for now that it makes more sense to me for feeds to be minimalistic indices to content which users can then fetch or not fetch depending on what makes sense, rather than big monolithic slabs of content. Of course, if people think there are compelling use cases for "fat feeds", we could easily enough establish a convention of filenames for both types - atom.xml and atom-with-content.xml or whatever.