Nice, I bet it wouldn't be too hard to put Manyverse there since our APK is served from GitHub releases.

Problems like this are why functional languages like Haskell are important.

Very much agreed. Not all programs need to be in Haskell, but the critical ones need to have all the checks possible. And this can also be done with external tools too. I remember in the University I learned temporal logic and model checking (promela) to simulate/model your code and then exhaustively verify that it is correct in all possible branches. Used for safety critical environments like space engineering, but why not, this should also be used for infrastructure and the grid.

Oh wow, I made a quick search for "isomorphic keyboard/piano" and ended up finding something that resonates with me A LOT: the Dodeka keyboard and the Dodeka music notation.

@Aljoscha I know you're talking about notes in relation to the root in some tonality, but you don't seem to have addressed the basic argument that I started with, which is: why name only 7 notes in our 12-tone equal temperament note system? There are literally 12 notes, why are 5 of these named in relation to their neighbors? There should be unique names for all 12, e.g. A,B,C,D,E,F,G,H,I,J,K,L. Then of course you could pick a key like H minor and play I# or Jb or whatever.

That would make a lot more sense than the current classic music notation we have, and honestly I still haven't heard any convincing argument for why we stick with A,A#,B,C,C#,D,D#,E,F,F#,G#, all I hear is dogma and I've been hearing this since I was 5 years old learning this shit. Like the youtube video I linked, it's kind of crazy how people get dogmatic about this, see e.g. how long humans insisted on Pythagorean tuning even to the point that the Catholic church persecuted those who used "bad intervals" until the Enlightenment came and we finally got rid of some bad logic in music tuning. We need to keep getting rid of illogical things in music.

The paper diagram is wrong in two ways, but such is the reality of paper diagrams and I'll leave it as an exercise to the reader to find the two mistakes. :D

Garbage collection

Working on this new area of the protocol feels like a fresh start, because it hasn't been designed for before in anything else that I'm aware of. It's fun!

I started by listing all the kinds of deletes that will be performed automatically, and classifying them by shared properties. Like, some deletes are performed immediately in reaction to an event (e.g. new replicated msgs) while other kinds of deletes are scheduled to happen once in a while. I have a neat table for all of these, but to list them more simply here:

• Removing feed holes (Tanglesync getting new range, avoid gap with old range)
• Feed decay (Deleting the oldest msgs in some select feeds)
• Natural PREDSL pruning (E.g. Set del that deprecates a Set add)
• Rewriting PREDSL pruning (Rewrite many Set items)
• Purge goalless msgs (E.g. delete replies to absent roots)

In particular, the "goalless" purging is the most interesting. To explain what a goal is, it's kind of like a query for a set of msgs that you are interested in, and I've been using these already in the implementation of tangle-sync:

A goal is a tuple (tangleID, rangeDescription) where rangeDescription is:

• "all"
• "newest-*" (where * is a natural number)
• "oldest-*"

Turns out that goals are useful not only for implementing replication, but also garbage collection. So I refactored that as a separate module, ppppp-goals which is used for both tangle-sync and gc.

A goal maps to a set of messages, and if those messages are absent in your database, this means replication must take place.

Now the inverse is: a message maps to a set of goals, and if those goals are absent (the set is empty), this means deletion of that msg must take place.

This nice dualism and inversion gives me good math vibes, and this is a good framework for thinking about the areas of replication and gc. I even think that I can phrase all the listed "kinds" of deletes in terms of goalless msgs. Implementing gc in itself is not so hard, but having this conceptual framework is good for other (potential) implementations to have easy guidelines on how to do it, and hopefully doing it in a globally consistent manner in the network.