Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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.

Abierto
  • ¿Algo no está bien?
#893 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
android, kotlin
Área
api, mobile, security

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
Kotlin
Estrellas
1.6k
Forks
187
Merge medio
1 d 16 h
PR fusionados (30 d)
20

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de FossifyOrg/Messages

Todos los issues de FossifyOrg/Messages

Issues similares

Más issues de Kotlin

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.