Data Storage & Architecture Clarification Questions

[neno-is-ooo]

Context

I'm evaluating Porto for a production application and need to understand the data storage model to make informed architecture decisions. After reviewing the SDK documentation, several critical questions remain unanswered.

Storage Architecture Questions

1. User Identity & Account Mapping

• Where is the mapping between user identities and account addresses stored?
  • Is this mapping stored on Porto's servers or purely client-side?
  • How does Porto link a user's WebAuthn credential to their Ethereum address?
  • What user identifiers does Porto store (if any)?

2. Account Recovery & Cross-Device Access

• How does account recovery work across devices?
  • If a user loses their device, how do they regain access to their Porto account?
  • What data needs to be synchronized between devices for the same user?
  • Is there a "master key" or recovery mechanism managed by Porto?

3. Data Persistence & Infrastructure

• What specific data does Porto store on its infrastructure vs. client-side?
  • Account addresses and key associations (confirmed from docs)
  • User metadata/profiles?
  • Transaction history?
  • Permission grants and their usage tracking?
  • WebAuthn credential storage location?

4. Data Sovereignty & Control

• Who controls the user's account data?
  • Can users export their complete account data?
  • What format would exported data be in?
  • Is there a way to migrate a Porto account to a standard self-custodial wallet?
  • What happens to user accounts if Porto discontinues the service?

5. Privacy & Data Collection

• What user data does Porto collect and store?
  • IP addresses, browser fingerprints, usage analytics?
  • Is user activity across different applications tracked/linked?
  • Where are Porto's servers located (data residency)?
  • What's the data retention policy?

6. Compliance & Legal

• How does Porto handle regulatory compliance?
  • GDPR right to erasure - can users delete all their data?
  • KYC/AML requirements for certain transaction volumes?
  • Data sharing with law enforcement or regulatory bodies?

7. Technical Failsafes

• What happens in disaster scenarios?
  • If Porto's servers go down, can users still access their accounts?
  • Is there a backup/recovery mechanism for Porto's infrastructure?
  • Can applications continue functioning if Porto's RPC servers are unavailable?

8. Integration Architecture

• For production applications, what should we architect around?
  • Should we maintain parallel user account systems?
  • How do we handle users who want to "disconnect" from Porto later?
  • What's the recommended approach for user data that shouldn't be tied to Porto?

Why This Matters

These questions directly impact:

• Security architecture - Understanding attack vectors and trust boundaries
• User experience - Setting proper expectations about account portability
• Legal compliance - Meeting data protection requirements
• Business continuity - Planning for various failure scenarios
• Product roadmap - Understanding long-term vendor relationship implications

Current Understanding (Please Correct If Wrong)

Based on the documentation, I believe:

1. Porto maintains a centralized registry of accounts and their associated keys
2. Client-side storage is configurable but primarily for performance/caching
3. Account recovery relies on Porto's infrastructure rather than user-controlled mechanisms
4. Users cannot fully self-custody their accounts without Porto's continued operation

Requested Response

Could the Porto team provide clarity on these points? Ideally with:

• Clear documentation updates addressing these topics
• Example scenarios (account recovery, data export, service discontinuation)
• Best practices for production applications regarding data architecture

Understanding these details will help developers make informed decisions about integrating Porto into production systems.