Reputation import from LN2Pbot to Mostro

[Catrya]

Proposal: Reputation Import from LN2Pbot to Mostro

Summary

A mechanism to transfer a user's reputation from LN2Pbot (Telegram) to Mostro, without administrator intervention, preserving user privacy, and without exposing private keys in Telegram.

Problem

LN2Pbot users have already built a reputation through many trades. When migrating to Mostro, they lose that reputation and must start from scratch. If Mostro node operators wanted to import their users' reputation from LN2Pbot, doing it manually would not be viable given the number of users. A secure, private, and automated mechanism is needed.

Constraints

• The user's master key in Mostro must never touch Telegram. The user does not enter their seed or Mostro private key in the bot.
• No administrator intervention. There are thousands of users; the process must be fully automated.
• A Telegram user cannot transfer their reputation to another person. Reputation selling or transfer must be prevented.
• Privacy. The user's Telegram ID is not exposed publicly or to Mostro.
• Optional per instance. Each Mostro operator decides whether to enable reputation import. Not all Mostros are required to accept it.

Components Involved

Component	Role
Mostro App (mobile)	Generates the verification key, initiates and confirms the import
Mostro daemon	Validates the reputation event, applies the reputation, stores the binding
LN2Pbot	Generates the signed reputation event with the user's reputation data

Design

Verification Key (vkey)

The Mostro app derives an ephemeral key exclusively for this process, using BIP-32 with a dedicated derivation path:

Trade keys:        m/44'/1237'/38383'/0/<index>   (current usage)
Verification key:  m/44'/1237'/38383'/2/0         (new, reserved)

This key:

• Is deterministic and recoverable from the mnemonic
• Never collides with trade keys
• Does not expose the master key
• Remains the same if the user needs to re-import (reputation update)

User Identifier Hash

To prevent a user from transferring their reputation to another person, the bot includes in the reputation event a hash of the user's internal identifier in its database:

SHA256(user._id)

• user._id: MongoDB ObjectId automatically assigned to each user (24 hexadecimal characters, e.g. 507f1f77bcf86cd799439011). Contains random components that make it unguessable.

Properties:

• Irreversible: the ObjectId contains random components (2^96 possible combinations), making brute force computationally infeasible without needing a secret key
• Deterministic: the same _id always produces the same hash, enabling duplicate detection
• Does not reveal identity: the hash does not expose the tg_id or any Telegram data about the user

Binding Rule

Mostro stores the user_hash directly in the users table, along with a temporary vkey_pub field for the import process:

-- New fields in the users table
ALTER TABLE users ADD COLUMN vkey_pub char(64);              -- temporary, during the process
ALTER TABLE users ADD COLUMN user_hash char(64);    -- permanent, SHA256 of the LN2Pbot user's _id

Rules:

• If the hash does not exist in any users record → store it for the user and import the reputation
• If the hash already exists and corresponds to the same master key (same pubkey) → allow update
• If the hash already exists and corresponds to a different pubkey → reject

This means that if an LN2Pbot user exports their reputation to another person's master key (whether by sale, deception, or transfer between scammers), they permanently burn their own ability to import to their real Mostro account. This transfer is not possible without the active cooperation of the Telegram account owner.

Complete Flow

  Mostro App                       Mostro daemon                     LN2Pbot (Telegram)
  ──────────                       ─────────────                     ──────────────────

  1. User opens
     "Import reputation"

  2. App derives vkey at path
     m/44'/1237'/38383'/2/0

  3. App sends to Mostro:
     Action: ImportReputation
     { vkey_pub }
                        ──────→   4. Verifies that vkey_pub
                                     is not already assigned
                                     to another user in DB
                                     → If exists: reject
                                     → If not: stores vkey_pub
                                       in the user's record
                                       in users table

                                  5. Responds to the app
                        ←──────      with confirmation

  6. App shows the user:
     "Send this in LN2Pbot:"
     /exportrep <vkey_pub>

                    ──── user goes to Telegram ────→

                                                        7. User sends:
                                                           /exportrep <vkey_pub>

                                                        8. Bot looks up the user
                                                           and their reputation in DB

                                                        9. Bot computes:
                                                           hash = SHA256(user._id)

                                                        10. Bot publishes Nostr event
                                                            kind 38388 (see structure
                                                            below)

                                                        11. Bot confirms to user:
                                                            "Done, go back to the app"

                    ←── user returns to the app ───

  12. User presses
      "Verify import"

  13. App sends to Mostro:
      Action: ConfirmImportRep
      { vkey_pub }
                        ──────→   14. Searches relays for event
                                      kind 38388 with tag
                                      #d = vkey_pub

                                  15. Verifies:
                                      a. Event signature is from
                                         the known LN2Pbot
                                         pubkey
                                      b. The event's vkey_pub
                                         matches the one stored
                                         for THIS user (only the
                                         owner can confirm)
                                      c. Event has not expired

                                  16. Extracts user_hash

                                  17. Queries DB:
                                      Is user_hash assigned to
                                      another master key?
                                      → YES: reject (that
                                        LN2Pbot account was
                                        already imported by
                                        someone else)
                                      → NO: continue

                                  18. Updates users table:
                                      - user_hash
                                      - total_reviews
                                      - total_rating
                                      - Clears vkey_pub
                                      (see "Imported Data"
                                      section)

                                  19. Responds to the app:
                        ←──────      "Reputation imported"

  20. App shows confirmation
      to the user

Nostr Event Structure (kind 38388)

{
  "kind": 38388,
  "pubkey": "<bot_nostr_pubkey>",
  "created_at": 1712500000,
  "tags": [
    ["d", "<vkey_pub>"],
    ["user_hash", "<SHA256(user._id)>"],
    ["total_reviews", "150"],
    ["total_rating", "4.8"],
    ["trades_completed", "200"],
    ["days", "730"],
    ["y", "lnp2pbot"],
    ["z", "reputation-attestation"],
    ["expiration", "<unix_timestamp_+24h>"]
  ],
  "content": "",
  "sig": "<bot_signature>"
}

Notes:

• Kind 38388: addressable event (replaceable by the d tag)
• expiration tag (NIP-40): relays delete the event after 24 hours
• y tag: identifies the source platform
• z tag: identifies the event type
• Content is empty; all information goes in tags

Imported Data

Mostro imports the following fields from the reputation event:

LN2Pbot Field	Mostro Field (users)	Notes
total_reviews	total_reviews	Number of reviews received
total_rating	total_rating	Weighted average (both use iterative mean algorithm)
trades_completed	—	Present in the reputation event but Mostro does not have this field; ignored
days	created_at	Calculated as created_at = now() - (days * 86400). Always replaces the existing created_at, reflecting the user's real seniority as a trader

Reputation is imported 1:1 without any reduction factor. Both platforms use the same rating calculation algorithm (iterative mean / Welford's method):

new_rating = old_rating + (last_rating - old_rating) / total_reviews

This makes the values directly compatible.

Security

Privacy Guarantees

• The Mostro operator cannot know which Telegram user is behind a master key. Mostro only stores the user_hash (SHA256 of the MongoDB _id), which is irreversible. It never receives the tg_id or the original _id at any point in the process.
• Telegram/LN2Pbot cannot know the user's master key in Mostro. The bot only receives the vkey_pub (ephemeral verification key), which has no derivable relationship to the master key without access to the user's mnemonic.

Threats and Mitigations

Threat	Mitigation
Reputation sale or transfer: an LN2Pbot user exports their reputation to another Mostro user's master key (by sale, deception, or collusion)	The LN2Pbot _id hash becomes permanently bound to that Mostro master key. The original user permanently loses their ability to import their own reputation. Not possible without the active cooperation of the Telegram account owner.
Identity impersonation: someone attempts to claim another user's reputation	Only the Telegram account owner can execute /exportrep in the bot.
Identifier brute force: attempting to reverse the hash to discover identities	MongoDB's ObjectId contains random components (2^96 combinations), making brute force computationally infeasible with simple SHA256.
Bot key compromise: someone could fabricate fake reputation events	Mostro can revoke trust in a specific pubkey. The Mostro operator updates the configuration.
Reputation event replay: reusing an expired reputation event	expiration tag NIP-40 (24h). Mostro verifies that the event has not expired.
In-progress import theft: an attacker sees a kind 38388 event on relays, copies the vkey_pub and sends ImportReputation to Mostro to try to steal that reputation	Not possible. The legitimate user registers the vkey_pub in Mostro (step 4) before pasting it in Telegram (step 7). The vkey_pub only becomes public when the bot publishes the event (step 10). By that time it is already assigned in Mostro. Additionally, ConfirmImportReputation only allows confirmation by the user who has the vkey_pub stored in their record.
Master key ↔ Telegram linking: an external observer attempts to correlate identities	The event only contains vkey_pub (ephemeral) and SHA256(user._id). The master key does not appear in the event. Mostro knows the vkey→master mapping internally but does not publish it.

Fraud Attempt Flow (reputation sale or transfer)

A fraud scenario would be a scammer trying to obtain another user's legitimate reputation to appear trustworthy in Mostro. This is not possible thanks to the system design:

1. The scammer generates vkey_pub in their Mostro app
2. The scammer sends vkey_pub to an LN2Pbot user with good reputation (by payment, deception, etc.)
3. The LN2Pbot user executes /exportrep <vkey_pub> in their Telegram
4. Bot publishes reputation event with SHA256(legitimate_user._id) + vkey_pub
5. The scammer imports in Mostro → the hash becomes bound to the scammer's master key
6. Result: the legitimate LN2Pbot user permanently loses their ability to import their own reputation to Mostro. Their _id hash has been consumed.

Why does this disincentivize and prevent fraud?

• The legitimate user has no reason to give away their reputation — it burns it forever.
• A scammer cannot take another user's reputation without their active cooperation (only the Telegram account owner can execute /exportrep).
• There is no way to force, impersonate, or automate this process without control of the Telegram account.
• An LN2Pbot account can only export its reputation to a single Mostro master key. A scammer with multiple bot accounts cannot concentrate their best reputation across multiple Mostro accounts: each bot account only serves one Mostro account.
• If a scammer has N bot accounts, they can only create N accounts with reputation in Mostro (one per _id), with no possibility of duplicating or reusing any of them.

Required Changes by Component

LN2Pbot (Telegram bot)

• New command /exportrep <vkey_pub>
  • Validates vkey_pub format (hex, 64 characters)
  • Computes SHA256(user._id)
  • Builds and publishes kind 38388 event to configured relays
  • Responds to user with confirmation
• No additional configuration
  • Uses existing relays for reputation event publication
  • No additional secret keys required

Mostro daemon

• New action ImportReputation
  • Receives vkey_pub from the user
  • Verifies that the vkey_pub is not already assigned to another user in the users table
  • Stores vkey_pub in the user's users table record (new field)
  • Responds with confirmation
• New action ConfirmImportReputation
  • Receives vkey_pub
  • Verifies that the vkey_pub matches the one stored for this user (only the owner can confirm)
  • Searches for kind 38388 event on relays (filter: kind 38388 + author = bot pubkey + tag #d = vkey_pub)
  • Validates bot signature and that the event has not expired
  • Extracts user_hash and verifies it is not assigned to another master key in the users table
  • Updates the user's reputation fields (total_reviews, total_rating, created_at)
  • Stores user_hash in the user's users table record
  • Clears the vkey_pub field
• New fields in users table
  • vkey_pub char(64) — temporary, used during the import process and cleared upon completion
  • user_hash char(64) — permanent, SHA256 of the LN2Pbot user's _id to control binding
• New migration
  • ALTER TABLE users ADD COLUMN vkey_pub char(64);
  • ALTER TABLE users ADD COLUMN user_hash char(64);
• New configuration in settings.toml
  • reputation_import_enabled: boolean, default false. When disabled, Mostro responds with cant-do to ImportReputation and ConfirmImportReputation actions.

Mostro-core

• New Action enum variants: ImportReputation, ConfirmImportReputation
• New payload type for import data

Mostro Mobile App

• New derivation path: m/44'/1237'/38383'/2/0 for verification key
• New screen: "Import reputation from LN2Pbot"
  • Step 1: generates vkey, sends to Mostro, displays code to copy
  • Step 2: "Verify" button that sends confirmation to Mostro
  • Step 3: shows result (success or error)

Future Phase: Unbinding

If a user loses their Mostro master key and creates a new one, the hash of their _id remains bound to the previous master key. An unbinding mechanism will be needed:

Possible approach:

• The user executes /resetrep in LN2Pbot
• The bot publishes a revocation event (kind 38388 with tag ["action", "revoke"] and the same user_hash)
• Mostro processes the revocation: removes the hash → master_pubkey binding
• The user can now re-import to their new master key

Considerations:

• Must have a cooldown (e.g. 30 days) to prevent abuse
• The user loses the imported reputation in Mostro upon unbinding
• Requires detailed design in a later phase