Badly Drawn XMPP Logo eaten by badly drawn flying Uxul.

In theory, XMPP needs no versioning: There is a mighty base-protocol with lots of extensions, and the extensions just need to be negotiated and can then be used. But then again, there are lots of xmpp clients out there with different sets of extensions. Some are older and unmaintained and do not support crucial new XEPs. Some are too new to support all XEPs. Nevertheless, all of them can be called "XMPP Clients". Because "XMPP" is a base-protocol with many extensions.

In my opinion, it would therefore be a good thing to take sets of such XEPs, and define "XMPP Levels" for them. "XMPP Level 1" could be the base protocol, while "XMPP Level 2" could contain the crucial XEPs for modern mobile communication, like Stream Management, Client State Indication, Message Carbons and maybe Cloud Push. Then, clients supporting only Level 1 would still be XMPP Clients, but maintained modern clients which support modern XEPs can call themselves "XMPPL2-Clients".

From a technical perspective, this seems random. But from a user perspective, knowing about "supported XEPs" is not really something desirable, whereas knowing "XMPPL2 New, XMPPL1 Old" is something that can be told to everyone. It would furthermore stigmatize older unmaintained XMPP Clients – which is a good thing in my opinion.

In some situations, some XEPs are not useful. Like for the BitlBee gateway, which is meant to run on servers with high connectivity, Stream Management seems not that important. But then they still could say "XMPPL2 except for Stream Management" – it is clear that especially open source projects will not always be up to date or will sometimes deliberately not comply with such versioning. But it would still be better than today's very chaotic system, in my opinion.

For every tesselation, we can give a graph, which contains the edges and nodes of this tesselation. For example, the graph of the dodecahedron is

It is a graph of the kind 5 3, where every surface has 5 edges, and at every node, 3 edges meet. For 5 3, this graph is finite. For 4 4, this graph is the regular tesselation of the euclidean space:

But, for example, for 3 8, there is no regular tesselation on the euclidean space anymore, and none on the sphere. But there is a regular tesselation of that kind on the hyperbolic space.

Now, I was inspired by HyperRogue to try to produce some code, without any direct goal. I created a program that generates such graphs. And for debugging, I wrote a method that creates a GraphViz definition. GraphViz is a program for layouting graphs; it has several methods to find good starting points for several types of graph. When trying the sfdp method (and tuning a bit), I got the following output:

The documentation says that sfdp tries to arrange the nodes by reducing force (whatever force exactly is in this case). It cannot arrange the outer nodes anymore, so we get a curly outer line – which reminds me of lettuce (Image Source: Wikimedia Commons):

Lettuce also approximates hyperbolic surfaces. I am not sure why exactly, but probably to maximize the surface of its leaves. Maybe some similar process is going on in both cases. Or maybe it is just coincidence.

Anyway, I think it is beautiful. :3

I was searching for a tutorial for how to generate hyperbolic tessellations programmatically. Since I found none, I guess it is a worthwile thing to use some of my free time to write about my own approaches. This is not a scientific text. Probably there are better solutions to this, and I would be interested in them, so feel free to comment.

I do not yet have a satisfactory way to give unique coordinates to every tile as for example HyperRogue does. If you know how to do this, feel free to send a comment. It has to do with Coxeter Groups.

We will work on the Poincaré Disk Model. In the poincare disk model, the hyperbolic space is the unit circle, and lines are circles and lines perpendicular to this unit circle.

For circles perpendicular to the unit circle, it is easy to see that we have 1+r^2=D^2, where D is the distance between the two centers, because they form a right-angled triangle. Hence, this holds for every line in hyperbolic space that is a circle in euclidean space.

If we want to generate a regular tessellation of regular n-gons, such that at every vertex m such n-gons meet, we need to generate an n-gon with inner angle \alpha = \frac{360^\circ}{m}. We know that the centers of the hyperbolic lines must form an n-gon in euclidean space. The side length of the regular n-gon in euclidean space is q:=2\sin\frac{\pi}{n}.

We now consider two such circles. Their center distance should be q\cdot
D. Their radii r are equal. Fix one of their two intersection points and draw the radii through these intersection points. Together with the segment between their two centers, this forms an isosceles triangle. The angle \varphi between the two radii is complementary to the angle of the normals through this point, and therefore we know that \alpha + \varphi =
180^\circ. The other two angles in this isosceles triangle, let's call them \psi, satisfy \psi + \frac{\varphi}{2} = 90^\circ.

Now we know by basic trigonometry that the height of the triangle is given by r\cdot\sin\psi, and the bottom side q\cdot D satisfies \frac{q\cdot D}{2} = r\cdot\cos\psi.

Inserting the above relation between D and r, we get

\frac{q\cdot\sqrt{1+r^2}}{2} = r\cdot\cos\psi

\frac{q^2}{4}(1+r^2) = r^2\cdot\cos^2\psi

  \frac{q^2}{4} = r^2 (\cos^2\psi - \frac{q^2}{4})

\frac{q^2}{4\cos^2\psi - q^2} = r^2

r = \frac{q}{\sqrt{4\cos^2\psi-q^2}}


\psi + \frac{\varphi}{2} = 90^\circ

\psi + \frac{180^\circ -\alpha}{2} = 90^\circ

\psi + 90^\circ  - \frac{\alpha}{2} = 90^\circ

\psi = \frac{\alpha}{2}

To generate the sides of the polygon, draw circles with radius r around the centers (D\cos\frac{2\pi k}{n},D\sin\frac{2\pi k}{n}) for n=0,\ldots,n-1.

To find the vertices of the hyperbolic n-gon, just calculate the intersection points between neighbouring circles, and choose the one with distance <1 to the origin. See this thread about how to calculate intersections.


I am used to the following Workflow: I have a feedreader with lots and lots of feeds and I first filter them according to their titles. Everything that sounds interesting will be opened in a new tab. The tabs load, the PC fan spins, and after a while, everything is loaded.

This way, I can load pages before I read them. Loading modern webpages can take seconds, while switching tabs usually took less than a second, and I can do something different while the tabs are loading. Especially when I am in a train, I like to read tabs which have already a loaded website. I usually had a multi-line tab-bar for the about 500 tabs I kept open.

Then, furthermore, I use tabs as bookmarks. I don't really see the big difference – from a user perspective – between bookmarks and tabs. Why the distinction? Why can't I just organize my tabs in groups, which are directories of tabs?

Well, Firefox was never battery saving, but at least it had lots and lots of extensions like, for example, Tab Mix Plus and Tab Groups Manager. Well… Until Mozilla decided to drop support for them. Now, Firefox is just another browser, and especially, it is a browser which does not perform too well. It has an extension Tree Style Tabs which does a good job at organizing tabs.

Palemoon still supports old extensions. I used palemoon for some time. But I am sceptical whether Palemoon will stay tuned with newer web standards and security.

And anyway, both Firefox and Palemoon are rather slow and keep draining my battery.

The obvious alternative to both is Chrom{e,ium} – which performs good for the casual user I guess, but is just terrible at handling many tabs. The tabs will degenerate to small "spikes" when too many are loaded. There are extensions which at least try to be a substitute for tree style tabs, but currently, none of them worked flawlessly for me.

And there is another drawback: Another feature of Firefox is that I could switch to a Socks-Proxy during runtime. This is not possible with Chromium.

I haven't tried Opera for long – it used to be an alternative, but meanwhile it appears like just being a clone of Chrome.

Now I am back at Vivaldi. Which has reasonable tab management in the sense that it at least supports grouping. I configured XFCE to remove the title bars from my windows when they are maximized. Unfortunately, Vivaldi draws its own window borders. You can make it show native window borders, but there will still be a bar above the window when maximized, in which there is only the Vivaldi-Symbol. And when switching to a side-tab-bar, the pinned tabs are expanded. I have openned lots of messengers, so that becomes a problem. Anyway, at least these are just minor UI flaws.

I have a lot of stuff to do recently. So I will pause blogging until about November. See you then, hopefully!