Awesome Philosophy
Nowadays, running a so-called “awesome list” of arbitrary technology stack/platform is almost turning into a de facto standard. However, of course, this type of list can be maintained for a lot more, say, metaphysical concepts.
Recently, I encountered with a decent repository named Awesome Philosophy, maintained by Digital Philosopher chogye. If you’re seeking a deliberate shift or conversion to the path of philosophy from another domain, this repository will serve as a valuable guide for you.
What is Digital Philosophy?
Defining a clear boundary for this beloved term would be quite cumbersome. Digital Philosophy, at its core, shouldn’t diverge much from our metaphysical approach to “the world.” The shift, or rather the juxtaposition of the digital, is happening mainly in response to the demands of historical advancement. Decades ago, the IETF laid out the specifications for Email, and now most significant communications are conducted via Email. The purpose of Digital Philosophy aligns similarly. As digital philosophers, we don’t necessarily believe that the digital world will ultimately prevail. Our very existence reflects the recent reevaluation of philosophical concepts, driven by historical progress.
Therefore, chogye’s Awesome Philosophy repository does not represent a guide to any fundamentally different philosophical field. Instead, I would argue that this guide is for those who genuinely wish to understand the world, utilizing the tools we are capable of mobilizing of the moment.
Radicle
Now this repository is running on Radicle, appropriate introduction is required for this technology. I asked ChatGPT for that very introduction, and here is the response:
Radicle is a peer-to-peer network designed for decentralized code collaboration, offering an alternative to centralized platforms like GitHub. It allows developers to share, contribute, and manage code repositories without relying on third-party servers by leveraging a peer-to-peer protocol built on Git. Radicle prioritizes user sovereignty and open-source development, ensuring that users have full control over their code and collaboration processes. By integrating with tools like Ethereum, it also supports decentralized funding and governance mechanisms, further empowering developers in a distributed, self-governed environment.
If you’ve been interested in the software freedom and related ideas, I believe the above definition is sufficient to draw your attention. Richard Stallman and Free Software Foundation provides the following general ideas of essential software freedom for humans.
- The freedom to run the program as you wish, for any purpose (freedom 0).
- The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
- The freedom to redistribute copies so you can help others (freedom 2).
- The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.
In the above code, adherence to freedom 0 and freedom 1 largely depends on the developers and maintainers of the software. However, freedom 2 and freedom 3 pertain to the distribution and redistribution of software. Often, distributing programs requires relying on a company’s server, which in turn means relying on their capital. While this setup resembles a shared economy, it’s essentially a relationship between you and the server provider. A company offering its computing power to users on a monthly basis might fit the concept of a shared economy, but it more closely resembles the Stalinist distributive economy of the Soviet Union. This approach can be useful for short-term information sharing (such as sharing a university project with groupmates), but it’s not ideal for long-term project maintenance, especially if you value your own and your users’ freedoms.
Instead, we can leverage the volunteered nodes in the network, those genuinely interested in your project, to host it collectively, rather than depending on a company that likely has little interest in your codebase unless you’re backed by an eye-catching venture capital investment.
Microsoft acquired GitHub in 2018. They also own 49% of OpenAI. One of our prophets of the future, the author Philip K. Dick, has shown us many projections of alternate dystopian realities that emerge when corporations amass too much power.
– Radicle user Guide
Getting Started with Radicle
Radicle already provides its own User Guide (https://radicle.xyz/guides/user), which is often sufficient, but I find it lacking in certain areas—likely because the project is still quite young. For example, their instructions on maintaining a private repository require a few extra steps that aren’t clearly outlined. Additionally, handling multiple Radicle IDs is not well explained, leaving some ambiguity. To serve as a humble supplementary guide to Radicle, I’ll offer a short cookbook to help address these gaps and provide clearer solutions for specific scenarios.
To begin, install Radicle on the system with the automated script. Make sure to use the authentic script from the Radicle site.
$ curl -sSf https://radicle.xyz/install | shHandling Multiple Identities
Radicle’s nature (Account <=> Identity <=> SSH KeyPair) implies the necessity of a structuralized method to handle multiple identities within a single machine. I’d say that it’s not a very good security practice to work with single Radicle identity whoever’s repository you’re working with.
Radicle’s guide instructs you to simply run rad auth after installation, which sets up a default Radicle configuration and key under the $HOME/.radicle directory. However, Radicle will use the $RAD_HOME environment variable if no identity is found in the default location. Thus, to better manage multiple projects and identities, I recommend using direnv to set this environment variable per project. This way, you can ensure that you’re always working with the correct node and identity specific to each project, providing a cleaner and more organized workflow.
So instead of running rad auth right away, initialize your git/radicle project like the following (Don’t forget to set your local git name/email! Omitting this might expose your personal information to commits pushed to Radicle):
# Install and setup direnv first from https://direnv.net/
cd your_project_dir
git init
# **Don't** forget to set your local git name/email
git config user.name "<your radicle alias>"
git config user.email "<your preferred email>"
echo "export RAD_HOME=$HOME/.radicle/identities/YOUR_PREFERRED_ID" > .envrc
direnv allow
rad auth # now your identity will be created under $RAD_HOME
rad node start # node started here works only for its spawnning id
git add .envrc
git commit -m "Radicle ID set"
rad init # --private if you want a private repository
git push rad masterGit Local Configuration – Sign Your Commits
Radicle User Guide made this part look like recommendation (“By the way since your Radicle key is a valid SSH key, it can be used to sign Git commits since version Git 2.34.0…”), but I humbly think this is mandatory for all users. To make your $RAD_HOME variable set by direnv effective, run the following commands provided by the User Guide, in the repository directory of your interest:
git config user.signingKey "$(rad self --ssh-key)"
git config gpg.format ssh
git config gpg.ssh.program ssh-keygen
git config gpg.ssh.allowedSignersFile .gitsigners
git config commit.gpgsign trueCloning
One should be allowed to clone the repository from the network if you pushed it. The process itself, is simple (compared to what is happening under the hood). Obtain the Repository Identifier (RID) of your own project.
rad .
# This will return a value like rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5, which is your RID.Then, use the RID to clone the project from the other system.
rad clone <RID>
# For example, rad clone rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5For public repositories, it is that simple. Let’s talk about private repository now.
Seeding
As mentioned earlier, the Radicle network is composed of voluntary contributor nodes, and in order to interact with the network, you must start a node. For example, cloning a repository, as done earlier, is also performed through a node. When rad clone is executed, rad seed is run behind the scenes. What is seeding, then? It means that you are also participating in hosting that project in a simple way. The official guide declares the following ethical code:
To seed is to give back. By seeding repositories on the Radicle network, you offer bandwidth, storage, and data availability to Radicle users.
The implications of this are quite profound. In the case of traditional Git hosting companies, the Stars or Upvotes that other users give to your project are no different from the “Like” button on social media. The direct help that this “Like” button offers to your codebase, devoid of any cult value (W. Benjamin), is purely an increase in its exhibition value. Ultimately, the project chosen by the algorithm will be “displayed” to many people. That’s the extent of it, and the ultimate goal.
In Radicle, seeding replaces the Star. Instead of blindly acknowledging the exhibition value of a project, participants contribute part of their bandwidth to that project, aiding in the preservation of the data. Of course, preservation also contributes to an increase in exhibition value. But what’s important is that this is not the ultimate goal. If we had to name it, we might call it an increase in archival or philological value.
In short, to send praise to a repository in Radicle, for instance, rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5, you can simply execute the following command:
rad seed rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5Collaborating with People
Contributor
Using Git hosting services like GitHub is convenient. It provides you many functionalities like Pull Requests, following each other, and so on. However, vanilla Git workflow is slightly different. It is a good practice to remind several forgotten collaboration functions of Git, which is still actively being used by Linux Kernel developers, collaborating over their mailing list. We can reference to <Awesome Philosophy>’s CONTRIBUTION section.
# 새로운 anomalous-data-897af 브랜치 생성
git checkout -b anomalous-data-897af
# 변경 사항 추가
git add test.md
# 커밋 생성
git commit -m "add test markdown file"
# 패치 브랜치로 푸시
git push rad HEAD:refs/patchesHere, changes you made will be sent to the remote rad. HEAD refers to the latest commit on your current working branch (anomalous-data-897af). The last push command will push your latest commit to the remote rad, under the refs/patches namespace. Then the repository maintainer will be able to take a look at the patch, and merge it accordingly.
Maintainer
To list all the submitted patches from your repository contributors, invoke the following:
git ls-remote rad refs/patches/*If you found a patch of your interest, run git fetch.
git fetch rad refs/patches/<patch-name>Then you can checkout to that patch branch with git checkout FETCH_HEAD, where FETCH_HEAD is a reference pointing the lastest fetch.
git diff FETCH_HEAD
# where FETCH_HEAD == refs/remotes/rad/patches/<patch-name>
git merge FETCH_HEAD
# If you want to test the branch first, `git checkout refs/remotes/rad/patches/<patch-name>`
git pushIf you’re using a handy git visualization tool like magit (https://magit.vc/), you can easily skim over patch diff just like you do in prestigious Git hosting websites.
