Low budget P2P content distribution with git
--------------------------------------------

In recent months I've spent a lot less time than is typical thinking
about anything to do with computers and the internet, but there is
one train of thought I've been repeatedly pondering.  I had hoped to
write up a bunch of less technical stuff first (don't worry, that's
still coming - I'm kind of disappointed in myself that I've lapsed
into writing a massive computery, internety post so soon after coming
back to writing here.  Bad Solderpunk!  In penance I'm going not
going to write any more for at least a month - stay tuned for
cycling, environmentalism and manga, though), but it seems like this
technical idea has become just a little topical just recently, so
perhaps now is actually a good time to get this idea out there.  Let
me be very clear from the outset that I'm just idea-sketching out
loud here.  This isn't a new project, or anything, I'm not giving the
system I'm about to describe a name or committing to fleshing out the
details or anything like that.  That's not to say nothing will ever
come of this, I just want to make it clear from the outset that these
ideas are half-baked at best and I'm absolutely not committed to
jumping head first into wherever this train of thought leads...

Protocols like Gemini and Gopher are an effective salve against many
of the miseries inflicted by the modern web, but by no means do they
solve *all* the web's problems.  All three systems share the same big
picture architecture, namely that the default pattern of usage is
that content lives in exactly one place, a server which is online
24/7, 365 days a year and accessible from anywhere on Earth, and that
to consume this content you request a copy of it at the instant of
consumption, render it to the screen and then discard it (perhaps
after a relatively brief cache lifetime), leaving no persistent copy,
with the understanding that if you want to read something again next
week or month or year you'll just request a fresh copy and do all
this again.  Because all three protocols work this way, all three of
them share a long list of common shortcomings, mostly about losing
access to stuff you'd like to still have access to.  Online content
can become inaccessible to *you* in the short term if your internet
connection goes down.  It can inaccessible to *anybody* in the short
term if the server goes down.  It can become inaccessible to large
groups of people in the *long term* due to the ease with which
authoritarian governments can block access to a single server.  It
can become inaccessible to *everybody* *forever* if the hosting
service disappears (think Geocities), or if the person running a
private server dies or is incapacitated and none of their friends or
family know which bills to pay to keep the thing up.  These problems
can be mitigated to some extent via load sharing, content delivery
networks, caching proxies, etc.  All these solutions involve setting
up yet *more* computers which are switched on and connected to the
net 24/7, which is expensive both financially and environmentally.
On a long enough timeline, the survival rate for all websites drops
to zero: find some mailing list archives from the late 90s or early
00s and try visiting all the URLs people shared in it.  More than 90%
of them won't work.  20 or 25 years is not an awfully long time span
for this kind of decay to happen in.

None of these observations are new or exciting, and there are no
shortage of projects attempting to address various of these
shortcomings in various domains.  You've maybe heard of DAT[1] and
IPFS[2] and SSB[3], and those are just the Johnny-come-latelies to
this sphere.  Freenet[4] has been around for over 20 years, and I
don't doubt that it has predecessors of its own.  What all of these
projects have in common is conceptual complexity.  They're
distributed, decentralised, peer-to-peer, content-addressed,
cryptographically authenticated, and more.  This isn't intended as
a criticism.  These projects have a much higher ratio of essential
complexity to "empty complexity" than something like a modern web
browser, because they're trying to solve substantially more
difficult problems, making some conceptual complexity is
unavoidable.  But all of the projects above and their associated
ideas have met with fairly limited implementation by developers and
fairly limited uptake by users, and I think the high barrier to
entry represented by a lot of conceptual complexity, even if it is
essential, is probably a large part of the reason for this (that
and a healthy serving of apathy, no doubt).  I'm not trying to
say that the search for clever solutions to these problems is futile,
not at all.  I'm just laying out what seem to me to be the facts.

Completely solving the problems associated with an always-online,
purely client-server web is never going to be easy.  The wait for
something which works well enough and is user friendly enough to
facilitate serious uptake is going to be a long (though hopefully
worthwhile) one.  In the meantime, it's tempting to wonder whether or
not there is some kind of "80:20" solution to these problems which
gets at least some of us at least some of the way there - enough of
the way to be worthwhile - without a huge learning curve.  Lately
I've been thinking that maybe there is, and that maybe it's actually
not even all that hard.  In fact it's so incredible simple that I'm
almost embarrassing to say it out loud, out of fear that if it were
*that* simple then people would *obviously* already be doing, so
clearly I've missed something big due to not being smart enough.  Or
maybe some people well of my radar *are* doing this, and that's what
I've missed.  Anyway, are you ready for this huge idea?  Here it is.

Use git.

No, really, just use git.  Not the way you're possibly using it
already (like I am), as a kind of deployment mechanism, where you
write your posts locally, commit them to a repo, then push to a
remote copy of that repo only you have access t only you have access
to, triggering a hook which checks out a copy of your work in
whatever directory your web/Gopher/Gemini server looks in (although,
if you're doing that, switching to using it the way I'm talking about
is a piece of cake).  I'm talking about using git for small internet
content the way people use it for source code, as an actual
distribution mechanism for ending up with a local copy of something
on our disk that you then use offline (by compiling it, interpreting
it, etc).  I'm talking about your text-centric online content being
nothing more than a public git repository.  If somebody wants to read
your posts, they clone your repo.  Then they've got your posts on
their disk, and they can read them from there. If they go offline, it
doesn't matter, because your stuff is on their disk.  They can read
it today, and tomorrow, and next year.  If your server goes offline,
it doesn't matter, because your stuff is on their disk.  If they like
your stuff and want to read more of it, then next time both they and
you are online, they are one `git pull` away from getting any updates
you've made since their original clone.  There is no need for Atom,
or RSS, or carefully formatted index pages with datestamps integrated
into link text.  When distributing by git, visiting a site and
subscribing to a site are one and the same thing.  No extra
technological concessions to the notion of "subscribability" are
needed.  Furthermore, when distributing by git, visiting a site and
making a complete offline archive of the site are one and the same
thing.  There's no need for slow, clumsy, error-prone and
admin-irritating loops of repeatedly fetching and parsing files using
tools like wget to discover the URL of every single resource in a
site.  You just grab the whole thing at once in a single network
transaction, no parsing required.  Git is actually better than
Atom/RSS and recursive wget combined!  An Atom or RSS feed usually
only has the 10 or 20 most recent updates in it, so if you're offline
for a long time you'll miss some stuff.  Git won't, you'll get every
commit made since your last pull.  And a recursive wget just leaves
you with an offline copy of an entire site as it was in one point in
time.  There's no way get *just* the new stuff one month later -
sure, with HTTP(S) you can use headers like If-Modified-Since to
avoid fetching new copies of stuff that's changed, but you still need
to make a request for every single page which *could* have changed.
With git you just pull and that's it.

I've barely scratched the surface here.  I'm going to keep going, but
first let's really quickly think about this from a network privacy
point of view.  Cloning or pulling a git repo involves making network
connections to *one* server, known in advance, and has no side
effects.  There are no cookies or anything cookie-esque to tie
subsequent requests together at a more fine-grained or persistent
level than the IP address.  This is much better than the web, and
exactly on par with Gemini and Gopher.  If you want to, you can do
git stuff over HTTPS or SSH, and that's normal and standard, so in
this respect we're better than Gopher where plaintext is the only
option.  But if you don't want to use crypto, or your computer can't
handle it, or you're using some futuristic internet overlay like
Yggdrasil so you get transport security without baking it into every
protocol, you can do a plaintext git:// clone.  So for some folks
this is better than Gemini, where it's TLS or bust.  But the
git-as-distribution-tool approach gives you something that none of
the web or Gopher or Gemini give you: it's one network transaction
for the *whole site*, and that's it.  A git admin knows that you (or
rather, your IP address) has cloned their repo and now has all their
posts.  But that's it.  They don't know which posts you read, and
which ones you don't.  They don't know which posts you read once and
which ones you read every day and which ones you only read in the
middle of cold, lonely nights.  There is nothing like a "click
stream" for them to analyse.  Even the boogeyman of "traffic
analysis", where the size and latency of opaque encrypted
transactions are used by third parties to reconstruct your path
through a public site gain no traction here.  Your fine-grained
consumption habits are entirely invisible to everybody but you.
That's really neat!

One more brief digression: I've described everything so far in
network terms (and will get back to that shortly and then do it for
the rest of this post).  But keep in mind, please, that there is
*nothing* network-centric about this idea.  We're all very used to
doing git clones and pulls over TCP/IP, but you can clone and pull
from the filesystem just fine.  Try it.  Git won't bat an eyelid.
That means you can clone and pull from USB sticks and SD cards, which
means this whole thing works just fine over sneakernet.  You don't
have to go "all in" on sneakernet, you can mix and match it with
networking in whatever proportion suits you, and transition slowly
from using mainly one to mainly the other on an as-needed basis.  I
think about sneakernet a lot these days, and I think anybody else
who's interested in sustainable/perma-/salvage computing ought to as
well.  I'll write more about this some other time.  Let me just say
for now that the fact that this git-for-distribution thing works
seamlessly via sneakernet is a big plus for me.

Okay, back to the main thrust: by visiting/archiving/subscribing to a
site via git we get even more than Atom/RSS and recursive wget
combined can offer, with less effort on the part of either producer
or consumer.  Jake.  But so far we've still talking about readers
fetching content from a single authoritative source operated by
authors, so we still have a lot the usual centralisation problems.
This approach still puts a potentially heavy load on one
authoritative server, it still requires lots of long distance data
traffic, and if the author's server disappears forever *before* you
got a chance to clone the repo, you're out of luck.  Getting past
these hurdles in a web/Gopher/Gemini context isn't easy.  If I use
recursive wget to get a complete local copy of some website, then in
order to enable somebody else to use a recursive wget to get a
complete copy from *me* (because my server is closer, or more
reliable, or the original is gone) there's a lot more rigmarole
involved.  I'd need to setup a webserver and point it at my copy, and
there's no guarantee that alone is enough.  The site may not work
properly without suitable URL rewriting or redirecting rules or
similar configuration details in place on the server side.  I'd need
to reproduce those settings exactly, and the information required to
do so is *not* something I'd end up with as a consequence of doing
the original recursive wget.  So the whole procedure kind of only
works once, and can't reliably be chained, with an n-th party getting
a fully functioning copy from a (n-1)-th party's copy.  Even if
redirects/rewrites weren't in the picture and this chaining *was*
possible, there'd naturally be a big question of trust, as at any
stage along the chain the site could be modified by somebody other
than the original author and you'd be none the wiser.  But none of
these problems are there in the git version!  You can clone a clone
of a clone no worries, that's normal.  Everybody who "visits a site"
distributed by git has everything they need to *redistribute* the
site.  And git has built-in support for signing commits with GPG,
which can go a long way toward resolving the trust problem (public
keys can be distributed as part of the repository itself, which works
out alright as long as you can be confident you make your initial
clone from the genuine origin - not foolproof, but much better than
nothing).  All of this is just bog-standard git functionality, tried
and tested, nothing new or exciting, 100% ready to go and documented
in countless sources.  This stuff is exactly what makes git a
*distributed* version control system.  The new idea here is really
nothing more than using it to distribute writing to readers, instead
of source code to developers or users.

It turns out we've *had* a decentralised, distributed, offline-first
system for P2P storage and delivery of text files for 17 years now!
It was just created for an application very different from
blogging/phlogging/gemlogging.  By the time git became an established
and familiar technology, the web was in the full blown grip of "web
2.0" fever, and static, non-interactive content that was 90% text was
consigned squarely to "the past".  This resulted, I think, in a
missed connection, which maybe we can finally make.  There's nothing
fundamentally wrong with interactivity, of course, nor with non-text
media, either.  But I don't need to tell anybody who is reading this
via Gopher or Gemini that there's a whole universe of material which
is interesting, or informative, or useful, or amusing, or uplifting,
or otherwise valuable even if it's "just text" and even if you read
it days or weeks or months or years after it was originally written.
That's not a unique property of source code.  It's true of our little
small internet world, too!  Git is just perfect for distributing
exactly this kind of writing.  You get delay-tolerant subscription
for free: Atom and RSS can go to the dustbin of history.  Constant
internet connectivity is not required, although it doesn't hurt.  You
can pull from all your repos four times a day every day if you live
all the time in an apartment with a permanent high-speed internet
connection.  If you're trying to spend less time online because you
think that's better for you in some way(s), you can connect once in
the morning, pull from all your repos and then disconnect and read
what you received at your leisure.  If you live on a boat and
sometimes go without internet access for weeks at a time, that works
just fine too.  If you are travelling without regular internet access
and you meet somebody on the way who follows some of the same repos
you do, whichever one of you pulled from upstream less recently can
pull from one who did so more recently to get some updates on the
road - and then pull later from the official source once back in
civilisation, without this switching of sources causing any problems.
Stuff can continue to circulate for years after the original source
disappears, provided enough people were interested enough in the
first place to clone it and make their clones readable.  To be
honest, this feels to me like it could be an even better small
internet platform than Gopher or Gemini, at least for some kinds of
content (for others, perhaps not - I'll return to this later).

Of course, this is nothing like a *real* solution to any of the nasty
problems of centralised client-server distribution.  You can update
your clone of a git repo from some source other than the original,
official repo, and have confidence that what you get is genuine
thanks to PGP, sure - if you know about that other source in advance.
But there's no magic means by which knowing only the URL of the
original repo you can automatically find the most up-to-date third
party copy or copies which are online now and close by to you in
network terms and pull from them instead.  That's the kind of hard
problem which makes real P2P systems complicated, and git does
nothing at all to solve these.  But we can 80:20 around this to some
extent.

I've been vague up until now about exactly how this works in a hands
on, daily use kind of way.  I'm not proposing we literally spend our
time doing git clones and git pulls manually by hand all the time
(although you *could* use this system that way, and that should be
seen as a feature, just like being able to access Gopherspace via
telnet).  We can build tools to streamline things.  This is largely
the reason, incidentally, for using git in particular and not
Mercurial or Fossil or whatever else might be hot these days.  Git is
ubiquitous and isn't likely to stop being so anytime soon.  It's been
ported everywhere - you can use git today on Plan 9 or Minix 3 or
whatever weird system floats your boat (are there still open source
descendants of Solaris out there?  If there are, I bet they have
git).  There are bindings to libgit in all major programming
languages, allowing you to automate this stuff.  All this work has
already been done, and these tools are going to be kept up to date
and ported further and documented better by people who don't know and
don't care about the small group of dorks using git as a plain text
content distribution system.  It's exactly the same philosophy behind
using TLS for Gemini and not something newer and better.  Tiny
guerilla computing projects can't afford to ignore the opportunity to
have the enemy manufacture our weapons for us.  So we build tools
based on git, because a lot of us already know how to build them, and
once they're built they'll be usable just about everywhere.  We can
throw together something which has the look and feel of a traditional
Atom/RSS-based feed reader, but it's powered by git under the hood,
it just looks at timestamped commits to figure out which files were
updated when.  And there's no reason we can't standardise on every
repo designed to be used in this way having (or *optionally* having)
a directory in the rep root with a well-known name which contains
simple .ini or .json or .yaml or whatever files (no doubt getting
everybody to agree on one of these would represent 99% of the work of
actually bringing this idea to fruition) that provide a little bit of
metadata in an easy-to-parse format.  These could provide some of the
feed metadata that you'd traditionally find in Atom/RSS, like a
repository's title, subtitle, author, contact details and license
information.  They could provide GPG public keys.  And they could be
used to advertise the URLs of clones of the repo, its "official
mirrors", and maybe where these clones are in the world and at what
times of day they are mostly likely to be online (ditto for the
original).  The git-aware app could register all those URLs as
additional "remotes" for the repo, and it could preferentially try to
pull from the nearest one most most likely to be up when the user
hits "refresh", and if that remote was down, it could fall back to
the second best choice, and so on.  This involves some manual
coordination between authors and willing mirroring parties, and
introduces a kind of dichotomy between "official mirrors" and
"unofficial mirrors" which you'd need to learn about out of band and
tell your client about, but I suspect we can tackle this in the usual
grass-roots, small internet way and still end up somewhere better
than we are right now.  It's far from perfect, but it's also far from
awful.

And we're *still* really just scratching the surface of what doing
this would enable.  To make it explicit, we're talking about a system
where every participant keeps a full copy of the full history of
every site they visit on their hard drive indefinitely.  This sounds
nuts at first.  It also sounds nuts that in this system there is no
way to fetch just a single post - if you want to read one post that
somebody has told you about, you have to clone the full repo
containing said post.  That's, in some sense, woefully inefficient!
These concerns diminish rapidly if we start thinking small.  I've
been phlogging on Gopher for over four years now.  Anybody who has
been following me all that time knows that I am *not* a succinct
writer.  I am relentlessly verbose.  And yet, my phlog directory is
1.7 megabytes.  Having to clone that whole lot to read one post
doesn't seem so horrible knowing that.  When visiting a single blog
post on the web today you could easily pull down a lot more than 1.7
MB of external fonts, style sheets, surveillance Javascript, flashy
background images and more.  Cloning my whole phlog repo to read one
post is less efficient than using Gopher to fetch just that one post,
but it's still more efficient than the status quo of the web.  Let's
suppose that I continue to phlog at the same exhausting level of
verbosity for fifty whole years in total.  That would bring me up to
just over 21 MB, which we can round up to 25 MB to make things
simpler.  Now, suppose you didn't want to just read *my* fifty years
of rambling, but you wanted to read the ramblings of *one hundred
people* who all wrote excessively for fifty years - arguably more
output than any person really has the time to read.  This would bring
us up to 2.5 GB.  That fits several times over on the smallest USB or
SD storage device you can buy.  Businesses literally give that much
storage away for free in the form of promotional key chains.  The
above calculations could be off by a factor of ten (git itself
obviously introduces some degree of storage overhead which I've
completely failed to address so far and, in truth, know almost
nothing about, but I'm pretty sure it's nothing like a factor of ten)
and the storage burden of 25 GB would still be underwhelming, even
for a 20 year old machine.  We really can live this way.  Text is
*small*.

Having full local copies of everything ever written by anybody whom
you've ever read a single small internet post by is a game changer in
and of itself.  Stuff like archive.org becomes at least partially
obsolete, because you have the full history of each site locally.
You can, to some extent, be your own search engine.  Obviously you
can't search your own disk to find stuff you've never previously
fetched, but you can easily find stuff you vaguely recall reading a
year ago, and if you've only just recently started following somebody
who has been writing for years, you can search their back catalogue.
You can ask your computer to find other posts you have on your disk
which are "similar to" some particular post, in terms of them both
using similar words or phrases which are otherwise rare.  All sorts
of machine learning, pattern recognition, recommendation engine type
stuff could be done, if you wanted, but it's something you could do
yourself entirely on your own machine with complete control and
transparency and perfect privacy.  If one of those metadata files in
a well-known location in every repo mentioned earlier was a kind of
machine-readable "git-roll" where authors could advertise the URLs of
other repos that they are reading, then you could even do a little
casual repo spidering (with a configurable maximum amount of disk
space and monthly bandwidth dedicated to this - possibly both set to
zero if you don't care for it).  This all sounds somewhat futuristic,
but indexing and searching and identifying fuzzy conceptual
connections between a couple of gigabytes worth of text files is not
exactly the computational cutting edge.  I'm starting to feel like in
some ways we have been denying ourselves super powers for years
simply by continuing to distribute our content in a fashion which
makes it really impractical to grab sites wholesale, even though the
bandwidth and disk space required to do this (for simple text files,
anyway) has long been easy to come by.

I've been unrelentingly positive about this whole prospect so far.
So many benefits to content distribution via git!  Aren't there any
problems?  Well, sure.  There are two big ones that I've identified
so far.  One is technical, the other is, uhh, sociological?  Or
something?  Let's deal with that one first.  The basic issue is that
stuff on the internet can become unavailable in two different ways.
Sometimes stuff disappears involuntarily - due to technical faults,
censorship, business failures, financial problems, etc.  But
sometimes stuff disappears because the author didn't want it up
anymore and willingly took it down, which feels like a reasonable
thing for authors to be able to do if they like.  We might, very
roughly, think of these as "bad disappearances" and "good
disappearances", respectively.  The problem is that it's not possible
to solve the bad disappearance problems without making good
disappearances impossible.  Publishing something via this git system
is in principle permanent and irreversible.  If just one person
clones or pulls from your repo before you take it down, other people
can pull/clone from them and there's nothing you can do to stop this
beyond asking nicely.  It's not just "taking stuff down" that becomes
infeasible.  If you change your mind about something you wrote ten
years ago and want to change it, you can do so - but everybody
"subscribed" to your repository will be notified of this fact and
will be able to see both the before and after versions.  This kind of
publishing is, by necessarily, radically long-lasting and radically
transparent in a way that people aren't used to and many may not be
ready for.

Many will say that the internet is *already* like this and you can
never guarantee that anything you publish, via any protocol, won't be
redistributed forever.  This is exactly right.  It's the very nature
of a global network of general purpose computing devices, and we
should never fool ourselves into thinking that any technology can
prevent this.  Furthermore, this isn't a problem unique to using git
for publication, it's going to be a problem in *any* solution to
these problems.  Does that mean we should just forget about this
issue?  Maybe not.  Just because something is always possible in
principle doesn't mean that making it as quick and easy and
convenient as possible will be without consequence.  An internet
which never forgets is handy in a lot of ways and in a lot of fields
of endeavour.  It's also strongly mismatched with human social
psychology and norms.  The small internet crowd tends to place a lot
of emphasis on "human scale" computing and on personal connections,
so I think this is worth flagging this and encouraging people to
think about it.  But I do also think it's possible to overstate how
big of a deal this is.  Maybe I've already done that.  I dunno.

The other big problem, the technical one, is that of linking.  That
whole hypertext thing.  Let's consider a "gitlog", i.e. a
blog/phlog/gemlog-style resource which is published exclusively via a
public git repository, and is not hosted on any of the traditional
server-client request-per-page protocols ("gitlog" is a horrible name
for this thing because it will cause massive confusion and search
engine collision with the `git log` command, but I'll use it as a
placeholder for now).  Internal links within one gitlog are
straightforward (at least if it's in HTML or gemtext, both of which
support relative URLs), but how does the author of a post in this log
provide a link to an individual post in another gitlog?  An
unambiguous pointer to an individual gitlog post necessarily has two
parts: the URL of (any clone of) the repository, and a path relative
to the repository root indicating the file containing the post in
question.  I am not aware of any pre-existing URL scheme for
unambiguously conveying both these things at once, nor of any
pre-existing hypertext format which allows "two part" links.  It's
not remotely hard to imagine how to cook up either one, perfectly
straightforward in fact, but ugh, once we do that this stops being a
super minimal "just use this existing thing to distribute your
arbitrary existing text, with maybe a tiny bit of optional helper
metadata sprinkled in if you want" approach and becomes a whole
*thing* with its own unique format which you have to buy into.  I
really like that a lot of people are basically already 100% geared up
to distribute their smol content this way by just making the private
repository they already use for deployment publically readable, super
quick and easy, no other change required.  Anything which stands in
the way of that feels like a bad idea.  But without a standalone
pure-gitlog linking solution, the whole system is limited to
bihosting scenarios, where git-based distribution kind of lurks
behind the scenes, and plain old gopher:// or gemini:// links what we
actually include in our posts.  This is not great, but perhaps
something we can live with?  Maybe there's a convention where if your
Gopher or Gemini content is also available in this way, you configure
your Gopher/Gemini server to respond to requests for a certain
well-known endpoint with (i) a git repo URL and (ii) a regex or
some-such for transforming your gopher:// or gemini:// URLs into
paths relative to your repository root?  That would work, I think, as
a kind of easy machine-readable "gateway" from the Gopher/Gemini view
of things to the git view of things.  Maybe there are even better
ways?  I don't mean to suggest we can't somehow make this linking
thing at least roughly work, I'm just highlighting that this is the
most substantial issue I've thought of without an obvious and easy
solution.  I still think there's something worth pursuing inside all
this.  Hell, even if we give up on external linking, that's not the
end of the world.  The short, whimsical urban fantasy of Joneworlds[5]
is a genuine gem of modern Gopher/Geminispace, and the vast majority
of it is entirely self-contained and very little would be lost by
distributing it without any links at all.

I think at last that this is all I have to say about this for now.  I
mean, there's more I could say, all sorts of little details, but I
think this is enough for now, to get the idea out there.  I am happy
to release this idea into the electronic wild and see what kind of
life, if any, it may take up in the minds of the denizens of the
small internet.  I look forward to hearing people's thoughts.

I've written all this up over the past week or so (took longer than I
thought it would!), but the core of the idea has been brewing for a
few months, and I've been influenced in various ways by some stuff
that I wrote and also some stuff I read over the past year or two.
I'm going to try to dump links to all of these influential things
below, but this probably won't be exhaustive, sorry.

I got started thinking about using git for content distribution
during the formation of Circumlunar Space's newish zine project,
Circumlunar Transmissions[6].  The zines are hosted via Gemini and
Gopher, but you can also clone a git repo, the idea being that people
can use this to easily host Gemini or Gopher mirrors.  At some point
I started wondering about the possibility of just skipping that last
part and distributing it entirely via git.  A zine is a *perfect* use
case for this.  No sane person expects a zine to be editable or
deletable after release.

I was motivated to write this stuff up *now*, not in another week or
a month, by a recent post by ploum[7] which asked "Could we imagine a
decentralised and delay-tolerant network simple enough so you could
implement it in a day?", and envisaged a system where folders of
PGP-signed Markdown documents are copied to the local disk and
browsed from there.  There are some extra ideas in there about using
the system for something like email, too.  If you ignore that part
and just focus on the Markdown distribution, well, I think git
basically already does this.

Not long at all after I read that post and decided I had better start
writing, I came across a short article[8], inspired by the off-grid
working habits of the 100 rabbits crew[9] (who produce code and art
while living on a 10 meter yacht, occasionally taking breaks to make
awe-inspiring and death-defying ocean crossings), which asserted that
"saving pages with wget is like low-budget p2p" (inspiring the title
of this post), and asked a bunch of provocative questions:

* What if the browser was local-first?
* What if websites showed up as files and folders on my computer?
* What if the browser saved a copy of everything I bookmarked?
* What if I had my own personal wayback machine?
* What if I had a little local Google that could search the full text
of everything I’ve ever saved?
* What if I could copy those website files and remix them? Add links.
Mark them up with highlights Write margin notes.
* What if the whole web was built around copying/remixing/sharing?

Using git for distribution straightforwardly opens up all of these
possibilities.

In writing this up, I tapped into some older ideas.  The first is one
of my own: I made a phlog post about 2 years ago wherein I claimed
that "on a computer with even vaguely modern specs, it would probably
be possible to use a Gopher client which *automatically and
immediately* archived every singe documented you visited, as you
visited it, and maintained a searchable full text index of those
archives, without this being unduly taxing on processor time or disk
space"[10].  I discussed this in the context of the value of being able
to easily disappear, which is something we lose with git distribution.

I take the question of when, if ever, radically permanent online
writing make sense as seriously a I do because of an even earlier
past made by Alex Schroeder[11], concerning the Secure Scuttlebut
protocol.  Alex says "I don’t like systems where I cannot delete
things. I don’t need non-repudiation since I’m talking to people,
not signing contracts. Basically a “unforgeable append-only”
system is similar to a legal set of contracts and not at all like
conversations in real life".  He's well aware that it's impossible to
guarantee all participants in a distributed system will comply with a
request to delete something, but still thinks it's better to build
systems which at least *try* to let us undo.  I'm still not 100% sure
I agree, but I totally understand and respect the perspective.
Systems with a hard "no take backs" property shouldn't be designed or
used lightly - especially not in light-hearted social contexts, where
they seem an especially bad match.

Drew Devault wrote about a year ago[12] about better (open-source,
non-commercial, pro-privacy) approaches to search engines, in which
he floats the idea of search engines not crawling the entire web, but
limiting themselves to a list of "tier 1" domains which are
"authoritative or high-quality sources for their respective
specializations", as well as pages which link to tier 1 domains.  My
idea of doing just a little bit of exploratory spidering and indexing
of the git repos which are advertised in those repos you subscribe
to, ending up with the ability to search a small, socially-defined
corner of "gitspace", was inspired by this.  Search is a useful
feature even if you can't search *all* the things.

[1] https://www.datprotocol.com/
[2] https://ipfs.io/
[3] https://scuttlebot.io/more/protocols/secure-scuttlebutt.html
[4] https://freenetproject.org/
[5] gopher://republic.circumlunar.space:70/1/~joneworlds/
[6] gopher://republic.circumlunar.space:70/1/zine
[7] gemini://rawtext.club/~ploum/2021-10-10.gmi
[8] https://subconscious.substack.com/p/saving-copies-of-everything-is-like
[9] gemini://gemini.circumlunar.space/users/hundredrabbits/
[10] gopher://zaibatsu.circumlunar.space:70/0/~solderpunk/phlog/the-individual-archivist-and-ghosts-of-gophers-past.txt
[11] gopher://alexschroeder.ch:70/0page/2018-06-29_No_Take_Back
[12] gemini://drewdevault.com/2020/11/17/Better-than-DuckDuckGo.gmi

You are viewing proxied material from zaibatsu.circumlunar.space. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.