Introducing Honeybee: Calling via XMPP

The main issue most people have when daily driving mobile linux is call and text reliability. A lot of work has been done to get us close to 100% reliability but if I want the best reliability, I have to use android. On postmarketOS, audio routing has alot of moving parts and for your phone to ring, callaudiod, modemmanager, and the audio subsystem must all work correctly. Audio never touches pulseaudio/pipewire and is alsa only ¹ - there are plans to move audio routing to pipewire.

Consequently:

• Under the postmarketOS wiki feature matrix, even if “Mulimedia Audio” works, there is no guarantee that “Modem calls/texts” will work
  • This leaves a whole class of devices unfit for “daily driving”
• Sending audio over Bluetooth headset support is still in the works
• Audio quality is reliant on the device manufacturer ²
• Scripting uses dbus which is not the prettiest interface ³

• If one component in the chain fails or your connection is faulty, you may miss a call and not know

  Overall, I have found the entire chain in the standard mobile stack difficult to debug.

I came across cheogram which allows you to link a number with an XMPP account and make calls with using any XMPP client. For example, you can call a phone number using dino and your non-XMPP recipient can answer the call using their cell phone. Cheogram+dino fixes most issues I had with the standard modem stack. However, I did not want to use dino on my phone because:

• There is no command-line interface
• Coming out of suspend is slow
• Dino is a heavy program
• No DTMF support - this is needed for virtual receptionists answering services

As such, I have started writing an XMPP client in zig for calling using the snikket sdk. The program is called honeybee and it is currently in pre-alpha. You control the daemon (honeybee) using honeybeec:

~/code/honeybee $ honeybeec help
info: usage:
info: status: print status of daemon
info: call <jid>: call <jid>
info: hangup <jid>: hangup from <jid>
info: accept_call <jid>: accept call from <jid>
info: dtmf <dtmf_tone>: send <dtmf_tone> to active call

Even in this early stage, honeybee has dtmf support, basic call functionality, and hooks. Since snikket-sdk is pre-pre-pre-alpha, honeybee should be treated as pre-pre-pre-alpha. I need help! If you want to make calls using emacs, please try out honeybee and send your improvements!

A cheogram account is only required if you want to make calls using the phone network. You can call your XMPP friends using honeybee without a cheogram account.

Another goal of honeybee is to further investigate writing core sxmo components in system languages ⁴. I have already tried doing this with peanutbutter - written in rust. I chose zig for this project cause it is simpler than rust, it’s error handling, and the build system is nice (easy static linking). I do think relegating error handling and critical components to a systems languages will help reliability but most of the improvement in reliability will come from a simpler call stack. Moreover, users can rest assured that even if honeybee fails, the missed call notification will be saved on the cheogram server and shown on their desktop/laptop. By using Cheogram, users can call/text from their laptop/desktop using any client they want.

I think postmarketOS/Sxmo still needs userspace work. In the future, I want to work on a XMPP texting app with the following features:

• Displays images using sixel
• Saves the texts in plain text on the file system (similar to Sxmo)
• Has hooks
• Written in a systems language (probably zig+snikket-api)
• MMS works out of the box - no configuration required (courtesy of Cheogram)

Also, I want to work on a contacts app that uses rustlang and the vcf crate that is a feature replacement for sxmo-contacts ⁴. This would allow for conversion between android contacts and sxmo contacts easier.

Moreover, we still need a mobile adaptive gui email client - this may be my next project!

There is much to do for linux phones and little time!