Tmp/editable aliases#271
Conversation
HocusLocusTee
force-pushed
the
tmp/editable-aliases
branch
from
5ce0e36 to
0ed5657
Compare
Kasia in its early days was kind of working like this: process every messages and try to decrypt, whether or not the alias was known. This added extra slowness randomly while using the application (background listening + decrypt) |
| this.processBlockAdded.bind(this) | ||
| ); | ||
| async stop() { | ||
| this.rpc.removeEventListener("block-added", this.boundProcessBlockAdded); |
There was a problem hiding this comment.
Are we implying this line isn't working as intended?
There was a problem hiding this comment.
Are you talking about this line or
in general? Observed behaviour before this is we still process blocks when logged out (after logging in). Unsubbing for block added is the main fix
There was a problem hiding this comment.
Yes this line,
So based on your comment it seems like this.rpc.removeEventListener("block-added", this.boundProcessBlockAdded); isn't working, but still your added line makes sense.
It's just that the previous one should stop incoming block for being processed, while the other one should tell block processor to stop ingest them (but they still are incoming)
I'll have a look 👍
There was a problem hiding this comment.
Could you please annotate the line (await this.rpc.unsubscribeBlockAdded();) with a TODO, like: This shouldn't be necessary as the listener on block-added is supposed to be removed (which seems to not be the case), so we force the un subscription from internal system
| // update the conversation reference with the latest from manager | ||
| // this ensures alias updates from self-stash are reflected (newer than db aliases) | ||
| oooc.conversation = conversationWithContact.conversation; | ||
| oooc.contact = conversationWithContact.contact; |
There was a problem hiding this comment.
todo izio: validate this flow and see if we shouldn't handle it elsewhere
note: it is expected (not necessarily working in every case) that this whole logic takes the last knows alias based on date of events, if there are multiple receive / sent for a single recipient, we should take the last known one, regardless
There was a problem hiding this comment.
Note: without this we would save the new alias. Stash it. Log out and back in but contact info model would reference old alias. So
You could either edit it which would update the state or just log out and back in again.
Initial self stash is handles already in logic above this line.
There was a problem hiding this comment.
Stash it. Log out and back in but contact info model would reference old alias
This likely indicate a greater issue where newer handshake (received / sent) events on this conversation aren't being ingested properly, potentially the same happens if I receive a new handshake while already having a conversation, we'd like the new handshake to be the new source of truth
|
After this comment #271 (comment), mergeable 🚀 |
HocusLocusTee
force-pushed
the
tmp/editable-aliases
branch
from
cbf98b2 to
b06777b
Compare
I still not quite understand. Irrespective of the 'bug' of us receiving blocks after removing event listener - why would we not want to unsub? Note: I had to re-base on staging. |
We do want to unsub, it's the correct line to add. But it's also has reflected an underlying bug |
ui: show aliases from contact info modal feat: add tooltip component and use in alias info WIP: adjust alias feat: more work - refactor alias update - add ability to get convo by id - extract alias validator style: improve alias editing style: warn block and misc styling refactor: extract send self stash to a hook fix: update convo reference on load - make sure we are removign the right event listener - unsub from block added sub chore:rebase
fix: db version
IzioDev
force-pushed
the
tmp/editable-aliases
branch
from
2f7572f to
bf60444
Compare
|
Modified so we allow editing their alias even if N/A (unset) If you're satisfied with the change, LGTM @HocusLocusTee |
I was planning to not merge this. And just pick some relevant parts after deterministic alias is added. |
|
All right, good for me! Should we mark it draft? |
2 participants
what?
adds the ability for a user to edit their aliases from the contact info modal
extracts self stash to a hook
fixes a bug (that was reintroduced) where the client processes messages when logged in then logged out again
some thoughts while working on this:
nearly everyone could use the same alias and just rely on the client to successfully or not successfully decrypt, encrypt the message - the impact of this requires some fundamental protocol thought from me.
additionally this also gives the ability for on-chain handshake obfuscation. where party A and party B could start a regular chat sending a transaction handshake to each other.
then within the encrypted chat they could agree on new aliases and swap those. a third party could assume that this has taken place but its not provable.