Conversation
…re still fails...
6513d3b to
9af1f93
Compare
9af1f93 to
f6edbe0
Compare
| text: | ||
| 'Nuking removes all local data, including encryption keys. If this is your last signed-in device you might no be able to decrypt any previous content.', | ||
| ), | ||
| TextSpan(text: 'Are you sure you want to nuke?'), |
There was a problem hiding this comment.
Nuke seems a strong wording. I would probably go for Erase or Wipe in terms of easy understanding and no assumed double meanings.
There was a problem hiding this comment.
It is intentionally strong wording as this is super dangerous... and should only taken if there is no other course of action left ... it won't even back up ... Hence also using the bomb_icon and big-red-letters ...
I mean ... ideally this screen never shows up to a regular user. It only does when we got the underlying SDK into an unrecoverable state - most likely upon startup.
| title: const Column( | ||
| crossAxisAlignment: CrossAxisAlignment.start, | ||
| children: [ | ||
| Icon(Atlas.bomb_bold,color: Colors.red,), |
There was a problem hiding this comment.
I would not be in favor of using this icon, could be brush or some more friendly warning sign...
There was a problem hiding this comment.
brush?
It was intended to be something that no one clicks without understanding the risk ... as this is a super-wipe-out without backups ... and see comments as above ...
There was a problem hiding this comment.
As in means of cleaning as we can see in some cleaning data apps, anyways I would like to hear what's the general opinion on this via feedback.
| notify(brief); | ||
| } | ||
| } | ||
| // final provider = ref.watch(featuresProvider); |
There was a problem hiding this comment.
Why is this commented out? Or its been moved somewhere else? If it is, you can remove comment.
There was a problem hiding this comment.
It was some previous code that would show local notifications just coming from our own local supply mechanism and show a local notification regardless of actual push ability on the device ... I suppose we could think about activating something similar again for desktop but we'd have to think about how to phrase that and actually make sure we get the needed data ... I'll remove this for now.
| } | ||
| } catch (error, trace) { | ||
| // ignore: deprecated_member_use | ||
| return state.namedLocation( |
There was a problem hiding this comment.
Very nice, a better handling approach.
|
|
||
| > Unable to make field private final java.lang.String java.io.File.path accessible: module java.base does not "opens java.io" to unnamed module @7fbe8ef | ||
|
|
||
| If you happen to come across this exception while compiling Android build for application launch, the reason for that is with the flutter fetching the JDK path from Android Studio directory as a default option. This is reported to be occuring in latest **Android Studio Flamingo (2022.2.1)** in reference to the Flutter issue [#106416](https://github.com/flutter/flutter/issues/106416). |
There was a problem hiding this comment.
this issue had been resolved in newly revised version. We can remove this section of doc :)
gtalha07
left a comment
There was a problem hiding this comment.
Very well put! Excited to try out new stuff.....
app/lib/features/activities/providers/notifiers/notifications_list_notifier.dart
Outdated
Show resolved
Hide resolved
app/lib/features/activities/providers/notifiers/notifications_list_notifier.dart
Outdated
Show resolved
Hide resolved
|
Great work |
This contains:
From this point forward all newly registration or logins will have a strong encrypted-on-rest-paradigm installed: upon creation the database we create a random password and use it to encrypt all data stored on disk (within the matrix-sdk store). All this is then kept in the secure enclave ('keychain') of the operation system. Old sessions will be moved over into that enclave though already existing database won't be migrated or encrypted. This was necessary because we couldn't open the unsecured session storage before from the iOS Service Extension (see below), but we can savely open this one.
When activated and upon restart, the user will be asked if they want to receive push notifications. When accepted, we are sending over a "pusher" to the homeserver using your newly added
$PUSH_SERVERas target (sygnal-servers already deployed).a) having a new service that enables us to read and decrypt the event, understanding its content and showing a decrypted message
b) for iOS background services, this PR already contains the necessary Service-Extension and uniffi-swift-plumbing to load the rust service (that's what those makefile changes are about), and it actually works. Unfortunately it isn't able to actually decrypt the data until we have deployed the sliding-sync mechanism, so we are running into a runtime error (theoretically this should just work once we have switched to sliding-sync). In those cases it will show a generic message for the time being (but c) still works)
c) Upon click, regardless of foreground or background, the app will open and route to the corresponding chat-room or space.
Note that if we are in foreground and looking at the chat, not notification is issued (we are usually seconds faster in showing the message in chat compared to when the push-message makes us to the device).
Supported Platforms: iOS & Android.
Instructions for testing: You need to set the
PUSH_SERVERor the code will be skipped altogether. For our test-setup use the usual matrix-domain and prefix it withsygnal.(DM me for help if you need it):Stil to do:
For later
Android:
android push.webm
iOS:
RPReplay_Final1696436232.MP4