easeout at tilde.team writes: > However, some of us are concerned with the complexity of creating a feed > alongside creating Gemini content. If one of our goals is to make Gemini > content easy to publish, making it easy to syndicate is an attractive > goal too. And it is jarring to go from writing Gemtext, which is > remarkably simple and straightforward, to writing Atom XML, or to > finding a static site generator tool that will do it for you. This feels > like a cost. It might remind us of the bloat on the web we are trying to > do without. Or it might be a barrier to entry for users who would be > confident publishing Gemtext, but not confident publishing Atom, or for > that matter, a web page. At this point in time, how many folks can write Gemtext but aren't confident writing HTML? Yes, for those that hand-author feeds, it's certainly a bit of a bother writing XML by hand (I've screwed it up myself a few times), but I'm not sure the Gemini community is at the point where we have users that are confident with Gemtext but not with HTML. > # Subscribing to any Gemtext page > > To get a feel for that, I did a proof of concept that you can try out: > > => https://github.com/kconner/gemini-subscription-cli Proof of Concept > > This repository contains a Makefile and a shell script. The script takes > a list of Gemini URLs to fetch, which are expected to be Gemtext pages. > It filters them down to just the link lines. It compares the set of link > lines with a previously-fetched set of link lines, and it identifies and > emits those that are new. It saves the new total set as the next run's > previous set for comparison. If there's just a shell script parsing text and making socat commands, what's stopping an author from using `jq` or `xidel` on the output to parse JSON and XML respectively? I realize in code it's not that simple, but most languages in general use have JSON and XML parsers easily available and generally well documented. > This proof of concept demonstrates that any Gemini page can already be > treated like a feed. This means that, if you don't mind not > participating in the broader internet feed reader ecosystem, and you > don't mind the occasional page redesign creating noise in subscription > results, you don't have to make a feed file at all. Syndication is > zero-cost. One of my favorite parts of Gemini is the attitude that it works with the rest of the net, as opposed to trying to cloister itself like the Web does. One of my pet peeves with the web is how it tries to reinvent everything. Long-lived connections, push protocols, things that TCP has had _forever_. > > In hindsight, why does RSS exist? What is "Really Simple" about it? > Well, it's simpler than HTML. If HTML was easy enough to parse, you > could just subscribe to web pages and not need feed files. But Gemtext > is already easy to parse. We don't our experience on the web to mislead > us into thinking a page, like your blog index page, is not already a > subscribable list of links. Small aside: Semantically annotated tags have been a dream for the W3C for quite some time now, and annotating feed links and other tags is the purpose behind Semantic Web initiatives. The web has definitely tried to allow in-band feeds. > Gemtext authors could feel like they are not burdened with creating a > in the wild. One way that could work is for a browser to have a way to > treat a bookmark like a feed subscription. I also think if CAPCOM would > accept Gemtext pages as a feed URL option, that would go a long way. I still feel like this is NIH, but I'm not a CAPCOM or Spacewalk author so a decision like this isn't my place. As long as we continue to have Atom/RSS support, that's all I'd like. I guess if there is a broader move to Gemtext feeds, there should be pretty simple methods available to convert those into Atom-compatible feeds. - meff
---
Previous in thread (1 of 8): 🗣️ easeout (a) tilde.team (easeout (a) tilde.team)
Next in thread (3 of 8): 🗣️ Jacob Moody (moody (a) posixcafe.org)