We still need usable Git-backed site distribution

A couple of recent posts by Ploum and Dominique discuss the necessity (or at least the convenience) of strengthening the publication of Gemini or Web sites by using Git repositories. I believe that, for it to be actually usable, this way distributing content would need well-defined specifications, mechanisms and practices. Since that is precisely the goal of the gwit project, both posts strengthen my conviction that gwit is still relevant and worth the effort.

De la brièveté de la vie et de la pérennité d’un blog (by Ploum)

Read this from git (by Dominique at Laniakea)

Ploum's piece reflects upon the preservation of one's writings against incidents, attacks or the unavoidable passing of time. He mentions some approaches that he has taken to make his site ready for the long term, like ensuring its autonomy and simplicity, and having permanent URLs, easy-to-render sources in a Git repo, and mirrors. He observes that new protocols or usages are needed to turn Internet into a worldwide archive, keeping in mind that we don't know which content will turn out to be relevant in the future. I consider it an insightful text overall with useful technical advice, much worth reading.

Dominique's article follows a different take, starting with the technical experiment to distribute the Laniakea site sources over Git. However, its brief conclusion section does a great job in synthesizing the motivations and potential of the experiment… and they turn to be much in the same line of Ploum's: content resilience, URL permanence, simplicity, mirroring, and the issue of unforeseen utility. If you don't read Ploum's text (because you can't read French or you're short of time), be sure to read at least Dominique's conclusion.

(It's no wonder that both texts refer to Solderpunk's initial essay on content distribution over Git, which also inspired gwit.)

Low budget P2P content distribution with git (by Solderpunk)

gwit and site resilience

Let's see how gwit fares in each of the points raised by the aforementioned posts:

Autonomy: gwit doesn't depend on domain names or certificates provided (and revocable) by third parties: the identification of a site and the verification of its content depend on a PGP key that you can create locally on your device, without external permission. You still need a place to host the site's Git repo (if you want it to be accessible online — repos on USB sticks are also an option), but the site's not bound to any Git remote URL, and it may be hosted in a resilient and evolving set of many remotes run by anyone — not just the site author.

Simplicity: gwit allows any kind of content in a site (as long as it can be stored as files), so simplicity much depends on the particular content: a site made of Gemini files will be more resilient than one made of HTML/CSS/Javascript files full of references to HTTP sites, both because of content being self-contained and not needing complex software to read it. Regarding software used to access gwit sites, it should be easy to implement anytime by a single person with just shell scripting, Git (which will be widely available for a while) and GnuPG — actually, the commands for many operations are shown as examples in the spec.

Permanent URLs: A gwit client should keep a local copy of the whole change history of each site that you access. Thus, if site X linked two years ago to a page in site Y (using a gwit URI), and the latter page does no longer exist when trying to follow X's link today, your gwit client may try to check Y's history to see where it went, or it may at least get it from the version of Y from two years ago, when it still existed. Also, gwit supports permanent links that refer to a particular version (commit) of the target site, regardless of future changes.

Mirror availability: A gwit site is just a bunch of files in signed commits in a Git repo. Moreover, the files are the actual, final content in the site. This means that anyone may publish a “mirror” using whatever mechanism supported by Git. You may turn the copy (clone) of your favourite site in your computer into one such mirror. You may even use your usual Git forge account for that. Note that there's no need to use some additional website generator software (which may break in the future) and publish an approved “rendered” site elsewhere.

Source availability: Files in a gwit site are final content, but since the site lives in a special repo branch, its sources (if any) may sit in the same repo and be fetched along the “rendered” gwit site, thus benefiting from replication.

Clone size: As a gwit site includes “rendered”, final content (and its past versions), it may weigh more than just the equivalent sources. The extra weight will depend of course on the content formats used by the site (e.g. gemtext is way lighter than HTML), so gwit may be more convenient for text-centric, lightweight sites. Then, Git makes a very good job in keeping text content compact, and storing duplicate content and changes efficiently.

Content archaeology (i.e. what if this becomes useful in the future?): Having normal gwit clients (“browsers”) clone whole sites with their history increases the chances of content survival. gwit offers no automated ways of locating clones of a site (this is no BitTorrent), but it should be possible to publish some plea for help from the readers of a site so that they can share their local clone!

I'd say that the gwit spec seems to cover those points pretty well!

The gwit network grows! 🪩

Last but not least, another recent surprise showing that gwit still stirs some interest was Matograine's post to the gwit-spec mailing list introducing what to my knowledge is the second gwit site ever. 🎉 It's still in its early stages, but it already contains a nice short guide (in French) on how to create a new gwit site, along with PGP keys, required files, etc.

Format for fingerprint and remotes (by Matograine)

Matograine's gwit site

Here's the site introduction with ID/key and Git remote URLs:

Merci beaucoup, Matograine !

🍃

🗒️ Back to log index