---
# System prepended metadata

title: ~~Server Side - MVP Notes~~ *OLD*

---

# ~~Server Side - MVP Notes~~ *OLD*

**deprecated**


![](https://i.imgur.com/C2k06qQ.png)


## External Services exposed to the Clients
* Esplora
  + Send completed Bitcoin Tx
* SpotBit
  + BTC → USD
* API
  + Registration of Bitcoin addresses for monitoring
* Messaging
  + E2EE message FIFO
* Encrypted Recovery Store
  + Only for L1 recovery

## Internal Services (No direct access)
* bitcoind
  + Monito client addresses (watch-only)
* Tx State Notifier
  + Bitcoin Tx changes state
  + New message in queue
* Registration database
* Message FIFO
  + Server only forwards
  + Client must retain in local store
  + Client side encrypt/decrypt
  + Server cannot get plain text

## TOR versus HTTPS
* Sprint 1 over HTTPS
* Sprint 2 move to TOR
  + Client, OK
  + Server, Not sure how easy this is

## Contact Import QR Code
* Bitcoin Address (for receiving funds)
* Public key for E2EE
* Metadata for general display (name/phone/?)
* Could say some byte words over phone call

## Bitmark Public Key
* Built into APP
* Pinned in DNS
* Certificate authority (e.g., Digicert)
* {all methods?}

## Client Registration Database
* Unique ID (hex string)
  + For address registration signing
  + Used as push notification ID
* Public Key for E2EE messaging
* {these are different}
* Addresses to Watch

## Messaging (**could be via lnd in the future**)
* Encrypt message with client private key and recipient public key (maybe offer other keys via DID)
* consider "linking" messages so can determin if "lost" messages
* Signed messages 25519 key compatible with .onion so can verfy
* Send to server tagged with recipent public key
* Server queues messages in FIFO
* Sever sends push notification
  + Push notification does not indicate type of message for privacy
  + Server may rate limit so Client should fetch all queued messages
  + Server cannot decrypt messages
* Client retrieves message only once
  + Server deletes read messages after confirmed read & sored in client
* Client decrypt and store messages in its local store
* Client local store is encrypted to backup storage
* If L1 then second backup to Encrypted Recovery Store
* {what about messages from unknown public key?}

## Bitmark Recovery Coordination (L1)
* Bitmark recieves notification of recovery request
  + Either using registered email/phone/? using suitable automation
  + Or, manual process to verify recovery
  + (this would be a paid registration so will be a way to verify request)
* Bitmark sends requests to particpants hoding backup data
  + Need to establish temporary public key for recovering client
* Backup clients message temporary public key with shard data
* Recovering client does automatic recovery
  + SEED is recovered when enough shards are returned
  + Public key for API is recovered
  + Register to API
  + Request latest Encrypted Recovery Store image
  + Decrypt, repopulate activity and contact data
  + Reestablish wallet addresses to be monitored
  + Rescan to compute current balance
* NOTES
  + L0 
    - Android → iOS can only be done manually
    - if phone lost need to restore on old palform first
    - use platform keychain **not** plain file (security) 
  + L! self sovereign
  + one shard in platform store
  + one shard with Bitmark (recover as above)
  + one shard offline
  + L2 need more shards e.g., 4 of 9
  + L2 also 2 of (2 of 3)
  + L1 inital 2 of 3 graduate to 3 of 5 (L1.5)
    1. Bitmark
    2. Platform
    3. Offline
    4. Friend 1
    5. Friend 2
  + Shards contain metadata
    - date of key creation
    - location of other shards (DID?)
    - multisig mappings
* Level migration
  + how to handle payments to old addresses
  + no need to use DID to ensure new payments
  + MVP should keep old keys for 2 week minimum (mempool expiry time)


Questions:
1. Where are the keys?
  * shard 1: user's device + cloud
  * shard 2: contact's device + cloud
  * shard 3: Bitmark shard server
  * User xprv on user's device (internal secure only)
  * Container xprv container stoage
2. How does recovery vs. compromised work?
  * Contact shard needd contact to open APP and accept
  * Bitmark shard uses emailed code
  * 
4. What are the endpoints?
5. What are the communication protocol between endpoints?