Some months ago I (again) came across radicle. It was released in version 1.0.0 in 2024 and I wanted to try it since, but as you know, life happens and always gets in the way of plans. But I found some time this year to try it out and even contribute to its codebase (of course dogfooding and using radicle itself to contribute to it). Unfortunately, my progress contributing declined since, but that's due to the fact that radicle inspired me to start working on my distributed social network idea again, so I consider that actually a win rather than a loss. ;–)

Still, I wanted to get some contributions out again, and as you should know, contributions to (FLOSS) software projects does not need to happen in code, but can also happen in documentation, translation, or in spreading the word. This here is my attempt to contribute to radicle in a way that benefits the project: In writing up where it must improve its UX to succeed from my point of view.

Of course this is going to be a very subjective article. Some bits are even ranty. I am writing all of this in good faith and with best intentions! I want radicle to succeed!

Still, I have to say...

...where I am coming from

I want to make clear where I am coming from. As this is going to be highly subjective, I think it must be totally clear where my current position is, to be able to understand why I am thinking a certain way about the topic at hand.

So here we go with some things that I think are important:

• I know git. No, I don't mean I can commit and push, I know git very good. I can work with email patchsets, I rebase a lot, including rewriting patches in the middle of a rebase for example. Most people fear git-rebase, I don't.
• I have strong opinions (1, 2, 3, 4) on how to work in a distributed manner with git. That reminds me that I should also write up an article “I hate linear git histories” or something like that. I think this is very important for reviewing the UX of radicle. We'll see. FWIW, I think about open-sourcing my aforementioned distributed social network idea at some point, but only making it available via a git cloneable git URL and only taking email patches as a first step, especially to making it only “contributable” to a certain audience. And then only later making it available via code forges like github, codeberg and sourcehut and taking PRs from all of them at once (not tying myself to one particular infrastructure provider there). You probably noticed that radicle is not in the list above. You may find out why in this very article.
• FWIW, I hate when people put their VS Code configuration in the repository. It simply does not belong there, keep your stuff locally! If I would notice radicle altering my repository, even just putting a dotfile there, that would be a deal-braker for me!
• I am working on the CLI exclusively. I feel like this has to be stated. When I see students at my local hackerspace I see a lot of stuff like IntelliJ, VS Code, stuff like that. I don't mind that, but I feel like sometimes these tools hide things that ought to be known before you abstract them away. Maybe another blog post lurking here? Anyways, I dig into stuff on the CLI. For example, I don't use any fancy git UI either (think gitui). These tools might be awesome, I am used to the plain git command. I rarely commit from within my editor (neovim) even. I use tig, but only for visualizing the log graph (I even have a git-graph utility which does the same thing, but muscle memory keeps me using tig). This also has the “downside” that I cannot comment on interaction between these tools and radicle – I simply don't know how gitui, IntelliJ or VS Code would interact with a repository that is on the radicle network. Would they even? Would there be a noticable difference? I simply don't know.

I hope the above points set the theme a bit.

How this is structured

I thought a lot about how to structure this article so that the radicle maintainers get the most value out of it. I think the best idea is that I simply write it from the standpoint of a person that wants to try it out. So I am going to install radicle for the first time here (on a different device than I did before, so it is really a fresh install) and I will write down my thoughts and questions in the process of doing so.

I try to summarize my questions and ideas, even the very minor (or even invalid) ones.

I hope that the radicle maintainers can distill them into “TODOs” for their implementation.

That being said, I am not a “default linux user” which does some apt install thingy and then stuff is there in general. I installed radicle on my NixOS hosts with home-manager and also installed the systemd services provided by home-manager (or nixos/nixpkgs).

Goal

My goal for this setup is as follows:

I have two devices, each of them has a copy of the project. That project is proprietary and not for public release yet. Though as I want to release it as GPL software at some point, there is not much damage done if I mess this up and accidentially expose it to the internets. You will see later why I explicitely state this. Currently I sync via codeberg, pushing on one host, fetching/pulling on the other.

As both devices are not online at the same time (most of the time), as these are both personal computers, I know that I need some always-online instance that syncs the repository for me.

For that I want to install radicle as a seeder on my home-server as well (a small device that sits in my office, not a big rack or something). I want that device only to sync that one repository and everything that belongs to it. You'll see later why I state this explicitely.

Installation

So, for the installation I went the (for me) normal way of services.radicle.enable (for that home server) and the equivalent in home-manager terms for the personal computers.

Here's the first gotcha though: I had to programs.radicle.settings.node.alias = "matthiasbeyer"; in my home-assistant configuration, which wasn't obvious for me. This generates a config.json file in my $HOME, as I would expect. But I didn't think that I had to rad auth to generate some public-private keypair and that this process would try to write that config file.

So, here's the first todo for the maintainers: If I rad auth and that fails because it cannot write $HOME/.radicle/config.json, don't just tell me that this failed, but also what would have been done. Why did you want to write this file?

I continued, but I am not sure whether this might be the root of all further issues because there's now something missing from that configuration file.

After the installation I had to rad node start, although I enabled the relevant systemd services in my nixos / home-manager configuration. There's also a shutdown setting, which tells the node to shut down after (for me) 5 minutes of idle time. That did not work at all, the nodes (on both personal computers) are running after rad node start + password, and only get stopped via rad node stop.

Setting up the repository

So then I cded to my project and rad inited it. I was queried for a name for the repository and whether it would be a public or private one. I went with the latter.

Later I noticed that there is also some “Repository follow scope”. To this day I am not sure what that even is.

On my second personal computer I did the same. Fuck. Apparently, there is some rad init --existing which would have associated that repository with the already-initialized on my other host. Who would have guessed?

So after finally getting everything to sync (see below) I rad cloned my own repository from my home server (although I already have it, but that one is initialized and I don't know how to un-initialize it...). For some commands, it still tells me that “there is no fork”, ... and I see in rad help that there is a rad fork command, but I don't even understand what that's supposed to mean,...

Syncing

Getting the repository to sync to my home server was a big BIG issue. I did not fully understand how I made it sync. I executed rad-system commands on that homeserver almost blindly.

Maybe it was some rad-system seed repository_hash something something. I don't know.

What I would have liked is a command that I can execute where I initialized the repository that is something along the lines of rad sync --to <node id of homeserver> and that then tells me “Hey, that remote instance does not accept this repository, here's what you need to do to make it: ...command...command...command”.

But somehow I managed to get it to sync to that homeserver of mine. I am not sure though, whether future changes will be synced there as well.

I am also not sure whether my home server now syncs that repository to the world. There's something called “scope”, which I set to “followed”. I also rad followed my personal computers on that home server and on each home server I rad followed the other personal computer and the home server (and added aliases for all).

1. I am not sure what “follow”ing even means in this case
2. I am pretty sure that it doesn't help at all if both personal computers are online, because I suspect they cannot connect to eachother (ports not open? Not sure...)
3. (nitpick) I don't know what these aliases are exactly – I suspect that these are only human-readable names... but I am completely unsure whether they are synced to the network in any form?

Node status

The next thing I do not understand and find suspicious is, if I execute rad node status, I get a list of connected peers. But why? I don't want to connect to all of them, I want to connect to my home server and, if it is online, to my other personal computer.

The same is true for my home server – why is it connect to some hosts I do not want it to connect to? That makes me suspicious whether my repository gets synced to these, and I don't want that.

For a service that I run on my server that provides a radicle node, I would like it to be closed down to the max at first, with the node operator having explicitely to allow connections. There's nothing wrong with a “no connection at all by default” and I can configure it to “allow all connections”, but the default for a server software should be restricted.

I see that “low friction to get running” is a valid excuse here, but IMO not for the server side of things. Having an “open all gates by default” is exactly the opposite of what I would expect!

Delegates?

I already understood the concept of “delegates”, I suppose – in my setup, I want to enable my second personal computer to push to my master branch, too – not one of my PCs is the single source of truth for my master branch, but both of them are.

What I do not yet understand is how conflicts would be handled here – if my two devices are air-gapped and I update and push master on both of them, that would mean that either would have to merge master from the other once they sync. That much is clear to me.

But then there is this idea of “canonical branches” that is floating around... which solves this? Or doesn't? I don't know. I don't see docs on this.

Also: Does the home server have to be a delegate? I suppose not, but I am not sure... FWIW I added it and now am not able to remove it again. Why? Well... the error message is not clear! It says I must follow some other peer (the one of the second personal computer) to remove the delegate for the home server. Why? I don't know.

Maybe, just maybe the rad follow aliases get mixed up at some point? Because after some careful investigation the aliases did not match the key I was expecting... but from my shell history I can tell that they were added correctly. Something to look at definitively!

git-notes

This is maybe a bit obscure, but nonetheless...

I do keep git-notes in my repository. What I do is generate some metadata about the project for every other merge to my master branch, such as test count, binary size, etc.

Right now I do not see how I could sync them via radicle. I can do git push rad refs/notes/commits, and that works, but when trying to fetch these on the other personal computer (git fetch rad refs/notes/commits), it just does nothing from what I see. No output, so no notes fetched.

Working with a repository

For the following, I had to use a new repository, because mine obviously does not yet have any issues, pull requests or discussions attached to it, and randomly putting some in there does not nearly result in the same experience.

So I went to get the radicle repository itself (“heartwood”) and play with that for a bit. To find it, I opened radicle-desktop, and used the search there (which redirects to https://search.radicle.xyz – which is nice).

After cloning the repository (which apparently works with rad checkout rather than rad clone, at least that's what radicle-desktop suggests), I am greeted with a load of remotes that I did not expect:

(Redacted for brevity)

$ git remote -v                                                                                                                                                                              at 13:46:24 
fintohaps@z6M...      rad://z3.../z6M... (fetch)
fintohaps@z6M...      rad://z3.../z6M... (push)
lorenz@z6M... rad://z3.../z6M... (fetch)
lorenz@z6M... rad://z3.../z6M... (push)
rad     rad://z3.. (fetch)
rad     rad://z3../z6M.. (push)
z6Mkg...        rad://z3gq.../z6MkgF... (fetch)
z6Mkg...        rad://z3gq.../z6MkgF... (push)
z6Mks...        rad://z3gq.../z6MksF... (fetch)
z6Mks...        rad://z3gq.../z6MksF... (push)
z6Mkt...        rad://z3gq.../z6Mkta... (fetch)
z6Mkt...        rad://z3gq.../z6Mkta... (push)

But why? It does not explain this during the clone (or rather checkout) step!

Executing tig now results in a lot of clutter in my tig log panel that I have to visually parse to understand what is going on. Especially because there are remotes with .../patches/... sprinkled in between that I did not ever expect. Why are there (apparently) PRs that have been merged (apparently heartwood uses fast-forward or rebase merges *grunt*). Why are these things put into my repository? I did not request them, there is no added value from these refs. If I want to look at them, I can get them from my locally running node, but having them in the repository from the get-go is just clutter I have to mentally cope with. Not nice.

Okay, well... now lets have a look at their current issues. For that, I executed rad issue list. I was greeted with a nicely formatted table, which exceeded my screen though, so I had to scroll up to find the column names. Not nice.

If we now look further, to check whether there are also pull-requests (confusingly named “patches”) for that repository, we execute rad patch. Luckily, this does not exceed my screen! That table looks rather good, but there's one column missing: How many comments were posted on a particular patch. Because I really wanted to look at a patch with lots of discussion (and reviews?), so see how that is displayed by the rad command.

The table has a column “Reviews”, but I don't know what its values mean... which are - - - - - ... umm what?

If I rad patch list --merged it prints all the things (which even on my beefy machine takes almost 2 seconds), which is not helpful either.

Unfortunately, I was not able to find a pull-request with discussions on it. Not even after using radicle-desktop to click through the list of open and closed (merged) pull-requests. This leaves the bad taste that even radicle developers rather use their zulipchat instance to talk about patchsets rather than the tool. Dogfooding anyone?

Edit: Apparently I missed – or failed to properly click on the button – to check the already-merged PRs, there's plenty with discussions on them. So this one is clearly on me.

Okay, so back to rad issue. I found an interesting issue via radicle-desktop, which is about “SystemD” (not to confuse with “systemd” of course). I found that patch via the desktop interface,... I could now find that hash that is the ID of that issue and copy that to the CLI to open the issue there... but that's too complicated, lets just...

rad issue list | grep SystemD  

...nothing. Huh? Okay, lets try

rad issue list | grep -i systemd

...nothing? Whut? ... okay

rad issue list --all | grep -i systemd  

aaah there it is. It is closed! Okay, well then rad issue list --closed | grep -i systemd should clearly yield something, right? But it doesn't? Whut? But rad issue list --solved | grep -i systemd does ... although when looking at the exact issue rad issue show 5767d6f it says... Status Closed (solved). MEH! Okay, so a solved issue is not a closed one, although it is named “closed”.

The rad issue show output for a specific issue also needs a bit of work UI wise: for example there's the header for each message, which is not really visually seperated from the content of the message. Small issue, but well...

For that last bit, I figured I could submit a pull request to heartwood to get that fixed. So I dove into the code, found the line where the output gets constructed and added a sweet line of whitespace in there. Easy. Now we have something that we can PR against the upstream project, a branch where I committed that change and of course tested the change, by running it with the same issue from above.

Now... how do I submit that patch as a PR?

I looked for rad patch propose or rad patch publish... (which should rather be rad pull-request or something along those lines). But I couldn't find it.

After consulting the documentation on https://radicle.xyz, I found that I have to push that patch to my special remote “rad” and to HEAD:refs/patches – Whut? There's absolutely no reason why this has to be so complicated. Why is there a command for everything in here, but not for the most common thing ever?

And once I do that push, my editor opens for the pull request message??? (I am sure it cannot use git-notes or branch descriptions, right?).

That is the weirdest workflow of all so far, to be honest. What I would expect is a rad request-pull with some flags for fetching the patch description from git-branch description or git-notes, plus some flag for editing or a simple --message/-m and so on.

Also, that the editor is now pre-filled with the commit message of that commit is weird! I suspect that if there are multiple commits on that branch, they all get put into that PR message? That would be even more weird, to be honest! What I would expect is an empty text/markdown document. Possibly some html comments that tell me what goes in here. Possibly a diffstat, that does not get put into the final PR message, but not this!

After editing my PR message, radicle seems to sync that to the network, so lets find it in the official upstream via the web interface! And yes, there it is: https://app.radicle.xyz/nodes/iris.radicle.xyz/rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5/patches/e1f7101a364166ba14fd9610e75aab312d635b5f

Nice!

The radicle output also tells me what to do to update this patch... and of course it wants me to git push if I simply have more commits, or to force-push to some weird remote: git push rad --force-with-lease HEAD:patches/e1f7101a364166ba14fd9610e75aab312d635b5f. How about rad patch update --to HEAD with --no-edit if I do not want to comment that new update?

Another thing that I found was: If I now run rad issue list, that pull request is opened by matthiasbeyer-hikari. Where does that come from? I've set that name at some point, but when I run rad self, my alias is matthiasbeyer, which I would have expected to be visible in the pull request as well (FWIW, the web interface shows the correct alias, without the -hikari)!

TUI

The rad-tui is a really nice project (which IMO should be part of the radicle repository)!

It still has some rough edges:

• rad tui issue list 5767d6f has the exact same output as rad issue list 5767d6f – where exactly is that sweet tui?
• (nitpick) It opens with “preview” enabled by default, which is exactly the opposite of what I would have expected. Opening it with rad tui issue should give me a list of issues, not one pre-selected and its details showing.
• There's no “reply” binding apparently? Weird!
• It does not do code highlighting for markdown code blocks

General UX

Some things I found while playing around with the stuff I described above which did not get explicitely mentioned yet:

• Naming pull-requests “patches” is ... no I won't use swearwords here.
• Finding the node ID (NID) is really not nice: rad node status and then find the NID in that blob of output. Why not rad node id and just get that ID?

Recap

All of the above seems pretty negative. It isn't. Let me repeat: I want radicle to succeed. I love the idea, I love the project. I think it is on the right track and I think it might be the solution to centralized forges. And, compared to federation in forgejo it already exists, which is huge!

All of the above was written with the intention that the project can derive tasks from it. All of the above things are UI and UX things, nothing of this is technical! I hope we can get into a discussion to get the best out of what I (finally) managed to write down and improve radicle with it.

---

After posting above article, I came to the realization that it sounds way more aggressive than I would have liked it to be. The frustration and anger that shines through above lines might have left a bitter taste with some of my readers here and I want to apologize for that. My intention was not to hurt anyone. radicle is an awesome piece of software with (in my opinion) a lot of raw edges. A diamond that needs proper polish, so to speak. I hope we can polish that diamond together!

Recently I came by a lot of blog posts and videos that recap on 2025, for example the one by Jan-Erik, and I must say I like the general idea of doing a recap.

So lets see what my recap is. I must say, I really have to think about it, because from the top of my head I can not think of that much. Doing a month-by-month recap is certainly not very fruitful.

Vacation in Great Britain

My highlight this year – or rather last year – was definitively my vacation in Great Britain.

My Wife and I flew to London and had three awesome nights in the Motel One Tower Hill. We visited the Warner Brothers Harry Potter Exhibition near London and it was absolutely fabulous. We strolled through London, saw Big Ben of course, the London Eye, visited the Sherlock Holmes Museum and the Frameless Experience. We had awesome Food during our stay in London! Quite contrary to what everyone said, the English Food was awesome – we only went to an Italian Restaurant once and resorted to English/Scottish Restaurants throughout our trip! This was definitively not a mistake.

Also, quite contrary to what everyone told us, the weather was awesome. We had sun every day and only had one day with light rain in Edinburgh, which is not that much for a two-week trip!

After our days in London we took the Caledonian Sleeper to Edinburgh. I did not expect to be able to sleep on a train, but I slept very well, although our compartment. We had a two-bed + sink room (yes, we did allow ourselves something here, but to be honest, it was not that expensive).

In Edinburg, we of course visited the City, the MinaLima House, had Haggis, saw the Castle – but didn't enter, because there was some festival and it was too expensive. We visited Craigmillar Castle instead (we walked there, yes) and Holyrood Park – unfortunately on the rainy day, but it was okay. We also had a Whisky tasting in the Holyrood Distillery which was really nice.

During our stay in Edinburgh we visited Sterling Castle for one day (by train) and had a three-day trip to Fort William, where we took the Harry Potter Steam train to Mallaig and back, just one day before September 1st. Of course we allowed ourselves to have the full experience, so we did the trip 1st Class and had a Whisky tasting during the trip. The whole Harry Potter Steam train was definitively the highlight of the whole vacation.

I probably left out a lot here, especially the different kinds of Haggis that we had. All in all it was a really nice trip and even the trip from Edinburgh Airport back to Germany was enjoyable (as enjoyable as flying gets in Economy I suppose).

RustWeek

Another highlight of last year was RustWeek in Utrecht. My employer send me there and I really thank them for that trip. First of all because I learned a lot, I met awesome people there, and I saw Utrecht – a City I immediately fell in love with. If I would have to live in Netherlands, I definitively would try to get a place in Utrecht! Such a walkable City, with so well-thought bike lanes and coordination of motorized traffic, I cannot possibly imagine a better city to be in.

RustWeek itself was awesome of course with all the awesome talks by awesome people and of course I already have my ticket for this years RustWeek – I am especially looking forward to Greg Kroah-Hartmann giving the keynote talk – most certainly about Rust in the Kernel. I am excited even thinking about it!

GPN

I attended GPN in Karlsruhe, as every year. I again was able to attend on company time this year and I am really fond of that. It was an awesome four-day weekend full of talks, nice people, good conversations and of course also a really nice party.

Even my wife came along this year and although she didn't attend any talks as far as I can remember, she still had an nice time there (She went to the Zoo as far as I can remember). I hope she will be able to come along this year as well.

Medieval Group

Of course I also spent one week on a castle with my wife, as every year. She participates in a medieval group and we spend one week on a castle every year, where some of us fight in armor, some of us cook and we spend the whole time there just having an awesome time and talking and of course drinking lots of beer (we're German after all).

This is always a very nice week, because it grounds you. Cellphone reception is available there, but nobody really is glued to the screen, so you can enjoy just being there.

Unfortunately we likely cannot attend this year, so we will see where I get my week of relaxing from this year.

Music

I got a lot better playing the saxophone last year and I continue to improve of course. For Christmas, my wife and I bought a piano (actually early December) and I am starting to learn playing it again (and hopefully my wife starts learning it as well). I played the piano for about ten years but that stopped about 15 years ago... still, I made a lot of progress already just in the last few weeks of the year.

I did not DJ that much last year as I should have and also my home-studio was not used as much as I would have liked. In late January a missing hardware piece should arrive (fingers crossed) and I hope everything works as expected then, so I can finally start learning how to make Techno tracks then.

Overall...

Overall, not that much happened last year. A few big events, but not that many events. I worked a lot of course, wrote a lot of code, got better (which my employer promised to honor this year... we will see).

After getting married and moving in 2024, having 2025 be a bit more quite was a good idea I suppose.

I do not yet have any plans for 2026 (certainly no new years resolutions), mostly because my wife seems to not have enough holidays to do some extensive traveling. I will attend RustWeek and hopefully also GPN of course. Besides that I only want my personal pet project to finally get to a stage where one can play with it. But I think I do not have any bigger plans for 2026.

So, to conclude this post,... am I happy with 2025? I think mostly. There are some things that could have been better, but this is really just nitpicking.

I wrote repolocli between 4 and 6 years ago. The goal was simple: Use the repology API and build a commandline tool for interacting with it – fetching state of packages, finding which repositories contain a package, find packages maintained by myself, finding problems with them... etc etc.

It worked quite well at the time, although the code is not really complex from todays perspective.

And that's where you come in: Do you want to learn Rust? Do you want to contribute to an opensource Rust project? Do you always have the problem of finding something to hack on because you lack ideas (I had this problem when I learned a new language quite often... )?

I'd love to revive this project, but I am currently not in a position to do so, because I simply lack the free time! I am more than happy to receive patches though, so if you want to give it a go, fire me some!

The development setup should be straight forward, the API of repology is free to use and you can even curl some JSON and then use that to feed into repolocli, so you can do development without talking to a remote server all the time! All you need is a Rust development setup and a way to send me your changes! You can do that via github, or, if you don't care for github, I also take changes via codeberg (just make sure to also send me a short notice via mail, because I am not constantly looking at my codeberg account) or you can even send me patchsets via mail!

This article describes how I think releases in a git project should be done.

The following sections do not talk about major releases (increasing “x” in a “x.y.z” version number) but only about the “y” and “z” (commonly known as “minor” and “patch” releases) part.

Preface

The goal of the workflow described in this chapter is to have as little impact as possible on the general development of a project. Releases should never stop, prevent or even just slow down the normal development of a project. For example, halting development on the master branch and forbidding contributors and maintainers to merge changes to it even for as little as one hour just so that a new release can be published is not acceptable. Also should “patch” releases have no impact on the project pace or even concern developers – they should just happen in parallel without any influence on the normal development activities.

With these requirements, I propose the following workflow.

Semver conformity and API coverage

We adhere to semver, with the exceptions implied by the cargo implementation of the standard (as I am mostly concerned with Rust these days) and with the exception that updating the rustc toolchain is not considered a semver-breaking change.

Parts of the API that are not covered by semver are explicitly marked. The public API is extensively tested in integration tests. If changes to the public API of the project are necessary, these changes are documented (in the commit message as well as) in the CHANGELOG.md file of the project, with reasoning why the change was necessary and how users can upgrade to the new interface(s).

We also define the following rules for our release process:

• We release new features by increasing the “minor” version
• When we release new patch releases, these releases never contain new features, but only fixes to bugs.

Release cycle

Until a minor release is published, the previous minor release can receive patch releases (accordingly to semver).

Strategy

We use the release-branch strategy, where development happens on the master branch and releases are done on dedicated release-X.Y.Z branches.

Because we employ the “evergreen master branch” strategy and all of our merge commits on the master branch are guaranteed to successfully build and pass CI, a release can potentially be made starting from every commit on the master branch ( That is not as in “every commit that is reachable from master”, but rather “every commit that gets returned from git log --first-parent master).

For a description of the release workflow, read below.

Release maintainer

For every release, one or more “release maintainers” are appointed by the core team.

The responsibilities of the release maintainers are:

• Creation and maintenance of the release-x.y.z branches
• Cherry-picking bugfix patches from the master branch and applying them to the relevant release-x.y.z branch (via pull request to that branch)
  • If a patch does not apply cleanly, it is not the responsibility of the release maintainer to make the patch apply. It is responsibility of the release maintainer, though, to talk to the developer of the patch and work with them to port the fix back to the release
• Create git-tags for the release(s) as appropriate
• Create github artifacts (or take care of a github-action pipeline that does) for releases (or whatever code forge you're on)
• Port the changes to the CHANGELOG.md file back to master (via pull request)
• Submit pull requests to the master branch to update all version numbers for the next release cycle

It is explicitly allowed for everyone to open bugfix-backport pull requests to a release branch, but the release maintainer(s) decide when and how to apply them to the release branch.

Release branches

Release branches MUST be named with a pattern. This pattern is

"release" dash <major version number> dot <minor version number> dot "x"

The "x" is used instead of the “patch version number”, because patch releases are published from the release branches (read below).

A release branch gets the following rules enforced via GitHub (or your code forge):

• Only the “release-maintainers” team can create branches named "release-*"
• Pull requests are required on these branches
• Status checks are required to succeed on these branches
• “CODEOWNERS” is not enforced on these branches
• These rules are also enforced for administrators

Workflow for minor releases

The following steps happen when a minor release is made:

1. One release maintainer creates a branch, starting from a recent commit on master, named after the aforementioned naming rule.
2. It is ensured that this branch cannot be pushed to by anyone except the bors merge bot (Refer to the “Merge strategies” point in the “Repository maintenance” chapter for more information) (When I initially wrote this article, “bors” was still a thing. There are most likely other solutions for this today).
3. The release maintainer crafts the CHANGELOG.md entries for this release and opens a pull request for it, targeting the aforementioned release branch.
4. Once agreed upon with everyone involved, they merge the PR for the CHANGELOG.md to the release branch
5. The release maintainer publishes the release on crates.io and creates a new tag for the release. They might add a tag message as they seem appropriate. They then push the tag to the GitHub repository of the project. They also make sure that release artifacts are published on GitHub for the new release (or make sure that a github-actions pipeline does this)
6. After the release is done, the CHANGELOG.md changes are cherry-picked to a pull request to the master branch by the release maintainer
7. After the release is done, the release maintainer opens a pull request to the master branch to update all version numbers of all crates to the next minor version

Note that development on master can continue without interruption.

Workflow for patch releases

Patch releases are published when appropriate, there is no fixed release cycle.

Backporting

Bugfixes that are added to a patch release must have been applied to the master branch, before they are backported to the appropriate release-x.y.z branch. If a bugfix that is applied to master cannot be backported, due to either conflicts or because the feature that is about to be fixed does not exist in the release-x.y.z branch anymore, the patch may be adapted to apply cleanly or a special patch may be crafted. The release maintainer is encouraged to reach out to the developer of the patch, as it is not the responsibility of the release maintainer to adapt patches.

In any case, fixes that are backported to a release-x.y.z branch, MUST pass CI and thus MUST be submitted to the release branch via a pull request.

Publishing of patch releases

A patch release is published as soon as the release maintainer thinks it is appropriate.

The steps the release maintainer follows are almost the same as the steps of the minor release workflow:

• The release maintainer submits a pull request to the release branch with the following changes:
  • CHANEGLOG.md entries for the patch level release
  • Updates of the version numbers for all crates in the “patch”-level position, e.g. “0.42.0” becomes “0.42.1”,
• Once the aforementioned pull request is merged, the release maintainer publishes the release on crates.io, tags (git tag -a vMAJOR.MINOR.PATCH) the release and pushes the tag to the GitHub repository of the project
• Once the release is published, the release maintainer opens a pull request to the master branch of the project, porting the changes that were made to the CHANGELOG.md file to this branch

More

The CHANGELOG.md is added on the release branch rather than on the master branch. The reason for this is the workflow: If the changelog is adapted on master, the branchoff for the release branch can only happen directly after the changelog was merged, because other merges may introduce new changes that need to be in the changelog. Also, the changelog-adding pull request must be up to date all the time, if patches get merged to master while the changelog is written, the changelog would need further fixes. If the changelog is added on the release branch, no synchronization is necessary, as the branchoff for the release already happened. Instead, the changelog entries can be “backported” to master, which is trivial.

In a similar fashion are patch-level CHANGELOG.md entries ported to the master branch.

Version number bumps happen right after branchoff for a release. Doing the version number bump before the release would mean that the release mastertainers would have to wait for the version-bump-pull-request, which is not acceptable under the preassumption that every commit from master can potentially be released. By bumping the numbers right after the release, but for the next release, we automatically get a peace-of-mind state for that next release, where the release maintainers can again just take any commit on master and start their release process.

The implication of the patch-level release workflow is that the master branch does never see changes to the version strings of the crates in the “patch” level position. This is intentional, as there is no need for that.

Today I had a rather unusual issue with my nixos setup. I tried to rebuild the system for one of my hosts, lets call it “H”. The system rebuild started a build from source for the waybar package, which is C++ application. Because H is a rather old host and I don't want to have a hot lap, I figured that this package should be built remotely.

But there's an issue. It is configured via home-manager deep inside of the derivation of the host! Also, I don't want to rebuild my whole host on that remote builder. I could, but there's another issue: All my other hosts are currently turned off and I am sitting on the couch. I don't want to get up, because I am a lazy fellow.

Luckily, I have access to the amazing nix-community.org builders (or one of them rather).

But ... I don't want to rebuild my system on a host that I share with others, that's essentially public. That's because I bake stuff into my system that's private (don't ask).

So here was the challenge: Rebuild one package from one of my nixosConfigurations on a remote host. Not baking in the host as a remote builder, of course.

Finding the attribute

Finding the right attribute is rather simple, actually. After some digging with nix repl, I found the right one:

nixosConfigurations.$(hostname).config.home-manager.users.$(whoami).programs.waybar.package

To break it down:

1. We access the current host within the nixosConfigurations attribute set – easy
2. We access the config of that host, where we go into the home-manager config bits
3. We access the right user
4. ...where the “waybar” program is configured and this one exposes a package attribute that points to the package in use

That's the one we want to build.

If we wouldn't need another host, that would be the commandline now:

nix build .#nixosConfigurations.$(hostname).config.home-manager.users.$(whoami).programs.waybar.package

Doing the thing remotely

But of course we want to --max-jobs 0 here, so that the local host does not build anything.

So what do we do? Well, there's the --builders attribute, that can be used to tell nix about additional builders it may use for this single invokation. According to the documentation we can pass something like

  --builders 'ssh://mac x86_64-darwin ; ssh://beastie x86_64-freebsd'

for example, to give it two additional builders. So for the problem at hand that would be --builders "ssh://build01.nix-community.org" – but that's not nearly enough.

See, the nix daemon runs as root. Even though I have a mapping from build01.nix-community.org to the right user and SSH identity in my .ssh/config, root does not know anything about that. So we must tell the nix invokation which user it should use to try to log into that sweet builder. Besides that, we must also tell it which SSH key to use (because again: nix runs as root, it doesn't know about my users ssh-agent instance, so it cannot query it for the appropriate ssh key and use that).

Luckily, we can also pass that. I did not fully figure out whether the ?ssh-key=... setting in the URL did the trick, or the setting within the --builders argument... but here's the thing: You can pass more options to the --builders option! You can pass platform identifiers to tell nix “hey, this machine can build aarch64” for example. You can tell nix about the relative speed of the machine (useful for large builds and if you have multiple machines that you pass), you can tell it the maximum number of builds it can execute on there.

All that is really nice, but not relevant for us with the rather small (although too much for my notebook) “waybar” package. Luckily, passing - instead of a real value uses the defaults.

Last but not least, we must tell nix about the host key identification of the host we're connecting to. Again, you can probably set this via programs.ssh.knownHosts in your nixos configuration, but the whole point here was that I don't want to rebuild my system before doing the package rebuild. Extracting the host key was a strange endeavour, because nix wants you to base64 that information, but not only the whole line from the ~/.ssh/known_hosts, but only the last two bits of it.

After I figured the whole thing out (with a bit of help from the nixos matrix channel – thanks for that folks and especially to the user named n4ch723hr3r!) – my commandline looked like this:

nix build -L .#nixosConfigurations.$(hostname).config.home-manager.users.$(whoami).programs.waybar.package --max-jobs 0 --builders "ssh://$NIX_COMMUNITY_USER@build01.nix-community.org?ssh-key=$NIX_COMMUNITY_KEY_PATH - $NIX_COMMUNITY_KEY_PATH - - - - $(cat ~/.ssh/known_hosts | grep nix-community | awk '{print $2,$3}' | base64 -w0)"

and I was able to build the package on the remote host.

The following piece was written months ago, right after the “We Are Developers World Conference” took place in Berlin. So far I have not been reached out to for providing feedback to the conference, and I am not expecting it will ever happen, so I am going to publish this (unedited) here on my blog instead.

There are some (at least one) swearword in here, for those of you who care about that.

Here we go...

---

I was really astonished about how bad such a conference can be organized, sorry to say.

First of all, the badges we're not even checked at the entrance. The person there was completely overwhelmed and couldn't even look at badges while people were streaming in. There was also too little space to actually check badges. At least 10 people and 5 queues (with a queuing system) would have been a good start. The way it was “organized” I could have just walked in while the person there looked somewhere else. I also heard that you could simply walk into the “premium area” that was reserved for expensive tickets. I didn't try, but given the other checks were basically nonexistent, I can imagine how easy it was.

The keynote talk was another issue. I am very sorry for the condition of Sir Tim Berners Lee and I wish him all the best and hope he gets better soon. He shouldn't speak at conferences in my opinion until he gets better. He was barely understandable, although I consider my English rather good. Other people I was talking to didn't understand a single word. Also his presentation was basically a “I want to sell my product” show, which is not what a keynote should be like, does it?

Next, the conference food was way to expensive. Not sure how much control the organizers have about that. But 20 euros for burger sounds like a joke. I went to the city to get food.

Next, the venue is too small for the amount of people. The hallways were way too crowded. Possibly an issue of a conference that grew too fast.

The venue map is really a joke, isn't it? I did not even figure out how many halls are there actually. Please provide a sane map, with a top-down view and also provide it printed out. There were like 10 locations were I found the map, but at least 50 would have been necessary. Also the map did never show the current position, which was a huge problem.

The app is something completely unnecessary as well. There are enough conference apps out there, for scheduling there's giggity, for chat there's open protocols like matrix. No need to dump money/effort into an app that I have to uninstall again right after the event! Yes I found that it is also available as website and I used that instead. Just wanted to give feedback about that.

The seats in the main hall/stage are an insult. I wasn't able to check the other seats because I wasn't able to catch one.

To the exhibitors: 90% of them had slides/booths that did say a lot of buzzwords, but no content. If you're doing “advanced cloud enterprise data connectivity”, that tells me exactly NOTHING about what you do. I could imagine that this buzzword bingo is normal for exhibitors for such conferences. Does not make it sane anyways.

All of the exhibitors were some form of “cloud” company. No other industries as far as I could tell. Except maybe the car manufacturers. That's sad.

Also, Vodafone should be punished for this fucking robot that blocked the hallways all the time.

In general I would ask exhibitors to send engineers to a developer conference rather than sales people. What good is it if I cannot even ask technical questions? All people at exhibitions I talked with were a disappointing! Maybe I just got the wrong people, I don't know.

I also found it very annoying and intrusive that people just took photos without asking and even the people that seemed to be from the press or similar didn't bother to ask. I am used to higher professionality in that regard.

The conclusion for me is that I urge my company to invest the money for the ticket to WeAreDevelopers rather into tickets to chaos communication congress, which has a ten times higher return of investment. I'd urge the organizers to attend at least one chaos communication congress. There are no exhibitors there (at least there weren't the last few times) but there's a huge opportunity to learn how an IT conference should be organized!

I recently encountered an issue with cargo check vs. cargo build. The former did succeed on my codebase, but the latter did not.

“Wait, what?”, you may ask. “Isn't check supposed to be build, but without actually creating the binary?“, you may say. Yes, it is. But in fact check and build have some differences which caused the latter to fail while the check succeeded.

Here's why.

Reproducing the issue

The first thing I tried was to reduce the issue to a minimal working (or rather “breaking”) example. I was able to reduce my example to the following piece of code:

struct Check;
impl Check {
    const CHECK: () = assert!(1 == 2);
}

fn main() {
    let _ = Check::CHECK;
}

The above piece of code declares a struct named “Check” and implements a associated constant on that type. The associated constant is of type empty tuple(, which compiles to nothing). Its right hand side is an assert macro call which asserts that 1 is equal to 2.

Further down, the code example implements the main function where it assigns an anonymous variable to the value of the associated constant of the Check type.

This example is really simple, and obviously this should not compile. The associated constant should be evaluated at compiletime and make the compiler yell at me, because after years of research, scientists have found out that 1 is indeed not equal to 2.

The problem

Of course I reported the problem upstream – turns out it was known and my report was a duplicate (first report).

The problem here is that the associated constant gets evaluated only at monomorphization time. And cargo check does not do that step during checking of the codebase – although one might argue that it should, because users would expect it to catch such compilation errors.

The solution

The solution for this issue seems to be pending, as the bug in the rust compiler is not yet resolved. Ralf Jung suggested that we could fake monomorphization and ask the compiler to emit metadata during cargo check (if I understood the comment correctly). This way, the issue could potentially be found.

I did not test this though.

Takeaway

The takeaway for me here is that CI should never just cargo check the code. There must be at least one cargo build in your CI setup that builds all of the code.

Besides that I learned about the awesome stuff you can build with const assertions. But that's only slightly related here.

---

I wrote the following post almost in one sitting. After powering through this, I do not find the energy to review it and fear that I will never post it because of that. That's also why the “Final thoughts” paragraph is rather short.

I don't want it to bit-rot in my editor, so here it goes...

---

Lately I have started again thinking about writing a distributed social network application. I've been thinking about this since 2017 on and off, but back then the available libraries for Rust were unusable for me, at least it was too much hassle for a free time side project.

But lately I started to think about it again, and some toots I have sent out to the world got some responses that made me think harder.

So let me (again) tell you about that idea.

The idea

The outcome I am targeting is the following: you can start up a GUI application on your desktop where you can post text, audio, video, much like you can with mastodon. The difference is that you don't need to be connected to a server or even to the internet at all. The application is an interface to a fully distributed network, where you can connect directly to your followers or the people you follow.

The application is focused on “macro blogging”, so more like diaspora or Lemmy/kbin, not so much like mastodon (User Interface wise) and tree-style discussion are supported (speaking of the interface/UI/UX).

You can boot that application while being air-gapped, you can boot it on several devices and post to the same account (which you can't with for example scuttlebutt, which is a “distributed social network” app).

That sounds not so fancy? Well, the UI and UX shouldn't be “fancy” in that regard at all. The underlying technology should be, though. So let's talk about it.

Core implementation

It is always hard to describe an implementation of something in text. This is no exception.

First of all, let's have a look at the actors in the system I think of.

Actor: user

A user wants to post text, images, videos, maybe polls, calendars, etc to their profile. They want to tag their content. Maybe they want to have different “streams” in their profile. Maybe they even want several profiles, but that's not very much important since it would only be an implementation detail.

They want to be able to post to that profile from multiple devices. Maybe they have two notebooks, maybe they have another workstation, maybe a tablet, a smartphone and maybe (just maybe) they also have a server from where they want to post via a bot, all to the same profile.

They want to be able to reply to posts from other users, they want to boost them (republish), like them, hide them, block other users, follow other users to see their content.

Maybe they also want to follow a single “stream” of one user, maybe they want to follow single tags.

Actor: discover server

Because of the distributed nature of the system (as we see further down this article), users cannot simply search for “TheAwesomeCat” user and get their profile. Each profile lives on the devices of the user of the profile, at first.

To solve this issue, there should be “discover server” instances. These instances can be hosted by power users or organizations. These servers do nothing but “announce” to connected instances of the application about profiles they know. Users can then decide (via interaction or configuration) whether to fetch these profiles.

Actor: Pin servers

Content lives, at first, only on the devices of the users that post it. If a users follow a profile, they automatically replicate the content that was posted on that profile, which helps distributing that content.

Of course, some might don't want to replicate content, which is totally fine and should be configurable (per followed profile, actually). Reposting content would be a option to ensure content is replicated.

Content replication by users might or might not be enought. To improve on this, there should/could be “pin servers”, that are always online, which a user can tell to pin their content for a decent amount of time. That would help distribution of the content. There could be multiple or a whole network of such servers. They are not really federated, but are more or less distributed as well.

These servers could be run by power users or organizations as well. Power-users can chose to pin only their own content or also that of friends, or even more stuff from other users they select or they get paid by, even.

Data Structures / The “Model”

The above might be a bit confusing because we haven't yet talked about how the system would work from a technical point.

That was on purpose, because I wanted to talk about this top-down rather than bottom-up, since I have better experience describing it this way.

Let's now look at the data structures.

There are two data types that we have to concern ourselves with in this system. The first one is, obviously, the “Profile” which a user posts to.

Profiles

A profile would be a DAG and Merkle Tree. Think about a profile like a git repository. A user posts to their profile by creating a entry in their “repository” (much like a commit in git). Binary content like audio or video would also be possible. “Commits” would contain metadata about the post, such as time, maybe location, tags, mime types of the content, etc.

In detail, there would be three “layers” in that repository. The lowest would be the actual content: text blobs, audio, video, files. The middle layer would be the “metadata” layer, pointing to the content (if there is any, as we'll see later there could be posts without content), the uppermost layer would be nothing more than a DAG of objects that link to their parent objects (multiple, as we need merges in such a system, or none for the first object in a profile) and contain some minimal metadata about the format (basically just a version number).

The uppermost layer may also contain a list of public keys of the instances that post to that profile. This way, discovering a full profile from just one object in the uppermost layer is possible. For size reasons, that list of public keys may also be embedded in the “metadata” layer.

The objects from the uppermost layer are really small and users could potentially cache these for other users. As they do not contain much data, but are vital to discovering profiles, they should be highly available in such a system.

Loading a profile of another user would now mean that the application would fetch the newest object on the uppermost layer and then traverse the DAG until it hits its root node. As an optimization, “pack nodes” could be added, which refer to a larger number of ancestor nodes, to speed up traversal. That would make deletion of stuff more complicated though. More on that later.

Device authentication

If a user wants to post from multiple devices, the application must be able to trust other devices.

If a user posts from device A, and device B sees that new post on the DAG, device B could potentially fast-forward its HEAD to the new node. But it must be able to verify that this new node is actually from a device that is owned by the user.

For such a thing, public-private key crypto is there and solves the problem just fine. Each node (in the uppermost layer) could get a signature and there we are. There could also be another way of solving this, by having the two devices communicate directly (off the DAG), which is something we talk about later.

Multi Device functionality/ Merging

To be able to use multiple devices, the application must be able to merge diverging DAGs.

If a user has two (or more) devices that are not connected, but posts on both, their profile dag advances on both devices and effectively leads to a diverging “HEAD” (in git-speak). For such a scenario, merges must be possible.

Because we're not actually merging content here, creating a merge is trivial. A new node has to be added to the profile, referring to the current two head nodes.

The concerning part here is that the two devices must agree on which one executes the merge, the other device must follow. Such problems are solved with concensus algorithms. As we're talking about a low number of actors here (if a user has more than 10 devices they post from at the same time, that's much, but not for a concensus mechanism), it shouldn't be that much of a problem.

But it is important that the merge is cheap, so it is vital that the objects that represent the DAG are lightweight.

Reposts

Reposting content would be a rather simple matter. The “metadata layer” we talked about eariler would simply note that the content it points to is actually a repost. It would also point to the metadata object (or even the DAG object that points to it), for discoverability.

Comments on posts

Commenting on a post is a bit more complicated. Well, the actual comment is not, but making that comment visible is.

First of all, a comment would just be another post to the profile DAG, with an entry in its metadata linking to the post it replies to (which of course could itself be a reply).

In a system where Alice, Bob and Clara post content, and Bob and Clara follow Alice. Bob and Clara don't know of each other in that system. Now if Alice posts something and Bob publishes a comment on that post, that does not mean that Clara sees that reply.

Also, Alice may not necessarily see Bobs post! But Bobs device(s) should tell the device of Alice that there has been a reply (see “Gossipping Applications” below). Alice is now able to configure her device for different behaviours if a reply is encountered:

1. Replies are not allowed, the device ignores the reply
2. Replies are allowed, Alices device posts a new object to her DAG that notes the reply on her profile
   1. And the device also replicates (for a configurable amount of time) the reply content
   2. The device does not replicate the content
      

That setting could even be per post, and there could even be a note in the “metadata” object telling followers what would happen with replies (although that is then set in stone, and I don't really like that, because this configuration should be mutable).

Replies on replies would need to be propagated to “upstream” as well, so that trees of replies are possible. They are not necessary from a technical standpoint, because if an instance loads a profile, finds “reply metadata nodes” and loads the profile that posted the replies, it would encounter replies on that reply as well (yeeees I know that sounds confusing).

As an optimization, replies should “bubble up” the chain until they hit the original post. This would give the author of the original post the opportunity to moderate the replies on their post, but it wouldn't give them the possibility to deny people speaking. They can only reduce the replication and visibility of replies.

This is also why metadata objects and uppermost layer objects must be designed to be small! Consider this: Alice publishes a post. Bob and Clara reply. And on each of these replies, 10 other people reply. If Alice has her device configured to re-announce all replies, and replies to replies, that would mean that she now has 23 new objects in her profile:

1 Post Alice made -> 1 DAG object and 1 metadata object = 2 objects
+ 1 Reply from Bob -> 2 objects
+ 1 Reply from Clara -> 2 objects
+ 10 Replies from Bobs followers -> 20 objects + 20 objects in Bobs profile
+ 10 Replies from Claras followers -> also 40 objects
= 46 objects in the profile DAG of Alice

As more replies are posted further down the tree of replies, more objects land in Alices profile DAG. That's why this has to be optimized and configurable.

Gossipping Applications

The second data structure we need is some form of gossipping protocol. Instances of the application, especially instances which are posting to the same profile, must be able to communicate directly with eachother. Not only for the DAG merges we had a look on above, but also for announcing their latest state.

Also, a gossipping protocol can be used to tell other users about the own profile, about profiles one instance “knows” and so on.

We did not yet talk about how an instance can find the current HEAD of other instances. That's exactly what the gossip protocol is (also) for: It sends, periodically, information about itself to that channel.

I considered a system like IPNS for that, but that seems to be not the right tool for the job, especially when we talk about updating that state every other second. Gossipping seems to be a better solution to this problem.

Such a gossipping protocol should basically be a global channel application instances send information into:

• “Hey I am Profile ID“
• “My current HEAD is Post ID“
• “Hey I know these instances: list of Profile IDs“
• I just posted Post ID

Configuration sync

Another concern, especially in scenarios where a user has multiple devices, is synchronization of configuration.

Configuration is not only what color scheme they prefer for their application instance, but also which profiles they “follow”, which ones they “block” and so on. This data has to be synchronized between devices. That's not too complicated, as this can easily be solved by CRDTs. We do not have to concern ourselves with preservation of history here, only the current state is of relevance.

Network of Trust

We already talked about having public-private key crypto in there for device authentication. Having public-private key crypto could also serve to build a network of trust.

Users might want to make sure that profiles they follow are actually humans. A network of trust would be ideal for that. Each post (or each node on the uppermost layer) should be signed with a private key anyways. Users might want to sign other users keys, so that they can build a network of trust.

Words on networks of trust have been written extensively, so I won't lose any more words about them here. I think they are a viable tool that should be explored for this application.

Non-concerns

I've written a lot about how the system would look like and some may think about certain problems that they can imagine such a system to have.

Here I want to address some of them.

Deleting content

First of all: deleting content is not of importance to me, although technically somewhat possible. To make that clear: If devices replicate content that is essentially content-addressed, there's no way to fully delete content from the network. That is the same as with putting a git repository open-source. If someone has a copy, there's just no way to remove it anymore.

It would be possible, though, to re-write the full profile chain and remove a single piece of content. As other instances may still have the “old” version of the profile DAG, they may see the content still, but devices that discover the content newly may never see it.

Moderation

Moderation is “possible”. I've put that in quotes because it is and is not at the same time. So first of all, everyone can post everything and nobody can forbid them to.

But users are able (and should) to configure their instances for what to replicate and what not. Replies to posts can be replicated for other followers to see, or not be replicated to make discoverability of them harder. But nobody can prevent someone from posting a reply to a post to their own profile.

For Spam and malice, block-lists could potentially exist and there could even be a feature in the “discover servers”. I am not really a fan of that, but I still want to mention that it is possible.

What I think would be a more valuable alternative would be a network of trust, essentially resulting in some form of reputation-system. If I sign another users profile as “is trustworthy for posting content, not spam” for example, my followers would see that and could themselves trust the other users profile better.

A spammer could still create hundreds of profiles and create a network of trusted accounts among them. I think there's no perfect solution to this problem anyways, but I beleive that a network of trust is a really good step towards a solution.

Chat

(Real-Time-)Chat is not a concern I have here. I think Matrix is a solution to that problem and I also think that matrix will become fully distributed at some point and matrix servers will go away at some point.

Encrypted communication

Encrypted (one-to-one or one-to-many) communication could be possible in such a system, given that public-private key crypto would be part of the system anyways.

That said, though, it is not really a good fit, because messages in such communication would still be posted to the profile and be potentially replicated forever, meaning that if crypto breaks some time in the future, the communication wouldn't be private anymore.

Of course that's true for all online communication that's encrypted. I am not sure whether I would implement such a thing, but it is possible.

Technology

Now that I've written a lot about what the ideas for the social network application are, I also have to write a bit about the technology I have in mind for implementing that application.

As said, I've been thinking a long time (since 2017) about this, and I have refined my idea several times during that time. The core of the idea is still the same though: there should be no need for servers (the server software mentioned above is simply an optimization and not really necessary technically speaking), a user may post from several devices to the same profile and they should be able to post content without being connected to the internet.

IPFS

IPFS was the technology that sparked that idea in the first place. IPFS and especially IPLD where the pieces of technology that I thought could provide the functionality that would be necessary for implementing the application.

Also, IPFS/IPLD would be a “common donominator” and linking to git-repositories or other data that is served via IPFS (think of the wikipedia, IIRC there has been an project to put the wikipedia on IPFS) would be possible easily.

But IPFS never had a decent Rust implementation or client libraries. All libraries that where available in my research were too complicated to use or too bare-bones to be a possible solution to the problems I am facing.

libp2p

I more or less recently discovered libp2p and it seems to be very complex to use, but also powerful enough to solve all the problems. And, and that's really important, there's a decent Rust implementation that seems to be on-par feature-wise.

Developing the application on libp2p is certainly involved, and a good plan must be made before starting such an project. Also I think I would need extensive help from others implementing the networking stuff, as I really do not comprehend where to even start!

Application UI

I am mainly thinking about implementing a GUI application here. I think there also should be CLI tooling, especially for power users, but it is not my main target here. The CLI tooling should not be for actually posting and “production use” but rather as a “plumbing toolbox” for inspecting profiles and instance state.

For GUI technology I am not really happy with the toolkits/frameworks I have used so far in the Rust world, except for Iced. I am not a fan of the react-style of framework and rather fancy elm-sytle frameworks (hence iced).

I also thought about trying Qt for that application, but given that it is mostly C++ only, and I really don't want to use C++ ever, it is not really an option either.

One framework that I did not yet have the pleasure trying out yet is Slint. From what I read online, it seems to be a really valuable alternative and from what I did read on its website, it seems to be a good framework. I will read more about it and try it out.

Final thoughts

I know this might be a major undertaking... I am not sure I am able to do all the things listed here – especially because my motivation drops as soon as I fail to understand docs or see ways to implement certain things.

Still, I think this is whole idea is worth exploring and implementing.

---

Feel free to contact me via mastodon or mail about this topic, of course!

On the Unix Friends and User Campus Kamp 2023 I held a talk called “101 Kommandozeilen-Werkzeuge” (“101 Commandline Tools”), where I showed the audience a number (actually more than 101) of commandline tools for Linux that are either cool, helpful or in any other way nice to know of. For the Linux-Day in Tübingen, I added some more tools to that presentation just this morning.

The range of tools is rather huge, from CLI utilities for processing structured data to full-fledged TUI applications for finance tracking, everything is included.

Did I say everything?

Well, not completely everything!

There's already five dozen!

There's probably five dozen different TUI applications for system monitoring. The most prominent is probably htop, which is a huge improvement over top (YMMV, just my opinion here). Then, there's also bottom, tiptop, glances, bashtop, bpytop, btop, gtop and probably another dozen more of these. All of these bring something new to the table. Configurable layout, better graphics,... whatever.

The next obvious thing is terminal file managers. When I started learning about Linux and especially the commandline, there was “Midnight Commander”. Later, there was also ranger, which is (again IMHO) a great improvement over “Midnight Commander”. Today, there is fff, nnn, vifm, fm, lf, felix, joshuto and probably another dozen of the same. Guess what? They all look the same, do the same, and have approximately the same feature set – although of course I would think that ranger still has the most features.

Another thing is text editor. I know this is a notoriously dangerous topic among Linux folks and commandline enthusiasts. I am myself guilty of evangelizing neovim at every opportunity and I do it mostly for the lolz, but not only. I honestly think it is the perfect text editor and I cannot for the life of me understand how anyone would ever want to work with these abominations called “IDE”s – or even a browser just for text editing.

But that's another topic.

In the beginning there was vi (yes, Linux greybeards, nowadays we can ignore that there was in fact a time before vi). Then there was vim, which was an improvement (pun intended). For a rather long time now there is neovim (“long” in terms of computer-science time calculation). Then there's also emacs. There's nano and there's probably five more that I do not know of that are similarly old and in use on some machines – I heard that Torvalds himself uses a patched version of microemacs or something like that.

I don't mind all of the above with regards to text editors. But today, there's also amp, helix, kakoune, micro, slap, turbo, zee, pepper, lapce, zed, glyph, hired, kibi, xi, ox – and I do not even include atom, vscode and all the other “big” “gui” editors here, let alone the fifteen different neovim GUI frontends. There's even a wikipedia list about text editors that is remarkably long – but doesn't even list the ones I listed above.

Seriously, almost none of these bring anything new to the table with regards to text editing. And what I do explicitly not want to say here is “just reach for (neo)vim”! No, I don't want to say this. I see that some of these improve the status quo of what older editors bring to the table – for example (IIRC) xi was the one that brought rope datastructures and improved performance of text editing under the hood. But that's not what I mean – What I mean is the five dozen text editors that are just a clone of one another without any improvement to what should be their job: text editing.

Instead, make something new!

Now I have been bitching about people investing their (probably free) time in something that they love doing. Yep, I am the asshole now here.

I don't really mind that, me expressing my thoughts about people wasting their time here. What I want to express, though, is that I am really sad about so much engineering energy and creativity lost into something that does not bring us forward as developers and Linux commandline enthusiasts in terms of tooling.

There are so many great tools out there that are absolutely amazing and bring new concepts for doing things – one of my favorite examples is fselect, which one can use to query the filesystem with SQL queries. You may think that this is a shit way of interacting with your files – but that's not the point I want to make! This tool is something that combines two things in a creative way that maybe someone has thought of before, but nobody implemented it. So it brings something entirely new to the table. And that's what I want to see out there. Not the seventieth iteration of a TUI file manager!

I am happy to announce that I am officially a (part-time/side-job) #freelancer for #rust #rustlang and #nixos #nix now!

You noticed the recent spike of Rust in your timelines? That's because Rust is the best thing since sliced bread! But Rust is not easy to learn!

That's where I come in! I am the guy you want for the time after the training of your developers! Because no training makes you a rockstar #rustlang programmer!

#hireme if you want to try out Rust in one of your projects to help your developers succeed! Whether it is #codereview, #consulting for your Rust experiments or for actual #softwaredevelopment, I can help your team get up to speed with #rustlang!

You also heard about #nix or #nixos and want to try it out? Let me help you exploring the ecosystem of functional package management to speed up your CI, development workflow and making your deployments reproducible!

---

For the readers of my blog: Above is clearly an advertisement. I won't post more ads on my blog, so be assured that this blog won't transform into an advertising machine!