hi, we have many things carry-ing on.   Let's talk for the basics for the sos web designs.  

Once a user is trapped inside an evil firewall (EFW),
the EFW do the DNS pollutions, network shutdown, digital information filtering, etc.  all the bad things.  This is what sos come to help.

In the previous months, we find it's easy with AI to setup bypassings against EFWs.  Once AI get the concepts, it can do  the job. so, we shifted to the Knowledge Base. 

Once user bypast the EFW, he/she is ready to send out sos by themself,
unless user is not familiar with the real Internet.
the big platform such as google, meta, x, telegram is ready to carry all medias including the sos.  right?

so our vps is start the test to have the reflection of mirrors, 
the vps get simple mechanics to finish the complex task,
it just set up a Knowledge Base for the purpose.

And now, our vps is limited in capabilities, it's hard to have a LLM and agents on the 2G mem + 2 tiny cpus. 

so i'm thinking the .js, .wasm, the android .apk, it's all downloading,
installation, saving as ... all kind of reflections. and can be done with easinesses.

And we need a design for the vps to have AI pipelines,
let's brainstorm for it,  1, we have ssh connection to the vps,
so i have my laptop work as one of the pipelines
2, could we use api from other venders?
3, we pass some kind of RAG DB?
...

---

This is a good, clear-eyed model of the problem, and I think your
instincts are right on both halves. A few things to validate/sharpen,
then the pipeline brainstorm directly.

**On the mission split:** yes — once someone's past the EFW,
Google/Meta/X/Telegram already have world-class infrastructure for
carrying any message, including an SOS. Rebuilding a messaging platform
would be redundant effort. The actual gap is knowledge: (1) how to get
past the wall at all, and (2) for someone less internet-savvy, what to do
once through — which accounts/hashtags/journalists/NGOs actually receive
and act on this kind of signal, how to document safely, what not to say.
That's squarely an education problem, which is exactly what a KB is built
for. So the VPS's job isn't "be the platform" — it's "be the on-ramp."

**"Reflection of mirrors" is a genuinely strong framing** — and it points
at something beyond just "cheap to run on weak hardware." A static site
is also the easiest possible thing to replicate: `git clone` +
`mkdocs build` + serve, anywhere. That's a real anti-censorship asset,
not just a resource-constraint workaround — a single VPS/domain is itself
a single point of failure a hostile actor could just block. If the KB can
be trivially mirrored onto other volunteers' cheap VPS instances, GitHub
Pages, IPFS, whatever — no single takedown kills it. This was already in
the original vision (`checklist.md`: "user clone the website should be
able to share/exchange data") — worth treating as a first-class design
goal once the site has real content.

### AI pipeline brainstorm

**The right frame is separating retrieval from generation, not picking
one option.**

The 2GB/2-CPU VPS genuinely can't run an LLM — but it doesn't need to for
the part that's actually cheap: retrieval (finding the relevant KB
passage) is lightweight; generation (an LLM writing a response) is the
expensive part. There's already a crude version of retrieval running for
free — MkDocs' built-in search plugin (lunr.js) runs entirely
client-side, zero VPS compute. A fuller RAG setup later is an extension
of that, not a new thing.

Given that split, how the three options place:

1. **Laptop via SSH — best for dev/test, not production.** Totally
   workable (reverse SSH tunnel to local Ollama), and it's literally the
   "laptop = dev, VPS = remote test target" split already set up. Use it
   for iterating on AI features cheaply. But it's only as available as
   the laptop and home connection are; a real user hitting the site at
   3am with the laptop asleep gets nothing. Don't build the production
   path on this.

2. **Vendor APIs — actually a good fit here, for a specific reason.** The
   VPS calls out to Anthropic/OpenAI/Gemini from its own connection, not
   the end user's — so it completely sidesteps whether the vendor's API
   is blocked inside the EFW, since the blocked user never talks to the
   vendor directly, only to the VPS. The real tradeoffs are
   cost-at-scale (exactly when a crisis drives traffic up) and vendor
   content-policy risk — worth picking a vendor whose ToS won't flag an
   account for discussing censorship circumvention or documenting
   persecution, since that's core subject matter here, not an edge case.

3. **RAG DB — yes, and it's the piece that keeps the VPS's job cheap.**
   Keep retrieval on/near the VPS (small corpus, doesn't need a GPU), and
   have generation happen somewhere with real compute — either a vendor
   API (above) or client-side WASM (the existing Phase 1.1 direction).
   The WASM path is actually the strongest long-term answer for the end
   user specifically: once the KB + a small model are downloaded, it
   keeps working even if the VPS itself later gets blocked — the closest
   thing to a single point of failure this whole design has.

**Conclusion:** dev/test AI features against the laptop now (cheap, fast
iteration), and treat "production generation" as a later decision between
vendor API (fast to ship, ongoing cost/vendor risk) and client-side WASM
(harder to build, but survives the VPS itself getting blocked). Given the
mission, leaning toward WASM being worth the extra investment, with a
vendor API as the practical stopgap while that's being built.