Back in early July of 2018, through my interest in decentralized technology I became interested in the ActivityPub protocol, which then led me to discover an emerging alternative to Twitter: Mastodon Unlike Twitter that is run by a singular entity, Mastodon is a collection of federated servers with their own administrators and local communities. This meaning that the network is only down if all of the federated servers are down and a user can only be silenced if they are banned from every server (which can be a good or bad thing, depending on how you look at it). So having discovered this, I wanted to try it out and suddenly became overwhelmed by the variety of options that new users have to choose from for which Mastodon server/community I wanted to start with. I spent about half an hour scrolling through the list of servers reading through the descriptions of what their communities are all about to see if any of them resonate with me. Sure, I could just join the most popular server and call it a day, but given the decentralized nature of project that seems kind of oxymoronic and even a bit wasteful when there is the opportunity to find a niche community that fits the odd mishmash of interests you may have. In fact, that is exactly what I did, and it was how I discovered tilde servers.
The Mastodon server that piqued my interest was tilde.zone, which was one of the many services running on the tilde.team server. What makes tilde.team interesting is that it is a public UNIX server that provides a free shell login to whoever requests an account on the server. The users of these servers will also typically get a homepage they can edit under $HOME/public_html that can be accessed via their username prefixed by a tilde (e.g. tilde.team/~aewens). This in itself is not a new idea as servers like sdf.org have existed since 1987, but the new modern version of these servers started when Paul Ford created tilde.club on a VPS that we can now easily acquire and setup from services like Digital Ocean. These tilde servers (that get their namesake from that tilde prefixing the username for the homepages) can be cheaply and quickly setup unlike ever before and provide an environment for other *nix nerds to socialize with each other from their terminals.j
Back to tilde.team, once I found out it existed I immediately signed up to get an account and after one of the admins emailed me that my account was ready I logged in and joined the IRC hosted on the server. From there I got to know the head admin of the server, Ben Harris, who not only runs the tilde.team server, but also coordinated with other tilde servers to create the Tildeverse, a "loose association of like-minded tilde communities". The most impactful binding agent that brings these communities together is its decentralized IRC network, tilde.chat, that provides a round-robin host that points to all of the IRC servers hosted on the tilde servers that are a part of the Tildeverse, which allows all users of those tilde servers to converse with the other users in the Tildeverse network as one community. However, there are also a variety of other services available to Tildeverse members such as the Mastodon server I mentioned earler, a gitea instance, a lobste.rs clone for sharing links, and so on.
After awhile of being in the Tildeverse, I wanted to give back to the community and was able to do so by providing some logos I designed to replace the original ones made in MS Paint and later on creating an IRC bot that among other things mirrors the new news and forum entries to their relevant IRC channels. Though, I later on came up with another way I may be able to further give back to the Tildeverse community by going back to the roots that brought me to the ecosystem in the first place: decentralization. While there are certainly elements of the Tildeverse that is decentralized, as the community discovered during the Great Outage of 2018-11-13, tilde.team and all of the Tildeverse services are all run from the same server. During an outage of this server, unless if you have an account on one of the other tilde servers in the Tildeverse, you have suddenly lost all communication to the community. If there were a decentralized or federated system for the tilde servers like Mastodon, the Tildeverse could become more resilient to server outages (whether temporarily or permanently). It was this set of realizations that led to my pursuit of the Tilde Center Project.
For me, Tilde Center is many things. For a few years I have been looking into decentralized technologies with great interest, but never really had an explicitly useful application for it that did not already exist. As well, I have been trying to find a good excuse to implement a server architecture to serve as the backbone for replacing many existing services with open source alternatives that can share data between each other for the benefit of the users (rather than monitoring and tracking thereof) to truly benefit from the advantages of using services on the Internet. So I have brought these idealogies together to create Tilde Center, a decentralized network of federated tilde servers built atop home-brewed open source projects (aka HBOSP). The HBOSP factor may seem arbitrary, but I included it as a core element to the project a few reasons.
Firstly, one of the things that strengthened my connection with the Tildeverse community was when I began giving back to the community. Transitioning from being not just a user of the system, but a contributer of it, can give one both a sense of pride being in the community along with a stronger sense of belonging. I feel that adding this factor to the project to encourage users to get involved in the development of the project and get the change to experience what I did could create a powerful community regardless of how many are a part of it.
Additionally, for selfish reasons I want to create a community of developers. While I do not expect all of the users will participate in the HBOSP part of the community (though that would be great!), I hope that including it as one of the three core values of the project may bring in more developers who would want to join on those projects. Should this be the case, I can have more eyes on the project to catch the bugs I will inevitably add along with potentially having users that would want to propose or lead their own projects without me needing to be involved. While I anticipate being the one to add most of the initial code, I hope for this project to belong not to be, but to the community.
Furthermore, I feel one of the big reasons there are less decentralized or federated applications or services in the world is because of how intimidating it can be to get started due to all of the additional overhead that needs to be considered. So while HBOSP is a core value, right behind that I want to focus on simplicity in the way those projects are developed. The intent is not to be the fastest or most optimized solution, but rather the most approachable and maintainable solution. If even one user is able to get from the Tilde Center project a sense of confidence in understanding how to make their own decentralized and/or federated applications or services from working on something in Tilde Center, then that is already a success.
Lastly, while there is some merit to not spending time trying to re-invent the wheel when it has already been done, there is also great joy that can be had through the act of creation and exploration through doing something oneself to understand why it came to be done that way. As a wise man once said:
What I cannot create, I do not understand.
~ Richard Feynman
This is an ideology I live by as I thrive to understand everything in the world around me through either taking them apart to discover how they work or to try and invent it myself to investigate why it that approach was used. However, in a world where more and more often the norm for the codebase for developers to be 90% code written by someone else being imported in along with 10% actually done by themself I worry that we may lose the kind of thinking that thrives for understanding and merely settle for accepting at face value. Not only do I believe this be upsetting from an ideological standpoint, but also from a maintainability standpoint. To always be working at a such a high-level of abstraction from what is going on in the code (e.g. using a framework that relies on specific version from a multitude of libraries), it adds needless overhead and complexity when trying to fix any bugs that
may exist in all of the lower layers of abstraction. While I acknowledge that in the real world, it is not worth the time to rewrite everything for this sake, it is still important to occasionally take a step back and understand exactly how the stack you are using works at least one layer of abstraction down (for those interested in doing these kind of projects, there is a great GitHub repository for exactly these kinds of projects).
Though Tilde Center is one of the projects I am taking on (for the curious, you can read more on the homepage and RFC of the project), I have found that with how my personality works I can get fidgety when I am only working on one project for long duration of times and long to take a break working on something else. So I also have another project planned that I am quite looking forward to, which I may be able to find ways to integrate later into the Tilde Center Project later on. This would be that IRC bot I mentioned earlier, BabiliBot, though I am wanting to broaden the scope of what it can do by making it into a more general purpose bot that exists outside of realm of IRC. Though the project is in early developments now, it will later reside at babili.xyz, as I am shortening the name of the project to just be Babili (the origin of the name being the word "chat" in Esperanto). My initial plan is to make Babili into a composable processing engine where other modules (e.g. an IRC module to use IRC as one of the clients to interface with the bot) can be added on to extend its capabilities. As you might have expected from me by now, I want to design it to be decentralized so that I can scale the processing power of the bot as it grows while also being able to heighen its availability should any of its peers go offline. Once I have the core architecture in a fairly stable state, I am planning to make Babili into something of an open source personal assistant as the general objective behind the project, but given the versatility I have in mind for its core it would be able to be used in many other applications.
There is one last project I will be working on, but through working on it I will technically be working on both of the others. Because there are many similarities between the underlying data structures and software designs that I want to use in both projects, I will be working on a shared codebase called abots (short for "A Bunch Of Tiny Scripts"). While I am starting this library for Tilde Center and Babili, I have been anticipating doing this for awhile since I have written little snippets of useful code across previous projects that I keep looking up to use in others, and I figured it is about time I put them all together into one library so I can just look in one place to find all of them. Though this may sound like the problem I mentioned earlier of developers importing in a bunch of code for their projects, since I am the author of this library I would also have the knowledge of how the lower levels of abstractions within it work and thus would not just be blindly accepting whatever magic the library is taking care of. I also am not planning to market this library as something that others should willfully seek out to add to their own projects, as this would both go against the beliefs I mentioned earlier and would probably overall be a bad idea since I am designing this purely for my own convenience and would most likely not be as pleasant to use for other developers for applications intended for production.
Those are the new projects I am planning on working on, I do not imagine they will be done anytime soon but will definitely give me something fun to keep busy moving forward. If you are interested in collaborating on any of them or want to see how progress is going you can find my code on my git profiles, GitHub and ~git, though you will probably find more up-to-date code on the latter rather than the former. I will probably post some summaries on my updates here later on once I have made enough progress, but do not hold me to that.