Why DarkSpeak Is Desktop First
One of the reasons DarkSpeak is desktop first - or Linux first - in an age where everything is running on the mobile phone is that the mobile phone simply cannot reliably do what needs doing in a decentralized app that doesn't have dedicated relays or any backend servers.
The problem is that mobile phone apps will normally only be fully active when you are interacting with them, when they are in the foreground. Some apps can also run in the background—for example, a media player, so you can listen to music while you are reading mail or while you are jogging.
But continuously running in the background and maintaining network connections uses more battery. Something like the Tor network also requires persistent network activity, and maintaining separate persistent connections can significantly increase battery consumption.
Android had fewer restrictions on background services in the past, but they have gradually locked down background execution. Today an ordinary app cannot simply assume that it will run reliably in the background forever. Android has foreground services for work that needs to continue, but there are restrictions on when these services can be started and what they can do. Android may also restrict an app if it consumes excessive resources.
When the phone is idle, Android's Doze and battery-management features can restrict background network access. This is one of the reasons Android encourages applications to use Firebase Cloud Messaging rather than each application maintaining its own persistent network connection.
I have background mode in one of my other applications on Android, NextApp. What I noticed there is that when the app goes into the background, it still responds to push notifications from Firebase (Google) while its own network activity may be restricted.
This is not because Android completely prevents background networking. An application running an appropriate foreground service can still use the network. But relying on an ordinary application process to remain alive and connected indefinitely is not something Android is designed to guarantee.
iOS is even more restrictive. Apps are normally suspended when they are in the background. There are specific background modes and tasks that can use the network, but an ordinary messaging app cannot simply keep running indefinitely with an arbitrary persistent network connection.
Push notifications and metadata
What other messaging apps do is that they have backends, and they let their backends send push notifications to Google or Apple, which then relay them to the devices.
Especially for Google, but also for Apple, this is very nice because they get metadata. For example, if we use push notifications for DarkSpeak, that means that Google or Apple necessarily become involved in notifying the device that something happened, at least when you are not interactively using the app.
DarkSpeak is designed specifically without dedicated backend servers or relays. Depending on Google or Apple push infrastructure to make messaging work would therefore change an important part of that design. So the way to deal with this is to have desktop apps that just run forever. If you have a laptop and you use this app, you should probably just leave the machine on even when you're not there if you want to receive incoming messages.
Using the desktop as a relay
I'm also thinking about using the desktop version as a relay for mobile devices, so that if you have a mobile device, you can still use it with DarkSpeak for the identities you choose to use it with.
You can have many identities on the desktop, and then you can have maybe one or two identities that you deem not requiring the same privacy that you have on a Linux-only desktop. So it's okay if Google or Apple can get some metadata just from the app working. They won't see the DarkSpeak message contents since everything is encrypted, but the mobile operating system necessarily has some information about what the application itself is doing.
The mobile app can use normal background features to periodically wake up. It can connect to the desktop machine and ask if there are any updates or new incoming events. Then it will get everything from the desktop app that's relevant for those identities you have on the phone, sent over securely from the desktop to the phone.
Exactly how often this can happen cannot be guaranteed by the app. Mobile operating systems decide when background applications are allowed to run in order to conserve battery.
Why DarkSpeak needs a computer that's available
If you want to use DarkSpeak, you need to use a real laptop or desktop computer. You can of course also use a server with a VM, which is probably the most secure. The application needs to be available on the network when other people try to contact you or send messages to you, or even send responses to messages like a thumb up or a heart or lots of positive emojis.
If we designed an account to run only on mobile, without any other usually-available DarkSpeak node, you could not rely on the application being reachable whenever somebody wanted to send something to you. That is the fundamental problem. Mobile operating systems are designed around applications that can sleep and be woken when necessary, often with the help of centralized push-notification infrastructure. DarkSpeak is designed around nodes communicating without dedicated backend servers.
Imagine two phone users in different time zones, with both applications suspended whenever their owners aren't using them. Neither phone can assume that the other DarkSpeak application is running and reachable at the moment it wants to communicate.
A desktop, laptop, or server can be different. It can simply stay there, connected.
The difference between peer-to-peer encryption and peer-to-peer messaging
The fundamental difference between a normal messaging app and DarkSpeak is that DarkSpeak is peer-to-peer only.
If you use Signal, Session, Telegram, or most other messaging apps, your application connects to a server somewhere. When you send a message, it goes from your device to that infrastructure and eventually from there to the person you are communicating with.
End-to-end encryption does not change that architecture. With Signal, for example, your phone encrypts the message before sending it to Signal's servers. Signal does not have the keys required to decrypt the contents, so it cannot read the message. But the server infrastructure still sits between the two participants and is involved in delivering the message.
DarkSpeak works differently because there is no messaging backend. When you connect to someone, you connect directly to a device owned by that person. The message does not need to be handed to a DarkSpeak server first because there is no DarkSpeak server sitting in the middle of the conversation.
DarkSpeak also applies its own end-to-end encryption on top of this peer-to-peer architecture. Messages may travel over the Tor network, but their security does not depend on Tor's encryption. Even if Tor's encryption were somehow magically broken, the message traveling from your device to your contact's device would still be encrypted by DarkSpeak. Tor provides the network path. DarkSpeak provides the encryption between the actual endpoints.
This architecture also becomes interesting when you start thinking about small group chats. A message does not necessarily have to travel directly from its sender to every member of the group. Another member's device could relay an encrypted message to someone who was unreachable when it was originally sent. The relay does not need access to anything beyond what that peer is already entitled to see, and nobody outside the group has the keys required to decrypt the group's messages.
That means the network can eventually become more resilient without introducing a central server. Devices can help move messages through the network while the cryptographic relationship remains between the peers themselves. The important part is that DarkSpeak does not have to become the middleman in order to make communication work.