Bellsworne/SessionZero-Client
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

update readme.md

Browse Source
This commit is contained in:
Chris Bell 2025-10-16 13:40:37 -05:00
parent 07b1f7e5fd
commit ca5057a9f7
1 changed files with 25 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
readme.md
View File

@ -92,6 +92,31 @@ The server uses ASP.NET Core default settings and appsettings files under src/Se
- Sample content: see samples/ (placeholder today). The design document shows complete JSON examples you can adapt. - Sample content: see samples/ (placeholder today). The design document shows complete JSON examples you can adapt.
## Self-hosting and future federation
SessionZero is designed to be self-hostable from day one, with a clear roadmap toward optional federation of independently run servers.
### Self-hosted server (today)
- Self-hosted by design: run the SessionZero server locally or on your own VPS; no central service is required to play with friends you invite. The desktop client works fully offline; the server is only needed for shared play and sync.
- Data ownership: datapacks and saves live on your disk. For online/shared play, your own server holds your data. Planned persistence for the server is PostgreSQL; early builds may use in-memory or file-backed storage.
- How to self-host (early stage):
1. Run the server: `dotnet run --project src/SessionZero.Server`
2. Expose it on your LAN or behind a reverse proxy (e.g., Nginx/Caddy) with TLS.
3. Configure `appsettings.json` under `src/SessionZero.Server` for host/ports and, when available, database connection strings.
4. Point clients to your server URL (UI setting to be added; defaults are `http://localhost`).
- Security and licensing notes:
- Use HTTPS when exposing publicly; prefer a reverse proxy and strong auth when available.
- The code is AGPL-3.0: if you modify and run a public instance, you must make the modified source available to its users.
### Federation (future/Phase 2)
- Goal: independent servers discover and share public content (datapacks, datasets, templates) across a trust network.
- Identity: users have global IDs; datapacks are identified by UUID.
- Discovery and sharing: opt-in directories/search; servers fetch and cache public content from peers you trust.
- Permissions and privacy: private games stay private; only content you mark public is advertised.
- Interop and versioning: content references remain stable across servers via IDs and versions.
See docs/design-doc.md, Section 7 for more architectural detail.
## Roadmap (high level) ## Roadmap (high level)
- Phase 1: Core Platform (client UI, server scaffolding, datapack format) - Phase 1: Core Platform (client UI, server scaffolding, datapack format)
- Phase 2: Federation (cross‑server discovery and sharing) - Phase 2: Federation (cross‑server discovery and sharing)