User stuck at "waiting to be added to group"

I got a group of non-technical friends to agree to try Delta Chat and I don’t want them to have to do debugging, so apologies if details are limited.

One user created a group chat and shared the invitation link with the group. Me and one other user were able to join using that link. A fourth user tried to join and sent me a screenshot of where they are stuck. Here is what they see on their screen:

Messages are end-to-end encrypted.
Tap to learn more.

Wednesday, September 2, 2026

X invited you to join this group.
Waiting for the device of X to reply…

X replied, waiting for being added to the group…

I believe both parties are using iOS.

Here’s a relevant answer in another thread:

It can happen that the invite link you clicked on has already expired or the whole group has been dissolved by today. Please ask for a new one from a member or ask them to add you directly without an invite. Note that invitations are only processed while both ends are online.

Is it true that invitation links expire, and is there any way to know their expiration time? I don’t see any indication in the UI that there is an expiration date or what it is.

If invitations are only processed “while both ends are online,” does that mean the particular sender of the invitation link must be online, and not just anyone currently in the group? I believe (but can’t confirm) that Signal and WhatsApp allow users to join a group chat by clicking a link even if the sender is not online. Is there any hope of achieving parity with this in Delta Chat, either now or in the future?

I can confirm Delta Chat is much more user friendly than any of the other encrypted messaging platforms that don’t require a smartphone, but I am worried that I over-sold it as being easy and intuitive for non-technical people. Any help making it work for my group is greatly appreciated.

The response for that topic was for a little different situation. In your specific case, the person who has generated the invite link can reset the invite link anytime manually, and it will cease to work immediately.

Each member within the group is able to generate an invite link of their own. If you pass around all of these links together to the friend you want invited, they can join whenever at least one of the members are online. It will not expire by itself.

Note that it is just a small inconvenience that joining the first time may take up to 8 hours (until the sender wakes up). A workaround already exists by adding an invite bot to your group that ran on a server 24/7.

You also seem to have missed an important part of the cite: you can also directly add your friend to the group from the group member dialog. The effect of this will be immediate then.

In this case it has been a few days. Can you elaborate on where the 8 hour figure comes from?

The sender is on iOS so I wonder under what conditions Delta Chat gets to run automatically in the background and start automatically on boot. I think we can assume my friend didn’t manually reset their invite link but also didn’t do anything special to make sure Delta Chat could run in the background unless they were prompted to. I think we can also assume that their phone has been powered on in last few days, though they may not have manually opened Delta Chat because barely anybody is in the group chat yet.

If an iOS user follows the path of least resistance to install Delta Chat, make a group chat, and send an invitation link, then turns their phone off and later turns it on again, is it possible that their Delta Chat instance wouldn’t start automatically to complete the invitation handshake?

It’s not that I missed it, it’s just not relevant to my situation because the people being invited aren’t on Delta Chat yet. The onboarding process is of utmost importance and Delta Chat is significantly better than the alternatives I tested (Matrix/Element, Session, SimpleX), but I didn’t foresee this problem. In order for us to start using this group chat I need to give some updated instructions to help people join because the path of lease resistance seems to have failed. But I want to get the full story so I don’t keep telling people to do just one more thing that they didn’t have to do with Signal and then it will be so easy.

I don’t see how guessing randomly over here will help, but my guess is they have already uninstalled Delta Chat from their device by now.

The workflow I follow is to create all needed groups myself and invite others (i.e., then the uptime of my devices will matter, not their, and as I have a bunch of devices running, my uptime is quite high). Ideally, you should install DC together in person and make them scan your QR immediately so you will have at least one verified and secure chat together. From that point, you can add them to your groups without further round trips later on remotely.

Another alternative would be for one of you to send over your vCard that also does not require extra round trips, but that’s more for experts.

Reading your question again, I think the solution is quite clear. You should generate an invite link with your own profile and share that link again on the other platform for the remaining interested members to join. It’s not a problem to have multiple invite links to the same group active.

It is unfortunate that I don’t have access to the devices experiencing the issue. Rather than random guessing, I would like to find information about the iOS app’s ability to run in the background and start up on boot. Can you elaborate on why it might take 8 hours? Is the iOS app only be able to operate in the background at 8 hour intervals?

I would like to know more about that. Are you saying that sending an invite link + a vCard can allow someone to join without round trips, whereas just sending the invite link requires round trips? Are the round trips necessary for some security property or is it just due to the current state of development?

I don’t have access to the other platform, so a non-technical friend will need to be involved either way. If I’m asking people to try this new platform I want to be as up-front as possible about the inconveniences compared to Signal, so I want to understand them so that I can communicate them concisely without stringing my friends along more than I already have. When I ask them to share a new link I would like to be able to explain why the first attempt didn’t work and what they need to be aware of going forward if they ever want to invite new people to a group chat in the future.

Sleep takes 8 hours.

The secure join invite link requires a round trip so you can reset it and no further users would harass you through that link. Once your vCard gets leaked out, anyone could spam you at present, hence why I only recommend it to experts.

That is interesting. I wonder if the Signal protocol has a way around this, such that the user can delegate the role of invite sender to the server without compromising end-to-end security…

Ah, LOL! So what has to happen before and after sleep in order for the delay to be limited to 8 hours? :slight_smile:

This tells us that it’s probably not about the device being offline and not about the invite QR being “reset”, because then we wouldn’t get to this point, so this seems a bit weird to me.

Regarding iOS and push notifications see FAQ - Delta Chat.

Lost messages?

Could you clarify how many round trips are normally needed for this type of join? If the client displays “waiting to be added to group,” what exactly is it waiting for?

I also don’t understand how having a vCard for the sender would reduce the number of round trips necessary? Surely a user’s vCard doesn’t include a membership list of every group chat they are in?

I read that but I don’t get it. If “Apple devices do not allow Delta Chat to fetch data in the background,” how do push notifications help with that? Doesn’t there still need to be some sort of process running on the phone and checking for new DC messages?

Not that I’m aware of? Not sure what you’re asking.

Related:

For what it’s worth, I had issues with this several times as well.

Problem solved by scanning the QR in person. But I think the problem also solved once by just sending new / additional invite links (idk why, maybe one of those times we were just online at the same time or something).

Signal works fine, yes. But you hit on something important. If Signal works, there is no reason why delta chat can’t work. Both are using servers to establish a connection. Why can chatmail servers not do a better job of establishing that connection?

It would be great to get some clarity on the source of this issue. e.g. how does the iOS “push notification” thing described in the FAQ work? Is it a fundamental limitation of iOS or is there something the Delta Chat app could do better?

I have been looking into this question and a user on the Signal Community Forum set me straight with a good explanation of how Signal’s group links work:

https://community.signalusers.org/t/group-links-and-security-of-group-membership/76396/12

Basically the Signal service stores encrypted group membership information which is accessed and updated anonymously using some fancy crypto. It seems like Signal’s solution may impose increased storage requirements on the server, which may or may not be an acceptable tradeoff for Delta Chat. But I guess the main barrier is the implementation of the fancy cryptography, which is not needed if the group information is only stored at the ends.

Short of adapting some complex scheme to achieve the level of convenience that Signal offers, it would at least be worthwhile to clarify why the difficulties arise, and show some disclaimer when the user copies the group link. It’s still not clear to me whether the sender needs to open the app in order for the join to proceed.

For what it’s worth, the user who was waiting to be added eventually was added without any intervention by me. I also noticed that more people were added right after I sent a message, which could have coincided with the sender of the invitation opening Delta Chat to read my message.

Signal Private Group System is complex and it assumes a somewhat trusted central server that will remain available and not restore old entries. From the paper describing the scheme:

The server in our system can neither decrypt group entries, nor forge new entries. These are our main security goals.
However, the server can observe a small amount of information regarding group state,
and could perform limited modifications to this state:

  • The server could observe when a particular encrypted entry performs some action,
    such as fetching the membership list, or adding or deleting other encrypted entries.
    Making updates not leak anything would be very expensive, e.g. clients would have to
    re-encrypt and rewrite a maximum-size group state with each operation and include
    a proof of correctness over the entire state.
  • The server could delete ciphertexts or reinstate old ciphertexts. We believe this
    system could be extended to add end-to-end integrity-protection by having clients
    sign each new group state (along with an incrementing ”version” number), however
    we have not tackled that in the initial system.

As far as I understand Signal does not require any other member inviting you to the group to be online, but at the cost of requiring a central server.

There are two round trips. When you scan a QR code or click on the invite link:

  1. You send a “key request” message.
  2. Inviter sends you a message with their key back.
  3. You send a message asking to join the group with your key attached.4
  4. Inviter sends a message telling they have added you to the group, to you and to all other members.

First round-trip is skipped if you have the key of the inviter already.

Worst case is if you and the inviter are in different timezones and are never online at the same time. If inviter is offline when you scan the QR code, you send a key request and wait for the inviter to go online. Meanwhile you go offline. Inviter sends you the key and goes offline. Then you go online and get the key, but have not joined the group yet. Only when inviter goes online again they will add you to the group, and then you will only learn about it once you get online again.

So, I’m replying here after being asked for clarification in private.

Yes. And you can further reduce the number of round trips if you changed your onboarding flow from invitations to directly adding them to your groups.

So to recap, it works best if you add somebody via an invite who is standing right beside you and both of you are connected to the internet. Otherwise, if each of you only have access once a day, it could happen that it could take more than 4 days to get added.

Normally, if users have Delta Chat installed properly on their mobile that connects to the internet once every few hours (i.e., as often as you get nearby a free wifi hotspot or 24/7 if you have a mobile data subscription), you shouldn’t worry about this - invitations will go right through in seconds. You are not supposed to keep opening Delta Chat to progress with invites and if it is killed in the background by your OS, it must be fixed.

I find that sometimes it’s best to ignore Google Services and instead install from f-droid and enable the Forced Background Connection - it doesn’t eat as much battery as you would think.

You can improve the situation by adding multiple devices that you own to the same profile (e.g., iOS, Android, desktop), so invites progress when any of them have a connection.

You can add an invite bot hosted by either you or someone else as I have mentioned. If you don’t have access to an invite bot, your best bet is to designate one person among your friends (or yourself) who is the most techie and who is not lazy to set up their 2-3 devices properly in the same profile (hopefully 24/7 up) and only generate and share invites by that user. Then new members are expected to get added almost instantly.

What else do you think we could do to help? Should the dialog that generated the invite link have a disclaimer that unless both parties are online at the same time, the invite process could take 4 round trips?

What you actually seem to desire is for Delta Chat to somehow reduce the number of round trips and the worst case latency, but that will result in many trade-offs.

Delta Chat could have a (default-on) setting to add a hosted bot to each group that you create for you. This bot could have multiple features, such as handling invitations, previews, reminders, etc. This would have privacy implications on multiple levels, even though pro users would be allowed to change the bot instance in the settings.

One of the worst aspects is that such bots receive and could thus record each message in the group. An earlier proposal would improve on this situation by inventing new user metadata markup to designate a user as a bot. We could then withhold messages and attachments from them and only send them group control metadata and direct messages addressed to them via user mentions, whitelists of slash commands or other regexp-based matching (such as only forwarding a bare link to a web preview bot, but not random files). It could then also be a setting whether their output should be broadcast to every member or to who had asked.

An invite link could be enriched by allowing to specify not one, but multiple users who can add us to the same group. It could improve the overall perceived uptime if the client tried to join by contacting one after another with a few seconds of delay until it succeeded.

A more radical change would be to invent the concept of “insecure groups” - ones whose invite link can not be revoked as it contained the full public key. This may sound like a step backwards, however, as group security would already need a major overhaul, abuse could also be handled in another layer.

Owned groups could be improved further by designating who is muted, who has full voice and whose messages are fully moderated by the owner (or designated moderators) such that the client of the member will first forwarding their message to a moderator and only injected by them (or their rule-based bot) into the group after acceptance. This is not unlike how moderated NNTP groups worked in the 80s.

Also, groups could still carry an invite token, but it would not be cryptography anymore - it was just an unrevoked “password” that needs to be present, otherwise the new member will not admitted at - the client of the owner will silently discard any and all of their messages instead. You could then also distribute multiple kinds of invite links to the same group: one that allowed only read-only access initially (channels) and one that allowed unrestricted access (e.g., for friends & family groups).