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

**deprecated**


## 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?