There’s more detail in this post, but this is one of a series of posts investigating the Free-as-in-Freedom social networks that are available, to see how they compare to the for-profit networks that exploit users. Each post is an overview of the system I have been and will be working with, along my general impressions.

Feel free to contribute your own findings as I go, either on the same networks or pointers to and descriptions of any networks I may have missed.

gitgeist's architecture

Note that I’ve added a specific socialshowdown tag to easily collect these posts, if you want to easily find the other posts in the series.

This time through, we have an entire social network designed to work without much of a data network.


Like twtxt, this is another very new discovery for me, only stumbling on it this week as I hit the home stretch of this project. But the gitgeist network is a proof of concept for a distributed network that used git for storage and transfer, with a small server to generate a static web page. And geist is the German word for “ghost.” Sounds like fun!

To be brief, this is a lot like a static blog generator (such as I already use), so a lot of this may already seem familiar.

Getting Started

The quickstart directions are straightforward enough. To summarize, though:

  • Clone the gitgeist repository to get access to the system scripts inside of the blog.
    • Symbolic links work well enough on Linux, but you could probably clone the scripts inside of your gitgeist content folder and add it to your .gitignore file, instead.
  • Run the initialization script with a host name, port, e-mail address, user name, and password. The last two will be useful later.
  • Run the server.

You now have a working page with no content, and a git repository accessible under the /git path. You want to clone that path (http://localhost:9005 in the gitgeist example) for writing posts.

User Experience

In your clone of the (empty) blog—it’s basically a blog, after all—you have two items of interest.

  • following is a list of followers.
  • style.css is the stylesheet for your page, which you can modify to whatever you like.

To post content, you’ll need to add a posts directory. Each post should get its own (numbered) directory under that—so posts/0001, posts/0002, and so forth—and an goes in those with the post contents in Markdown.

Once you have a post, you then create a signed commit to validate the you are the person posting, and push the changes. The server will automatically get the changes and update the page.

To post comments on posts, the post’s directory needs a comments subdirectory (for example, posts/0001/comments) and a Markdown file gets dropped in there. Commit and push, and the comment will appear. If you’re commenting on somebody else’s post, you need to clone their repository and go through the same process.

Note that this is a security issue, because it requires allowing public access to your repository, so anybody can upload anything to your server. But it works…

If you go back to your page and go to the /priv path (so a URL of http://localhost:9005/priv, in the documentation’s example), you’ll see content from the users you follow.

Which is all to say that the experience is pretty bare-bones, as befits a proof of concept.


I see a few people talking about the network, but don’t see anybody on the Internet saying “follow me on gitgeist” or anything like that—including the creator—so, I’m going to assume that there is no community until proven otherwise.

Verdict &

As a proof of concept, this is great. It operates reasonably well and while the user interface is terrible (for example, if you don’t sign every commit, you can no longer push to the repository) and has security issues (like allowing anybody to commit to the repository, meaning that they can technically modify your work), those are things that can easily be fixed.

I won’t be using it, because getting a Node.js server to run over Secure HTTP through my web server (like I do for my “person generator”) is too much trouble. But the idea has a lot of potential.

In particular, using version control to host each account means that you get the best of both worlds when it comes to editing: You can update or remove old posts so that they’re no longer casually available—unlike Scuttlebutt, for example, where every post is permanent—but the history of changes are still available—unlike twtxt, where you can hand-edit the text file to say whatever you please.

If it could resolve those problems, though, especially if there was an easy fix for security (difficult) and if it could periodically generate a single static HTML page I could serve separately (probably easy), I would absolutely give it a try for a few weeks.

Credits: The header image is the system architecture diagram from the gitgeist repository, made available under the terms of the Apache License v2.0.