RFC: 🫛 Solid Pods for User-Owned Data Cross-Instance Wallet

[flyblackbox]

RFC: 🫛 Solid Pods for User-Owned Data Cross-Instance Wallet

Summary

This RFC proposes exploring Solid Pods as a future architecture for user-owned identity and portable data across Quote.Vote instances (forks). The goal is to enable a user to participate in many Quote.Vote communities (workplace, city, school, nonprofit) while keeping a unified, user-controlled “data wallet” that can aggregate their activity and preferences across instances.

This is a request for comment to validate the concept, identify risks, and decide whether Solid should become part of our long-term v2+ roadmap.

---

Background / Motivation

Quote.Vote is designed to be forkable and community-governed. Over time, a single person may belong to many independently-run Quote.Vote instances.

Today, that creates fragmentation:

• Identity and reputation reset per instance
• Preferences and personal history stay trapped per instance
• Users depend on instance administrators for exports and deletion requests
• Forks remain isolated by default, which reduces long-term continuity for users

Solid introduces a model where storage is decoupled from applications: the user controls a Pod and grants apps permission to read/write specific resources. This aligns with Quote.Vote’s civic-infrastructure posture and emphasis on user agency.

---

Proposal

Explore adopting Solid Pods as a way to support:

1) User-owned identity anchor

• A portable identity profile that can be used across Quote.Vote instances
• Instances still retain local roles/permissions and local governance

2) User-controlled cross-instance “data wallet”

• A Pod can hold user-owned data (exports, persistent preferences, cross-instance data management and reports)
• Users can revoke access to their data from any instance at any time
• The user can view and export their own aggregate activity across instances

3) Clear boundary between instance governance and user custody

• Each instance remains responsible for its own posts/votes/moderation enforcement
• The Pod holds user-owned data and portable metadata (where appropriate)

---

Concept: “Unified Wallet Across Forks”

A user might be active in 12 Quote.Vote instances:

• quote.vote (public sandbox)
• city.example/qv
• company.example/qv
• school.example/qv
• etc.

With Solid:

• Each instance remains its own community and data context
• The user’s Pod becomes a unifying wallet for identity + user-owned exports + preferences + cross-instance index
• Instances can remain isolated while the user retains continuity and portability

---

Data Ownership Matrix

Likely belongs to the Instance (local governance truth)

• Posts and comments submitted to that instance
• Votes and aggregated ranking results for that instance
• Moderation actions, reports, bans, enforcement metadata
• Local reputation and anti-abuse signals
• Local audit logs required for governance

Likely belongs to the User Pod (user-owned truth)

• Identity profile primitives (handle, avatar, bio, keys) (portable)
• Preferences (follow lists, muted tags, notification settings) (portable)
• User-owned exports (my votes, my posts, my citations, my logs)
• Cross-instance directory/index (which instances I belong to + pointers)
• Portable proofs (optional): “I participated in X” / “I earned Y badge” (careful: gameable)

---

Benefits

• User agency: portability, revocable access, easier exports
• Fork-friendly continuity: identity and preferences can travel across instances
• Privacy posture: data minimization via user-controlled storage for certain artifacts
• Ecosystem alignment: fits long-term goals around open standards and civic trust
• Future interoperability: potential alignment with other Solid-based systems and partners

---

Challenges / Tradeoffs

• Conceptual overhead: Solid introduces new models (auth grants, resource URLs, linked data shapes)
• Contributor learning curve: volunteer devs need docs, patterns, reference implementations
• Performance & reliability: reading/writing Pods can add latency; requires caching/sync strategy
• Operational hosting: where Pods live (self-hosted vs community-hosted vs institution-hosted)
• Security: permissions, token handling, and safe-by-default access patterns
• Legal & policy: cross-instance portability and user custody interacts with retention, takedowns, subpoenas, and compliance obligations
• Scope creep risk: full Pod-first architecture could become a major refactor beyond v2

---

Questions for the Community

1. Should Quote.Vote adopt Solid?
   • Does Solid align with our values and likely adoption path?
2. What belongs in the Pod vs the Instance?
3. What is the right hosting posture?
   • Self-hosted Pods, community-hosted, institution-hosted — what’s realistic?
4. What are the biggest technical risks?
   • Auth complexity, caching strategy, schema modeling, contributor onboarding
5. What are the biggest product risks?
   • Confusing UX, onboarding friction, perceived “complexity tax”
6. What legal/policy concerns should we surface early?
   • Subpoenas, retention, GDPR/CCPA-style rights, moderation liabilities
7. What’s a minimal proof-of-concept that would validate feasibility?
   • Example POC: connect user avatar + export to Pod; show cross-instance index

---

Success Criteria for an Initial POC

• User can connect a Pod and store a small portable profile object
• User can export or delete personal activity to or from their Pod (readable, structured)
• Instances remain fully functional without requiring Pods for basic usage
• Clear developer docs exist for running the POC locally

---

References

• Solid overview: https://solidproject.org/
• Inrupt: https://inrupt.com/
• Community Solid Server: https://github.com/CommunitySolidServer/CommunitySolidServer
• Quote.Vote roadmap board: Quote.Vote v2 Roadmap

---

Labels

rfc architecture solid pods data-ownership privacy discussion