- get wnodes from resources/config/fleets.json which is taken from
fleets.status.im
- store wnodes by fleet and not by network since they are always the same
- reset wnodes settings during migration
- add option in developper menu to select fleet
- mailservers are now presented by their real name
Signed-off-by: Igor Mandrigin <i@mandrigin.ru>
reorganize config flags
remove offline-inbox-enabled? flag
remove universal-links-enabled flag
remove add-custom-mailservers-enabled? flag
remove spam-button-detection-enabled? flag
remove flags from config files
Signed-off-by: Eric Dvorsak <eric@dvorsak.fr>
simplified flow:
- event `:ui/login` is dispatched
- node is initialized with user config or default config
- `node.started` signal is received, applying `:login` fx
- `:callback/login` event is dispatched, account is changed
in datastore, web-data is cleared
- `:init/initialize-account` event is dispatched
replace event dispatches by function composition
fix bug in universal links where url to be processed after login
was never removed
Signed-off-by: Eric Dvorsak <eric@dvorsak.fr>
When creating a new account / recovery we don't poll the mailserver anymore for historic messages, which solves the immediate issue of fetching only received messages
Handle messages sent from a different device in public chat / restore history. The message will be added, shown correctly as sent by the user, and the status will be set as sent ( need to check for seen race condition, as messages will now be added twice). This means that multidevice should now work for public chats.
Move contact updates to discovery topic. This is necessary as there is a pre-existing bug whereby contact updates would not work anymore after wallet recovery, as the code relies on the initial contact request being stored on the mailserver, which we cannot guarantee (we only pull 7 days of data). Not pulling history anymore exacerbate the problems but does not introduce it.
To make sure that contact updates will work after wallet recovery, we also need to consider a ContactUpdate in the same way we consider a ContactRequest (the other peer has no idea that the user has recovered the wallet). This does not change any behaviour in terms of obscurity/security as ContactRequest are automatically processed (in both case the contact will be set as pending?, not as accepted)
At this stage ContactRequest, ContactRequestConfirmed, ContactUpdate have all the same logic, i.e. update the contact information, leave the pending flag alone.
Only 1 day of history is fetched for newly joined chats, if catching up 7 days is the cap as before.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
This handles a bug whereby we'd run receive-whisper-messages
when the user is logged out.
I could not replicate locally, but a few issues are apparent from
just inspecting the code:
1) there are some race-conditions on logout as we don't wait for all
the filters to be removed. Changing this behaviour is non trivial and
not sure if we can actually handle this completely
(status-go-has-a-message->remove-filter->logout->status-go-deliver-message).
2) no error handling is made in receive-whisper-messages.
This PR defensively handles both cases.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
- fix a bug in profile where app would was returning directly to profile
screen after photo capture, showing updating to user but not actually saving
and broadcasting it
- adds support for offline contact request, confirmation and updates by
leveraging the :sent and :not-sent signal from status-go. Each chat
in the protocol layer uses a `resend?` field to keep track of the current
state of the contact, between `nil`, `contact-request`,
`contact-request-confirmation` and `contact-update`. There is no case
were it can be more than one case because if `contact-request` or
`contact-request-confirmation` was not sent yet `contact-update` is not
necessary as the latest contact infos will be sent with the request/confirmation
Signed-off-by: Eric Dvorsak <eric@status.im>
message cache was initialized when logging-in so it was basically useless
it was causing a bug when switching account and getting a contact request
from the same user in 2 accounts without killing the app because the cache
was not reset and the subsequent contact requests were ignored
Signed-off-by: Julien Eluard <julien.eluard@gmail.com>
* Do not try to reconnect when offline
* If online, but mailserver is disconnected, show notification
* Tap on notification starts reconnecting process
Signed-off-by: Eric Dvorsak <eric@dvorsak.fr>
previous naming was confusing because it actually sends using
the symkey of each chat whose simkey is passed as an argument
Signed-off-by: Eric Dvorsak <eric@dvorsak.fr>
- Fetch discovery topic from offline inboxing
- Send ContactRequestResponse on discovery channel with new-key message
for recovery of invited contacts
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
* Add "connecting" mailserver status
* Send push notification when "envelope.sent" signal received
Signed-off-by: Dmitry Novotochinov <trybeee@gmail.com>
* Set message status based on signal from Go
* Set status as "not-sent" on app start if no signal received
Signed-off-by: Dmitry Novotochinov <trybeee@gmail.com>
I have extended and modified the current algorithm for message ordering
so that it applies for group and public chats alike.
We use Lamport timestamps but we prefix the unix timestamp, which should
maximize the chances of the message being seen on the top of the chat.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
janherich
yenda
Andrea Maria Piana
Eric Dvorsak
Pedro Pombeiro
Roman Volosovskyi
Connor Christie
Dmitry Novotochinov
Andrey Shovkoplyas
psdp