I build a small messenger and I’d like opinions, not installs. Disclosure up front: I’m the developer of FlickerTalk (Android, AGPL-3.0, no account, no phone number). Limits first, since this is a privacy community: it only works when the other person has it; 1:1 and small circles, no large groups; on a direct connection the other phone can see your public IP; Google delivers the wake-up push and sees that one arrived, not what it says.

The design decision I keep second-guessing: instead of adding features to the messenger, I put them in an “Apps” tab as small sandboxed web packages you open inside a conversation. Each tool sees only what you hand it, and nothing leaves the phone until you tap send. Today: a document scanner, signing a PDF together, a shared list, split expenses, a poll, a whiteboard during calls, a few two-player games.

Questions for people who think about this more than I do:

  1. Is “tools inside the chat” a privacy win (less data sent to third-party apps) or a bigger attack surface, in your view?
  2. Which everyday task would you actually want to do without leaving a conversation?
  3. What should a messenger refuse to bundle, no matter how convenient?

I’ll answer every reply and I’m fine with “none of this, keep it simple” as an answer.

  • XLE@piefed.socialEnglish
    6·
    7 days ago

    Why not just build on something that already exists? Like DeltaChat already has most of these things and then some, and uses a trusted encryption protocol (none is mentioned for your app).

    Kinda concerning when the readme contradicts itself in an obvious way within a few lines

    Text, files, voice and video calls between two people, with the history living only on the phones — never on a server … [If] the other phone is off, the message waits in a mailbox on our server

    • ioan@lemmy.worldOPEnglish
      1·
      5 days ago

      Fair points, and thanks for reading the README closely; that is what I asked for.

      Encryption. Messages are end-to-end encrypted with Olm (Double Ratchet) through the vodozemac Rust library. It is in the README’s third bullet, but it should have been in this post; that is on me. Transport is a WebRTC data channel between the two phones, and the DTLS fingerprint is tied to the contact’s identity key through the signalling, which is Olm-encrypted too.

      The README. I don’t think it contradicts itself: those are two different things. “No history on a server” is about your conversations, which only ever live on the two phones. The mailbox is a separate, optional feature for a message that could not be delivered because the other phone was off. I agree the first sentence was too short to make that clear, so I have tightened it to “the server keeps no history”; a README can lag behind the app, and the app is what counts, so install it and check for yourself. The two options the user has:

      • Mailbox on (the default): if the other phone is off, the message waits on our server end-to-end encrypted, with no sender attached, until it is picked up or seven days pass; it is deleted the moment it is picked up. We cannot read it and we keep no history.
      • Mailbox off: either side can switch it off in the settings. A message only goes to the mailbox if both people have it on; otherwise it waits on the sender’s phone until both are online, and nothing of yours is stored on our server at all. The server keeps no preference either: each request carries the flag.

      Files and calls never go through the mailbox in either mode. The full list of what the server keeps is on the site under “how it works”.

      Why not build on the app you mention. It is a good project and its email-based model is a solid choice. Honest answer, in two parts. First, FlickerTalk started as a personal project where I needed to learn, Rust and WebRTC mostly, and it grew from there. Second, I could not find a messenger that was both private and modular: one where the core stays small and you extend it with isolated tools, each seeing only what you hand it, instead of every feature being baked in. That is the gap I am trying to fill, and it is also what this post is about. The itch behind it is personal: I used to spend hours on the phone playing chess with my father, and I wanted that right inside the chat, along with the small utilities I use every day, without the ad-filled apps you end up installing on Android for each of them. Along the way I wanted two things the email model does not aim for: delivery straight from phone to phone when both are online, and no account of any kind, not even an email one, plus voice and video calls. Different trade-offs, not a claim of being better.