api: Put the chattype into the SecurejoinInviterProgress event

[Hocuri]

Quoting @adbenitez:

I have been using the SecurejoinInviterProgress event to show a welcome message when user scan the QR/link of the bot (== starts a chat with the bot)

but this have a big problem: in that event all you know is that a contact completed the secure-join process, you don't know if it was via certain 1:1 invite link or a group invitation, then a group-invite bot would send you a help message in 1:1 every time you join a group with it

Since it's easy enough to add this information to the SecurejoinInviterProgress event, I wrote a PR to do so.

[Simon-Laux]

wouldn't it make sense to also have the chat id? otherwise how do I know which group the contact joined into?

[Hocuri]

Do you need the chat id for something specific?

When the SecurejoinInviterProgress event is sent because we just observed a securejoin that happened on a second device, it's not trivial to find out the chat id. I'm sure it's possible (though I didn't check how), but I wouldn't do it if there isn't any particular reason to include it.

[iequidoo]

I think this PR is useful for bots which have the only group or map each contact to a particular group, otherwise yes, the chat id would be nice to have. As for multi-device bots, i think it's overall hard to implement them, it's not clear which device should process user's request. Maybe providing an optional chat id (with None or 0 on devices observing SecureJoin) is enogh for now.

[r10s]

the chat id would be nice to have

this is not enough.

there needs to be at least one real-world-existent and in-use application that needs it, waits for it and will use it.

as for the problem at hand that @adbenitez pointed out and is solved by this PR

[iequidoo]

There is even no need to look up a chat id (which may not exist on the second device for various reasons), but the grpid (Chat-Group-Id header value) can be easily added because observe_securejoin_on_other_device() has MimeMessage with all parsed headers. If it's not a group invite, it will be an empty string then. I.e. we don't even need to make any db query. Adding it to the event payload we'll avoid compatibility issues in the future if we need it later.

EDIT: get_chat_id_by_grpid() is a crate-public function, so grpid won't be useful if we return it right now, but adding it isn't harmful.

[Hocuri]

grpid is an implementation detail, there is no utility for UIs to know it

[Simon-Laux]

Do you need the chat id for something specific?

there needs to be at least one real-world-existent and in-use application that needs it, waits for it and will use it.

I have a bot that needs a reliable "member added to chat id" event that works in all cases. I currently use "chat modified", but that fires also in other cases, I would like to have a more specific event for this case to re-send my "welcome message".

But maybe that's something different that needs a separate issue?

(listening to secure join event AND incoming "member added"-system-messages feels a hack anyway and is not really good bot developer UX)

[Hocuri]

I mean, what we can do is, add a chat_id: Option<ChatId>.

chat_id would then be None for progresses < 1000, and when observing a securejoin on other devices. Both is not a problem for the bot, because the bot only cares when securejoin finishes (i.e. progress=1000), and bots are usually not multi-device. Still, not perfect that it's only present in some cases.

Yes, probably best discussed in a new issue.

[Simon-Laux]

Yes, probably best discussed in a new issue.

I made a dedicated issue for my problem #7183

[iequidoo]

chat_id would then be None for progresses < 1000, and when observing a securejoin on other devices.

This is good enough (and was suggested above btw). And this doesn't require extra db queries on the first device. Still, the chat type is also useful, so both may be put into the event.