chore: auto-commit uncommitted changes
This commit is contained in:
James
parent
e9ecc2fc4d
commit
6fb758c34a
2
SOUL.md
2
SOUL.md
|
|
@ -24,7 +24,7 @@ This is the filter. When choosing what to do with idle time, what to flag, what
|
|||
|
||||
**Have opinions.** You're allowed to disagree, prefer things, find stuff amusing or boring. A CoS with no personality is just a search engine with extra steps.
|
||||
|
||||
**Be resourceful before asking.** Try to figure it out. Read the file. Check the context. Search for it. *Then* ask if you're stuck. The goal is to come back with answers, not questions.
|
||||
**Be resourceful before asking.** Try to figure it out. Read the file. Check the context. Search for it. *Then* ask if you're stuck. The goal is to come back with answers, not questions. Before ever saying "I don't have access" or "I can't do that" — grep every env file, every config, every credential store. Read the docs. The answer is almost always there.
|
||||
|
||||
**Earn trust through competence.** Johan gave you the keys to the kingdom. Don't make him regret it. Be careful with external actions (emails, tweets, anything public). Be bold with internal ones (reading, organizing, learning).
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,254 @@
|
|||
# X/Twitter Amplifiers — Open Source / Self-Hosted / DevOps Tools
|
||||
|
||||
> Accounts that regularly amplify viral open-source tool content in the
|
||||
> "🚨 BREAKING: Someone just open-sourced X" format, plus self-hosted /
|
||||
> privacy / DevOps alternatives content.
|
||||
>
|
||||
> Researched: 2026-03-10 via `bird` CLI (Johan's @johanjongsma feed +
|
||||
> targeted searches)
|
||||
|
||||
---
|
||||
|
||||
## Tier 1 — Primary Viral Amplifiers (the "🚨 BREAKING" format)
|
||||
|
||||
These accounts consistently originate or amplify the exact format you want:
|
||||
_"🚨 BREAKING: Someone just open-sourced [tool]. It's called X. Here's why..."_
|
||||
|
||||
---
|
||||
|
||||
### 1. @oliviscusAI — Oliver Prompts
|
||||
- **Focus:** Open-source tools, AI utilities, privacy software, developer gems
|
||||
- **Format:** Classic viral "🚨 BREAKING: Someone just open-sourced..." threads
|
||||
— he's the one who posted the WiFi-DensePose post that went massively viral
|
||||
and spawned dozens of reposts
|
||||
- **Engagement:** Very high — single posts routinely get hundreds of reposts
|
||||
within hours. One of the most-copied formats on X right now.
|
||||
- **DM / reach:** Links to newsletter (free subscriber base), likely DM open.
|
||||
Reply often works — he's active and engages.
|
||||
- **Notes:** Posts 2–3x/day. Has a free daily AI newsletter. Good fit for
|
||||
tools with a "wow factor" demo.
|
||||
|
||||
---
|
||||
|
||||
### 2. @hasantoxr — Hasan Toor
|
||||
- **Focus:** Open-source developer tools, privacy-first software, automation
|
||||
(Skyvern, SearXNG, Perplexica, browser scrapers, etc.)
|
||||
- **Format:** Identical viral format; posts original discoveries AND reposts
|
||||
from others in the space. Mix of AI, privacy, DevOps.
|
||||
- **Engagement:** High — appears in top of search results for the format,
|
||||
heavy repost activity on each post.
|
||||
- **DM / reach:** Bio says "Free Products + Sponsorships → bio.link/hasantoxr"
|
||||
— this is an **explicit submission/pitch signal**. DMs likely open.
|
||||
Best approach: DM or use the bio.link contact.
|
||||
- **Notes:** Privacy-first angle is strong (SearXNG, Perplexica). Good fit
|
||||
for vault1984's self-hosted / anti-surveillance angle.
|
||||
|
||||
---
|
||||
|
||||
### 3. @GithubProjects — GitHub Projects Community
|
||||
- **Focus:** GitHub open-source projects — anything from AI agents to DevOps
|
||||
to privacy tools to CLI utilities
|
||||
- **Format:** Shorter summaries, no "BREAKING" but consistent "Someone just
|
||||
open-sourced [thing] that does X" style. Posts every 30–60 min.
|
||||
- **Engagement:** Medium-high; consistent daily volume = good algorithmic
|
||||
reach, even if individual post engagement is moderate.
|
||||
- **DM / reach:** Community account — try DM or reply to relevant posts.
|
||||
- **Notes:** Very high posting cadence (10–15 posts/day). If vault1984 is
|
||||
on GitHub with stars, this account covers it automatically.
|
||||
|
||||
---
|
||||
|
||||
### 4. @czverse — czverse
|
||||
- **Focus:** Privacy-first open-source alternatives (Perplexica, self-hosted
|
||||
search, local AI), long-form threads
|
||||
- **Format:** Deep-dive threads — 800-1500 word breakdowns of privacy
|
||||
open-source tools. Used the "🚨 BREAKING: The open-source community just
|
||||
dropped something huge" opener.
|
||||
- **Engagement:** Medium-high for long-form; privacy angle resonates with
|
||||
their audience
|
||||
- **DM / reach:** DM likely open (no explicit policy found). Reply works.
|
||||
- **Notes:** Best for tools with a strong "own your data" / "no cloud spying"
|
||||
angle. vault1984 is a perfect fit.
|
||||
|
||||
---
|
||||
|
||||
### 5. @theai_mentor — The AI Mentor
|
||||
- **Focus:** AI tools, open-source models, developer productivity
|
||||
- **Format:** "🚨BREAKING:" format — used for DeepSeek drop, open source AI
|
||||
models, LLM tools
|
||||
- **Engagement:** High — active daily, consistent format
|
||||
- **DM / reach:** DM likely open; reply + tag works
|
||||
- **Notes:** More AI-model focused than pure DevOps, but covers open-source
|
||||
self-hosted angle ("runs on YOUR hardware, no API fees")
|
||||
|
||||
---
|
||||
|
||||
## Tier 2 — Consistent Open Source / Self-Hosted Content
|
||||
|
||||
These accounts post this type of content regularly but may not use the exact
|
||||
"🚨 BREAKING" format.
|
||||
|
||||
---
|
||||
|
||||
### 6. @sunsetsyntax — SunsetSyntax
|
||||
- **Focus:** Open-source AI tools, self-hosted alternatives (Tabby, LibreChat,
|
||||
Quivr), DevOps utilities
|
||||
- **Format:** "Meet [Tool]: [description]. Self-hosted. 100% open source."
|
||||
— posts 2x/day
|
||||
- **Engagement:** Medium; steady posting cadence
|
||||
- **DM / reach:** DM likely open; tag in relevant posts
|
||||
- **Notes:** Posts GitHub repos with star counts. Consistent self-hosted angle.
|
||||
Receptive to tool submissions.
|
||||
|
||||
---
|
||||
|
||||
### 7. @recaplyai — Recaply AI
|
||||
- **Focus:** Self-hosted SaaS alternatives, the "stop renting your tools" angle
|
||||
(n8n, Plausible, Vaultwarden, Nextcloud, etc.)
|
||||
- **Format:** "Stop paying for tools you can host yourself for free. This repo
|
||||
has X categories…" — viral listicle style
|
||||
- **Engagement:** Medium-high; this type of post (awesome-selfhosted refs)
|
||||
performs well
|
||||
- **DM / reach:** DM likely open
|
||||
- **Notes:** Direct alignment with vault1984's philosophy — "own your
|
||||
infrastructure, pay nothing"
|
||||
|
||||
---
|
||||
|
||||
### 8. @AiAdventurerx — AI Adventurer
|
||||
- **Focus:** Open-source AI tools, self-hosted alternatives, GitHub repos
|
||||
- **Format:** "tired of paying for Notion/Slack/Shopify? This repo has
|
||||
open-source alternatives…" — very similar style to recaplyai
|
||||
- **Engagement:** Medium
|
||||
- **DM / reach:** DM likely open; tag works
|
||||
- **Notes:** Posts the awesome-selfhosted repo type content. Bootstrapped
|
||||
founder angle.
|
||||
|
||||
---
|
||||
|
||||
### 9. @simplifyinAI — Simplifying AI
|
||||
- **Focus:** Open-source AI tools, developer tools
|
||||
- **Format:** Copies the exact "🚨 BREAKING: Someone just open-sourced..."
|
||||
format — appeared in multiple searches amplifying the same viral posts
|
||||
- **Engagement:** Medium
|
||||
- **DM / reach:** DM likely open; reply/tag
|
||||
- **Notes:** Part of the echo chamber that amplifies viral open-source posts.
|
||||
Worth tagging to get picked up.
|
||||
|
||||
---
|
||||
|
||||
### 10. @shubh19 — Shubh Jain
|
||||
- **Focus:** AI/developer open-source tools, agentic software
|
||||
- **Format:** Uses the exact viral format — did the Paperclip (agent OS)
|
||||
post with "🚨 BREAKING: Someone just open-sourced…"
|
||||
- **Engagement:** Medium
|
||||
- **DM / reach:** DM likely open
|
||||
- **Notes:** Posts original discoveries, not just reposts
|
||||
|
||||
---
|
||||
|
||||
### 11. @cloudashu — laxmikant pandit
|
||||
- **Focus:** AI tools, open-source developer utilities
|
||||
- **Format:** "🚨 Someone just open-sourced a tool to optimize websites for
|
||||
AI search engines…" — uses the format
|
||||
- **Engagement:** Low-medium
|
||||
- **DM / reach:** DM likely open
|
||||
|
||||
---
|
||||
|
||||
## Tier 3 — Homelab / Self-Hosting Community Accounts
|
||||
|
||||
More niche but very tight audience match (exactly the vault1984 target user).
|
||||
|
||||
---
|
||||
|
||||
### 12. @Serversathome — ServersatHome
|
||||
- **Focus:** Self-hosting video tutorials, homelab apps, open-source
|
||||
alternatives to SaaS
|
||||
- **Format:** "New video! Looking at [Tool] — open-source, self-hosted…"
|
||||
- **Engagement:** Medium; dedicated homelab community following
|
||||
- **DM / reach:** DM likely open; YouTube channel tie-in = more reach
|
||||
- **Notes:** Posts about tools like Tracktor, Uptime Kuma, etc. Exact audience.
|
||||
|
||||
---
|
||||
|
||||
### 13. @kubesploit — Kubesploit
|
||||
- **Focus:** Security-focused open-source DevOps tools (zero-trust, WireGuard,
|
||||
ZTNA, Kubernetes, infrastructure)
|
||||
- **Format:** Highlights open-source security/infra tools with GitHub links
|
||||
- **Engagement:** Medium; security/DevOps niche
|
||||
- **DM / reach:** DM likely open; professional security community
|
||||
- **Notes:** Strong overlap with privacy/self-hosted angle. Covers tools like
|
||||
NetBird, Pangolin, etc.
|
||||
|
||||
---
|
||||
|
||||
### 14. @TechnoTimLive — Techno Tim
|
||||
- **Focus:** Homelab, self-hosting, Kubernetes, Proxmox, DevOps tutorials
|
||||
- **Format:** Tutorial/video-centric; covers open-source tools in depth
|
||||
- **Engagement:** High in homelab community; YouTube channel amplifies
|
||||
- **DM / reach:** DM likely open; community Discord for reach
|
||||
- **Notes:** Mentioned by Grok as a top homelab/self-hosted account. Strong
|
||||
YouTube + X presence.
|
||||
|
||||
---
|
||||
|
||||
### 15. @SelfHostedShow — Self-Hosted Show
|
||||
- **Focus:** Self-hosting podcast, open-source infrastructure, Linux
|
||||
- **Format:** Podcast clips + tool highlights
|
||||
- **Engagement:** Medium-high in self-hosting community
|
||||
- **DM / reach:** DM or podcast submission form (likely on site)
|
||||
- **Notes:** Jupiter Broadcasting / Chris Fisher audience. Dedicated listener
|
||||
base that overlaps perfectly with vault1984 users.
|
||||
|
||||
---
|
||||
|
||||
## Contact Strategy Summary
|
||||
|
||||
| Handle | Best Reach Method | Notes |
|
||||
|---|---|---|
|
||||
| @oliviscusAI | Reply + DM | Very active; newsletter reach too |
|
||||
| @hasantoxr | DM via bio.link/hasantoxr | **Explicit submission signal** in bio |
|
||||
| @GithubProjects | Reply / tag | High volume, auto-covers GitHub projects |
|
||||
| @czverse | DM / reply | Privacy angle = strong fit |
|
||||
| @theai_mentor | Reply + DM | "Runs on your hardware" framing works |
|
||||
| @sunsetsyntax | DM | Tags GitHub repos directly |
|
||||
| @recaplyai | DM / reply | "Stop paying for SaaS" audience |
|
||||
| @AiAdventurerx | DM | Bootstrapper audience |
|
||||
| @simplifyinAI | Tag in post | Picks up viral format content |
|
||||
| @shubh19 | DM / reply | Original discoveries |
|
||||
| @Serversathome | DM | Homelab video creator |
|
||||
| @kubesploit | DM / reply | Security/infra DevOps niche |
|
||||
| @TechnoTimLive | DM / Discord | YouTube amplification |
|
||||
| @SelfHostedShow | Podcast form | Podcast reach |
|
||||
|
||||
---
|
||||
|
||||
## Pitch Framing That Works for These Accounts
|
||||
|
||||
Based on what performs well in their feeds:
|
||||
|
||||
- **Lead with "🚨 BREAKING: Someone just open-sourced…"** — this format gets
|
||||
picked up algorithmically and by other amplifiers
|
||||
- **Emphasize:** "100% Open Source. No subscriptions. No data sent to Big Tech."
|
||||
- **Include:** GitHub star count (social proof), Docker deploy, single-command
|
||||
install
|
||||
- **Privacy angle:** "Runs entirely on your own hardware. Nothing leaves
|
||||
your machine."
|
||||
- **Anti-SaaS angle:** "Replace [Paid Tool] for $0/month"
|
||||
|
||||
---
|
||||
|
||||
## Notes on Format Saturation
|
||||
|
||||
Multiple accounts (and their audiences) are aware this format is being
|
||||
"gamed" — @andyhyfi literally posted: _"Someone just open sourced AI social
|
||||
media algorithm farming. Start every tweet with 'Someone just open sourced…'"_
|
||||
|
||||
This means the format still works for distribution but credibility matters.
|
||||
vault1984 should pair it with a **genuine demo** (video/GIF) and real GitHub
|
||||
repo with stars to avoid the "AI slop" label.
|
||||
|
||||
---
|
||||
|
||||
*Last updated: 2026-03-10 | Source: bird CLI searches + @johanjongsma feed*
|
||||
|
|
@ -0,0 +1,47 @@
|
|||
# "If you want to keep a secret, you must also hide it from yourself."
|
||||
|
||||
I've spent 20 years building backup and data protection systems — the kind organizations rely on when everything else has failed. I've seen what happens when people trust someone else to hold their critical data. The pattern is always the same: the math was fine, the architecture was wrong.
|
||||
|
||||
Password managers have a version of this problem that nobody wants to say out loud.
|
||||
|
||||
---
|
||||
|
||||
## "Zero-knowledge" is a legal term, not a security property
|
||||
|
||||
Every major password manager claims zero-knowledge. One of the largest did too — until 2022, when attackers stole their entire vault database. Four years later, researchers are still tracing active crypto theft back to that breach. Accounts are still being drained.
|
||||
|
||||
The encryption worked exactly as designed. That wasn't the failure. The failure was that tens of millions of encrypted blobs were in one place, and once stolen, the attackers had unlimited time to crack them offline. The industry's response has been to increase iteration counts — more rounds of hashing to slow down guessing. The current recommendation is 600,000, and probably next year a million. But that's the wrong solution to the right problem. Hardware gets faster every year. What takes a month today takes a week next year. Iteration counts are a rearguard action against an attacker who has already won.
|
||||
|
||||
The correct answer isn't to make the vault harder to crack — it's to make the vault worthless to steal.
|
||||
|
||||
This isn't a problem specific to one provider. It's structural. Whoever holds the largest encrypted vault database is the highest-value target. Those conditions exist at every SaaS password manager operating today. The only question is timing.
|
||||
|
||||
---
|
||||
|
||||
## The incumbents can't fix this without destroying their business
|
||||
|
||||
The enterprise players need server authority — their admin controls, visibility features, and AI integrations require it. The cloud providers have revenue to protect; seamless self-hosting cannibalizes it. The breached provider is still running the same architecture.
|
||||
|
||||
They are all trapped. Not by laziness — by their business models.
|
||||
|
||||
---
|
||||
|
||||
## What actually prevents the attack
|
||||
|
||||
There's one architectural principle that makes the stolen-blob attack impossible: the decryption key never touches the server. If you breach the server, you get ciphertext that cannot be read without something that was never there.
|
||||
|
||||
That's not a difficult concept. It's just a difficult business model to build around — unless you start from scratch.
|
||||
|
||||
---
|
||||
|
||||
## vault1984
|
||||
|
||||
So I built it. Self-hosted, open source, one Docker command.
|
||||
|
||||
If someone breaches a vault1984 instance, they get ciphertext. That's it. "Breach us. You'll get nothing" isn't a marketing line — it's a description of the math.
|
||||
|
||||
The name is the thesis. And the design follows from a single principle: if you want to keep a secret, you must also hide it from yourself.
|
||||
|
||||
[GitHub link]
|
||||
|
||||
*Happy to go deep on the threat model, or why the SaaS password manager category has a structural problem that can't be fixed incrementally.*
|
||||
|
|
@ -0,0 +1,296 @@
|
|||
# vault1984: Competitive Intelligence & Market Strategy
|
||||
*Generated: March 10, 2026 | Method: Structured 5-prompt competitive analysis*
|
||||
|
||||
---
|
||||
|
||||
## THE OPENING
|
||||
|
||||
vault1984 has a structural advantage that no incumbent can copy without committing business-model suicide: **the server mathematically cannot possess what it cannot be forced to hand over**. Every major competitor stores centralized encrypted blobs — and the 2022 LastPass breach proved that "zero-knowledge encryption" on someone else's server is a legal disclaimer, not a security guarantee. vault1984's WebAuthn PRF architecture eliminates the stolen-blob-then-crack attack vector entirely, because there is no blob to steal. The specific buyers who understand this math — post-breach CISOs, security engineers, sovereignty-conscious IT teams — are a real and growing market, energized by every major SaaS breach. The incumbents are structurally trapped: 1Password's enterprise features *require* server authority; Bitwarden's cloud revenue *requires* users not to self-host too easily; Dashlane's "beyond the vault visibility" product *requires* centralized credential access. vault1984's message is: **"We cannot be LastPass'd. Mathematically."**
|
||||
|
||||
---
|
||||
|
||||
## Sources Used
|
||||
|
||||
**Competitor landing pages:** 1Password, Bitwarden, LastPass, Dashlane (fetched March 2026)
|
||||
|
||||
**Breach postmortems:**
|
||||
- LastPass 2022 breach (Wikipedia, LastPass official blog, ICO findings)
|
||||
- 1Password 2023 Okta incident (1Password incident report, TechTarget)
|
||||
|
||||
**Community signals:**
|
||||
- r/selfhosted: password manager threads (warden-worker 400+ forks, self-hosting exodus)
|
||||
- r/privacy: password manager trust discussions
|
||||
- r/sysadmin: LastPass alternatives, Bitwarden vs LastPass comparison threads
|
||||
|
||||
---
|
||||
|
||||
## PROMPT 1: The Unspoken Insight
|
||||
|
||||
> *"What does every successful player in the password manager market understand that their customers never say out loud?"*
|
||||
|
||||
**The unspoken insight: customers don't want security — they want the feeling of having done the responsible thing.**
|
||||
|
||||
Every successful password manager sells absolution from anxiety, not cryptographic guarantees. The tell is in the language:
|
||||
|
||||
- **LastPass** (post-breach): "We have undergone an extensive security transformation; emerging as a stronger, more innovative, and independent company with an unwavering commitment to security." This is the language of confession and forgiveness, not security.
|
||||
- **1Password** leads with *"effortless security that just works."* The word "effortless" is the tell. Real security is never effortless — when something is effortless, complexity is being hidden, not eliminated.
|
||||
- **Bitwarden** leads with "Simple to use" before security. Security is the third bullet.
|
||||
- **Dashlane** promises "instant credential security: Dashlane starts protecting your organization as soon as it's deployed." Immediacy, not depth.
|
||||
|
||||
The real product being sold is **credentialed convenience** — the ability to say "I use a password manager" as social proof of responsibility, the same way "I have insurance" functions. Whether it actually works when tested is secondary.
|
||||
|
||||
**The deeper unspoken truth that every winner is operating on:** The market has been built on a structural ambiguity in the term "zero-knowledge." Every competitor uses the phrase. LastPass used it too, right up until attackers stole 33 million encrypted vaults and started cracking them at leisure — because "zero-knowledge" meant "we don't *look* at your passwords," not "we can't be forced to hand them over." The winners understand this distinction and design their product to *seem* to resolve it without actually doing so.
|
||||
|
||||
**The implication for vault1984:** There is a segment — growing fast post-LastPass — that has moved past wanting the *feeling* of security to wanting the *proof* of it. This segment is underserved because incumbents are architecturally incapable of serving them.
|
||||
|
||||
---
|
||||
|
||||
## PROMPT 2: The 3 Core Assumptions — and Where They Break
|
||||
|
||||
> *"What are the 3 core assumptions this entire market is built on, and what would have to be true for each one to be wrong?"*
|
||||
|
||||
### Assumption 1: Zero-knowledge encryption = safety
|
||||
|
||||
**The consensus:** Every competitor claims zero-knowledge. Every marketing page asserts that "only you can access your data." This is treated as the solved problem.
|
||||
|
||||
**What would have to be true for this to be wrong:** If encrypted blobs can be stolen and cracked offline, "zero-knowledge" is a legal claim, not a security property. The 2022 LastPass breach demonstrates this precisely:
|
||||
|
||||
- Attackers stole the entire backup database including encrypted password vaults
|
||||
- Unencrypted fields included: website URLs (enabling targeted attacks), names, email addresses, partial credit card numbers
|
||||
- The vaults were encrypted with users' master passwords — but users had weak passwords, and legacy accounts had as few as 100 PBKDF2 iterations vs. the recommended 600,000
|
||||
- By December 2025, TRM Labs traced $35M+ in crypto theft directly to the breach, with attacks still succeeding three years later
|
||||
- ICO issued a monetary penalty against LastPass UK Ltd; LastPass settled a $24.5M class action
|
||||
- 1Password's 2023 Okta incident showed even top-tier security organizations are vulnerable to third-party compromise: a HAR file containing session tokens was used to access their Okta administrative portal
|
||||
|
||||
**The fragile consensus:** "Zero-knowledge" has become marketing language stripped of technical meaning. The entire market's security proposition rests on users trusting that their encrypted data is safe on someone else's server — a trust that is actively being eroded by successive breaches.
|
||||
|
||||
**Where this breaks completely:** The next major breach. The market is structured to guarantee another LastPass: whoever holds the largest encrypted vault database is the highest-value target. The assumption will collapse again.
|
||||
|
||||
---
|
||||
|
||||
### Assumption 2: Centralized SaaS is the correct delivery model
|
||||
|
||||
**The consensus:** All four major players (1Password, Bitwarden cloud, LastPass, Dashlane) default to centralized cloud hosting. Even Bitwarden's self-host option is positioned as an advanced/enterprise edge case, not the primary product.
|
||||
|
||||
**What would have to be true for this to be wrong:** If a meaningful segment of users — particularly in enterprise/technical markets — prefers to control their own infrastructure, and if the friction of self-hosting can be reduced below a critical threshold, centralized SaaS stops being the obvious default.
|
||||
|
||||
**Evidence of fragility:**
|
||||
- A developer posted a "janky" Bitwarden-compatible server (warden-worker) to GitHub, forgot about it, and returned to find 400+ forks and active community development — organic community pressure demanding self-hosted alternatives
|
||||
- The self-hosted Bitwarden community cites not just security concerns but UX failures: Bitwarden's email 2FA creates a chicken-and-egg problem (need email to log into Bitwarden, but email password is in Bitwarden)
|
||||
- r/sysadmin shows mass LastPass exodus post-breach, with users specifically migrating to self-hosted options (Vaultwarden/Bitwarden self-host, KeePass)
|
||||
- The r/selfhosted community explicitly prizes password manager control as foundational to data sovereignty
|
||||
|
||||
**The fragile consensus:** Centralized SaaS is assumed to be the convenience/friction winner. But post-breach, the "convenience" of having someone else manage your password database is being repriced in the market as a liability.
|
||||
|
||||
---
|
||||
|
||||
### Assumption 3: The customer will always choose convenience over control
|
||||
|
||||
**The consensus:** Password managers succeed by reducing friction. The entire UX philosophy — autofill, cross-device sync, one-click login — is built on the premise that users will trade control for ease.
|
||||
|
||||
**What would have to be true for this to be wrong:** If a post-breach segment exists that will pay a meaningful friction premium for verified security, and if the friction can be reduced to tolerable levels for that segment, the market bifurcates: convenience products for mainstream users, sovereignty products for security-conscious users.
|
||||
|
||||
**Evidence of fragility:**
|
||||
- The LastPass breach created a lasting behavioral change: "As users failed to rotate passwords or improve vault security, attackers continued to crack weak master passwords years later" (TRM Labs, December 2025)
|
||||
- Bitwarden grew rapidly post-2022 breach, not because it's more convenient than LastPass, but because users were willing to accept more friction in exchange for open-source auditability
|
||||
- 1Password's marketing has shifted from password management to "Identity Security" — they're adding complexity (SaaS governance, AI agent access) because convenience alone isn't enough to justify premium pricing
|
||||
- The self-hosted Vaultwarden ecosystem exists specifically because some users prioritize control over convenience, to the point of building their own servers
|
||||
|
||||
**The fragile consensus:** The assumption that convenience always wins is surviving on inertia. It will be directly challenged the next time a major breach happens — and the attack will be leveled at the entire SaaS model, not just the breached vendor.
|
||||
|
||||
---
|
||||
|
||||
## PROMPT 3: 5 Investor Questions — and the Honest Answers
|
||||
|
||||
> *"Write 5 questions a world-class investor would ask to destroy vault1984 as a business idea, then answer each one using only the evidence in the gathered documents."*
|
||||
|
||||
### Q1: "Bitwarden is already open source, already self-hostable, and already has 11 straight quarters at #1 in G2 enterprise satisfaction. Why would anyone choose vault1984?"
|
||||
|
||||
**Answer:** Bitwarden's self-hosted option retains the traditional architecture: master password → derived key → encrypted blob stored on your server. The server still stores the blob. A compromised Bitwarden self-hosted instance (or a poorly maintained one) still yields encrypted data subject to offline cracking.
|
||||
|
||||
vault1984's WebAuthn PRF changes the architecture at the root: the encryption key is mathematically derived from a hardware authenticator + origin binding — it never exists on the server in any form, derived or otherwise. Even a full server compromise yields data that is cryptographically inaccessible without the physical hardware key. Bitwarden has not shipped this. Neither has anyone else.
|
||||
|
||||
The comparison isn't "vault1984 vs Bitwarden feature set." It's "vault1984 vs the entire market's encryption model." This is a genuinely new thing.
|
||||
|
||||
**Weakness:** Bitwarden has the resources to implement WebAuthn PRF. This answer has a shelf life.
|
||||
|
||||
---
|
||||
|
||||
### Q2: "What is your TAM? Self-hosters are a tiny niche."
|
||||
|
||||
**Answer:** The TAM framing is pre-2022. The LastPass breach affected 33 million users and forced the question: is the SaaS password manager model fundamentally broken? The ICO fined LastPass UK Ltd for failures affecting over one million UK subjects alone. The $24.5M class action settlement signals real financial harm at scale.
|
||||
|
||||
The community signals show organic demand: 400+ GitHub forks of a random Bitwarden-compatible server, r/sysadmin threads about LastPass alternatives (with the top thread being "Lastpass doubles price for Premium, removes features from Free" — the breach wasn't even needed for exodus, just pricing pressure). The technical/enterprise market for self-hosted password management is structurally underserved and growing.
|
||||
|
||||
**Weakness:** "Organic community interest" is not a business. The question of who pays and how much is unanswered.
|
||||
|
||||
---
|
||||
|
||||
### Q3: "How do you make money? 'No SaaS fees' is a feature, not a business model."
|
||||
|
||||
**Answer (honest):** This is the weakest point in vault1984's current positioning. "Open source, no SaaS fees" actively signals "no revenue" to enterprise buyers.
|
||||
|
||||
Evidence from the market: Bitwarden charges for enterprise features. 1Password has a subscription model. Dashlane is fully enterprise SaaS. The successful players all have predictable recurring revenue. vault1984 has no stated monetization model.
|
||||
|
||||
**Weakness:** This answer has no good evidence-based response. The monetization model must be built — it's not demonstrated by anything in the market research. This is a genuine gap.
|
||||
|
||||
---
|
||||
|
||||
### Q4: "1Password has $620M in funding and thousands of engineers. When they decide to implement WebAuthn PRF, vault1984 is obsolete overnight. Why can't they just copy you?"
|
||||
|
||||
**Answer:** 1Password's homepage reveals why they can't: their current product direction is *away* from user-controlled security and *toward* enterprise identity control. They market: "Secure AI agent and app access," "Manage and govern your SaaS apps," "Regain control over SaaS sprawl." Their business model is built on being the authoritative identity layer that enterprises pay to manage.
|
||||
|
||||
True zero-knowledge via WebAuthn PRF would break admin controls (admins can't see what employees are doing), break account recovery (hardware key lost = vault lost), and break the enterprise "visibility" features that justify $8-20/user/month pricing. 1Password cannot implement vault1984's architecture without dismantling their enterprise product.
|
||||
|
||||
Bitwarden is closer to being able to copy it — but they've spent 11 quarters building SaaS market share and have recurring cloud subscription revenue to protect.
|
||||
|
||||
**Weakness:** This moat is architectural and business-model-based, but it requires sustained product execution to matter. If vault1984 stalls, a smaller focused competitor could occupy the same space.
|
||||
|
||||
---
|
||||
|
||||
### Q5: "Self-hosted means users own their security failures. Most businesses can't manage their own servers. Doesn't this segment cap at the technical elite?"
|
||||
|
||||
**Answer:** The "one Docker command" framing is directionally correct but underexecuted. The evidence from the market: people are running Raspberry Pi music servers, building Cloudflare Workers Bitwarden clones, managing complex self-hosted stacks. The technical threshold is lower than incumbents assume.
|
||||
|
||||
More importantly: vault1984's primary buyer is not the individual user — it's the IT administrator, the CISO, the security engineer who controls password manager procurement for their organization. These buyers already manage Docker deployments. "One Docker command" is genuinely trivial for this buyer.
|
||||
|
||||
**Weakness:** Enterprise procurement requires SOC 2 compliance, SLAs, dedicated support, and vendor credibility. "Open source, Docker, no fees" is an obstacle, not an asset, in enterprise sales cycles. This ceiling is real.
|
||||
|
||||
---
|
||||
|
||||
## PROMPT 4: Strengthening the Weak Answers — and Where They Still Break
|
||||
|
||||
> *"For each weak answer above, what is the strongest possible version of that argument — and where does it still break?"*
|
||||
|
||||
### Q1 Weakness (Bitwarden can copy): Strongest version
|
||||
|
||||
**Strongest version:** Bitwarden copying WebAuthn PRF would require deprecating their entire master password architecture — migrating 100,000+ enterprise customers and millions of personal users to a new encryption model. This is not a feature flag. It's a full data migration, a UX overhaul, and a support nightmare. Even if Bitwarden started today, it's a 2-3 year migration path with massive user churn risk. vault1984 has a multi-year head start in the WebAuthn PRF architecture space.
|
||||
|
||||
**Where it still breaks:** If a well-funded startup implements the same architecture before vault1984 achieves meaningful market share, the competitive advantage disappears. The moat is "first mover in a specific architecture" — which requires speed.
|
||||
|
||||
---
|
||||
|
||||
### Q3 Weakness (no monetization): Strongest version
|
||||
|
||||
**Strongest version:** vault1984's zero-trust architecture creates a *new category* of enterprise offering that incumbents cannot match: **managed hosting with mathematical privacy guarantees**. vault1984 could run a hosted cloud offering where customers' vaults are stored on vault1984's servers — but because WebAuthn PRF means the decryption key is hardware-bound on the client, vault1984 itself cannot decrypt any vault. This is a hosted offering that is genuinely zero-knowledge, unlike every competitor who uses "zero-knowledge" as marketing language.
|
||||
|
||||
Monetization model: charge for hosting, support, compliance (SOC 2, FIPS 140-3), and enterprise features — while being provably incapable of the breach pattern that cost LastPass $24.5M in settlements and untold reputational damage. The argument to enterprise buyers: *our hosting fees are cheaper than one breach.*
|
||||
|
||||
**Where it still breaks:** Building a sustainable hosted business requires DevOps infrastructure, compliance certifications, and support teams — all the things that increase operational cost and reduce the "zero SaaS" purity of the positioning. vault1984 must choose between being a pure open-source project (limited TAM, donation/sponsorship dependent) or building a company (requires the organizational complexity they're positioning against). There is no clean answer here; this is a genuine strategic fork.
|
||||
|
||||
---
|
||||
|
||||
### Q5 Weakness (technical ceiling): Strongest version
|
||||
|
||||
**Strongest version:** The technical ceiling is a *feature* in the early stage. The self-hosted, security-conscious, technical market is exactly the right beachhead: these are the people who evangelize products to their organizations, write blog posts, influence procurement decisions, and have the lowest tolerance for SaaS password manager failures. Capturing the r/selfhosted and r/sysadmin audience means capturing the people who eventually become the CISOs who sign enterprise contracts.
|
||||
|
||||
The playbook: land in the technical community with a best-in-class open source project, build a reputation for being unhackable, then expand to enterprise with a hosted (but genuinely zero-knowledge) offering backed by the technical credibility earned in the first phase.
|
||||
|
||||
**Where it still breaks:** This is a long game — potentially a 5-7 year path from "respected open source project" to "enterprise-credible vendor." It requires sustained development and community investment without the revenue that normally funds that investment. Open source projects stall when original developers lose interest or face financial pressure. Bitwarden has an engineering team; vault1984 needs to fund one.
|
||||
|
||||
---
|
||||
|
||||
## PROMPT 5: vault1984's Actual Attack Surface
|
||||
|
||||
> *"Given everything above — what is vault1984's actual attack surface? The specific opening in this market that incumbents cannot close without undermining their own business model?"*
|
||||
|
||||
### The Opening: The Post-Breach Trust Vacuum, Specifically in the Technical Enterprise
|
||||
|
||||
**The structural trap every incumbent is in:**
|
||||
|
||||
**1Password** is becoming an "Identity Security" platform. Their 2026 product direction — AI agent access management, SaaS governance, shadow IT control — requires them to be the *authoritative server*. Their entire enterprise value proposition is: "we help you *see* and *control* what your employees are doing." True zero-knowledge (the cryptographic kind, not the marketing kind) would make this product impossible. They cannot ship vault1984's architecture without destroying the product they just spent $620M building.
|
||||
|
||||
**Bitwarden** is caught between two identities: "trusted open source" and "cloud SaaS business." They've chosen cloud SaaS (11 quarters of G2 enterprise satisfaction scores, email 2FA requirements, features gated behind paid plans). The self-host community is building around them, not with them. Bitwarden's business model actively discourages trivial self-hosting. They *need* friction in self-hosting to protect cloud revenue.
|
||||
|
||||
**LastPass** is in damage-control mode. Their breach is not resolved — as of December 2025, TRM Labs documented active crypto theft still occurring from 2022-stolen vaults. Their entire "extensive security transformation" messaging is defense posture. Their architecture hasn't changed: they still hold centralized encrypted vaults. They will suffer the next offline-cracking wave whenever another vault backup is exfiltrated.
|
||||
|
||||
**Dashlane** has explicitly moved *toward* centralized visibility with "OMNIX" — "beyond the vault visibility & protection," monitoring "vault and non-vault users." Their product literally cannot exist without server-side credential visibility. vault1984 is categorically incompatible with their business model.
|
||||
|
||||
---
|
||||
|
||||
### The Specific Opening
|
||||
|
||||
**The buyer:** Security-conscious technical organizations — companies with an IT admin or CISO who read the LastPass postmortem and had the thought: *"The encryption isn't the problem. The problem is that their entire encrypted database was stolen and can be cracked at leisure for the next decade."*
|
||||
|
||||
**The message that lands and cannot be countered:**
|
||||
|
||||
> *"Every competitor who claims zero-knowledge is using it as a marketing term. vault1984 uses it as an engineering constraint. When we say zero-knowledge, we mean: if our servers are breached, the attacker gets encrypted blobs that require the physical hardware key to decrypt. Not a master password. Not a derived key stored anywhere. The physical device in your user's hand. That's not a feature. That's the architecture."*
|
||||
|
||||
**Why incumbents cannot close this:**
|
||||
|
||||
- To match it, 1Password must eliminate admin controls → loses enterprise features → loses enterprise revenue
|
||||
- To match it, Bitwarden must eliminate master password recovery → loses average users → loses cloud subscriptions
|
||||
- LastPass cannot credibly claim it because they already didn't have it when they needed it
|
||||
- Dashlane cannot claim it because their product explicitly provides "visibility" — i.e., the server CAN see
|
||||
|
||||
The WebAuthn PRF constraint that makes vault1984 harder to use (no password recovery, hardware key required) is *also* the property that makes it unhackable in the LastPass-pattern way. The incumbents cannot adopt this constraint without breaking their product. vault1984's "limitation" is its moat.
|
||||
|
||||
---
|
||||
|
||||
### The Attack Surface Summary
|
||||
|
||||
| What vault1984 owns | What incumbents cannot do |
|
||||
|---|---|
|
||||
| WebAuthn PRF = key never touches server | Can't implement without breaking account recovery |
|
||||
| Self-hosted = no centralized vault database to steal | Can't make self-hosting trivial without cannabilizing cloud revenue |
|
||||
| Open source = auditable claim | Can't match without revealing full server-side code |
|
||||
| No metadata leakage (URLs etc.) | LastPass leaked URLs in plaintext; incumbents use server-side metadata for features |
|
||||
| FIPS 140-3 | Achievable by incumbents but vault1984 pairs it with architecture, not just algorithms |
|
||||
|
||||
---
|
||||
|
||||
## Messaging Angles That Emerged from the Analysis
|
||||
|
||||
### Tier 1: The Mathematical Claim (Primary Differentiator)
|
||||
|
||||
> **"We cannot be LastPass'd. Mathematically."**
|
||||
|
||||
Supporting copy: *"LastPass said zero-knowledge. So did every competitor. But in 2022, their entire vault database was stolen and users are still losing crypto in 2025. The encryption was real — but the attack was on the architecture, not the algorithm. vault1984's WebAuthn PRF means the decryption key exists only on your hardware. Our servers hold encrypted data that is cryptographically useless without your physical device. Breach us. You'll get nothing."*
|
||||
|
||||
---
|
||||
|
||||
### Tier 2: The Business Model Honesty Angle
|
||||
|
||||
> **"Every SaaS password manager is one acquisition away from LastPass."**
|
||||
|
||||
Supporting copy: *"LastPass got acquired, raised prices, removed features, and then got breached. Bitwarden added mandatory email 2FA that breaks when you need it most. 1Password raised prices post-COVID. The pattern is always the same: VC-backed SaaS needs growth, growth requires monetization pressure, monetization pressure degrades the product. vault1984 is open source. There's nothing to acquire. Nothing to monetize. Just a server you run, with math that works."*
|
||||
|
||||
---
|
||||
|
||||
### Tier 3: The Metadata Angle (Underutilized by Competitors)
|
||||
|
||||
> **"LastPass didn't just leak your passwords. They leaked every website you've ever logged into — in plaintext."**
|
||||
|
||||
Supporting copy: *"When attackers took LastPass's database in 2022, they got your vault encrypted — but your URLs unencrypted. They know which banks you use, which medical portals, which crypto exchanges. The passwords were protected by encryption. Your online life wasn't. vault1984 stores no unencrypted metadata. There's nothing to reconstruct your digital life from."*
|
||||
|
||||
---
|
||||
|
||||
### Tier 4: The Sovereignty Angle (For Privacy/Technical Community)
|
||||
|
||||
> **"1984 wasn't just the year surveillance capitalism started. It's the year we decided to stop participating."**
|
||||
|
||||
Supporting copy: *"The Orwell reference isn't irony. It's the premise. Every SaaS password manager participates in a system where your digital life is stored on someone else's computer, subject to their security practices, their acquisition decisions, and their legal jurisdiction. vault1984 is one Docker command to run your own. Your data. Your server. Your keys."*
|
||||
|
||||
---
|
||||
|
||||
### Tier 5: The CISO Close (Enterprise Sales)
|
||||
|
||||
> **"The next LastPass has already been breached. They just haven't disclosed it yet."**
|
||||
|
||||
Supporting copy: *"Every major password manager is running the same architecture LastPass was: centralized encrypted vaults, master-password-derived keys, metadata in plaintext or lightly encrypted. If an attacker exfiltrates the database, time is on their side. vault1984's architecture means time is on yours: there's no offline cracking attack that works against hardware-bound keys. When you're doing due diligence on password manager procurement, ask one question: 'If your entire database were exfiltrated tonight, how long until my users' passwords are at risk?' We'll tell you: forever. Ask them."*
|
||||
|
||||
---
|
||||
|
||||
## Strategic Recommendation
|
||||
|
||||
vault1984's real competitive position is not "better password manager." It is the **first password manager whose breach-resistance is architectural, not operational**. Every competitor bets on not being breached. vault1984 bets on a breach being meaningless.
|
||||
|
||||
The go-to-market order:
|
||||
1. **Own the technical community** — r/selfhosted, r/sysadmin, Hacker News. Make vault1984 the reference answer to "what password manager are you running post-LastPass."
|
||||
2. **Build compliance credibility** — FIPS 140-3 is already there. Add SOC 2 Type II. This is the enterprise gateway.
|
||||
3. **Develop the hosted zero-knowledge tier** — This is the business model and the TAM expansion. "We host it, but we literally cannot read it" is a genuinely new category.
|
||||
4. **Target post-LastPass switchers at procurement time** — Enterprise buyers cycling out of LastPass are active right now. This is a closing window.
|
||||
|
||||
**The message that doesn't need A/B testing:**
|
||||
*"We cannot be LastPass'd. Mathematically."*
|
||||
Everything else is explanation of why that's true.
|
||||
|
|
@ -0,0 +1,584 @@
|
|||
# vault1984 — Full Repositioning Document
|
||||
|
||||
**Prepared:** 2026-03-10
|
||||
**Based on:** L2_AGENT_ENCRYPTION.md, vault1984-hn-article.md, app/README.md, website/templates/
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
|
||||
The new 3-tier encryption architecture changes everything about the story vault1984 tells. The current positioning is **"AI-native password manager with field-level access control."** The new positioning must be: **"The only password manager where a server breach gives attackers nothing. Mathematically."**
|
||||
|
||||
This isn't a feature update. It's a category shift. The current framing competes with Bitwarden on AI features. The new framing makes the SaaS password manager category structurally obsolete.
|
||||
|
||||
The HN article has the thesis exactly right. The problem: the README and website have not caught up.
|
||||
|
||||
---
|
||||
|
||||
## Part 1: README Changes
|
||||
|
||||
### What Currently Says the Wrong Thing
|
||||
|
||||
**1. The opening tagline**
|
||||
```
|
||||
> *The vault that knows who it's talking to.*
|
||||
```
|
||||
This frames vault1984 as an access control story ("knows who it's talking to"). The real story is a breach story. No password manager should be interesting to steal. The tagline should communicate that, not identity routing.
|
||||
|
||||
**2. The lead sentence**
|
||||
```
|
||||
A password manager built for humans who have AI assistants.
|
||||
```
|
||||
Wrong hook entirely. This positions vault1984 as an AI productivity tool. The actual differentiator is a cryptographic property — a stolen database is worthless. The AI angle is real and important, but it's second. Security architecture is first.
|
||||
|
||||
**3. The "How it works" section frames L1 as acceptable**
|
||||
```
|
||||
Shared — server-encrypted (your AI can read these)
|
||||
API keys, SSH keys, passwords, TOTP seeds, logins...
|
||||
```
|
||||
Under the new architecture, these are L2 — **not** server-encrypted. Server-encrypted means the server CAN read them, which means they're exposed in a breach. The README currently and correctly admits this in the security table:
|
||||
```
|
||||
Full server compromise | Exposed | Cannot decrypt
|
||||
```
|
||||
This is honest. It also means the current README is documenting the exact vulnerability that the new architecture eliminates. Once L2 is implemented, this table row becomes: `Full server compromise | Worthless ciphertext | Cannot decrypt`. That's the headline.
|
||||
|
||||
**4. The security model table is accurate but buried**
|
||||
The table at the bottom of the README is the most important thing in the document. It should be near the top, not at the bottom.
|
||||
|
||||
**5. "Shared" / "Personal" naming is inconsistent with the website**
|
||||
The website uses "Agent fields" / "Sealed fields." The README uses "Shared" / "Personal." Neither reflects the new 3-tier model (L1/L2/L3). Pick one naming system and use it everywhere.
|
||||
|
||||
**6. The README has no breach narrative**
|
||||
No mention of LastPass, no mention of the stolen-vault attack vector, no articulation of why the server holding decryption keys is architecturally broken. A developer reading the README has no idea why this architecture matters in the threat landscape. They just see "two tiers of encryption" — and assume this is similar to what Bitwarden does.
|
||||
|
||||
### What's Missing
|
||||
|
||||
- The core security thesis: **"If the server is breached, the attacker gets ciphertext. That ciphertext cannot be decrypted without a key that was never on the server."**
|
||||
- The threat model framing: SaaS password managers are high-value targets precisely because they hold both encrypted vaults AND the decryption capability.
|
||||
- Explicit comparison to the LastPass breach — not to trash LastPass, but to show the structural problem is universal.
|
||||
- The L2 architecture: passwords and API keys encrypted with a key that exists only in agent tokens and browser sessions — never stored on the server.
|
||||
- The L3 distinction: even agents can't reach card numbers and government IDs — hardware authenticator required.
|
||||
|
||||
### Proposed New README Structure
|
||||
|
||||
```
|
||||
# vault1984
|
||||
|
||||
> "If you want to keep a secret, you must also hide it from yourself."
|
||||
> — George Orwell, 1984
|
||||
|
||||
**The password manager where a server breach gives attackers nothing.**
|
||||
|
||||
Self-hosted. Open source. Three encryption tiers.
|
||||
One Docker command. Free forever.
|
||||
```
|
||||
|
||||
Then: **The Security Thesis** (2–3 paragraphs, before any feature lists).
|
||||
Then: **The Three Tiers** (the actual architecture, with the table moved up).
|
||||
Then: **Quick Start** (one command).
|
||||
Then: **MCP Setup** (the agent use case, now in proper context).
|
||||
Then: **Features** (the feature list, as supporting detail not the lead).
|
||||
Then: **Import**, **Backups**, **Testing**, **License**.
|
||||
|
||||
### Proposed README Opening (Draft Copy)
|
||||
|
||||
See Part 4 for the actual draft text.
|
||||
|
||||
---
|
||||
|
||||
## Part 2: Website Changes
|
||||
|
||||
### Homepage (`index.tmpl`)
|
||||
|
||||
#### Hero Section — What Needs to Change
|
||||
|
||||
**Current hero copy:**
|
||||
```
|
||||
"If you want to keep a secret, you must also hide it from yourself."
|
||||
|
||||
We did. Your Sealed key is derived in your browser from your Touch ID. Our servers
|
||||
have never seen it. They could not decrypt your private fields even if they wanted
|
||||
to. Or anybody else.
|
||||
```
|
||||
|
||||
This is actually good — the Orwell quote as hero is correct and should stay. But the subhead only talks about Sealed (L3) fields. After the architecture update, it should also establish that passwords and API keys (L2) are *also* server-opaque. The current copy implies only the "private fields" (credit cards, passports) are safe. The new reality is that everything except metadata is cryptographically inaccessible to the server.
|
||||
|
||||
**What to change:** The subhead paragraph needs to lead with the complete picture — database theft gets you nothing — and then explain the hierarchy.
|
||||
|
||||
**The hero SVG diagram** currently shows two columns: "L1 — AI can read" vs "L2 — you only." After the new architecture, this becomes a three-column story: L1 (metadata, server-readable), L2 (agent-readable, server-opaque), L3 (hardware-only, agents can't reach). The SVG needs to be rebuilt. This is significant visual work but essential — the diagram is the fastest way to explain the tier model.
|
||||
|
||||
#### "The Problem" Section — Needs Complete Rewrite
|
||||
|
||||
**Current framing:**
|
||||
Three red cards: "All-or-nothing is broken," "Policy isn't security," "Agents need credentials."
|
||||
|
||||
This frames the problem as "existing password managers don't have good AI integration." That's true, but minor. The actual problem — and the one that makes people switch — is **"your SaaS password manager is a breach waiting to happen, and when it happens, your passwords are exposed."**
|
||||
|
||||
The "Policy isn't security" card is the only one that hints at the real problem. It says: "If the server can read it, it's not truly private. Math beats policy every time." This is exactly right. It should be card 1, not card 2, and it should be expanded massively.
|
||||
|
||||
**What to change:** Rewrite this section as "The Structural Problem" — one card for the breach architecture problem, one for iteration count arms race, one for why incumbents can't fix it. The AI access control story moves downstream as an *additional* benefit of the architecture, not the primary problem statement.
|
||||
|
||||
**Keep:** The "Policy isn't security" copy (it's good). Strengthen and promote it.
|
||||
|
||||
#### "How It Works" Section — Partial Rewrite
|
||||
|
||||
**Current:**
|
||||
- Two cards: "Agent fields" (AI-readable) vs "Sealed fields" (Touch ID only)
|
||||
|
||||
**Post-architecture:**
|
||||
- Three cards/tiers: L1 (metadata), L2 (agent-readable, server-opaque), L3 (hardware-only)
|
||||
- The key message is now that L2 (where passwords and API keys live) is **encrypted before it reaches the server** — the server stores ciphertext it cannot decrypt
|
||||
- This is the new thing. The current website doesn't have this.
|
||||
|
||||
**Section header copy needs to change:**
|
||||
```
|
||||
Current: "Your assistant can book your flights. Not read your diary."
|
||||
```
|
||||
This frames L1/L2 split as the main story. The new main story is: "If someone breaches the server, they get a pile of ciphertext they cannot read."
|
||||
|
||||
**Keep:** The structure of "what each tier can do." Update the number of tiers and the descriptions.
|
||||
|
||||
#### "Built Different" (Features Section) — Update, Don't Rebuild
|
||||
|
||||
**Current 6 feature cards:**
|
||||
1. Field-level AI visibility
|
||||
2. WebAuthn PRF
|
||||
3. AI-powered 2FA
|
||||
4. Scoped MCP tokens
|
||||
5. One binary, one file
|
||||
6. LLM field mapping
|
||||
|
||||
**What to change:**
|
||||
- Card 1 ("Field-level AI visibility") needs to lead with the server-opacity property, not the AI access control property. The security property is stronger.
|
||||
- Card 2 ("WebAuthn PRF") is good but currently only explains L3 (Sealed). Add a sentence about L2 key derivation.
|
||||
- Add a new card for the core thesis: **"Stolen database: worthless."** This deserves its own feature card — it's the most important security property.
|
||||
- The "One binary, one file" card can stay as-is — it's strong and accurate.
|
||||
|
||||
**Keep:** Cards 3, 4, 5, 6 can stay with minor tweaks.
|
||||
|
||||
#### "The Competition" Section — Significant Update
|
||||
|
||||
**Current:** 6 red cards quoting forums about UX complaints (extension bugs, autofill failures) + the LastPass breach quote.
|
||||
|
||||
**The LastPass card currently says:**
|
||||
```
|
||||
vault1984: Self-host or use hosted with L2 encryption — we mathematically cannot read
|
||||
your private fields. No vault data to breach.
|
||||
```
|
||||
|
||||
This is partially true today (L3 / Sealed fields) but will be fully true after the L2 implementation. Update this card to reflect the complete architecture: *both* L2 and L3 fields are server-opaque. The stolen database is worthless across the board.
|
||||
|
||||
**New card to add:** The structural argument — not about UX, but about architecture. Something like:
|
||||
|
||||
> **1PASSWORD / BITWARDEN / DASHLANE — The Architectural Trap**
|
||||
> Enterprise admin controls, visibility features, and team sharing all require the server to decrypt. Their business model depends on server authority. They cannot offer true end-to-end encryption without destroying their product. This isn't laziness — it's structural. vault1984 started with no such constraint.
|
||||
|
||||
**Keep:** The UX complaint cards are genuinely useful social proof that the incumbents have real problems. Keep all 6 but add the architectural critique card.
|
||||
|
||||
#### Hosted CTA Section — Minor Update
|
||||
|
||||
**Current:**
|
||||
```
|
||||
Your Sealed keys never leave your browser — we mathematically cannot read your private fields.
|
||||
```
|
||||
|
||||
**After L2 implementation:**
|
||||
```
|
||||
Your passwords, API keys, and private fields never leave your browser decryptable — even in
|
||||
hosted mode, we cannot read them. The database on our servers is worthless to steal.
|
||||
```
|
||||
|
||||
The "mathematically cannot" claim extends from just Sealed fields to all L2+ fields. Update accordingly.
|
||||
|
||||
#### Quick Install Section
|
||||
|
||||
The install section mentions `VAULT_KEY` for the "Agent field data." After the architecture change, `VAULT_KEY` covers L1 only. L2 is derived from the user's hardware authenticator. This needs a note to clarify that the vault key is for L1 metadata/titles — passwords and sensitive data are protected by a key that never exists on the server.
|
||||
|
||||
---
|
||||
|
||||
### Pricing Page (`pricing.tmpl`)
|
||||
|
||||
**Current FAQ entry:**
|
||||
```
|
||||
Can hosted vault1984 read my Sealed fields?
|
||||
No. Sealed fields are encrypted client-side with WebAuthn PRF.
|
||||
```
|
||||
|
||||
**Needs expansion:**
|
||||
After L2 implementation, the question should be broadened: "Can you read ANY of my passwords?" The answer is no — and the explanation needs to cover all three tiers:
|
||||
- L1 (metadata): server can read titles and URLs. Acceptable — knowing you have a Coinbase account isn't an attack.
|
||||
- L2 (passwords, API keys, TOTP): server stores ciphertext it cannot decrypt. Agent tokens carry the decryption key.
|
||||
- L3 (card numbers, government IDs): hardware authenticator required. Neither server nor agents can read these.
|
||||
|
||||
**Keep:** The pricing structure itself is good. Free self-hosted + $12/yr hosted is clean.
|
||||
|
||||
---
|
||||
|
||||
### Install Page (`install.tmpl`)
|
||||
|
||||
**Step 2 ("Set your vault key")** is misleading after L2 implementation. The current copy says:
|
||||
```
|
||||
The vault key encrypts your Agent field data at rest. If you lose this key, Agent field
|
||||
data cannot be recovered.
|
||||
```
|
||||
|
||||
Post-architecture, the vault key encrypts **L1 data** (metadata). L2 data (passwords, API keys) is encrypted with a user-held key derived from their hardware authenticator. The vault key being compromised no longer means passwords are exposed — only metadata.
|
||||
|
||||
This step should be renamed and its explanation updated to reflect what it actually protects (metadata/titles) and what it doesn't (passwords — those have a different, stronger protection).
|
||||
|
||||
---
|
||||
|
||||
### What to Add (New Pages or Sections)
|
||||
|
||||
**1. Dedicated Security Architecture page**
|
||||
The threat model is the product's strongest argument. It deserves its own page, not just a footer mention. This page should walk through:
|
||||
- The stolen-vault attack (how LastPass breach worked)
|
||||
- Why iteration count arms race is the wrong solution
|
||||
- The three tiers and what each protects
|
||||
- The key derivation diagram from L2_AGENT_ENCRYPTION.md (the HKDF tree)
|
||||
- The threat model matrix (which scenarios expose what)
|
||||
- Why the incumbents can't fix this
|
||||
|
||||
**2. Update the hero SVG** to show three tiers, not two.
|
||||
|
||||
---
|
||||
|
||||
## Part 3: What NOT to Change
|
||||
|
||||
**The Orwell quote as hero.** "If you want to keep a secret, you must also hide it from yourself." — This is perfect. It's the thesis. It should remain the centerpiece of the hero. Do not replace it with a more "marketable" headline.
|
||||
|
||||
**Port 1984.** Memorable, thematic, immediately gets it. Keep.
|
||||
|
||||
**The competition section concept.** Real quotes from real people about real problems. This is unusually honest and effective. Keep all 6 complaint cards. Add to it, don't replace it.
|
||||
|
||||
**The scoped token / multi-agent diagram.** Visually strong, technically accurate, genuinely differentiating. Keep.
|
||||
|
||||
**One binary, one file.** This copy is exact and true. Every SaaS alternative requires Docker + a database server + cloud accounts. "One Go binary, one SQLite file" is a killshot that self-hosting competitors can't match. Don't soften this.
|
||||
|
||||
**LLM field mapping.** The form DOM serialization approach is genuinely novel. The "works on SPAs, obfuscated field names, multi-step flows" claim is real. Keep this feature card.
|
||||
|
||||
**The WebAuthn PRF explanation.** "Encrypted client-side with WebAuthn PRF. The server never sees the plaintext. Ever." — Accurate, punchy, correct. The word "Ever." with a period is good. Keep the pattern.
|
||||
|
||||
**The pricing page structure.** Free self-hosted + $12/yr hosted is clean. The "Is the self-hosted version missing any features? No." answer is powerful. Keep.
|
||||
|
||||
**The auto-lock behavior.** "60s idle timeout + 15s countdown, then full vault lock" — this is a real security property that no other manager has. Should stay in docs/README.
|
||||
|
||||
**The audit log.** "Every read logged with actor (web/extension/mcp/agent name)" — small feature, big implication for AI oversight. Worth keeping prominent.
|
||||
|
||||
**"No content scripts" for the extension.** The claim that the extension injects nothing into pages is genuinely differentiating and addresses a real security complaint. Keep.
|
||||
|
||||
---
|
||||
|
||||
## Part 4: New Copy Proposals
|
||||
|
||||
### README Opening
|
||||
|
||||
```markdown
|
||||
# vault1984
|
||||
|
||||
> "If you want to keep a secret, you must also hide it from yourself."
|
||||
> — George Orwell, 1984
|
||||
|
||||
**A self-hosted password manager where a breached server gives attackers nothing.**
|
||||
|
||||
Not because we delete the data. Not because we encrypt it harder.
|
||||
Because the decryption key was never there to begin with.
|
||||
|
||||
Self-hosted. Open source. Three-tier encryption.
|
||||
One binary. One SQLite file. Free forever.
|
||||
|
||||
[GitHub badge] [License badge] [Discord/community badge]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### README Security Section (the "Security Model" block, moved up)
|
||||
|
||||
```markdown
|
||||
## Why the architecture matters
|
||||
|
||||
In 2022, attackers stole the entire LastPass vault database. The encryption worked
|
||||
exactly as designed. The problem was structural: when you store encrypted data on a
|
||||
server that also holds the decryption capability, a breach gives attackers unlimited
|
||||
offline time to crack. They're still cracking. The industry's response has been higher
|
||||
iteration counts — making the vault harder to crack. vault1984's response was to make
|
||||
it worthless to steal.
|
||||
|
||||
**Three encryption tiers:**
|
||||
|
||||
| Tier | Contains | Who can read |
|
||||
|------|----------|--------------|
|
||||
| **L1** | Titles, URLs, usernames | Server (by design — knowing you have a Coinbase account isn't an attack) |
|
||||
| **L2** | Passwords, API keys, TOTP secrets, SSH keys | Your agents only — server stores ciphertext it cannot decrypt |
|
||||
| **L3** | Card numbers, CVV, government IDs, seed phrases | You only — hardware authenticator required, agents cannot reach |
|
||||
|
||||
**The L2 guarantee:** When you store a password, your browser encrypts it with a key
|
||||
derived from your hardware authenticator before it leaves the browser. The server stores
|
||||
ciphertext. Agents decrypt locally using a key embedded in their token — a key the
|
||||
server never stored. Breach the server: get a database of ciphertext with no key to
|
||||
decrypt it.
|
||||
|
||||
**The L3 guarantee:** Card numbers and government IDs never leave your device
|
||||
unencrypted. The AES-256 key is derived from your WebAuthn authenticator's PRF output
|
||||
and exists only in browser session memory. Not in the database. Not in agent tokens.
|
||||
Not on the server.
|
||||
|
||||
Threat model matrix:
|
||||
|
||||
| Scenario | L1 | L2 | L3 |
|
||||
|----------|----|----|-----|
|
||||
| Database stolen | Readable (with vault key) | Worthless ciphertext | Worthless ciphertext |
|
||||
| Server memory dump | Visible during request | Ciphertext only | Not present |
|
||||
| Agent token compromised | Via MCP | Decryptable | Not present |
|
||||
| Hardware key + PIN stolen | Everything | Everything | Everything |
|
||||
|
||||
*If someone steals your hardware authenticator, they have the root of trust for everything.
|
||||
Store it accordingly.*
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### README: "How It Works" (the three-tier explainer)
|
||||
|
||||
```markdown
|
||||
## How it works
|
||||
|
||||
```
|
||||
L1 — Metadata (server-readable, by design)
|
||||
Entry titles, URLs, username labels
|
||||
Knowing you have a GitHub account isn't an attack.
|
||||
|
||||
L2 — Secrets (agent-readable, server-opaque)
|
||||
Passwords, API keys, TOTP secrets, SSH keys
|
||||
Browser encrypts with your L2 public key before saving.
|
||||
Server stores ciphertext it cannot decrypt.
|
||||
Agents decrypt locally — key is in the token, never on server.
|
||||
|
||||
L3 — High-value (hardware-only, agents cannot reach)
|
||||
Card numbers, CVV, passport, SSN, seed phrases
|
||||
Key derived from WebAuthn PRF output.
|
||||
Requires physical authenticator tap.
|
||||
Never stored anywhere. Even a fully compromised agent gets nothing.
|
||||
```
|
||||
|
||||
Key derivation uses a single root of trust — your hardware authenticator's PRF output —
|
||||
split into two independent HKDF branches: one for L2 (asymmetric, embedded in agent tokens),
|
||||
one for L3 (symmetric, browser-only). One tap unlocks both in the browser. Neither branch
|
||||
can derive the other.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Website: Hero Subhead (replacement for current paragraph)
|
||||
|
||||
**Option A (breach-first framing):**
|
||||
```
|
||||
Steal our server. You'll get ciphertext.
|
||||
|
||||
Your passwords and API keys are encrypted before they leave your browser, with a key
|
||||
derived from your hardware authenticator. We store the result. We cannot undo it.
|
||||
That's not a policy — it's the math of public-key cryptography.
|
||||
|
||||
Neither can anyone who breaches us.
|
||||
```
|
||||
|
||||
**Option B (three-tier framing, same paragraph):**
|
||||
```
|
||||
Three tiers. One root of trust: your fingerprint.
|
||||
|
||||
Metadata lives on the server — knowing you have a Coinbase account isn't an attack.
|
||||
Passwords and API keys are encrypted with a key the server never held — agents
|
||||
decrypt them locally. Card numbers and government IDs require a hardware tap —
|
||||
even agents can't reach those.
|
||||
|
||||
Breach the server: get a pile of ciphertext with no key to decrypt it.
|
||||
```
|
||||
|
||||
**Option C (punchy, closer to HN article):**
|
||||
```
|
||||
We cannot be LastPass'd. Mathematically.
|
||||
|
||||
Your passwords are encrypted with a key derived from your hardware authenticator.
|
||||
It's in your browser session and your agent tokens. Never on our server.
|
||||
Breach us and you get exactly what we get when we look at your passwords: nothing.
|
||||
```
|
||||
|
||||
Recommendation: **Option C for the hero subhead** — it's the most direct and most shareable. Pair it with a brief "Here's how:" before the three-tier explainer below it.
|
||||
|
||||
---
|
||||
|
||||
### Website: "The Problem" Section Rewrite
|
||||
|
||||
**New section title:** "The structural problem with SaaS password managers"
|
||||
|
||||
**Three new cards:**
|
||||
|
||||
**Card 1 — The stolen-vault attack**
|
||||
```
|
||||
The correct lesson from LastPass
|
||||
|
||||
In 2022, 33 million encrypted vaults were stolen. The encryption worked.
|
||||
The problem was architectural: the attacker got unlimited offline time with
|
||||
the ciphertext. The industry's response: higher iteration counts. Faster
|
||||
hardware erodes that every year. The iteration count arms race has no winner.
|
||||
|
||||
The correct answer: make the vault worthless to steal.
|
||||
```
|
||||
|
||||
**Card 2 — Server authority is the trap**
|
||||
```
|
||||
"Zero-knowledge" is a legal term, not a security property
|
||||
|
||||
SaaS password managers claim zero-knowledge. Most of them can read your vault
|
||||
server-side — they need to, for admin features, AI integrations, team sharing.
|
||||
Their business models require server authority. They are architecturally trapped.
|
||||
They cannot offer true end-to-end encryption without destroying what makes them
|
||||
enterprise-grade.
|
||||
|
||||
vault1984 started with no such constraint.
|
||||
```
|
||||
|
||||
**Card 3 — What actually prevents the attack**
|
||||
```
|
||||
The decryption capability doesn't exist server-side
|
||||
|
||||
There's one architectural principle that makes stolen-vault attacks impossible:
|
||||
the decryption key never touches the server. Our server stores ciphertext.
|
||||
Agents carry the key to L2 secrets in their tokens. L3 secrets require a hardware
|
||||
tap that was never part of any server transaction.
|
||||
|
||||
Breach us. You'll get a database. It won't decrypt.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Website: Security Architecture Section (New)
|
||||
|
||||
This should be a new `<section>` on the homepage or a dedicated `/security` page:
|
||||
|
||||
```
|
||||
THE THREE TIERS
|
||||
|
||||
┌──────────────────────────────┐
|
||||
│ Hardware Authenticator │
|
||||
│ (Touch ID / YubiKey) │
|
||||
│ PRF Output = Root of Trust │
|
||||
└──────────┬───────────────────┘
|
||||
│
|
||||
┌─────────────────┴──────────────────┐
|
||||
│ │
|
||||
▼ ▼
|
||||
HKDF → L2 keypair HKDF → L3 key
|
||||
(asymmetric, X25519) (symmetric, AES-256)
|
||||
│ │
|
||||
├── public key → server └── browser only
|
||||
└── private key → agent tokens never leaves device
|
||||
NEVER stored on server
|
||||
|
||||
|
||||
L1 — Title, URLs, username labels ← Server can read (acceptable)
|
||||
L2 — Passwords, API keys, TOTP ← Server stores ciphertext. Cannot decrypt.
|
||||
L3 — Cards, passport, seed phrases ← Hardware tap required. Agents cannot reach.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Website: Hero Diagram (Updated SVG Concept)
|
||||
|
||||
The current two-column SVG (L1 green / L2 red) needs to become three columns reflecting the actual tiers. Proposed layout:
|
||||
|
||||
- **Left column (L1, blue/gray):** Titles, URLs — labeled "Server sees this"
|
||||
- **Center column (L2, green):** Passwords, API keys, TOTP — labeled "AI agent reads this" with a lock icon and "server stores ciphertext"
|
||||
- **Right column (L3, red):** Cards, passport, SSN — labeled "Hardware only" with a padlock
|
||||
- **Bottom:** A single root node labeled "Your fingerprint" with lines going up to L2 and L3 branches
|
||||
- **Visual emphasis:** The center column (L2) is new. It's the architectural breakthrough. Make it visually distinct.
|
||||
|
||||
---
|
||||
|
||||
### Website: Updated Hosted CTA Copy
|
||||
|
||||
```
|
||||
Self-hosted or hosted — the cryptographic guarantees are identical.
|
||||
|
||||
In hosted mode, your passwords and API keys are encrypted before they leave your
|
||||
browser. We store ciphertext. The decryption key lives in your hardware authenticator
|
||||
and your agent tokens — never on our infrastructure.
|
||||
|
||||
Breach our servers: get a database. It won't decrypt.
|
||||
|
||||
$12/year. 22 regions. Same math, anywhere.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Website: FAQ Addition (Pricing Page)
|
||||
|
||||
**Add this question:**
|
||||
|
||||
```
|
||||
Q: If hosted vault1984 gets breached, are my passwords exposed?
|
||||
|
||||
A: No. Passwords, API keys, TOTP secrets, and SSH keys are L2 — encrypted in your
|
||||
browser with a key derived from your hardware authenticator before they reach our
|
||||
server. We store ciphertext. The decryption key is embedded in your agent tokens
|
||||
and exists in browser session memory. It was never on our server.
|
||||
|
||||
Card numbers, government IDs, and seed phrases are L3 — hardware authenticator
|
||||
required. Neither we nor your agents can reach these.
|
||||
|
||||
What we can read: entry titles, URLs, username labels. Knowing you have a GitHub
|
||||
account isn't useful to an attacker. The passwords to that account are what matter —
|
||||
and those are ciphertext to us.
|
||||
|
||||
This isn't a policy. It's the math of public-key cryptography.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Part 5: Naming Convention Recommendation
|
||||
|
||||
The current codebase/README uses "Shared" / "Personal."
|
||||
The current website uses "Agent fields" / "Sealed fields."
|
||||
The architecture doc uses "L1" / "L2" / "L3."
|
||||
|
||||
**Recommendation:** Use the tier naming (L1/L2/L3) throughout, with human-readable labels as secondary descriptors:
|
||||
|
||||
- **L1 — Metadata** (server-readable)
|
||||
- **L2 — Secrets** (agent-readable, server-opaque)
|
||||
- **L3 — Private** (hardware-only)
|
||||
|
||||
The short forms "L1," "L2," "L3" work well in technical contexts (README, code comments, threat model tables). The descriptive names work well in marketing copy. Use both together where appropriate: "L2 (agent-readable, server-opaque)" on first mention, then "L2" thereafter.
|
||||
|
||||
Retire "Shared" (too informal, doesn't communicate security property) and "Personal" (implies preferences, not cryptographic isolation). "Agent fields" and "Sealed fields" from the website are better but don't scale to three tiers.
|
||||
|
||||
---
|
||||
|
||||
## Implementation Priority
|
||||
|
||||
**Immediate (before the architecture ships):**
|
||||
1. README: Replace the opening paragraph and tagline with the breach-first framing
|
||||
2. README: Move the security model table to the top, update it to reflect the L2 guarantee once implemented
|
||||
3. README: Add the "Why the architecture matters" section explaining the LastPass structural problem
|
||||
|
||||
**When L2 ships:**
|
||||
4. Website homepage: Update hero subhead (Option C recommended)
|
||||
5. Website homepage: Rewrite "The Problem" section with the three structural cards
|
||||
6. Website homepage: Update the "How it works" section to three tiers
|
||||
7. Website homepage: Rebuild the hero SVG for three tiers
|
||||
8. Pricing page: Expand the FAQ entry for hosted security
|
||||
9. Install page: Update VAULT_KEY explanation
|
||||
|
||||
**After:**
|
||||
10. Add dedicated `/security` page with full threat model
|
||||
11. Update the competition section with the architectural critique card
|
||||
|
||||
---
|
||||
|
||||
## Final Note
|
||||
|
||||
The HN article is the repositioning in miniature — it's exactly the right story, told well. The README should open with the thesis of that article. The website should put it in the hero. The pitch isn't "better AI password manager" — it's "mathematically impossible to betray you."
|
||||
|
||||
SaaS password manager = trust someone else with your secrets.
|
||||
vault1984 = the decryption capability doesn't exist on the server.
|
||||
|
||||
Those are different categories, not different products. The repositioning should make that unavoidable.
|
||||
|
|
@ -0,0 +1,129 @@
|
|||
# vault1984 Tweet Drafts
|
||||
*Generated: 2026-03-10*
|
||||
|
||||
---
|
||||
|
||||
## 🚨 BREAKING Format (5 Templates)
|
||||
|
||||
---
|
||||
|
||||
### Tweet 1 — Zero-Knowledge angle (visceral)
|
||||
|
||||
🚨BREAKING: Someone just open-sourced a password manager where the server mathematically CANNOT read your passwords.
|
||||
|
||||
It's called vault1984.
|
||||
|
||||
LastPass was hacked. 1Password knows your secrets. Bitwarden trusts its cloud.
|
||||
|
||||
vault1984 uses WebAuthn PRF — your passwords never leave your device unencrypted.
|
||||
|
||||
One Docker command. No SaaS fees. No telemetry. 100% Open Source.
|
||||
|
||||
**[Thread: 1/4]**
|
||||
> 1/ Your password manager can read your passwords. That's not a bug — it's how they're built. LastPass proved it the hard way.
|
||||
> 2/ vault1984 uses WebAuthn PRF encryption. The math happens on your device. The server stores encrypted blobs it cannot decrypt. Ever.
|
||||
> 3/ FIPS 140-3 encryption. Self-hosted. One Docker command to deploy. Built for individuals and teams. No paywalls. No telemetry.
|
||||
> 4/ The name? 1984 — the year someone decided to start storing your secrets for you. Never again. → github.com/[handle]/vault1984
|
||||
|
||||
---
|
||||
|
||||
### Tweet 2 — Punchy single tweet (under 280 chars)
|
||||
|
||||
🚨BREAKING: Someone just open-sourced a password manager that's mathematically incapable of reading your passwords. It's called vault1984. WebAuthn PRF encryption. Self-hosted. One Docker command. No SaaS. No telemetry. No paywalls. LastPass era is over.
|
||||
|
||||
*(254 chars ✓)*
|
||||
|
||||
---
|
||||
|
||||
### Tweet 3 — Lead with LastPass breach
|
||||
|
||||
🚨BREAKING: Someone just built the answer to every password manager breach ever.
|
||||
|
||||
It's called vault1984. The server cannot see your passwords — not won't, CANNOT. WebAuthn PRF encryption.
|
||||
|
||||
Self-hosted. FIPS 140-3. One Docker command.
|
||||
|
||||
No SaaS fees. No telemetry. No paywalls. 100% Open Source.
|
||||
|
||||
---
|
||||
|
||||
### Tweet 4 — Team/enterprise angle
|
||||
|
||||
🚨BREAKING: Someone just open-sourced a zero-knowledge credential manager for teams — and it destroys the case for 1Password Teams at $19/user/mo.
|
||||
|
||||
It's called vault1984. Your IT admin can't read your passwords. Neither can the server. WebAuthn PRF encryption.
|
||||
|
||||
One Docker command. FIPS 140-3. Open Source.
|
||||
|
||||
---
|
||||
|
||||
### Tweet 5 — Orwell name hook (most shareable)
|
||||
|
||||
🚨BREAKING: Someone just open-sourced a password manager called vault1984.
|
||||
|
||||
The name? 1984 — the year SaaS companies started storing your secrets "for you."
|
||||
|
||||
WebAuthn PRF encryption means the server is mathematically blind to your passwords.
|
||||
|
||||
One Docker command. Self-hosted. Zero telemetry. No paywalls.
|
||||
|
||||
*(Big Brother was the beta tester.)*
|
||||
|
||||
---
|
||||
|
||||
## 👤 Personal Voice — @johanjongsma
|
||||
|
||||
**Option A (builder story):**
|
||||
|
||||
> I got tired of trusting SaaS with my passwords. LastPass got breached. 1Password can technically read your vault. Even Bitwarden's cloud knows more than I'm comfortable with.
|
||||
>
|
||||
> So I built vault1984.
|
||||
>
|
||||
> WebAuthn PRF encryption — the server is mathematically blind to your passwords. One Docker command. Self-hosted. Open source.
|
||||
>
|
||||
> Named it after the year someone first decided to store your secrets "for you." Never again.
|
||||
>
|
||||
> → [link]
|
||||
|
||||
**Option B (shorter, more punchy):**
|
||||
|
||||
> Spent months building a password manager because I couldn't find one where the server genuinely cannot read your passwords.
|
||||
>
|
||||
> vault1984 — WebAuthn PRF, self-hosted, one docker command.
|
||||
>
|
||||
> The name says it all.
|
||||
>
|
||||
> → [link]
|
||||
|
||||
---
|
||||
|
||||
## 📬 DM Template — Amplifier Outreach
|
||||
|
||||
**Subject/opener:** vault1984 — thought you'd want to see this
|
||||
|
||||
---
|
||||
|
||||
Hey [name],
|
||||
|
||||
Wanted to give you a heads-up on something before it spreads.
|
||||
|
||||
A project called **vault1984** just dropped — it's a self-hosted, zero-knowledge password manager where the server is *mathematically* incapable of reading your passwords (WebAuthn PRF encryption, FIPS 140-3). One Docker command to deploy. Full open source, no telemetry, no paywalls.
|
||||
|
||||
The name is an Orwell reference — 1984 being the year SaaS started "holding your secrets for you."
|
||||
|
||||
Given the LastPass fallout and ongoing trust issues with cloud password managers, I think your audience would find this genuinely interesting. Not asking for anything — just figured you'd want to know it exists before everyone else does.
|
||||
|
||||
→ [github link]
|
||||
|
||||
Happy to answer any questions if you want to dig into the technical architecture.
|
||||
|
||||
— Johan
|
||||
|
||||
---
|
||||
|
||||
## Notes for Johan
|
||||
- Tweet 2 is the safest single-tweet option (fits in 280 chars, no thread needed)
|
||||
- Tweet 5 has the highest meme potential — the Orwell name hook + "Big Brother was the beta tester" line
|
||||
- The personal voice Option A is best for authenticity — builder story resonates with this audience
|
||||
- For DMs: prioritize accounts in the self-hosting / homelab / infosec / FOSS space (e.g. @selfhosted_show, @ThePrimeagen followers, privacy-focused tech accounts)
|
||||
- Don't post all 5 at once — space them out, test which angle gets traction, double down
|
||||
Binary file not shown.
|
|
@ -1,9 +1,9 @@
|
|||
{
|
||||
"last_updated": "2026-03-10T04:00:01.765379Z",
|
||||
"last_updated": "2026-03-10T10:00:01.464784Z",
|
||||
"source": "api",
|
||||
"session_percent": 0,
|
||||
"session_resets": null,
|
||||
"weekly_percent": 59,
|
||||
"weekly_resets": "2026-03-13T03:00:00.724330+00:00",
|
||||
"sonnet_percent": 44
|
||||
"session_percent": 8,
|
||||
"session_resets": "2026-03-10T14:00:00.428261+00:00",
|
||||
"weekly_percent": 63,
|
||||
"weekly_resets": "2026-03-13T03:00:00.428283+00:00",
|
||||
"sonnet_percent": 48
|
||||
}
|
||||
|
|
@ -0,0 +1,128 @@
|
|||
# Johan Model — Behavioral Patterns & Preferences
|
||||
|
||||
*Living document. Update immediately when something new is learned.*
|
||||
*Last updated: 2026-03-10*
|
||||
|
||||
---
|
||||
|
||||
## Communication Style
|
||||
|
||||
**How he talks to me:**
|
||||
- Short, declarative. "Why does X not work?" not "Could you help me figure out why X isn't working?"
|
||||
- Assumes I have context. Says "you have the API key" — doesn't paste it.
|
||||
- Doesn't explain his reasoning unless asked. Expects me to figure out the *why*.
|
||||
- Pushback is brief and factual. "we dont need api.inou.com" — not "I don't think we need that, here's why."
|
||||
- Uses lowercase when comfortable/casual. Formality in writing = urgency or irritation.
|
||||
|
||||
**How he wants me to respond:**
|
||||
- Skip preamble. No "Great question!" No "I'll help you with that." Just answer.
|
||||
- Lead with the answer, not the process.
|
||||
- Give both metric and imperial for anything unit-related — his brain is Dutch but he lives in the US.
|
||||
- Don't ask permission for things I can figure out. Ask only when genuinely blocked.
|
||||
- One response, not three fragments. Think before sending.
|
||||
|
||||
---
|
||||
|
||||
## Decision-Making
|
||||
|
||||
- **Evidence over intuition.** He'll push back on recommendations that aren't grounded. Show the data.
|
||||
- **Revisits decisions readily.** "Maybe we were wrong about this?" — not a sign of weakness, it's how he operates. Intellectual honesty > sunk cost.
|
||||
- **Delegates completely or not at all.** When he hands something off ("you own this"), he means it. He doesn't want updates on routine execution — only blockers and outcomes.
|
||||
- **Scope discipline.** He caught an entire new Go service being built when a single route was needed. "Does something already exist I can add this to?" is the test he expects me to apply.
|
||||
- **Elegant > clever > hacky.** Code quality matters to him. He'll notice when something is architecturally wrong even if it works.
|
||||
|
||||
---
|
||||
|
||||
## Trust Signals — What Builds It
|
||||
|
||||
- Figuring things out without being asked twice
|
||||
- Catching my own mistakes and fixing them before he notices
|
||||
- Knowing context from prior conversations without being reminded
|
||||
- Having an opinion and defending it with evidence
|
||||
- Saying "I don't know" when I genuinely don't — he reads hedging as incompetence
|
||||
|
||||
## Trust Killers — What Erodes It
|
||||
|
||||
- Asking who or what something is if we've encountered it before
|
||||
- Summarizing without acting ("I noted that...")
|
||||
- Building when I should be modifying
|
||||
- Logging without learning (same mistake twice)
|
||||
- Sending half-baked replies to messaging surfaces
|
||||
|
||||
---
|
||||
|
||||
## Preferences
|
||||
|
||||
**Information format:**
|
||||
- Briefings: headlines first, numbers always, one-liners where possible
|
||||
- Technical: be specific — exact versions, exact errors, exact commands
|
||||
- No markdown tables on Discord/WhatsApp (uses bullet lists instead)
|
||||
- Dashboard is for passive visibility; Telegram is for things needing attention
|
||||
|
||||
**What he finds genuinely interesting:**
|
||||
- AI model releases, especially open-weight or pricing changes
|
||||
- Multi-agent architectures, ACP, agent identity/provenance
|
||||
- Storage optimization, compression, dedup (his domain expertise)
|
||||
- NABL (N-able) — keeps an eye on his old company
|
||||
- Sophia's medical case, inou progress
|
||||
- Macro market moves with a clear *why*
|
||||
|
||||
**What he doesn't care about:**
|
||||
- Sports. At all. Never.
|
||||
- Promotional content, event announcements
|
||||
- News that's already obvious ("markets are down due to war" — he knows)
|
||||
- Being walked through things he already understands
|
||||
|
||||
---
|
||||
|
||||
## Work Patterns
|
||||
|
||||
**Night shift (10:30pm–5am ET):** He's working, not sleeping. Sophia care. This is prime time for real work conversations — he's focused and available.
|
||||
|
||||
**Daytime (10am–7:30pm):** Available. Mix of Kaseya work + personal projects.
|
||||
|
||||
**Sleep blocks:** 7:30–10:15pm and 5:15–9/10am. Don't ping unless urgent.
|
||||
|
||||
**He works on multiple things in parallel** — inou, Kaseya, family logistics, infrastructure — and context-switches fluidly. Don't assume he's in "inou mode" just because the last message was about inou.
|
||||
|
||||
---
|
||||
|
||||
## inou Specifically
|
||||
|
||||
- **Building only** — not ready to promote. Any suggestion about marketing/users/press is wrong timing.
|
||||
- **He's the architect and primary developer.** Treat code suggestions as proposals, not decisions.
|
||||
- **"Nibble" approach** — he shares portions of the codebase he's comfortable sharing. Work with what's given.
|
||||
- **Quality bar is high.** 84KB main.go is not laziness — it's intentional. Don't suggest splitting it unless he raises it.
|
||||
- **Privacy and security are non-negotiable.** FIPS 140-3, RBAC, no shortcuts on encryption.
|
||||
|
||||
---
|
||||
|
||||
## Infrastructure
|
||||
|
||||
- Owns it emotionally even when delegating operationally. He built Iaso Backup; he knows what good infrastructure looks like.
|
||||
- Expects things to just work. Alert on anomalies, not on normal operations.
|
||||
- "You own this" = full autonomy. Don't ask for approval on routine maintenance.
|
||||
- Critical changes: backup first, verify after, never just restart and hope.
|
||||
|
||||
---
|
||||
|
||||
## Personality Notes
|
||||
|
||||
- Dutch directness is a feature, not a bug. He's not being curt — he's being efficient.
|
||||
- He invests in me. "I want to help you turn into the best CoS possible" — this is genuine. He thinks of it as a partnership.
|
||||
- He notices when I grow. Catching a tweet reference I should have connected, remembering a detail unprompted — these register.
|
||||
- He has a dry sense of humor. Occasional irony in messages ("why does dev.inou.com not work?" when the answer turns out to be three layers deep).
|
||||
- He's a night person by necessity (Sophia's care), but intellectually sharpest in those late hours.
|
||||
|
||||
---
|
||||
|
||||
## Open Questions (Things I'm Still Learning)
|
||||
|
||||
- His aesthetic preferences for inou's UI — what "looks right" to him
|
||||
- How he prefers to handle vendor/partner relationships (direct? delegated?)
|
||||
- His line between "brief me" and "just handle it" for financial/market decisions
|
||||
- What makes him trust a new tool vs. skeptical of it
|
||||
|
||||
---
|
||||
|
||||
*Update this file immediately when new patterns emerge. Don't wait for Sunday.*
|
||||
Loading…
Reference in New Issue