Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Implement limited, opt-in/perms-protected local API to read, mark read and delete messages, send messages, and notify changes. NO internet access requested/required.

Open
  • Is something wrong?
#893 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
android, kotlin
Domain
api, mobile, security

Research direction

Start by reading the app's existing message-action and Settings code, then assess the proposed bound AIDL service and runtime permission; the issue names app/build.gradle.kts as the AIDL build entry point. The change is done when opt-in, permission-protected access covers the requested SMS/MMS actions and change notifications without adding networking to FM; the API boundary and security model need design first.

Written by the indexing model from the issue text.

Description

feature request needs triage
Checklist
  • I made sure that there are no existing issues - open or closed - to which I could contribute my information.
  • I made sure that there are no existing discussions - open or closed - to which I could contribute my information.
  • I have read the FAQs inside the app (Menu -> About -> FAQs) and my problem isn't listed.
  • I have taken the time to fill in all the required details. I understand that the request will be dismissed otherwise.
  • This issue contains only one feature request.
  • I have read and understood the contribution guidelines.
Feature description

An opt-in API in Fossify Messages ("FM") that lets a separate, user-approved app on the same phone do the following through FM:

- read conversations and messages
- send messages to new recipients and to groups
- mark messages read
- delete messages
- be notified of new, sent, read and deleted messages

while FM STAYS the default SMS app.

Access to the API should be off by default.

FM Settings should toggle it on/off, and list which apps can use it. Anything done through the API should work exactly like doing it in FM itself (blocked numbers, recycle bin, notifications, etc.).

Intended use: a separate app on the phone connects to my desktop over local Wi-Fi ONLY. No Google, no cloud relay, no account. FM still sends/receives everything over the phone's SIM, same as now.

Scope: SMS and MMS only. No RCS.

Why do you want this feature?

I want to read/send/manage my phone's SMS from my Linux desktop.
For user workflow here, phone-only SMS, without desktop integration is a non-starter.

Two primary, current ways to use SMS on a Linux desktop (KDE, in my case) through the phone are:

(1) Google Messages: an Electron app on the desktop wrapping Google Messages for Web. The phone has to run Google Messages.

It works, BUT it needs Google services and a Google account.

(2) KDE Connect: KDE Connect with PhoneLink on the desktop, and KDE Connect on the phone. It's Google-free, and can read/notify/send via FM (or any SMS app) on the phone.

BUT the desktop can't delete messages on the phone; deletions stay on the desktop. Afaict, KDE Connect has no packet type for deleting a message or conversation.

It's also been buggy as heck in my use.

The other options listed in #665 (tijder/SmsMatrix, beeper/android-sms, benkuly/matrix-sms-bridge, RebekkaMa/android-sms-gateway-server) all need a Matrix homeserver or some other self-hosted server in the middle.
Automatic backup (#1, suggested in #112 by @Aga-C) produces a one-way copy; it can't send, mark read or delete messages on the phone.

A separate app CAN'T fix this on its own. FM doesn't currently give other apps a way to read or send messages or to see changes. So a standalone app would either have to:

- replace FM as the default SMS app

or

- read the system message store directly, which can't mark messages read or delete them. It'd also bypass FM's blocked numbers and recycle bin.

With THIS requested API, a companion app on the phone can relay all of it to the desktop. Delete on the desktop, it's deleted on the phone, and vice versa.

I.e., the functional split is:

FM API (on the phone, no network access):
- everything in FEATURE DESCRIPTION above, off by default

Standalone companion app (on the phone, installed separately):
- all networking: discovery and the local connection to the desktop
- desktop pairing (approve/revoke)
- encryption
- relays desktop requests to the FM API, and FM's change notifications to the desktop
- syncs a desktop that was offline

Additional information

Related issues, all closed:

THIS request adds NO internet access to FM.

It's JUST the API, and Settings control.

It adds no new library dependencies.

ALL networking stays in a separate app. User explicitly opts in to it. It remains completely separate from FM.

No separate "connected" flavor needed. There's no network code in the API, so it ships in every FM flavor.

FM's "part" would be just the local API and one Settings switch; the desktop integration itself lives entirely in the separate apps.

My initial thoughts on a stack I'd use:

FM API:
- a bound AIDL service (Android Binder IPC)
- protected by a new FM runtime permission (e.g., org.fossify.messages.permission.COMPANION_ACCESS)
(maybe, content provider + broadcasts, instead?)
- needs buildFeatures { aidl = true } in app/build.gradle.kts (AIDL is off by default since AGP 8.0)
- a "Companion app access" switch in Settings, off by default
- reuses FM's existing code for each action

Standalone Android companion app:
- Kotlin, Gradle, Jetpack Compose/Room
- NO Google Play services or Firebase
- F-Droid install compatible
- mDNS discovery and QR-code pairing
- encrypted, mutual auth for local connection to desktop

Likely candidate stack for Desktop app:
- packaged as a Flatpak
- frontend, GTK4
- backend, Rust
- connection: rustls + tokio-tungstenite
- D-Bus (Avahi discovery, notifications): zbus
- cache: rusqlite + SQLCipher
- key storage: oo7

Dominant language
Kotlin
Stars
1.6k
Forks
187
Avg merge
3d 5m
Merged PRs (30d)
16

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from FossifyOrg/Messages

All issues in FossifyOrg/Messages

Similar issues

More Kotlin issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.