Wallet Implementation Guide — Notifications, Sound Hints, and Spam Controls

This guide covers wallet behavior for ÐMP DogeTag Offers, Ðignal, and Ðocial. It is implementation guidance, not a replacement for the protocol specs.

Core Requirements

• Wallets MUST clearly distinguish signals from settled state. A DogeTag is not escrow, a Ðignal message is not acceptance, and ÐMS metadata is not ownership.
• Wallets MUST let users disable sound hints globally and per sender where possible.
• Wallets SHOULD default to quiet notifications until the user opts into sounds.
• Wallets SHOULD expose the attention amount sent with each DogeTag and allow local minimum thresholds.
• Wallets MUST treat encrypted content as untrusted data until decrypted and parsed safely.

ÐMP DogeTag Offers

When a transaction includes a Ð:𝕏 OP_RETURN payload and a recipient output controlled by the wallet:

1. Decode the 40-byte payload.
2. Verify magic, version, kind, asset_type, price_koinu, expiry, and attention amount.
3. Match asset_hash16 against local inventory or trusted indexer candidates.
4. Display ambiguous asset matches as ambiguous or hide them from primary UI.
5. If flag bit 1 is set, play a sound only when the user’s local policy allows it.

Wallets SHOULD group repeated DogeTags by sender, asset, and block window. A sender who repeatedly sends the minimum attention amount SHOULD be collapsed into a single notification summary.

Ðignal

When a transaction includes a Ð:DIG OP_RETURN payload:

1. Detect whether the signal is the 48-byte binary form or the short text form.
2. For binary signals, match recipient_hash16 against locally controlled chat public keys or room keys.
3. If content is expected, ask for user consent or apply a local allowlist before fetching encrypted inscriptions.
4. Verify the encrypted content inscription uses "p": "Ð:DIG".
5. Attempt decryption only in a safe, non-rendering context.
6. Render decrypted text as text. Do not execute scripts, HTML, SVG, or active document formats.
7. For public short text signals, label the content as public and permanent.

Ðignal notification sounds SHOULD be separate from DogeTag sounds. Wallets MAY make trusted contacts louder than unknown senders, but they MUST preserve user control.

Ðocial

When a transaction includes a Ð:SOC OP_RETURN payload:

1. Prefer 30-byte binary v1.1 (kind, reaction, target_hash16).
2. For kind = engage, resolve the target post; tip_koinu = DOGE to pay_to in the same tx (default paid threshold 100,000 koinu). Free engage if no tip.
3. Product Like = engage + reaction=like + tip ≥ minimum — show amount before sign.
4. For follow / unfollow, update local graph after confirmation (public forever).
5. For post/reply announces with content expected, fetch "p":"Ð:SOC" after policy allowlist.
6. Do not emit legacy Ð:P for new social actions; historical Ð:P is free-react only if indexed.

Ðocial notification sounds SHOULD be separate from Ðignal and DogeTag sounds. Throttle engage/follow spam per sender.

Spam Controls

Wallets SHOULD provide:

• Minimum DogeTag attention amount.
• Minimum Ðocial like amount (display threshold).
• Per-sender mute.
• Per-asset mute.
• Global quiet mode for OP_RETURN signals.
• “Known contacts only” mode for Ðignal sounds.
• A review queue for encrypted content from unknown senders.
• Optional hide of below-minimum or invalid Ðocial likes.

Wallets MUST NOT silently discard the underlying transaction history. Hiding spam in UI is local policy; the chain record remains queryable.

Integration Display

Recommended display labels:

When multiple layers are present, wallets SHOULD show the stack explicitly: for example, “DogeTag offer signal with encrypted Ðignal context.”