Deterministic Aliases by MEZTech-LLC · Pull Request #284 · K-Kluster/Kasia

MEZTech-LLC · 2025-12-23T20:24:57Z

New implementation (deterministic, but non-unified aliases).
Distilled related documentation.

…lias

HocusLocusTee · 2025-12-23T21:37:35Z

Functional test - seems to work as intended.

You'll need to revise the 'Offline Handshake' flow though as it's now broken.
How to access: Long hold on the new conversation + symbol.

Whether we remove this and absorb it as part of the discrete mode - makes sense) - but this hidden mode is far 'cleaner' than the current new chat window (speaking UI here). So maybe some consolidation needs to be done.

Also, adding a discrete chat should probably still show a message or something that handshake is completed? Maybe something like "Discrete Chat Initiated".

Also, I'm still not sold on these docs being part of the repo.

HocusLocusTee · 2025-12-23T21:43:43Z

^ Edited above.

HocusLocusTee · 2025-12-23T21:45:00Z

Also FYI, maybe a little more detail in the PR desc next time.

MEZTech-LLC · 2025-12-24T20:43:20Z

**"You'll need to revise the 'Offline Handshake' flow though as it's now broken.
How to access: Long hold on the new conversation + symbol.

Whether we remove this and absorb it as part of the discrete mode - makes sense) - but this hidden mode is far 'cleaner' than the current new chat window (speaking UI here). So maybe some consolidation needs to be done."**

Wasn't aware of that flow. Somewhat disagree that the hidden mode is cleaner. It's quite difficult to discover despite being a pretty important feature (imo). What do you recommend in terms of merging the two? My opinion is we should just remove the hidden mode and keep the optional discrete convo checkbox, but open to leaving the "hidden option"/existing offline handshake flow if we can figure out a clean way to make it more discoverable.

"Also, adding a discrete chat should probably still show a message or something that handshake is completed? Maybe something like "Discrete Chat Initiated"."

Roger that

"Also, I'm still not sold on these docs being part of the repo."

Sure, can remove. I mostly left them in there just to help with debugging as we add this feature.

HocusLocusTee · 2025-12-24T20:46:34Z

**"You'll need to revise the 'Offline Handshake' flow though as it's now broken.

How to access: Long hold on the new conversation + symbol.

Whether we remove this and absorb it as part of the discrete mode - makes sense) - but this hidden mode is far 'cleaner' than the current new chat window (speaking UI here). So maybe some consolidation needs to be done."**

Wasn't aware of that flow. Somewhat disagree that the hidden mode is cleaner. It's quite difficult to discover despite being a pretty important feature (imo). What do you recommend in terms of merging the two? My opinion is we should just remove the hidden mode and keep the optional discrete convo checkbox, but open to leaving the "hidden option"/existing offline handshake flow if we can figure out a clean way to make it more discoverable.

"Also, adding a discrete chat should probably still show a message or something that handshake is completed? Maybe something like "Discrete Chat Initiated"."

Roger that

"Also, I'm still not sold on these docs being part of the repo."

Sure, can remove. I mostly left them in there just to help with debugging as we add this feature.

I should've specified... I don't think the 'hidden-ness' is cleaner - rather the model itself.

MEZTech-LLC · 2025-12-24T20:56:31Z

Alright,
Perhaps having tabs for each convo type at the top of the modal is better then? (Handshake and Offline-Handshake) where the offline handshake tab shows the existing modal?

HocusLocusTee · 2025-12-24T21:17:08Z

Alright,

Perhaps having tabs for each convo type at the top of the modal is better then? (Handshake and Offline-Handshake) where the offline handshake tab shows the existing modal?

Decent idea. Maybe let's leave it as is, do the clean up and the review of core idea and after I'm happy to propose some UI work.

…andshake logic bug

MEZTech-LLC · 2025-12-26T19:47:39Z

@HocusLocusTee
Made changes discussed above + added a fix for an edge case handshake logic bug.
If user A and B had an ongoing discrete chat and user A deleted their conversation, if user A attempts to "rehandshake" (non-discrete) with B, user A would not be able to receive messages from B due to no handshake response being received.
Changed behavior to automatically send a handshake response for any chat that is currently "active" in response to a handshake attempt.

HocusLocusTee · 2025-12-26T20:43:30Z

Part of the discrete conversation flow should give the option to self stash the alias.

Also, self stash or not - from a UX perspective we should add a self (off-chain) message saying a discrete handshake was completed.

This will also add a date time so we don't get a blank card with no reference like the image below:

MEZTech-LLC · 2025-12-26T21:55:11Z

Ok added a toast for the discrete message init, but will change it to a message in the thread.

What do you mean by "self stash the alias"?

HocusLocusTee · 2025-12-27T06:12:42Z

What do you mean by "self stash the alias"?

In the current system we send a 'self stash' tx to ourselves - which is indexed by the indexer - so we can keep the handshake between difference devices.

Now, in the proposed alias changes: if I am A and set up a discrete handshake with B, then chance devices - we will need to self stash this to sync it.

MEZTech-LLC · 2025-12-27T21:12:24Z

@HocusLocusTee
Added proposed changes.

Also something I noticed that would be a useful future improvement; seems like contact names/nicknames are not stored anywhere except the local db. Should probably track these on the indexer using some sort of similar self-stash method.

HocusLocusTee · 2025-12-27T21:54:58Z

If A has no funds, they cannot start Discrete chat. (They should be able to). We should find a way to segregate the self stash tx and the creation of chat. See old Offline Handshake flow.

Still trying to think of a better way to handle new chats. This branch currently adds a 'Discrete Chat Initiated' message but the in chat link for that is now a dead-link. https://explorer-tn10.kaspa.org/txs/discrete_start_b2bcf46f-2df1-46df-b9d7-c04e317411f6. We could do a hacky patch but there might be a better option?

RE: your statement: Sure, seems low priority. But IMO it's outside of this scope. Maybe open an issue ticket for it.

MEZTech-LLC · 2025-12-28T18:09:36Z

"If A has no funds, they cannot start Discrete chat. (They should be able to). We should find a way to segregate the self stash tx and the creation of chat. See old Offline Handshake flow."

Not sure I understand this.
Doesn't self-stashing require the user to have at least some funds, otherwise they wouldn't be able to conduct a tx (cover fees).
Do you just mean that the 0.2 KAS balance shouldn't be required? Or do you mean that the .2 KAS balance shouldn't be required AND if the balance is 0 (not enough to cover the network fee) the self-stash should just be skipped?

HocusLocusTee · 2025-12-28T20:19:04Z

Self stash does require KAS. But setting up a discrete handshake does not.

Right now, no balance blocks me from even creating the handshake.

If balance is 0, we could automatically skip the self stash... but we should eventually add a way to stash it again at a later date.

… handshaking an emepty wallet (now always listening when initiatedByMe is true

MEZTech-LLC · 2025-12-30T16:38:14Z

Got it - self stash is now skipped when funds are not available.

HocusLocusTee · 2026-01-05T08:03:52Z

-      });
+      // Optionally create self-stash for cross-device sync (requires minimal funds for network fees)
+      // Check if user has sufficient balance before attempting
+      const minFeeAmount = BigInt(100000); // ~0.001 KAS for network fees


we use const minAmount = kaspaToSompi("0.19"); in other places. maybe we should generalize this.

Leaving this as is for now - linter flags usage in the subsequent conditional if I change it to use kaspaToSompi since undefined can be returned.

HocusLocusTee · 2026-01-05T08:06:08Z

 import { ImagePresenter } from "../Modals/ImagePresenter";
 import { BroadcastParticipantInfo } from "../Modals/BroadcastParticipantInfo";
 import { QrScannerModal } from "../Modals/QrScannerModal";
-import { OffChainHandshakeModal } from "../Modals/OffChainHandshakeModal";


We need to clean up OffChainHandshakeModal.

HocusLocusTee · 2026-01-05T08:09:24Z

 }) => {
-  const handleShortPress = () => {
-    onNewChat();
+  const handleClick = () => {


We don't need this component at all anymore. It can be styled with a regular + button and none of the 'holdable' complexity.

I had left it for future usecases, but will remove

HocusLocusTee · 2026-01-05T08:19:13Z

@@ -0,0 +1,306 @@
+# Debugging Alias Routing - Logging Added


I still dont think we need this doc. There are plenty of decent comments explaining how this works in the new util file.

HocusLocusTee · 2026-01-05T08:22:34Z

+        }
+      } else {
+        console.log(
+          "[createDiscreteConversation] Skipping self-stash - insufficient balance for network fees (conversation works locally)"


Great. But how does one self stash at a later date?
We should add a warn that we did not self stash due to no balance.
We also need to add the ability to self stash at a later date (and track this somehow). I don't think it should be part of this PR as it'll muddle the context - but we should be aware and open an issue / put it into future work.

Want me to open this as a new issue? Or can you?

HocusLocusTee · 2026-01-13T08:55:25Z

@MEZTech-LLC please see the commits in this branch:
#286

Feel free to cherry-pick them if you approve.

MEZTech-LLC · 2026-01-13T16:04:39Z

Looks good to me

HocusLocusTee · 2026-01-14T07:47:40Z

+          shouldSendResponse: boolean;
+          conversationId: string;
+        };
+        if (typedResult.shouldSendResponse) {


I think we should extract some of this to the conversation manager stop. Maybe something like sendAutomaticHandshakeResponse

HocusLocusTee · 2026-01-14T07:48:08Z

-    // add an offline handshake
+
+    /**
+     * @deprecated Manual alias exchange is no longer needed. Aliases are derived deterministically.


Probably dont need legacy comments like this and the one on line 1247

HocusLocusTee · 2026-01-15T09:20:19Z

      this.monitoredAddresses.clear();
      const conversations = conversationManager.getMonitoredConversations();

+      console.log("[block-processor] Updating monitored aliases:", {


I think we should remove the logs you've added. They are way too noisy.

@MEZTech-LLC I've done it for you. feel free to just pick the last 2 commits so I don't claim write ownership over your other commits
#289

Thanks @HocusLocusTee - Apologies I couldn't get to this sooner; other pressing tasks came up

IzioDev

Rust part sounds good, I'll dedicate more time on the application code later (and actually try it locally too :) ).

IzioDev · 2026-02-01T01:27:01Z

+    // Get my public key from my private key
+    let my_public_key = my_private_key.to_public_key()
+        .map_err(|_| JsError::new("Failed to derive public key"))?;


Minor: We can avoid computing pk from sk if the client provide a public key instead of the private key.
Public key can safely be computed once by the client upon startup (where we initiate the wallet state), and provide it here.
same for xonly_pk (below)

IzioDev · 2026-02-01T01:30:47Z

+    // Parse their address to extract their public key
+    let address = Address::try_from(their_address)
+        .map_err(|e| JsError::new(&format!("Invalid address: {}", e)))?;
+
+    // Extract X-only public key from address (32 bytes, no parity)
+    let their_xonly_pk = XOnlyPublicKey::from_slice(address.payload.as_slice())
+        .map_err(|e| JsError::new(&format!("Invalid public key in address: {}", e)))?;


This block is done twice, once here and once in derive_alias_with_context.

I propose to let responsibility to calling site to compute address + xonly_pk and now derive_alias_with_context takes a xonly_pk as argument

IzioDev · 2026-02-01T01:33:31Z

+
+    // Construct info string: "chat" || shared_secret || context_pubkey
+    let mut info = Vec::new();
+    info.extend_from_slice(b"chat");


If we re-use another domain separation, maybe we should name chat more explicitly.

What it is, is: a 1:1 conversation alias for now. I propose to simplify as alias as it may be a general concept within the application for other purpose as-well

or dm_alias, or pchat (private chat) or w/e

nit: could be made under an enum: enum HashDomain { ... }

# Conflicts: # src/components/Modals/NewChatForm.tsx # src/service/block-processor-service.ts # src/service/conversation-manager-service.ts # src/store/ui.store.ts

HocusLocusTee · 2026-02-27T09:39:20Z

+        // In deterministic system: I monitor myAlias, they send to theirAlias
+        // Due to ECDH symmetry: their theirAlias === my myAlias
+        monitored.push({
+          alias: conversationAndContact.conversation.myAlias,


This is correct, but will be an issue with old v1 alias. Do we just optimistically hope they upgrade? If so, why do we then even give them the option to upgrade if the code isn't fully compatible with v1.

True, maybe just lock the conv and force manual upgrade (no hidden / automatic mechanism), wdyt?

Is it with just running a db migration on boot?

Currently, on boot it adds a version field at conversation level (the entity holding alias data) and we set it to v1 by default.
Later, when you enter a conversation, if it's v1, you're asked to migrate (it replays handshake, and set to v2).
All new conversation are created as v2

Ack on that. But why not just compute new alias on db bump / opening new version?

Absolutely right, 0 need into re-initiating an handshake. Besides it would reveal stealth conversation.

Should be good with latest commit, let me know what you think, silently migrate basically

HocusLocusTee · 2026-02-27T09:55:20Z

+            <Button
+              variant="primary"
+              onClick={sendUpgradeResponse}
+              disabled={isSubmitting}


Maybe we should disable this with a funds check and a message if they try to send with no funds?

General Q for this great feature: Wonder if we need a way to 'force' an upgrade. Lets say they are not getting upgrade messages, we can compute this without interaction, so should we allow it?

Removed because I don't think it has a use-case at the moment, maybe for dcom upgrade (not even sure that'll be necessary)

MEZTech-LLC added 3 commits December 23, 2025 15:15

Undo unified conversation alias, create deterministic myAlias, theirA…

e8d9aac

…lias

Undo unified conversation alias, create deterministic myAlias, theirA…

4ce9d3e

…lias

Undo unified conversation alias, create deterministic myAlias, theirA…

c326fcf

…lias

Removed offline-handshake flow, add discrete chat toast, fixed edge h…

08d8bd1

…andshake logic bug

Discrete init chat offline message & self stash address

e54e38e

Self-stash made optional for discrete chat & fixed edge case bug with…

bdf46ea

… handshaking an emepty wallet (now always listening when initiatedByMe is true

HocusLocusTee requested changes Jan 5, 2026

View reviewed changes

MEZTech-LLC and others added 7 commits January 11, 2026 21:52

Updates to deterministic alias

b256151

Updates to deterministic alias

b5e3a2f

Updates to deterministic alias

7115c70

fix: remove balance check in discrete mode

333a886

style: new chat panel modifications

4bf118e

chore: remove holdable plusbutton

09f19ff

chore: take min kas to constant and delete offlinehandshakemodal

6c49643

HocusLocusTee mentioned this pull request Jan 13, 2026

Ability to re-send handshakes #287

Open

Merge branch 'staging' into staging

146b1c4

MEZTech-LLC requested a review from HocusLocusTee January 14, 2026 03:56

HocusLocusTee reviewed Jan 14, 2026

View reviewed changes

HocusLocusTee reviewed Jan 15, 2026

View reviewed changes

chore: remove redundant functions

8437087

IzioDev requested changes Feb 1, 2026

View reviewed changes

IzioDev added 5 commits February 27, 2026 01:20

Merge remote-tracking branch 'origin/staging' into MEZTech-LLC/staging

f4b6ee6

# Conflicts: # src/components/Modals/NewChatForm.tsx # src/service/block-processor-service.ts # src/service/conversation-manager-service.ts # src/store/ui.store.ts

chore(env): remove usage of testnet-10 entierly

dde98fc

feat: conversation migration path and fix historical retreival

678b05b

self-review

3c36321

chore: cipher refacto

726e00c

IzioDev requested a review from HocusLocusTee February 27, 2026 04:59

HocusLocusTee reviewed Feb 27, 2026

View reviewed changes

review: silently migrate on unlock

aeab016

Uh oh!

Conversation

MEZTech-LLC commented Dec 23, 2025

Uh oh!

HocusLocusTee commented Dec 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

HocusLocusTee commented Dec 23, 2025

Uh oh!

HocusLocusTee commented Dec 23, 2025

Uh oh!

MEZTech-LLC commented Dec 24, 2025

Uh oh!

HocusLocusTee commented Dec 24, 2025

Uh oh!

MEZTech-LLC commented Dec 24, 2025

Uh oh!

HocusLocusTee commented Dec 24, 2025

Uh oh!

MEZTech-LLC commented Dec 26, 2025

Uh oh!

HocusLocusTee commented Dec 26, 2025

Uh oh!

MEZTech-LLC commented Dec 26, 2025

Uh oh!

HocusLocusTee commented Dec 27, 2025

Uh oh!

MEZTech-LLC commented Dec 27, 2025

Uh oh!

HocusLocusTee commented Dec 27, 2025

Uh oh!

MEZTech-LLC commented Dec 28, 2025

Uh oh!

HocusLocusTee commented Dec 28, 2025

Uh oh!

MEZTech-LLC commented Dec 30, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

HocusLocusTee commented Jan 13, 2026

Uh oh!

MEZTech-LLC commented Jan 13, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

IzioDev left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

HocusLocusTee commented Dec 23, 2025 •

edited

Loading

HocusLocusTee Feb 27, 2026 •

edited

Loading