Ishtaria Logo

Overview

  • Vision
    • What Ishtaria is
    • What Ishtaria is not
    • Design principles
    • Platforms
  • World overview
    • A planet in layers
    • Base terrain
    • Environment: biomes and climate
    • Generated content
    • The world clock
    • Real planets from datadisks
    • Federation
    • Not finished yet
    • See also
  • Gameplay guide
    • Starting out
    • Controls
    • Staying alive
    • Gathering and crafting
    • Building, farming and fishing
    • Hunting and combat
    • Magic
    • Trading
    • Social
    • Pictures
    • Where to go next
  • Quests and characters
    • The pilot disks
    • Talking to characters
    • Dialogue model
    • Quests
    • A worked example: the Epic of Gilgamesh
    • Where and when a character stands
    • Generated characters
    • Writing a datadisk
  • Roadmap
    • Where we are (November 2026)
    • Milestones
  • Glossary

Architecture

  • Architecture overview
    • Building blocks
    • Distribution
  • Server
    • Sharding by cells
    • Tick rates
    • Process layout
  • Client
    • Large coordinates
    • Terrain
    • Avatar
    • Prediction
  • Simulation and persistent time
    • Levels of detail
    • Catch-up
    • Offline players
    • Inventory, survival and permanent memorials
  • Gathering and crafting
    • Tools
      • Durability
    • Resources
    • Logs and wood
    • API
    • Client
    • Experience and levels
    • RPG items
    • Animals and fish
    • Dropping items
    • Planned
  • Trading, ground loot and wayfarers
    • Merchants
    • Player exchanges
    • Dropping and ground piles
    • Buying from a finder
    • Wayfarers
    • Client
  • Story datadisks
    • Files
    • Generating a world with datadisks
    • HTTP API
    • Client
    • Settlements and harbours
    • Spawn point
    • Not yet
  • Persistence
    • Base world is a function
    • Stores
    • Current server implementation
    • Economy ledger

Federation

  • Federation model
    • Separate planets, linked by portals
    • Portals as gameplay
    • Trust
    • Identity
    • Discovery
    • Moderation
    • Chat
  • Federation agreement
    • Example
    • Fields
  • Portals and share links
    • Building a portal
    • Linking
    • Breaking the link
    • Operator configuration
    • Limits and safety
    • In the client
    • Not yet implemented
  • Travel ticket and handover
    • Contents
    • Two-phase handover
    • Guests and offline players
    • Death in the host world
  • Items and economy across worlds
    • The core risk
    • Provenance
    • Unknown item kinds
    • Currencies
      • Coins in the inventory
      • Portal toll
    • Custom content packs

Operating a world

  • Installation
    • Packages
    • Adding the repository
    • Playing
    • Running a world
    • Running a world with a story datadisk
    • Administration
  • Configuration
    • Limits, logs and metrics
    • Federation agreements
  • Hardening a public world
    • Network and TLS
      • HAProxy
      • nginx
    • Accounts and limits
    • The system service
    • Checklist
  • Monitoring
    • Logs
    • Metrics
    • Capacity: what one machine did
  • Backup, restore and upgrade
    • What to keep
    • Back up
    • Restore
    • Upgrade
    • Try the restore

Development

  • Repositories
  • Local development setup
    • Prerequisites
    • A private server
    • Starting the client against it
    • Testing
    • What headless tests cannot show
  • Project rules that never change
    • Authority and trust
    • Persistence
    • Game rules owned by the project
    • Security and secrets
    • Assets and licences
    • Honest reporting
  • Tour of the server code
    • How a request is handled
    • Modules
    • Data files (etc/)
    • Tests
  • Tour of the client code
    • Principles
    • Files
    • Look of a new window
    • Keys and Settings
    • Tests
  • Cookbook: adding things to the game
    • Add an item
    • Add a recipe
    • Add a spell
    • Add a crop, a thing to place, or fishing
    • Add a merchant or a shop
    • Add or change an animal
    • Add an endpoint
    • Add a window or a key to the client
    • Add an NPC or a quest
  • Audit (November 2026)
    • How this audit was made
    • Executive summary
    • Current state of the systems
    • Security
      • B-01 – passwordless accounts can be taken over and destroyed (P0, small)
      • B-02 – GET /world/objects writes, and needs no sign-in (P1, small)
      • B-03 – a character can be bricked by its own move sequence (P2, small)
      • B-04 – federation hardening gaps (P3, small)
    • Visual quality
      • V-01 – the target look already exists, outside the engine (P1, medium)
      • V-02 – the client has no post-processing at all (P1, small)
      • V-03 – the detail terrain is too coarse, so the world reads as flat (P1, medium)
      • V-04 – NPC name labels do not scale sanely (P1, small)
      • V-05 – the game is effectively silent (P1, medium)
      • V-06 – characters are about twice the size of the architecture (P1, large)
      • V-07 – the water has nothing to reflect (P2, small)
      • V-08 to V-10 – interface defects
      • V-11 – market stalls read as a board game (P2, small)
      • V-12 – untextured buildings and glTF import errors (P2, small)
    • Gameplay
      • H-01 – tools cannot be made, yet gathering requires one (P1, small)
      • H-02 – the crafting tree consumes nothing (P2, small)
      • H-03 – the materials are not those of Early Dynastic Sumer (P2, medium)
      • H-04 – finished work that nobody has seen (P1, large)
      • H-05 – the first quest is mostly walking (P2, medium)
      • H-06 – the world is not inhabited (P1, large)
      • H-06a – residents should sleep at home and come out in the morning (P1, medium)
      • H-08 – a new character can be killed before it can move (P0, small)
      • H-07 – land leases are finished and unreachable (P3, small)
    • Story and content
      • O-01 – the story gives the player nothing material (P1, medium)
      • O-02 – player choices have no consequences (P1, medium)
      • O-03 – the achievements demand roughly 70 to 100 hours of walking (P2, medium)
      • O-04 – Achaemenid architecture stands in for Uruk (P2, revised)
      • O-05 – 66 of 71 pinned cities have no content (P2, medium)
      • O-06 – the easter eggs are never packaged (P2, small)
      • O-07 – the protocol does not describe content the server loads (P2, small)
      • O-08 – withdrawn
      • O-09 – the public site lost English (P2, small)
      • O-10 – ishtaria-content is inert but documented as required (P3, small)
      • O-11 – documentation contradicts itself (P2, small)
    • Technical
      • T-01 – the recommended way to play is probably broken (P0, medium)
      • T-02 – the terrain is rebuilt every 100 m of walking (P1, medium)
      • T-03 – per-frame work that can be removed safely (P2, small)
      • T-04 – the kilometre scene scale is a standing trap (P2)
      • T-05 – the client has no diagnostics (P2, small)
      • T-06 – every object request scans all graves (P1, small)
      • T-07 – further queries that will scan (P2, small)
      • T-08 – tables that are never pruned (P2, small)
      • T-09 – transaction and data details (P2/P3, small)
      • T-10 – ishtaria-core is effectively dead, and the cost is real (P2, medium)
      • T-11 – the client architecture blocks visual iteration (P2, large)
      • T-12 – props are drawn without batching (P2, medium)
      • T-13 – build and packaging friction (P3, small)
    • Prioritised backlog
    • Quick wins
    • Suggested order of work
    • How to verify the work
  • Building packages
    • Notes per repository
    • CI
  • Publishing on Steam
    • The decisions that come first
    • What Valve requires
    • Technical requirements for a Linux build
    • Store page and graphics
    • Content rules and disclosures
    • Money
    • Achievements
    • Where Ishtaria stands
    • Checklist
    • Sources
  • Contributing
    • Before you start
    • Working with Claude Code
    • Definition of done
    • Conventions
    • Security

Decision records

  • Decision records
    • 0001 – Separate planets linked by portals
      • Context
      • Decision
      • Consequences
    • 0002 – Rust server and core, Godot client
      • Context
      • Decision
      • Consequences
    • 0003 – Debian packages, Linux only
      • Context
      • Decision
      • Consequences
    • 0004 – Licensing
      • Decision
      • Consequences
    • 0005 – Portal pacts start with a player invitation
      • Context
      • Decision
      • Consequences
    • 0006 – Monetization with real money: land leases, imported models, custom avatars
      • Context
      • Decision
      • Consequences
    • 0007 – Text chat and friends
      • Context
      • Decision
      • Implementation (same world)
      • Consequences
    • 0008 – Story datadisks
      • Context
      • Decision
      • Consequences
    • 0009 – Portals are built alone and linked by a share link
      • Context
      • Decision
      • Consequences
    • 0010 – Magic: mana, scrolls and a small set of data-driven spells
      • Context
      • Decision
      • Consequences
      • Change (2026-10): day and night
    • 0011 – Sharing achievements and memorials on social networks
      • Context
      • Decision
      • Steps
      • Alternatives considered
      • Consequences
    • 0012 – Datadisks bring buildings of their own
      • Context
      • Decision
      • Consequences
      • Addendum: many buildings (buildings/*.yaml)
      • Addendum: the sky of a disk’s world (astronomy)
    • 0013 – Datadisks bring local terrain
      • Context
      • Decision
      • Consequences
      • Addendum: cleared ground (2026-10-13)
    • 0014 – A datadisk may give the player a character
      • Context
      • Decision
      • Consequences
    • 0015 – Characters of a datadisk may walk
      • Context
      • Decision
      • Consequences
      • Addendum: a character that is talked to stands still (2026-10-13)
      • Addendum: wayfarers on the roads (2026-10-22)
    • 0016 – Places of a datadisk lie where history puts them
      • Context
      • Decision
      • Consequences
    • 0017 – Datadisks bring the whole real planet
      • Context
      • Decision
      • Consequences
    • 0018 – Datadisk wildlife overlays and cover / ambient music
      • Context
      • Decision
      • Consequences
    • 0019 – Characters tell what they know: knowledge cards
      • Context
      • Decision
      • Consequences
    • 0020 – Relief is generated into the world map
      • Context
      • Decision (proposed)
      • Choices
      • Consequences
    • 0021 – The number of a life on a memorial
      • Context
      • Decision
      • Consequences
Ishtaria
  • Decision records
  • 0009 – Portals are built alone and linked by a share link
  • View page source

0009 – Portals are built alone and linked by a share link

Status:

Accepted and implemented; supersedes 0005 – Portal pacts start with a player invitation

Date:

2026-10-06

Context

Linking two worlds began with a signed invitation from one player to another and a pact that both players then built together. The project owner decided on a simpler model: a portal is built on its own, and only a finished portal can be linked.

Decision

  • A player builds a portal alone: a construction site where they stand, and the materials of etc/portal.json delivered to it. No invitation, pact or peer is needed.

  • A finished portal offers two functions: copy its share link, and paste the share link of another world’s portal.

  • When a link is pasted, the player’s server first checks that the other world is reachable, that the link is signed by that world’s published key, and that the offered portal stands there and is finished. Only then does it ask the other world to link its end (a signed request that the other world checks in turn) and activate both ends.

  • The operator policy still applies: closed refuses links, approve leaves the link pending until the operator approves it, open opens it at once.

  • A portal has exactly one counterpart. A linked portal neither offers a link nor accepts one. The owner of either end can break the link; both portals are then finished and unlinked again and can be linked anew. Closing a portal breaks its link and leaves a ruin.

  • A broken link is reported to the other world with a signed message that is repeated until delivered. Only the world a portal is linked with can release it.

Consequences

  • A share link can be sent through any channel and carries no secret; it only names a portal and is signed by its world. Whoever holds it can try to link, but the other world’s checks and policy decide.

  • Invitation codes, pact acceptance and joint building were removed; their message formats in ishtaria-protocol were replaced by portal-link, portal-link-request and portal-unlink.

  • Travel through a linked portal (tickets, tolls) is still planned.

Previous Next

© Copyright 2026, Vítězslav Dvořák / VitexSoftware (CC BY-SA 4.0).

Built with Sphinx using a theme provided by Read the Docs.