Introducing Honeybee: Calling via XMPP

Published 2024-10-06 on Anjan's Homepage

Problem Statement

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 1 - there are plans to move audio routing to pipewire.

Consequently:

  • Under the postmarketOS wiki feature matrix, even if “Multimedia 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 2
  • Scripting uses dbus which is not the prettiest interface 3
  • 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.

VOIP and Cheogram

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

Honeybee

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 4. 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.

Future work

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 4. 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!

Have a comment on one of my posts? Start a discussion in my public inbox by sending an email to ~anjan/public-inbox@lists.sr.ht [mailing list etiquette]

Articles from blogs I follow around the net

These articles/blogs do not represent my own opinions or views.

Text processing on the Command Line - sharing my tools

Text processing on the command line - sharing my tools Introduction I'm quite fond of the command-line and spend a larger chunk of my life in a terminal emulator than I dare admit. I try to embrace the unix philosophy of using tools that "do one thing…

via Proycon's website July 7, 2024

Linux phones are not automatically secure

A common point in the Linux community is that escaping the walled garden of ecosystems like Android or iOS is already a means to higher security. Having no contact with Google or Apple servers ever again, nor cloud providers ever snooping on your private …

via TuxPhones - Linux phones, tablets and portable devices January 25, 2023

Generated by openring