💾 Archived View for kayvr.com › gemlog › 2022-03-17-Rover-Experiments.gmi captured on 2023-01-29 at 15:52:40. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-04-28)
-=-=-=-=-=-=-
I've been meaning to scratch an itch for a while: making feeds easier and experimenting with gemini clients. Specifically git-like clients. It's been a sliver in my mind ever since solderpunk mentioned using git for content distribution. So I built rover.
Rover operates on local filesystems by allowing you to 'subscribe' to directory updates. So you'll know if anyone, yourself included, modifies the contents of a directory. Want to subscribe to updates from another user on a pubnix? Or simply keep track of changes you're making to a few directories? Rover is happy to oblige.
Rover stores one file per directory and is built to be simple to use. All you need is python 3.6+ and 'rover.py' since there are no external dependencies.
Let's peek at an example.
Using rover for the local filesystem is pretty straightforward. Execute 'rover land <absolute-path>':
$ cd ~/tour $ rover land /home/clifford/rover/log clifford Land complete $ ls clifford <all of clifford's log entries>
Here we subscribed to Clifford's log. After executing the land, a replica of Clifford's log directory appears as the 'clifford' subdirectory in (~/tour/clifford). Okay, we've essentially copied Clifford's current directory state. That's well and good but how do we tell if Clifford makes changes? Use 'rover tour'.
'rover tour' can be executed from a subscribed directory or any parent directory. For example, after you landed Clifford's log, say Clifford goes to the beach and writes a new entry (/home/clifford/rover/log/JellyfishAttacks.gmi).
$ cd ~/tour $ rover tour A clifford/JellyfishAttacks.gmi A clifford/2021-05-04-Cliffords-Jellyfish-Classification.gmi M clifford/2020-09-03-Favorite-Treats.gmi
Looks like Clifford made more than one change! Two files were added and a previous file was modified. An 'A' in the first column means added, and an 'M' means modified. Deleted files will show up as 'D'. Rover recursively iterates through all directories underneath CWD and prints out changes.
Now say you've subbed to a number of different users whose local replicas exist under your ~/tour directory. How does one easily consume the content? One possibility is by running the following script from the ~/tour directory:
#!/usr/bin/env bash
rover tour | while read line
do
local_file=$(echo $line | awk '{ print $2 }')
rover fetch $local_file || exit 1
< /dev/tty less $local_file
done
And that's it. You'll see all of the new and modified files.
I kept a few ideas in mind while building rover. And a few other themes popped up along the way.
All rover commands, except for 'tour', are non-recursive by default. This lack of (default) recursion is intentional and suggests moving slowly and only keeping files that matter to *you*. Individuality is an underlying theme you'll find in rover.
As for state, there's a single '.rover' file stored alongside each directory. Rover files are UTF-8 encoded and easy to parse.
In git, entire directory hierarchies (and their history) are the operational unit. In rover, it's a single directory with no history. Well, no history other than what can be gleaned from a diff of stored files. A diff determining what *you* haven't seen yet. This facilitates the building of directory hierarchies that are individually meaningful. Want to check out a single directory in a git hierarchy and be notified of changes from the last time you saw it? Rover can be made to do that.
As a side note, git and rover work well together. Build a rover directory hierarchy inside of git to record all state changes, relevant to you, over time. More on this later.
Rover was designed to encourage you to keep only meaningful files. Landed directories are not meant to be a complete replica of the source directory. 'rover tour' will not bother you if it finds deleted files in your replica. You can keep using rover tour and only upstream modifications are shown. But, just in case, you can see deleted files using 'rover status'.
All files are expected to be text. Specifically UTF-8 encoded. Rover refuses to to transfer files that cannot be UTF-8 encoded but otherwise operates as expected.
This article briefly touched on the features of rover but there's a bit more to it. Subcommands like 'rover fetch', 'rover status' and 'rover submit' weren't covered. I've also begun building support beyond local filesystems. Gemini for example. And I'll write a post on these in a bit.
While rover's primary git repository is on tilde.git there is a mirror on github (for CI and experimentation). I've also disabled github's collaboration features in deference to tilde.git.
Since this is an experiment I'm focused more on utility than polish. There's some rough edges. And, hey, something like this may have been done before. So drop me a line if you have any questions, bugs or if you wish to put rover out to pasture with prior-art.