I'm sorry to announce this, but I have to stop all my work on my current projects. I haven't been doing anything about them for a few months, and writing currently my new thesis, it is impossible for me to continue a responsible development. I already pushed some changes, especially to Markdowku, but didn't make a release yet, since I don't want to do the support.
I will come back to this once I finished my Master thesis, which should be some time around summer.

But, on the good side: I was just contacted by a person who wants to implement a nicer interface for Calendoku! So maybe with the next versin, you will have a much nicer overview than the current table!

When you're communicating with a certain kind of people via Jabber/XMPP, you're
often asked for encryption. I do use encryption, even end-to-end, but I don't
use Off-The-Record Messaging (OTR), which is what
most people assume, and I have reasons for that:

Perfect Forward Secrecy is uninteresting for me

I log every communication. More or less willingly, but I don't take special
notes of things that are said, so chatlogs are an important source of
information for me.
Most people do so as well. Since logs and keys are in most cases stored on the
same storages, getting hold of the key also means getting hold of the chat logs.

I don't want to say Perfect Forward Secrecy (PFS) is useless, I'm just saying
that for XMPP this is an attack scenario I don't see myself in.

OTR messes up multiple clients/resources

I often use several clients simultaneously connecting to one account - my
notebook, my desktop computer, my mobile phone. XMPP is perfectly able to handle
multiple resources, and it is one of the excellent features. But with OTR,
the ability to use multiple clients in a sensible way is broken.
Apart from OTR handshakes going terribly wrong when multiple clients are
responding to a message (though I've been told this is a thing from the past),
you cannot pass a connection to other clients. Even further, when one client
goes offline and the message is directed to another one, the message is
unreadable without the sender noticing. Or even having another client with a
different key breaks readable messages.

OTR has no network behind it

Even though libotr, the most common library used for OTR (or the only one?),
in the background uses libgcrypt, the library handling the crypto behind GnuPG,
it uses its own key material, and the only frontend to this being the XMPP
client.
There is no clean and easy way to exchange keys or trust between XMPP clients,
so if you change your client because your old one is outdated (guess who had
this recently), you have to reestablish all validations again, and create new
keys.
Even though, all in all, the crypto behind OTR and the mechanisms would allow
you to use your PGP key and the PGP trust network. You could use the
web of trust which has been established for decades and
has a huge amount of users. It is just not done yet.

OTR cannot handle offline messages

The most important point to me is: OTR does not encrypt offline messages. About
ten years ago, I tried to get people away from the MSN messenger which couldn't
at that time handle offline messages. And nowadays, technical folks are
willingly refusing offline messages, since OTR cannot encrypt that. I don't
refuse, and I often use offline messages, so OTR is useless for me.

It is clear that ensuring PFS with asynchronous communication is not easy, but
why not just use non-PFS, but asynchronously encrypted connections for offline
messages?

"There is no alternative to OTR"

There is an alternative to OTR: PGP. There is even an obsoleted XMPP
extension specifying how PGP is
implemented in XMPP. But PGP has drawbacks as well: On the one hand, it isn't as
widely deployed as OTR (I think Pidgin and Adium the main reasons) and it
doesn't have an included key exchange – you have to exchange keys prior to the
communication with a tool handling your PGP keys.

Even though I don't like the “I don't like detail X, so I won't use it” approach,
I think in this case it is appropriate. OTR doesn't give me the security I want
(offline messages) without being userfriendly (multiple clients).

What now?

I still hope for somebody writing a combined encryption library, which uses the
key material and network from PGP, and uses PGP for offline messages, but OTR
for synchronous messages. If I have time (and the missing knowledge) to do so
one day, I'll do, but until that time comes, I'll have to stick to GPG. There is
no way to achieve a useful encryption with OTR with my setup.

Researching for this article, I also found this excellent
article about the state of
mobile XMPP in 2014. I highly recommend it to you to read, since a lot of
issues with XMPP and their are explained.

Wow, I finally got some feedback, so people are actually using calendoku!

I didn't write about the former ones, but there are two new releases: One was rather a bug fix one week ago, the other (recent) one is another release (v5). This release adds support for timezones for the dates.

Sometimes I really wonder why people are doing some things. I'm usually pretty happy with anybody who is doing anything, as long as they don't start insulting other people (and even with that, I have a very high tolerance). And I don't complain about software written by other people.

I have already written about my endorsement of a markdown standardization, and I always held back with my complaints about the author not willing to further develop his buggy software, but also blocking standardization efforts. Standard^W Common Markdown was an effort to circumvent this and extent the language which is already heavy in use. But now there are even complaints about this (WHY?), forcing the project to rename itself.

There is a huge industry behind it which wants to use Markdown, there are lots of people using it for their own projects, and a lot of Open Source coders spending hours of having to deal with this shit. Congratulations, now the situation becomes even worse, with the author making clear that, whyever, he will not tolerate any standardization except for his own software.

It's not only what he is doing in this case. It is that he states clear that he will not tolerate anybody trying to use the name for something looking even closely official. Anybody who uses the name Markdown cannot be sure whether he will someday receive a complaint by John Gruber. Who knows, maybe he will get into legal issues as well? It's the same as with patents, except that in this case, there is no company with a rational interest behind it.

I don't have a voice in this whole issue, except for my own plugin which is far from being Markdown, I never contributed anything. But I really hope they just fork it, find a new name, and develop it with their own name. Github, Stackexchange and Reddit should have enough influence to be able to actually make a useful formatting language which extends Markdown in a sensible way.