feat(qt): DashPay profiles and contacts

Contacts run over DIP-15 as the mobile wallets implement it. Sending a request derives our receiving keychain for the contact, serializes it in the 69-byte compact form (parent fingerprint, chain code, public key), has the wallet compute the ECDH secret between our ENCRYPTION key and the recipient key the SDK's mint-side policy selects, and the accountReference MAC over the compact xpub, and hands only those 32-byte outputs to build_contact_request, which encrypts and assembles the document. The rotation version of a resend comes from the chain: our latest request to that contact is unmasked with our MAC and its version bumped, so the unique (ownerId, toUserId, accountReference) index cannot reject it and nothing is lost on seed recovery. The request is confirmed by a proved re-query of our sent requests, repeated with a backoff for three minutes. A request Platform accepted for broadcast is never reported as not sent: the UI says it was sent and is being confirmed, the contacts list shows it as a sent request, and a confirmation that takes longer hands over to the contacts refresh; only a typed refusal is a failure. A new contact request waits while one is being confirmed or while the profile signed at registration still holds the identity's first DashPay nonce.

Accepting a request checks the sender and recipient key purposes against the SDK's receive policy and never runs ECDH with the MASTER key (a request from a wallet too old to have encryption keys is refused with a visible reason), decrypts the compact xpub with our key at recipientKeyIndex through dip15_decrypt_xpub, validates it, imports our receiving keychain with a rescan birth time that is ours (the time of our own confirmed request, or now on a first accept, never the counterparty's document time), labels the chain for transaction history, stores the contact's xpub and sends the reciprocal request, all under a single wallet unlock. A contact is established only once both directions are on chain and its key is imported. A request that answers ours establishes the contact with no broadcast, as the mobile wallets do: a refresh or an unlock decrypts it and imports the keychains without asking for the passphrase. Until then the row is Accepted: it asks for an unlock only while the wallet is locked, otherwise it shows why finishing failed, and a request that cannot be read is not retried on every refresh.

Profiles are a display name and a public message, no avatar: the profile is read (proved) before a replace so every field another wallet set is carried through, and the update is confirmed only by a proved re-read at the next revision. Contact metadata (username, profile name) is cached from proved reads only, and a change is shown by rebuilding the rows from the records it was written to, without reading the contact requests again; a profile name is always shown as an untrusted profile name, never as a verified identity. The dashboard gains the contacts list with accept, Add contact… (a username lookup that sends a contact request), and the profile dialog.

Tests (test_dash-qt over FakePlatformClient and a real descriptor wallet): decryption with the ECDH secret the wallet derives, the MASTER-key and wrong-purpose refusals, the full accept with a birth time no earlier than our own request and the labelled receiving chain, accepting after our own request sending nothing (contactAcceptAfterOurRequestSendsNothing), one passphrase prompt per accept (contactAcceptAsksToUnlockOnce), an answered request established on unlock with no broadcast and the Accepted row state (answeredRequestEstablishesContact), an answered request that cannot be read showing why without the unlock wording and not being retried (answeredRequestThatCannotFinishSaysWhy), the resend bumping the on-chain version with the ENCRYPTION sender key and the SDK-selected recipient key, the profile replace carrying the existing document and confirmed by proof, an accepted request reported as sent and being confirmed rather than failed (contactRequestConfirmationIsNeverAFailure), search results carrying the proved profile name read once a session, and contact metadata shown without re-reading the requests (contactMetadataShownWithoutRereadingRequests).

The profile dialog cannot be edited or saved before the current profile has loaded, since a save would publish empty fields over it; saves, searches and contact requests show a busy bar. The contacts section puts the selected row's actions next to Add contact… in its header, sizes its table to its rows (three to twelve, then it scrolls) with the columns as wide as their content and Status next to the data, hides an empty Profile name column, has a loading state and a compact empty state that says contacts are paid by username from the Send tab, clears success messages after a few seconds, and offers Ignore / Hide contact, kept on this wallet under contact/hidden/ because a contact request can be neither rejected nor withdrawn on Platform. Rows and search results act on a double click or Enter, never on the single click some platforms activate rows with, since both write to Platform. The Add a contact dialog lays out Close and Send contact request itself so the primary stays last on every platform, keeps its column widths from one search to the next, and shows each result's proved profile name, read once a session (at most one page of 25). The profile dialog keeps each label on the line of its field, gives both character counters the width of the longest count so the name field and the message box end at the same edge, and grows to show a whole error. The light and dark themes give the contacts table a text colour, and the contacts and search tables one visible selection. The contacts list is not read while the node has pushed no evonode endpoints (network activity off, syncing, or not pushed again yet after a pause): a refresh asked for then, or while one is running, runs once they arrive or it ends, and a read that failed because the endpoints went away is not reported. The dashboard header puts Edit profile… to the right of the name block, top-aligned, and a success message there clears itself; a failed profile read is retried once 30 s later while the tab is shown (one pending retry, like the credits). Tests: the profile dialog waits for the loaded profile and lines its fields up, an ignored request leaves the list until shown again or asked, and turning network activity off and on shows no contacts error while the endpoints are not back and clears one when they are (contactsWaitForEndpointsOnResume).

There is no Refresh: the list reads itself again when the dashboard is shown, on a new ChainLock while it is shown (at most once a minute), on a five-minute fallback, and after the user's own changes (a request sent or accepted, a profile saved); a failed read is tried again after 30 s, 60 s, 2, 4 and then every 10 minutes, and its error line offers Try again. Last updated at … shows under the list only while it may be out of date. Nothing is read while the list is hidden, paused or without endpoints. The dashboard has one filled button: the selected row's Accept (or Unlock to finish, Try again) while it needs an answer, otherwise Add contact… (the empty state's own while there are no contacts), and none while the registration card holds the page's action. With requests waiting, the first is selected when the list is shown, without taking the focus, so its Accept is visible at once. Add a contact asks for a Username (buddy label, placeholder Their DashPay username), says the answering evonode sees what is looked up, and looks nothing up before three characters, the shortest username. Edit profile… waits for the profile to be read, and a failed read offers Add profile…, disabled until one succeeds. A connected contact's tooltip says to pay them from Send by typing their username or pressing @. Tests: the dashboard offers no Send, Disable, Refresh or Find people and offers Add contact… (dashboardHasNoSendDisableOrRefresh); one filled button in each registration and contacts state (onlyOneFilledButton); ChainLock reads throttled to one a minute, the failure backoff and its reset, Last updated only while stale, nothing read while hidden (contactsRefreshFollowsChainLocks); showing the tab twice within 30 s reads once (showRefreshThrottled); the first waiting request selected with a filled Accept (firstIncomingRequestSelected); nothing looked up under three characters (addContactNeedsThreeCharacters).

A contact that sends again (a DIP-15 re-send, say with new payment addresses) is one row, and only its newest request counts: requests are ranked by createdAt and then accountReference, as the mobile wallets rank them, so both ends pay the same chain. An established contact whose newest request is not the one it was established from is re-established from it without a broadcast, and a changed xpub restarts its payment cursor at the first address. A new request (or a newer one from a known sender) reads the contact's username and profile again, and otherwise every contacts refresh re-reads them once five minutes have passed, so a profile edit shows within minutes. Add contact reads the chosen result's identity once a session (a send reads it too) and marks one with no key a contact request can be encrypted to as Can't receive contact requests; a request we sent, on chain, recorded by this wallet or being confirmed, reads as Request sent; the Note column shows only when a row has a note. Tests: a re-send replaces the earlier request, is re-established from its xpub with the cursor restarted, and listing the same requests again changes nothing (contactResendUsesNewestRequest); an identity that cannot receive is marked, cannot be sent to and is read once (addContactMarksIdentitiesThatCannotReceive).

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

Author: PastaPastaPasta

src/Makefile.qt.include

@@ -124,13 +124,18 @@ QT_MOC_CPP = \
 
 if ENABLE_PLATFORM_GUI
 QT_MOC_CPP += \
+  qt/platform/moc_contactflow.cpp \
+  qt/platform/moc_contactsmodel.cpp \
+  qt/platform/moc_contactspage.cpp \
   qt/platform/moc_createusernamewizard.cpp \
   qt/platform/moc_dashpayoptionswidget.cpp \
   qt/platform/moc_identityflow.cpp \
   qt/platform/moc_platformoptindialog.cpp \
   qt/platform/moc_platformpage.cpp \
   qt/platform/moc_platformservice.cpp \
-  qt/platform/moc_platformui.cpp
+  qt/platform/moc_platformui.cpp \
+  qt/platform/moc_profiledialog.cpp \
+  qt/platform/moc_usernamesearchdialog.cpp
 endif
 
 BITCOIN_MM = \
@@ -237,13 +242,18 @@ BITCOIN_QT_H = \
 
 if ENABLE_PLATFORM_GUI
 BITCOIN_QT_H += \
+  qt/platform/contactflow.h \
+  qt/platform/contactsmodel.h \
+  qt/platform/contactspage.h \
   qt/platform/createusernamewizard.h \
   qt/platform/dashpayoptionswidget.h \
   qt/platform/identityflow.h \
   qt/platform/platformoptindialog.h \
   qt/platform/platformpage.h \
   qt/platform/platformservice.h \
-  qt/platform/platformui.h
+  qt/platform/platformui.h \
+  qt/platform/profiledialog.h \
+  qt/platform/usernamesearchdialog.h
 endif
 
 QT_RES_ICONS = \
@@ -380,13 +390,18 @@ BITCOIN_QT_WALLET_CPP = \
   qt/walletview.cpp
 
 BITCOIN_QT_PLATFORM_CPP = \
+  qt/platform/contactflow.cpp \
+  qt/platform/contactsmodel.cpp \
+  qt/platform/contactspage.cpp \
   qt/platform/createusernamewizard.cpp \
   qt/platform/dashpayoptionswidget.cpp \
   qt/platform/identityflow.cpp \
   qt/platform/platformoptindialog.cpp \
   qt/platform/platformpage.cpp \
   qt/platform/platformservice.cpp \
-  qt/platform/platformui.cpp
+  qt/platform/platformui.cpp \
+  qt/platform/profiledialog.cpp \
+  qt/platform/usernamesearchdialog.cpp
 
 BITCOIN_QT_CPP = $(BITCOIN_QT_BASE_CPP)
 if TARGET_WINDOWS

src/qt/platform/contactflow.cpp

@@ -0,0 +1,141 @@
+// Copyright (c) 2026 The Dash Core developers
+// Distributed under the MIT software license, see the accompanying
+// file COPYING or http://www.opensource.org/licenses/mit-license.php.
+
+#ifndef BITCOIN_QT_PLATFORM_CONTACTFLOW_H
+#define BITCOIN_QT_PLATFORM_CONTACTFLOW_H
+
+#include <platform/types.h>
+#include <wallet/platformtypes.h>
+
+#include <QObject>
+#include <QString>
+
+#include <cstdint>
+#include <optional>
+#include <string>
+#include <vector>
+
+class PlatformService;
+
+/**
+ * Sends a DashPay contact request and imports the resulting friendship
+ * keychains so payments to/from the contact are tracked by the wallet.
+ *
+ * A contact request carries our DIP-15 receiving xpub in its 69-byte
+ * compact form, encrypted by the SDK with the ECDH secret the wallet
+ * derives between our ENCRYPTION key and the recipient's DECRYPTION (or
+ * ENCRYPTION) key, plus the DIP-15 accountReference masked with the MAC the
+ * wallet computes over that xpub. Our receiving chain is imported before
+ * the request is sent, so the recipient can pay as soon as they accept.
+ * Accepting an incoming request decrypts and stores their xpub for outbound
+ * payments, then sends our request back unless ours is already on chain.
+ * A request that answers ours establishes the contact without any
+ * broadcast, as the mobile wallets do.
+ *
+ * The key work of an operation (decryption, keychain derivation, MAC, ECDH,
+ * signature) runs under one wallet unlock, released before every network
+ * wait; the identity keys used are those the proved identity carries at
+ * the ids the identity record names.
+ *
+ * Per-contact state is persisted under the "contact/…" platform data
+ * records; the request documents themselves live on Platform.
+ */
+class ContactFlow : public QObject
+{
+    Q_OBJECT
+
+public:
+    explicit ContactFlow(PlatformService& service, QObject* parent = nullptr);
+
+    //! The one request per sender DashPay acts on, in first-seen order: the
+    //! latest, then the highest accountReference (whose top four bits are
+    //! the DIP-15 version), as the mobile wallets choose it. A sender sends
+    //! again to replace its payment addresses, and Platform keeps every
+    //! request.
+    static std::vector<platform::ContactRequest> NewestPerSender(const std::vector<platform::ContactRequest>& requests);
+
+    //! Send a contact request to a proved identity. The recipient key is
+    //! chosen by the SDK's mint-side policy. Emits requestSent/requestFailed.
+    void sendRequest(const platform::Identity& recipient);
+
+    //! Accept an incoming request: verify the sender identity, decrypt the
+    //! sender's xpub, import the keychains and send a request back unless
+    //! ours is already on chain.
+    void accept(const platform::ContactRequest& incoming);
+
+    //! Establish a contact whose request answers ours, without asking for
+    //! the passphrase (the wallet must be unlocked already) and without any
+    //! broadcast. Emits acceptedCompleted.
+    void completeAccepted(const platform::ContactRequest& incoming);
+
+    //! Decrypt the compact xpub of an incoming request with our key at its
+    //! recipient_key_index, which must be our ENCRYPTION or DECRYPTION key,
+    //! after checking both key purposes against the DIP-15 receive policy.
+    //! sender is the proved sender identity.
+    std::optional<wallet::CompactXpub> decryptXpub(const platform::ContactRequest& incoming,
+                                                   const platform::Identity& sender, QString& error);
+
+    //! Import the contact's sending chain as our receiving keychain and
+    //! validate their xpub. birth_time (unix seconds) bounds later rescans;
+    //! it is the time of OUR own request, never the counterparty's document
+    //! time, which the sender controls.
+    bool importKeychains(const platform::Identifier& their_identity, const wallet::CompactXpub& their_xpub,
+                         int64_t birth_time, QString& error);
+
+Q_SIGNALS:
+    //! Platform accepted the request for broadcast; it is being confirmed.
+    void requestPending(const QString& to_identity_hex);
+    //! The request is confirmed on Platform (or the contact established
+    //! without one).
+    void requestSent(const QString& to_identity_hex);
+    //! Platform did not confirm the request it accepted within the
+    //! confirmation window; the contacts refresh shows it once it does.
+    void requestUnconfirmed(const QString& to_identity_hex);
+    //! The request was not sent, or Platform refused it.
+    void requestFailed(const QString& to_identity_hex, const QString& error, const QString& details);
+    //! error is empty once the contact is established; otherwise
+    //! `retryable` says whether a later attempt can succeed on its own (an
+    //! unanswered read, a wallet locked in the meantime) or the request
+    //! itself was refused.
+    void acceptedCompleted(const QString& identity_hex, const QString& error, bool retryable);
+
+private:
+    //! Send our request; when accepting, their request is established under
+    //! the same unlock.
+    void sendRequest(const platform::Identity& recipient, std::optional<platform::ContactRequest> accepting);
+    //! When our own request to an identity was created, if we sent one.
+    std::optional<int64_t> ourRequestTime(const platform::Identifier& to_identity) const;
+    //! Decrypt an incoming request, import the keychains and store their xpub.
+    bool establish(const platform::ContactRequest& incoming, const platform::Identity& sender, int64_t birth_time,
+                   QString& error);
+    //! establish() for a request that answers ours, sent at our_request_time.
+    bool establishAnswered(const platform::ContactRequest& incoming, const platform::Identity& sender,
+                           int64_t our_request_time, QString& error);
+    bool prepareReceivingKeychain(const platform::Identifier& their_identity, wallet::FriendshipXpub& xpub,
+                                  int64_t birth_time, QString& error);
+    //! The account references of our requests to a contact on chain, page
+    //! by page: the next request's rotation version is one above the latest
+    //! of them (unmasked with our MAC), or 0 for a first request.
+    void collectOurRequests(const platform::Identity& recipient, std::optional<platform::ContactRequest> accepting,
+                            const platform::Identifier& start_after, std::vector<uint32_t> account_references,
+                            int pages_left);
+    //! Reads our proved identity and DashPay contract nonce, then signs.
+    void buildAndBroadcast(const platform::Identity& recipient, std::optional<platform::ContactRequest> accepting,
+                           std::vector<uint32_t> account_references);
+    void signAndBroadcast(const platform::Identity& sender, const platform::Identity& recipient,
+                          const std::optional<platform::ContactRequest>& accepting,
+                          const std::vector<uint32_t>& account_references, uint64_t nonce);
+    //! Confirms the request just broadcast by its account reference among
+    //! our requests created since since_ms, page by page, repeating the
+    //! query with a growing interval until deadline (unix seconds).
+    void confirmRequest(const platform::Identifier& to_identity, uint32_t account_reference, uint64_t since_ms,
+                        const platform::Identifier& start_after, int pages_left, int64_t deadline, int interval_ms);
+    void fail(const platform::Identifier& to_identity, const QString& error, const QString& details = {});
+    //! fail() with the plain-language text for a failed client call.
+    void fail(const platform::Identifier& to_identity, const platform::Status& status, const QString& operation);
+
+    PlatformService& m_service;
+};
+
+#endif // BITCOIN_QT_PLATFORM_CONTACTFLOW_H