If you are following KaiOS and BananaHackers, you probably have noticed that not much is happening. I have written a post about state of KaiOS in 2023. Back then, there was still pinpricks of hope in me. Now it's all gone.

Smart feature phone was a very good idea. And so was KaiOS. But they didn't well play the game. So they lost. I'm not gonna go through the reasons why it failed. However, I sure have technical criticisms from user and developer point of view. I do wish it succeeded. But not all wishes would be granted.

KaiOS is dead in the global market. However, it has still has some presence in the US and some parts of Africa. WhatsApp withdrawing from KaiOS makes the situation even worse for them. It seems they are slowly sinking in the water. Maybe water is already over their head.

If KaiOS had a global presence, a Matrix client like chooj had the potential to make a major influence for KaiOS. As you could use beeper's software to connect to various Messaging platforms all from Matrix. This means you could have WhatsApp, Telegram, and tons of other IMs right in your KaiOS device. It could be a game changer.

I imported a Nokia 2780 Flip. Affe Null made contributions to make it hackable. But my main motivation for writing apps for KaiOS, is the fact that it was my daily driver. That I was the first user of the apps. Now without global devices, I don't have a KaiOS phone as a daily driver. So no motivation to write KaiOS apps.

Another problem with newer KaiOS devices is that you can't simply enable debugging on them and sideload apps, to then use them as development devices. That was another major problem for us. However, enthusiasm made us find ways to hack the devices, find hidden codes, root them and finally write apps. Now there is no device to hack, anymore.

I'm afraid when there is no KaiOS, there is also no Matrix client for KaiOS. So I'm archiving the chooj repositories today. And I won't renew the domain any longer. If anyone would like to continue chooj, I would be happy to help them and to tell them about internals of the app. You don't know how much do I hate to let chooj go. I humbly thank people who donated, people who tested and people who encouraged me.

You might be interested in my other “wares”. In that case, here are some links to various places I have presence:

• My English blog
• My Persian blog
• Mastodon
• Codeberg
• Github

TL;DR; Thanks to one of brilliant community members, Cyan, our wiki now renders on KaiOS and is usable there. This is possible by integrating a custom Javascript and the script does not run if the browser is not a KaiOS browser.

Why it was not working on KaiOS browser?

The currently widespread version of KaiOS, version 2.x, is based on an ancient version of Gecko. Gecko is the browser engine used by Firefox and the version KaiOS uses, doesn't support newer technologies and standards.

The wiki software we use, wiki.js, uses the new technologies to render the content. Thus, it doesn't render on KaiOS 2.x which is using an ancient browser engine. However, this is not a problem on KaiOS 3.x which is based on the modern engine. But unfortunately, this new version of KaiOS is not widespread globally, yet. And most users have got devices which run the older version.

What has changed now?

Cyan has written a script which we've integrated with our wiki using the custom HTML feature. This script first checks if the target browser is a KaiOS one. If it isn't, it won't do anything. But if it is KaiOS, it'll try to render the content of the wiki pages so that visitors from KaiOS can see the content.

Does it affect efficiency and performance of the wiki?

Yes. But the affected performance is very trivial. The script is less than 10 KiBs minified. And if the browser is not KaiOS, only a simple check is extra there.

It is not perfect, yet.

Cyan has done great job. I am very grateful. However, it might be that in some cases, like edge cases, the script won't work and render things properly. Feel free to contact Cyan to improve the script. He is available on our community chatrooms accessible from Matrix and Discord.

#linux #kaios #bananahackers #bananahacker #pmOS #nokia2780 #hack #kaios3 #firefoxos

It has been a while since 2780 is out. Most BananaHackers have been waiting a long time to get their hand on a KaiOS 3.x device and Nokia 2780 is the first one released which is not carrier-locked. Many other community members, like Luxferre seem to prefer waiting till a global 3.x device gets released. This 3.x flip phone is not global but because it's not carrier locked, one could import them from third party stores like Amazon.

I haven't got my hand on a 2780, yet. But according to Affe, no code worked on Nokia 2780 Flip to enable debugging like other Nokia models such as the BananaPhone. And using W2D does not enable ADB. It's very unfortunate. But like most other hackers in the world, Affe was not willing to give up till he gets what he wanted and now we have the weeknd Toolbox created by him.

This toolbox enables users to modify the internal storage of 2780. This let's us side-load third-party apps outside KaiStore as well as modifying the pre-installed System and obviously, the stock apps among them.

Remember that debugging is not yet possible on 2780. And side-loading the apps is not done through the debugging protocol of B2G like the other phones. Thus, this phone is not suitable for app development purposes, yet. Unless, of course, you are willing to do some device hacks to make it so.

If you want to learn more about 2780 and the technical story behind the hack, you can read the wiki page dedicated to this phone on BananaHackers wiki.

#kaios #bananahackers #hacker #hacking #featurephonedevelopment #featurephone #notandroid

A few years ago, Luxferre founded the BananaHackers community to hack KaiOS, the web based mobile OS, and to develop for this platform. I joined this community after I got my BananaPhone. The famous 8110 which has a yellow colour and is curved. I remember I was exactly looking for the yellow version of the phone and it was very exciting.

I remember when I wanted to get my 8110 back in 2017, there were just around 100 apps in KaiStore or maybe even less. The community was young and so was KaiOS. I think my first app for KaiOS was VM-IRC which the VM part was standing for Very Minimalistic. Later when I joined the community chatrooms which back then were hosted on r/KaiOS Discord guild. I found the community welcoming and very active. We had Uncle Ivan(or Ivan Alex HC) among us who was not a developer but had spirit of a tinkerer. You might know his Youtube channel. We also had many other members which you can find a list, hopefully complete, in the credits page of our wiki.

I was honored to become a trusted member of the community and later a council member. The council is the heart of the community and we have very old members there who are still active. We also had many members there who are no longer around, unfortunately.

In 2018, the partnership of KaiOS and Mozilla was announced to bring modern and performant web for KaiOS. Almost everyone of us were waiting for KaiOS 3.0 which was based on the new Gecko rather the ancient one used in Firefox 48. There are so many advantages in this upgrade. Including but not limited to support of WebAssembly, newer WebGL, much better performance in rendering and new web APIs. We were looking forward to the new KaiOS and hoping it to be still debug-enabled and available worldwide.

But now, in 2023, this mobile Operating System seems to be on the verge of death. Not only KaiOS 3.0 is out but also KaiOS 3.1 is also out. But there is no device which is available worldwide. Only few carrier-locked devices for North America. Nevertheless, there is Nokia 2780 Flip which is not carrier locked. And one can buy from online shops like Amazon almost anywhere in the world. But first, this phone will cost one around 140 bucks to get into their hand. Second and more important, this device is not debug enabled and thus it cannot be used for app development purposes in a convenient way.

Many “council” members have lost interest in developing for KaiOS. Many have not and believe this OS will live on and cover a minority of the market. Both opinions seem reasonable and we'll have to wait to see what will happen.

I've already considered an alternative mobile OS. I have two main requirements: First and most important, I must be able to easily hack the OS and write apps for it. Unfortunately, not Android nor iOS are not my answer. Developing an Android app requires you to have huge resources on your PC. And its ecosystem is hard to hack. Compiling Android itself takes ages and a regular PC. iOS on the other hand is even worse. To develop for iOS you need a MacBook and a developer licence from Apple. The second requirement is that I don't want my phone to be only a display which is boring and the outside view of most smartphones these days.

I haven't decided, yet. But postmarketOS looks very promising. There is already good support of hardware features in 8000 4G and 2720 Flip. There is a possibility to port the new Gecko to pmOS to bring the new KaiOS to the older phones. However, this is not easy, simple nor trivial.

One of members, mostly known as Affe Null, had developed their own ecosystem for KaiOS phones, mainly 8110 at that time. He had ported Debian to 8110 and also developed many apps for it including a graphical shell. Later, he moved to pmOS which seems a reasonable move.

#chooj #matrix #matrixorg #chat #chatapp #chatclient #foss #kaios

After a long period of no progress, I've got time to work on chooj, the Matrix client for KaiOS, again! The progress is slow and constant funding is needed so that project will reach stable status within a reasonable period.

What's new?

From user point of view

Because many security flaws were found in one of dependency libraries of chooj, matrix-js-sdk, I had to tell everyone to stop using chooj. The most important change is that with upgrade of this dependency, chooj is usable again.

There are many small features which have been added. Most importantly, there is a much better and more friendly login progress, you can save pictures to gallery, log out from chooj(In past the only option was uninstalling chooj and logging out from another client), and join rooms by entering room's alias(name) or id . Many bugs have been fixed and probably many new ones have been introduced. Finally, I've added partial support for checking presence of your contacts. Please check if this feature works with your homeserver. For my homeserver, all contacts show as offline(gray badge next to the user avatar).

From developer point of view

All dependencies have been upgraded to latest versions. This include Inferno, the JS SDK, localforage and many others.

I've also switched from webpack to parceljs. The app was initially created with Create Inferno App which used webpack. But during upgrading dependencies(which also required upgrading node), I've found webpack has too much overhead with its configuration. While when targeting KaiOS, zero configuration truly doesn't exist, parcel requires way less effort for this. Also parcel uses Rust which makes building much faster.

There are working development and production builds. But more work must be done. For instance, when targeting Firefox 48, parcel tries to build a bundle which is good for both the ancient FF48 and newer browsers. FF48 doesn't support Javascript modules while modern browsers support. So parcel builds both module and nomodule Javascripts which make the bundle size twice. You can see this issue in parcel's repo for tracking the progress of it.

Regarding the UI library, chooj was using AdrianMachado's KaiUI which is both ancient and intended to be a React UI library. React on KaiOS is really a terrible idea because of its efficiency. chooj, however, was using just styling stuff from the KaiUI. But the dependencies which were supposed to be used in a React project, was also installed with yarn install.

As a long term solution, we need to fork this KaiUI and maintain it ourselves because Adrian is no longer working on it. For now I've forked it to KaiUIv2 where all React stuff have been removed and now that is dependency of chooj. The styling stuff, however, is untouched. Many works must be done. I invite users of this KaiUI to help me with maintaining KaiUIv2.

Future plans

I plan to keep the look and feel of chooj as is till I release the first version(which will be 0.0.0). The 0.0.0 release will have very basic functionalities of a chat app including basic chatting, joining rooms both through public directories and by name, inviting users to DM, managing invites, experimental push notification support and perhaps voice call or end to end encryption support.

After that, huge changes must be made. You can see a proposed UI design in this issue. And so many internal changes like separating the KaiUI Inferno components from chooj should also be done.

KaiOS 3.x support

There is no KaiOS 3.x support at the time of writing this post simply because there is no KaiOS 3.x global device which is also debug enabled. Many phones have been released which are US-only. There is Nokia 2780 which is US-only but not carrier locked. But community member who have bought this device are spending their time on finding a way to enable debug mode on this device.

Funding and help needed

Constant funding is needed for the project in the long term:

• Push gateway server is required for receiving push notifications. The server software should be written in Rust(or possibly Go if someone else wanted to take the job) which relays the notifications from user's homeserver to user's device. The server cost will vary depending on the number of users of chooj. If the number of users are big enough, we could have more than one server for different regions.

• Funding is also needed for development of chooj and its push gateway software. While I try to not abandon chooj, but I need an income for my life.

• chooj must be tested on different KaiOS versions and phones with different hardware features. For instance, the video call feature will require a phone with a front/selfie camera. While it is possible that I do this part of development remotely(e.g. tell someone else to test), it will be very painful and slow.

To help with funding, I've put a Bitcoin Cash(not Bitcoin) address in the project's README. If you are not already familiar with cryptocurrency stuff, you can buy from Paypal or an exchange like which I've mentioned in the link above. And then sending to my address.

There are many other stuff which money will not solve like testing. There is no machine which I can feed it money and after that it will tell me bugs of this project. Also I am a developer and not a UI/UX designer. So help and feedback from the community is necessary just like funding.

If anyone wants to write on this blog, email Farooq with a sample Kai post of their own and he'll reply with an invitation link as soon as possible.

Here's the email address:

fkz [at] riseup [dot] neeeeet

Note that it is riseup.net not neeeeet but robots don't know this :))

delta.map – an application to aid in hiking

Hello everyone! Im new here to this blog, and in my first post, we'll talk about an application I have been adapting to my needs and made open source some time ago, delta.map...

How I started off

I started off forking o.map, I was full of ideas at the moment, unfortunately, some days later I had to go in vacation and left my computer at home, but wait! I built it later at my location so I could continue development! I had made lots and lots of updates, automatically fetch location, weather, accuracy, and wait, I had an idea that was supported by a friend, iGameEveryDay06, I suggested that I should edit the app to fit the style of KaiOS, it seemed pretty easy, but then I realized everything was written in react, which needs to be compiled, minified, it's pretty annoying. One day, when I was hopeless, Cyan linked to me a GitHub Repo containing native code for KaiUI, it looked beautiful, it was still difficult to implement, but then I realized I could easily add the item class to make the items selectable, once I implemented it enough, it seemed like it would be more difficult to revert back to the old modified o.map style.

What i am currently working on

Im currently working on adding .kml file support, fix a SoftKey bug and maybe improve the code as it is currently a mess + all of the random fixes I do which makes it 100% optimizable if some javascript god happens to run across my repo and make a giant pull request :)

Help me

If you want to support us (me and perry share bits of our code so o.map and delta.map will be always updated), the Repo is here: https://github.com/Delta-Applications/delta.map

Some screenshots

5cb.png)

In the last post I wrote about the #ApiDaemon. In this post, I will show that it is possible to add “add-on” services to the daemon, and also explain what else the daemon does.

Remote services

Remote services are like plugins for the API daemon. Unlike normal services, they don't have rust libraries that are compiled into the api-daemon binary, but instead run as a separate “child” daemon. When needed, the API daemon starts the child daemon with the environment variables LD_LIBRARY_PATH set to the remote service's path and IPC_FD set to a file descriptor number that is used for IPC between the API daemon and the child daemon.

General structure

Remote service daemons are located in subdirectories of /data/local/service/api-daemon. The subdirectories are named after the service. Each subdirectory should contain at least a daemon binary but can also have a valid_build_props.txt file. Remote services also need a JS library in the http_root. For example, the wavoip2 service contains the following files:

/data/local/service/api-daemon/remote/wavoip2/daemon
/data/local/service/api-daemon/remote/wavoip2/libc++_shared.so
/data/local/service/api-daemon/remote/wavoip2/libwa_voip.so
/data/local/service/api-daemon/remote/wavoip2/valid_build_props.txt
/data/local/service/api-daemon/http_root/api/v1/wavoip2/service.js.gz

The valid_build_props.txt file contains a whitelist of values of ro.build.cver. If the file exists, the service is only considered valid if ro.build.cver matches one of the lines and SELinux is in enforcing mode. wavoip2 is even more strict: Even if the daemon does start, it still checks for SELinux enforcing and ro.build.cver values. Because of this, WhatsApp calls don't work on rooted or soft-rootable devices. However, you can spoof SELinux enforcing with the following commands:

echo -n 1 > /data/local/tmp/enforce
mount -o bind /data/local/tmp/enforce /sys/fs/selinux/enforce

And if you then run setprop ro.build.cver QC_8905_3_10_49_SEC_1, wavoip will start successfully.

I haven't figured out the IPC protocol yet, but looking at the API daemon's source code will probably help: https://github.com/kaiostech/api-daemon

KaiAds

The API daemon also serves the #KaiAds SDK for privileged apps. This is probably used because of CSP restrictions that apply only to privileged and certified apps. Newer versions of the SDK provide a “SDK loader” that decides whether to load the real SDK from kaiads.com or http://127.0.0.1:8081/sdk/ads.

Telemetry

Another thing which the daemon does is telemetry. I first noticed this when I tried enabling SELinux enforcing to get wavoip working. After running setenforce 1, my phone suddenly became very slow, and when I looked into logcat, there were a bunch of lines saying that the telemetry process couldn't read from /proc/kmsg!!! Later I found out that this process belongs to the API daemon. This means that the API daemon reads the kernel log messages for telemetry purposes.

Also, I found the following lines in the daemon's configuration file:

[telemetry]
enabled = true
send_app_opened_events = true
token_uri = "https://api.kaiostech.com/v3.0/applications"
metrics_uri = "https://api.kaiostech.com/v3.0/apps/metrics"

so the daemon also sends “app opened” events to KaiOS.

All of this can be disabled by setting enabled to false. But KaiOS also provides development versions of the API daemon that have enabled set to false by default: https://packages.stage.kaiostech.com/base_23/api-daemon-1.4.26.zip. I will write about the packages.*.kaiostech.com domains in the next post.

You might have already heard that #WhatsApp uses some undocumented APIs that are built into the #KaiOS system. These APIs are powered by the api-daemon, a daemon which lies at a lower level than Gecko. In this post, I will explain what I have found out about this daemon.

The api-daemon is written in #Rust, and provides several “services”. Each service has two parts, the JS client and the Rust library. The Rust library is linked into the api-daemon executable. The JS clients are accessible via HTTP at http://127.0.0.1:8081/api/v1/<service>/<script>.js and expose APIs in a lib_<service> variable. A pre-installed version of the daemon is available in /system/kaios, but it is copied to /data/local/service to allow updates without modifying the system partition.

Using the APIs

To demonstrate the usage, let's create a simple app called “Daemon Test”. We will use the telephony service. Although it is meant to be used to get and set the call state, it seems that real calls have no effect on the reported state. However, the state might reflect ongoing WhatsApp and other VoIP calls.

To use the APIs on KaiOS 2.5, we need the external-api permission:

manifest.webapp

{
  "name": "Daemon Test",
  "launch_path": "/index.html",
  "description": "An app to demonstrate api-daemon functionality",
  "type": "privileged",
  "permissions": {
    "external-api": {}
  }
}

index.html

<!DOCTYPE html>
<html>
  <body>
    <div id="callstate">Loading...</div>
    <script src="http://127.0.0.1:8081/api/v1/shared/core.js"></script>
    <script src="http://127.0.0.1:8081/api/v1/shared/session.js"></script>
    <script src="http://127.0.0.1:8081/api/v1/telephony/service.js"></script>
    <script src="daemon-test.js"></script>
  </body>
</html>

We can now use these APIs as described in https://developer.stage.kaiostech.com/docs/sfp-3.0/09.migration-from-2.5/next-new-apis/daemon-api/telephony/daemon-api-telephony/, except that we will need to replace localhost with localhost:8081. Note that the documentation is for KaiOS 3.0, but on 2.5 only the telephony, libsignal (for WhatsApp) and tcpsocket services are available. You can also look at the api-daemon source code, which is also only for KaiOS 3.0.

First, we need to set up a sess variable that stores the api-daemon session:

var sess = new lib_session.Session();

Then, we write some handlers that get called when the session connects/disconnects:

function onsessionconnected(){
  lib_telephony.TelephonyService.get(sess).then(function(service){
    /* handle session connect */
  });
}
function onsessiondisconnected(){
  /* handle session disconnect */
}

And after that we try connecting.

sess.open('websocket', 'localhost:8081', 'secrettoken',
  {onsessionconnected, onsessiondisconnected}, true);

Here is the final code:

daemon-test.js

window.onerror = function(e){
  // Error handling
  alert(e);
}

var sess = new lib_session.Session();
var el_state = document.getElementById('callstate');
var toggleCallState = null;

function callStateChangeCallback(state){
  el_state.textContent = state;
}

// Set up session callbacks
var onsessionconnected = function(){
  alert('Session connected');
  // Get an instance of the telephony manager
  lib_telephony.TelephonyService.get(sess).then(function(manager){
    alert('Got Telephony manager');
    try {
      // Show the call state
      manager.callState.then(function(state){
        el_state.textContent = 'Call state: ' + state;
      });

      // Show it again if it changes
      manager.addEventListener(manager.CALLSTATE_CHANGE_EVENT, function(state){
          el_state.textContent = 'Call state: ' + state;
      });

      toggleCallState = function(){
        // Get the call state
        manager.callState.then(function(state){
          // Set the call state
          manager.callState = state ? 0 : 1;
          alert(state ? 'Idle' : 'Calling');
        });
      }
    } catch(e) {
      alert(e);
    }
  }).catch(function(e){
    alert('Failed to get Telephony manager: ' + JSON.stringify(e));
    toggleCallState = null;
  });
}
var onsessiondisconnected = function(){
  alert('Disconnected');
  toggleCallState = null;
}

// Initialize the api-daemon session
sess.open('websocket', 'localhost:8081', 'secrettoken',
  {onsessionconnected, onsessiondisconnected}, true);

window.addEventListener('keydown', function(e){
  if(e.key == 'Call'){
    // Toggle the state if 'Call' is pressed and the session is ready
    if(typeof toggleCallState === 'function') toggleCallState();
  }
});

There is a lot more to this. I will also make a wiki page, and some more posts about things such as the updater-daemon and remote services.

More tags: #ApiDaemon