A Web Version of Pod

[aaronmallen]

Summary

Ship a hosted version of Pod that runs in the browser. Users pay a monthly fee in ISK, which FC's license allows. The desktop app stays free, stays local, and keeps working with no account. Data that isn't tied to a character, such as market prices, moves to a shared service that both versions can read.

Motivation

Pod today is a desktop app with a local database. That design has two costs.

First, users can only reach their data from the machine that holds it. A browser tab at work, a phone during a fleet, or a second laptop are all out of reach.

Second, every install fetches and stores its own copy of data that isn't character-specific. Market prices and SDE lookups are the same for everyone, yet each machine pays for them in ESI traffic and disk.

A web version fixes both. It also lets a server poll ESI around the clock, so outbid alerts, structure attacks, and expiring orders could reach users even when they have nothing open. An ISK subscription gates access to the hosted version, and FC's license allows it. One thing it does not do: ISK cannot pay a hosting bill, so real-world costs stay ours. The Unresolved Questions section returns to this.

We would serve three kinds of users:

1. Desktop only. Today's users. Nothing changes for them. No account, no fee, data stays on their machine.
2. Web only. They log in from a browser. All their data, including ESI tokens, lives on our servers.
3. Web and desktop. They use both and expect to see the same state in both places. This is the hardest group to serve well.

Goals

• Offer a hosted, browser-based Pod for a monthly ISK fee.
• Keep the desktop app free, local, and usable without an account.
• Serve all three user groups without degrading the first.
• Store shared, non-character data once and serve it to everyone.
• Share one core between the desktop and web frontends so features land in both.

Non-Goals

• Replacing the desktop app. It remains a first-class product.
• Requiring an account for desktop use, now or later.
• Offline desktop use with full write access for web-and-desktop users. The proposed sync model gives that up on purpose; see below.
• A mobile app. The web version should work in a phone browser, but a native app is out of scope.

Proposed Design

Phase one: shared data service

Before accounts or billing exist, stand up a public read-only service for prices and other non-character data, and have the desktop app consume it. We already run a Cloudflare worker for telemetry, so we have done this at a small scale. This phase delivers one of the two stated wins, teaches us what running a service for Pod users costs, and requires no accounts, no billing, and no sync.

Phase two: accounts and the hosted app

• Accounts and billing. Sign-up, password resets, cancellation, and ISK payment tracking. Payment is an ISK transfer to a designated in-game wallet, and we can verify it from the wallet journal through ESI, the same data Pod already reads, so billing can be automatic. Refunds are ISK sent back. This is a customer relationship, not only code.
• Token service. A server that holds ESI refresh tokens and polls on behalf of users. Tokens are encrypted at rest, and we write down the breach response and revocation story before the first token arrives.
• Storage. Per-user server-side storage, probably Postgres, plus an importer for an existing local SQLite database so desktop users can bring their history with them.
• Web UI. iced targets the desktop; its browser support is not something I would ship. This means a second frontend over a shared Rust core. Whether that frontend is a fresh web UI or the core compiled to WASM with a thin view layer is an open question below.

Sync model

The journal is the source of truth, and sync means two writers against it. Proposed: for paying users the server owns the data and the desktop app becomes a client of it. One writer, no merge protocol. The cost is that web-and-desktop users lose offline desktop writes, which the Non-Goals section states openly. Desktop-only users are untouched; their app never talks to our servers.

Background work

Because the server holds tokens and polls ESI, it can act while the user is away: outbid alerts, structure attack notices, expiring orders, delivered by mail or push. Paying users get monitoring around the clock instead of only while the app runs.

Alternatives Considered

Do nothing. Desktop-only Pod works and costs us almost nothing to run. But both motivating problems stay unsolved, and the project has no income.

Full merge sync. A protocol that lets desktop and web both write while offline, then reconciles. It preserves offline use for the paying group, but it is far more expensive to build and to trust, and every bug corrupts financial history. We can revisit it later if one-writer sync proves too limiting.

Compile the existing iced app to WASM. Attractive because it is one UI, but iced's browser output today is not something we would put in front of paying customers. Kept as an open question rather than the plan.

A real-money subscription. It would pay the hosting bill directly, but FC's license restricts charging real money, and it brings card processing, taxes, and chargebacks with it. ISK avoids all of that, at the cost of not covering real-world expenses.

Donations instead of a subscription. No payment tracking at all, but donations gate nothing, so they cannot define who gets an account.

Unresolved Questions

• What's the monthly ISK price?
• Do free desktop users get the hosted shared data, and at whose cost?
• Where does user data live, and what do we promise about export and deletion?

Future Possibilities

• A real merge protocol, restoring offline desktop writes for paying users.
• Push notifications to phones once the background workers exist.
• A native mobile app on top of the same server API.
• Server-side features that need long history, such as year-in-review summaries.

[Reuhania]

How about self-host web version?
Self-hosted web version of Pod can solve data issues.

[aaronmallen]

I'm not sure I want to take on the burden of explaining to users how to setup a self hosted version tbh.

[aaronmallen]

I've slept on this a bit and actually this is a forth use case I might be interested in supporting.

[Reuhania]

Maybe one well-made docker image and compose file can replace(not fully but significantly) detailed how-to setup.

Other problem is advanced setup like reverse proxy but you can leave it in non-supported(DIY) area.