LogoLogo
  • README
  • Contribute
    • Discuss on Github
  • Example
    • Banana-Powered Bitcoin Wallet Control Protocol
  • Apps
    • The deployment-info.json Specification
  • Wallet
    • Transaction Creation
    • Data Encryption and Decryption
    • Digital Signature Creation and Verification
    • Input Redemption
    • HTTP Wallet Communications Substrate
    • XDM Wallet Communications Substrate
    • Window Wallet Communication Substrate
    • Wallet Transaction Output Tracking (Output Baskets)
    • Submitting Received Payments to a Wallet
    • Certificate Creation and Revelation
    • Unified Abstract Wallet-to-Application Messaging Layer
    • Transaction Labels and List Actions
    • Output Basket Removal and Certificate Deletion
    • Group Permissions for App Access
    • Extensible Proof-Type Format for Specific Key Linkage Claims
    • P Protocols: Allowing future wallet protocol permission schemes
    • P Baskets: Allowing Future Wallet Basket and Digital Asset Permission Schemes
    • Unified, Vendor-Neutral, Unchanging, and Open BSV Blockchain Standard Wallet-to-Application Interface
  • Transactions
    • Everett-style Transaction Envelopes
    • Simplified Payment Verification
    • Merkle proof standardised format
    • TSC Proof Format with Heights
    • Raw Transaction Format
    • TXO Transaction Object Format
    • Transaction Extended Format (EF)
    • Merkle Path JSON format
    • Compound Merkle Path Format
    • Background Evaluation Extended Format (BEEF) Transactions
    • Simplified Payment Verification
    • Merkle Path Binary Format
    • BSV Unified Merkle Path (BUMP) Format
    • Graph Aware Sync Protocol
    • Scalable Transaction Processing in the BSV Network
    • Atomic BEEF Transactions
    • BEEF V2 Txid Only Extension
  • Scripts
    • Bitcoin Script Binary, Hex and ASM Formats
    • Bitcoin Script Assembly Language
    • Pay to Public Key Hash
    • Pay to R Puzzle Hash
    • Pay to False Return
    • Pay to True Return
    • Push TX
    • Bare Multi-Signature
    • Pay to Push Drop
  • Tokens
    • There is no BRC-20
    • Definition of UTXOs as Bitcoin Tokens
    • Token Exchange Protocol for UTXO-based Overlay Networks
    • Mandala Token Protocol
  • Overlays
    • Overlay Network Data Synchronization
    • Confederacy Host Interconnect Protocol (CHIP)
    • Overlay Network Lookup Services
    • Confederacy Lookup Availability Protocol (CLAP)
    • Universal Hash Resolution Protocol
    • Overlay Network Transaction History Tracking
    • Private Overlays with P2PKH Transactions
    • Standardized Naming Conventions for BRC-22 Topic Managers and BRC-24 Lookup Services
    • Overlay Services Synchronization Architecture
    • Diverse Facilitators and URL Protocols for SHIP and SLAP Overlay Advertisements
  • Payments
    • Direct Payment Protocol (DPP)
    • Paymail Payment Destinations
    • Simple Authenticated BSV P2PKH Payment Protocol
    • PacketPay HTTP Payment Mechanism
    • Hybrid Payment Mode for DPP
    • HTTPS Transport Mechanism for DPP
    • Paymail BEEF Transaction
    • HTTP Service Monetization Framework
  • Peer-to-Peer
    • Authrite Mutual Authentication
    • PeerServ Message Relay Interface
    • PeerServ Host Interconnect Protocol
    • Identity Certificates
    • Genealogical Identity Protocol
    • Publishing Trust Anchor Details at an Internet Domain
    • Message Signature Creation and Verification
    • Serialization Format for Portable Encrypted Messages
    • Defining a Scalable IPv6 Multicast Protocol for Blockchain Transaction Broadcast and Update Delivery
    • Proven Identity Key Exchange (PIKE)
    • Peer-to-Peer Mutual Authentication and Certificate Exchange Protocol
    • HTTP Transport for BRC-103 Mutual Authentication
  • Key Derivation
    • BIP32 Key Derivation Scheme
    • BSV Key Derivation Scheme (BKDS)
    • Security Levels, Protocol IDs, Key IDs and Counterparties
    • Admin-reserved and Prohibited Key Derivation Protocols
    • Revealing Key Linkages
    • Protecting BRC-69 Key Linkage Information in Transit
    • Mnemonic For Master Private Key
    • Linked Key Derivation Scheme
    • Bidirectionally Authenticated Derivation of Privacy Restricted Type 42 Keys
    • Limitations of BRC-69 Key Linkage Revelation
    • Verifiable Revelation of Shared Secrets Using Schnorr Protocol
  • Outpoints
    • Format for Bitcoin Outpoints
    • Spending Instructions Extension for UTXO Storage Format
  • Opinions
    • Users should never see an address
    • List of user experiences
    • Legitimate Uses for mAPI
    • Security and Scalability Benefits of UTXO-based Overlay Networks
    • Improving on MLD for BSV Multicast Services
    • Web 3.0 Standard (at a high level)
    • Thoughts on the Mandala Network
    • Outputs, Overlays, and Scripts in the Mandala Network
  • State Machines
    • Simplifying State Machine Event Chains in Bitcoin
Powered by GitBook
On this page
  • Abstract
  • Motivation
  • User experiences
  • Payment
  • P2P identity exchange
  • References

Was this helpful?

Edit on GitHub
Export as PDF
  1. Opinions

List of user experiences

Roger Taylor (roger.taylor.email@gmail.com)

Abstract

This document is a curated set of relevant and high level user experiences to aid as a reference for developers.

Motivation

When I ask for a use case what I mostly get is a higher layer of the solution, not what I consider a use case. What I am asking is who is going to use the thing you are proposing and how will they use it. I want to see the range of user experiences that it is perceived as being employed for. If you have gone away and worked on a thing you want people to use and you do not know the user experiences it needs to be usable for, how can you have a relevant picture of the requirements for things of this type?

If there are user experiences that are common to different projects that developers will be working on, then it should be possible to maintain a list of them. And it should be possible to do so in a way where developers can come to the list and see well defined user experiences and to gain a higher level understanding of what they are solving than they may not have already had. It is not intended to exhaustively add anything people can think of, but the curated set which Roger thinks are of value.

Perceived value:

  • Identify additional user experiences you want to provide.

  • Gain a higher level understanding of the variety of user experiences.

  • Provide common definitions of user experiences and any nuances worth also defining.

It is envisioned that this document will start with simple definitions and through collaboration be expanded. Are these relevant user experiences? Let's talk about it somewhere and flesh out this document.

User experiences

Payment

Implementation details are hopefully limited to those necessary to illustrate the context of a given user experience. Because we are talking about Bitcoin SV, the implication is both parties are using digital devices with wallets. Maybe Alice as the seller is using a desktop or tablet, and Bob is using his on-the-go wallet on his mobile phone. Maybe Bob and Alice are using P2P wallets, or they are using wallet as a service apps. Those things can be factored into expansions on a given user experience to give a pcut

In-person

Alice and Bob meet. Alice is selling eggs. Bob wants to buy eggs. Alice gives an invoice to Bob. Bob pays Alice. Alice gives Bob the eggs once the payment is received.

Web store

Alice has a web site where she has products listed. Bob adds some items to his cart and then checks out. The web site displays an invoice to Bob. Bob pays it. Alice sends the products digitally or physically once the payment is received.

Email

Bob knows Alice from a contact of some sort. He emails her and asks her about something. Alice sends him a link to an invoice. Bob clicks on it and pays it. Alice sends the products digitally or physically once the payment is received.

Automated / recurring

Bob has a recurring payment to Alice. Bob sets it up and authorises pre-funding of some kind and the schedule at which it should be paid. Alice gets her payment on time regardless of Bob being connected to the network or needing to authorise the payment at the exact time the payment is delivered.

P2P identity exchange

Even if we had usable integration of government identity as a tool that can be employed where necessary, it would still be extremely valuable to have non-governmental or P2P identity. These experiences are intended to illustrate the set of applications, agents or services that could be made available to users.

Public identity

Alice has a web site that everyone knows belongs to her. She can generate a public identity and put the identity packet for it on that web site. This can be used for whatever operations she allows with given constraints.

Referral

Alice knows Carol and wishes to put Bob in contact with Carol. Alice shares Carol's identity packet with Bob, giving him the ability to know that he is interacting with Carol and select details about her.

Proof of referral

Carol rejects contact from David who has obtained her identity packet but has no proof of a referral. Bob however got a signed referral from Alice, and Carol's wallet verifies this, by confirming Bob is referred by Alice, who is on Carol's whitelist.

References

None.

PreviousUsers should never see an addressNextLegitimate Uses for mAPI

Last updated 1 year ago

Was this helpful?