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.

#kaios #foss #opensource #freesoftware #libresoftware

About software and its distribution

In the years which software was not commercialized and copyright about software was not yet a thing. People were distributing software and its source code and users were changing the software to their wish for better usability. The term hacker didn't mean someone who breaks into servers but it meant someone who plays around with the software and possibly fix bugs or add features to make it more useful. Today, this is known as “Hacker in the MIT sense”.

Later came FOSS to bring the same advantages to the software world in the modern era. FOSS stands for Free Open Source Software. Strictly speaking, free software and open source software are different. Free here means freedom not zero price. However most pieces of software which are free software are also open source and vice versa. This includes those under MIT/X11, GPL, LGPL, MPL and many many other such these licences.

Nowadays, a software does not necessarily come with the source code. Even if it's written in a language like Javascript which does not give your a binary, yet you don't have the source code because people mangle and minify the JS code. This will make the final package smaller and will also prevent users from understanding what the software does. To understand such a code, first you must add proper formatting and indentation to it. After that you'll have a bunch of function or variable names which use a single character and no comments to help you understand the code. I remember a friend had said “These apps have been written without any love”. I told him the “love” has been removed from the apps before deploying to production!

From a point of view, KaiOS is just a pre-built Lego, just like any other Unix-like distribution. It's a Linux distro. The main parts of this Lego are the Linux kernel which its job is communication with the hardware, the libraries including libc which provide a useful and more abstract way to talk to kernel, and finally Gecko which on the top of it KaiOS applications, including the System app and the stock apps, run. There are also many other stuff like propriety vendor-dependent stuff.

Which parts of KaiOS are FOSS?

The Linux kernel used in KaiOS phones is under GPLv2. GPL is a strong copyleft licence. Many other “userland” libraries have similar licences. Gecko has a copyleft licence but a weak one. Copyleft means you can take the software and use it and possibly change it. But if you want to give the software to the others, you must give them the software and the changes in source code form as well. So from a legal point of view, KaiOS manufacturers must provide users the source codes which are under a copyleft licence. For example Nokia has published source code of Linux, many libraries and Gecko.

But will giving you the source code make it possible for you to change the OS to your wish and deploy the new version to your phone? Sadly, the answer is not a total yes.

First, many drivers are vendor-dependent and propriety. For instance, my 800 Tough has a Snapdragon from Qualcomm. If you have a similar phone, you will find many stuff in your phone with qcom in their name for various hardware features of the phone, including but not limited to Camera, charging, Cellular data and 3D acceleration. So where's the copyleft? The Linux kernel is under GPL which is a strong copyleft. Strong copyleft simply means you cannot combine propriety code with strong copyleft code. But Qualcomm uses propriety firmwares for various hardwares on the phone which are not linked with the Linux kernel and therefore it's not necessary to release the source code. Also not every part of KaiOS is strong copyleft. There is also weak copyleft which permits the combination as long as the original source code will be available. Or in other words, the open source part does not become closed source. Gecko uses Mozilla Public License or MPL which is of this kind.

Second, there are many “System” and “Stock” apps used in KaiOS which are not FOSS. If you want your own free KaiOS, you'll have to write your own version of these apps. Like Contact, Call log, messaging and Settings app. And the most important one, the System app which runs other apps.

Third and the worst problem is that even if you've got an OS to deploy, the problem is the deploying process! You'll need to write your version of OS to device's internal storage and make your phone boot it. It's not easy, simple or straightforward. Companies usually lock their phones to prevent this and frighten customers that if they try such these ways, their phone will go out of warranty.

Nevertheless, there has been attempts to port different stuff to KaiOS phones by using the Linux kernel and possibly other userlands. You can see Affe Null's Bananian project which ports Debian to the BananaPhone. I also remember Affe talking about running KaiOS 3.x on his port but it wasn't useful without hardware drivers and other apps, especially the System app. Last time I asked him, he said he is no longer working on Bananian and instead working on postmarketOS.

Note: postmarketOS is a Linux distribution for the mobile phones. It uses the mainline Linux kernel and Alpine Linux on the top. You might see a variety of different old or very old mobile phones, mostly Android ones, which pmOS supports them. Unfortunately, because of drivers being propriety and little manpower to reverse engineer and replace them with FOSS ones, there aren't many devices with very good support of pmOS.

So just the kernel being FOSS has enabled the community to port different stuff to these feature phones. And this shows importance of the kernel to be FOSS.

Which parts of KaiOS are source available but not FOSS?

Source available means you can see the source code but you are not permitted to change it and/or distribute with or without changes. All stock and System apps of KaiOS are source available because they are written in Javascript. Because the JS code has been mangled and minified, it's not easy to understand and modify them. Yet the BananaHackers community has provided near 20 ways as of writing this post to customize your device. To have custom launcher, custom Contact app, custom apps to launch from Lock-screen, change settings of stock apps and a lot more.

Now imagine if we had source code of these apps under a FOSS licence, we could do much better and travel much further. Because the licence of stock apps does not allow re-distribution, legally we are not permitted to publish the entire improved packages or custom ROMs.

Conclusion

So if the ecosystem was FOSS-based and if the devices were not locked, KaiOS could be much better and it wasn't the only practical choice we have got on our mobile phones. And we see that even though the stock apps are not FOSS, and their sources are not available, we have made significant improvements to the ecosystem for ourselves and other users of this ecosystem. If locked phones were not locked, their users could have these improvements in their hands as well.

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