Integration Proposal: Lighthouse + TACo #29
Description
Kavach Repo Issue: Edit
Hey Lighthouse team,
We've previously chatted a few times about the Kavach encryption SDK and how the current design involves encryption/access control reliant on 5 servers that the Lighthouse team controls. As you know, we (TACo) believe there's a very viable integration path to making Kavach fully decentralized – removing the burden of SPOF risk from the Lighthouse team and Lighthouse users, and strengthening the product offering. This is
The Current Situation
From what we can observe in public repos, Kavach's setup has these issues:
- Centralization risk: All 5 nodes under the unilateral control of a single team - if Lighthouse as a commercial entity disappears, so does the access control function, thereby rendering encrypted data inaccessible.
- Trust concentration: Although keys are sharded, this doesn't reduce the risks of errant or malicious behavior by the single entity performing validation.
- Operational burden: Lighthouse is maintaining critical infrastructure that could fail or run into regulatory issue.
- Single point of failure: If nodes go down or Lighthouse is forced to shut down then, there's almost no redundancy.
How TACo Could Help
TACo is a permissionless threshold encryption network. Instead of your 5 nodes, you'd use a decentralized network of independent node operators. Here's what changes:
- True decentralization: ~100 independent operators vs. one entity managing 5 servers.
- No single point of failure: Network continues even if operators leave (via handover protocol).
- Trustless execution: Conditions evaluated collectively by nodes no one entity controls.
- Regulatory resilience: No single entity to shut down or subpoena.
- Already running and revenue-generating: TACo has been live on mainnet with active integrations since January 2024.
Realistic Integration Path
Let's be practical about how this could work:
Phase 1: Run Both Systems in Parallel
- Existing users keep using Kavach as-is.
- New users can opt into TACo encryption.
- Lighthouse learns how the system works and requests extensions/tweaks.
Phase 2: Migration Support
- Build migration tools for users who want to switch.
- Keep backwards compatibility for old data.
- Gradual transition as benefits to users becomes increasingly obvious.
Phase 3: Full Transition
- Sunset the centralized servers.
- Save on infrastructure costs.
- Lighthouse focuses on storage, not key management.
The Hard Parts
We need to be honest about the challenges:
-
Legacy data: Existing encrypted files need to keep working. Options:
- Dual-system: Keep your 5 nodes running indefinitely for old data (highest cost, easiest).
- Re-encryption: Users download and re-upload with TACo (changes CIDs, breaks links).
- Gradual sunset: Set a deadline, give users plenty of time to migrate voluntarily.
-
Condition mapping: Two approaches:
- Compatibility layer: Keep Lighthouse SDK unchanged, translate conditions to TACo format behind the scenes.
- Clean break (v2): New SDK version with TACo's condition language, clearer but requires user code changes.
Your conditions (ERC20/721, custom contracts) map well to TACo, but the syntax differs.
- Developer/user education: TACo and Lighthouse build content and guidance for developers and end-users to maximize the benefits of using the technologies in combination.
Why This Makes Sense
For Lighthouse:
- Removes burden of running critical, high-risk encryption infrastructure.
- Enables Lighthouse to offer a genuinely decentralized and trust-minimized infrastructure package.
- Reduces liability and operational costs.
- Gain edge on storage-layer competitors (including through unique features).
For TACo:
- Major integration into the IPFS ecosystem.
- More real-world usage to improve the protocol.
- Network effects, joint marketing, and product validation.
For Developers & End-users:
- Moving beyond "just trust us" supports new use cases that would otherwise be too risky.,
- End-users get true control and sovereignty over their data
- More optionality for access management – condition logic, etc.
Let's Talk
We'd like to understand:
- How many users actively use encryption?
- Are there other pain points you're facing that this could help with?
- Have we missed any long-term blockers?
TACo docs: https://docs.taco.build/
Note: We understand that changes to core infrastructure require careful consideration. We're happy to adjust this proposal based on your needs and constraints. This issue is meant to start a collaborative discussion, not prescribe a rigid path forward!