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).