This PR removes prepareMsg, which put messages into the OUT_PREPARING state and was used while videos were recoded. It also removes the now-unused method isIncreation().
- It was buggy because when you forwarded a message while it was InPreparation, or when the app was killed while a message is InPreparation, the message would stay InPreparation forever.
- Android is the only UI using this InPreparation (according to @r10s, I didn't check this myself), so we can simplify some things in core, which will also make it easier to deduplicate blob files.
these RPC calls are probably a relict of first tries,
they are not exhaustive in their area are nor were ever used,
maybe not even working.
if we decide to go that way at some point anyways much more is needed :)
* Don't always show the sender in notifications
In 1:1 chats, don't prepend the sender name to every line. The exception is when the display name is not equal to the chat name (i.e. there is an OverwriteSenderDisplayname), in this case we still prepend it.
* Always show the "~" before the sender name if it's overridden
When we introduced this, I assume that we weren't sure whether we should
do it and only showed it in some places. But I think it's nicer to
show the same sender name everywhere, i.e. always add the "~".
this PR removes options to create encrypted database.
existing encrypted databases will continue working for now.
the 'encrypted database' experiment started some years ago
was never finishes and already stopped working partly,
eg. importing backups as encrypted accounts stopped working
some years ago for newer android.
in the light of Signal's "encryption key flaw",
but also recent issues with worsending core things in Delta Chat,
it seems wise to concentrate on the core things ("you have one job!"),
and not on side topics comparable few persons are interested in.
also, it will become harder to maintain that path on upcoming api changes,
leaving the database open as opening is slow is needed but will become harder,
this will make notifications tricy,
may need additional effort to run in background etc.
all that is doable,
however, it will remove resources from far more important parts,
dangerously up to a level that breaks the app - a focus is limited.
also, no one really complained as it is already partly not-working,
it was _never_ working on desktop
(where it would make much more sense),
removal on iOS was flawless, see https://github.com/deltachat/deltachat-ios/pull/2011
tl;dr: better leave the protection up to the operating system
and concentrate on other things.
- add a device message for existing profiles potentially using gmail
- reset oauth2 method for existing profiles on opening login screen
- do not offer gmail-oauth2 for new profiles
there are not really reasons to not allow sending videochat invitations to the self chat:
- it is useful for testing
- one may forward them from there to somewhere else
- it is allowed on desktop and ios as well
in fact, i was very confused that it is not possible
when playing around with https://github.com/deltachat/deltachat-android/issues/3187 .
might be a relict where we did _only_ allow videochat in normal one-to-one chats.
B. Petersen