Shared protocol and data infrastructure for World Dai Star: Yume no Stellarium (YMST / ユメステ)
Client-derived protocol models · MasterMemory schema/tooling · MagicOnion realtime contracts · OpenSirius internal service contracts
SiriusData is the shared protocol and data-model foundation used by the TeamOpenSirius ecosystem around World Dai Star: Yume no Stellarium.
Its primary purpose is to keep game-facing data structures in one reusable, versioned repository instead of allowing the server, realtime service, desktop tools, calculators, and other utilities to maintain incompatible private copies.
Most game-facing models in Sirius.Protocol were reconstructed and adapted from client-side SiriusApi.* type information exported during reverse engineering. The recovered structures were then normalized for normal .NET use, MessagePack compatibility, MasterMemory generation, and reuse across OpenSirius projects.
The repository also contains a small set of TeamOpenSirius-specific contracts under Sirius.Protocol.InternalApi. These models are private infrastructure contracts used for communication between OpenSirius services such as the game server, account/platform services, and realtime backend. They are not intended to represent original client APIs.
In short, SiriusData acts as the shared boundary between:
- reconstructed YMST client protocol structures;
- server-side implementations of those structures;
- MagicOnion realtime communication;
- MasterMemory master-data access and tooling;
- OpenSirius service-to-service contracts;
- desktop and offline tooling that needs the same data definitions.
SiriusData is designed around a few simple rules:
- One canonical model set for protocol and master-data structures.
- Wire compatibility first — serialized shape, union IDs, field order, and type identity matter.
- No duplicated protocol trees across server/tool repositories.
- Client-derived and OpenSirius-specific contracts stay distinguishable.
- MasterMemory uses the real source-generator pipeline, not compatibility stubs.
- Unknown reverse-engineered fields remain explicitly unknown instead of being given invented semantics.
- The protocol assembly stays a leaf dependency that can be referenced by multiple projects.
| Component | Purpose |
|---|---|
Sirius.Protocol |
Shared YMST protocol DTOs, enums, MessagePack models, MasterMemory table definitions, realtime contracts, and OpenSirius internal contracts |
Sirius.MasterData |
Typed MasterMemory inspection, editing, export, rebuild, and verification layer |
Wds.MasterMemory.Tool |
Offline CLI for unpacking, editing, translating, repacking, and validating mastermemory.db |
Sirius.Protocol is the core assembly.
It contains the shared types used across HTTP/API-like payloads, player state, master data, live calculation, realtime communication, and related game systems.
The project currently targets:
net8.0
net10.0
Its direct package dependencies are intentionally small:
MessagePack3.1.8MessagePackAnalyzer3.1.8MasterMemory3.0.4MagicOnion.Abstractions6.1.7
Sirius.MasterData builds on top of Sirius.Protocol and provides a typed API for working with YMST MasterMemory databases.
It handles operations such as:
- database verification;
- table discovery;
- record enumeration;
- typed add/update operations;
- JSON export;
- controlled rebuild from exported JSON;
- byte-exact no-op round-trip verification.
The command-line tool provides the same model-aware MasterMemory workflow for scripts and offline maintenance.
Typical use cases include:
- unpacking
mastermemory.db; - inspecting tables;
- exporting editable JSON;
- extracting translatable strings;
- applying localization CSVs;
- rebuilding a valid database;
- verifying schema and round-trip behavior.
The majority of the game-facing protocol tree originates from client-side SiriusApi.* structures recovered during reverse engineering.
The current repository is not a raw dump of those client types. The recovered definitions have been adapted so that they can serve as a maintainable shared library:
- namespaces are organized under
Sirius.Protocol.*; - MessagePack contracts are preserved where required;
- MasterMemory attributes are applied to master-table models;
- incomplete/newer schema information is reconciled against observed database data where possible;
- compatibility fixes are isolated instead of being spread throughout consumer projects.
This repository should therefore be treated as a reconstructed compatibility model of the game protocol, not an official SDK or official source release.
Models/InternalApi/ is different.
These types describe TeamOpenSirius-owned service-to-service APIs, including parts of:
- realtime authentication;
- account/platform management;
- account import and takeover flows;
- player administration;
- realtime presence and revocation;
- multiplayer session coordination;
- game-master/platform operations;
- photo/platform operations.
They exist so that OpenSirius services can share strongly typed contracts without depending directly on each other's implementation projects.
They should not be interpreted as client-derived official YMST API definitions.
Models/Shared/ contains most of the reusable game-facing data model.
It includes structures covering areas such as:
- player/profile state;
- characters and character progression;
- parties;
- music and live data;
- posters and accessories;
- items and possession data;
- missions;
- shops and currencies;
- events;
- leagues;
- photo/albums;
- gacha;
- home data;
- social and user-block state;
- other shared result/payload types.
Many of these types participate in the central MessagePack IDataObject union.
Sirius.Protocol.Shared.IDataObject is an important compatibility boundary.
It is a MessagePack [Union] interface whose union members span a large part of the shared game model, including master-table and runtime/player objects.
Because master-table objects participate in this same union, the MasterMemory model layer cannot be safely split into an unrelated assembly without changing type identity and protocol dependencies.
This is why the complete shared protocol remains in Sirius.Protocol.
Models/Realtime/ contains models and abstractions used by the realtime network layer.
The realtime side includes MagicOnion-compatible hub contracts and shared types used for features such as:
- common realtime communication;
- circle / chat functionality;
- multiplayer state;
- live-related realtime messages;
- notifications and presence.
Where required, MagicOnion-specific interfaces are kept next to the reconstructed realtime model so both the realtime server and compatible clients/tools can reference the same contract definitions.
Models/LiveEngine/ contains models and enums used by live/scoring logic, including effect, trigger, branch-condition, and related calculation structures.
MasterMemory table models live under:
src/Sirius.Protocol/Models/Shared/Models/Master/
The current model set covers 229 MasterMemory tables.
The checked-in source contains model definitions only. The following types are generated at compile time by Cysharp MasterMemory 3.0.4:
Sirius.Protocol.Shared.MemoryDatabaseSirius.Protocol.Shared.DatabaseBuilderSirius.Protocol.Shared.ImmutableBuilderSirius.Protocol.Shared.Tables.*Table- MasterMemory MessagePack resolver support
Do not add hand-written replacements for those generated classes.
flowchart TD
Client["YMST Client<br/>SiriusApi.* metadata"] --> RE["Reverse engineering / type export"]
RE --> Protocol["Sirius.Protocol"]
Protocol --> Shared["Shared game DTOs"]
Protocol --> MMModels["MasterMemory table models"]
Protocol --> RT["Realtime / MagicOnion contracts"]
Protocol --> Live["LiveEngine models"]
Protocol --> Internal["OpenSirius InternalApi contracts"]
MMModels --> Generator["MasterMemory source generator"]
Generator --> DB["MemoryDatabase / DatabaseBuilder"]
Protocol --> Server["SiriusServer"]
Protocol --> Realtime["Realtime backend"]
Protocol --> Tools["Desktop / offline tooling"]
Protocol --> Calculators["Standalone calculators"]
DB --> MasterData["Sirius.MasterData"]
MasterData --> Tools
MasterData --> CLI["Wds.MasterMemory.Tool"]
Internal --> Server
Internal --> Realtime
The important design point is that consumer projects depend on SiriusData, rather than SiriusData depending on server implementation code.
SiriusData/
├── .github/
│ └── workflows/
│ └── dotnet.yml
├── SiriusData.sln
└── src/
├── Sirius.Protocol/
│ ├── Common/
│ ├── Compatibility/
│ ├── Models/
│ │ ├── InternalApi/
│ │ ├── LiveEngine/
│ │ ├── Realtime/
│ │ ├── Root/
│ │ └── Shared/
│ │ └── Models/
│ │ └── Master/
│ ├── MasterMemoryGeneratorOptions.cs
│ ├── README.MasterMemory.md
│ └── tools/
│ └── Wds.MasterMemory.Tool/
└── Sirius.MasterData/
├── IO/
└── MasterMemory/
For the full multi-target solution, use a .NET SDK capable of building both target frameworks.
dotnet restore .\SiriusData.sln
dotnet build .\SiriusData.sln -c ReleaseThe main libraries target:
net8.0
net10.0
The offline MasterMemory tool targets .NET 8.
For active development, TeamOpenSirius repositories are normally checked out side by side:
workspace/
├── SiriusData/
├── SiriusServer/
└── SiriusToolbox/
A consuming project can reference the source directly:
<ItemGroup>
<ProjectReference Include="..\SiriusData\src\Sirius.Protocol\Sirius.Protocol.csproj" />
</ItemGroup>For environments where a sibling source checkout is not available, Sirius.Protocol can also be packed and consumed as a NuGet package.
dotnet pack .\src\Sirius.Protocol\Sirius.Protocol.csproj `
-c Release `
-o .\artifacts\packagesThe package ID is:
Sirius.Protocol
Consumer repositories may use a conditional ProjectReference / PackageReference strategy so developer environments use live source while isolated build environments use the packed artifact.
mastermemory.db is a MasterMemory database and should not be treated as a plain MessagePack root object.
Use the generated database type:
using Sirius.Protocol.Shared;
byte[] bytes = await File.ReadAllBytesAsync("mastermemory.db");
var db = new MemoryDatabase(
bytes,
maxDegreeOfParallelism: Environment.ProcessorCount);
var music = db.MusicMasterTable.FindById(1);Sirius.MasterData provides higher-level operations:
var report = MasterMemoryDatabaseService.Verify(databasePath);
var tables = MasterMemoryDatabaseService.GetTables(databasePath);
var rows = MasterMemoryDatabaseService.ListRecords(
databasePath,
tableName,
offset,
limit);
await MasterMemoryDatabaseService.ExportAllJsonAsync(
databasePath,
jsonDirectory);
var pack = MasterMemoryDatabaseService.PackFromJson(
sourceDatabase,
jsonDirectory,
baselineJsonDirectory,
outputDatabase,
requireExact: true);The rebuild pipeline tries to preserve original table payload blocks when values are unchanged. This makes strict no-op round-trip verification useful both for binary reproducibility and as a practical schema/model correctness check.
Run the CLI help:
dotnet run --project .\src\Sirius.Protocol\tools\Wds.MasterMemory.Tool -- --helpTypical workflow:
dotnet run --project .\src\Sirius.Protocol\tools\Wds.MasterMemory.Tool -- `
unpack .\mastermemory.db .\dump
# edit dump\tables\*.json
dotnet run --project .\src\Sirius.Protocol\tools\Wds.MasterMemory.Tool -- `
pack .\dump .\mastermemory_modified.db
dotnet run --project .\src\Sirius.Protocol\tools\Wds.MasterMemory.Tool -- `
verify .\mastermemory_modified.dbExact no-op round trip:
dotnet run --project .\src\Sirius.Protocol\tools\Wds.MasterMemory.Tool -- `
roundtrip .\mastermemory.db .\rtLocalization workflow:
dotnet run --project .\src\Sirius.Protocol\tools\Wds.MasterMemory.Tool -- `
extract-text .\dump .\translation.csv
dotnet run --project .\src\Sirius.Protocol\tools\Wds.MasterMemory.Tool -- `
apply-text .\dump .\translation.csvSee src/Sirius.Protocol/tools/Wds.MasterMemory.Tool/README.md for tool-specific details.
Protocol work in this repository should prefer evidence over guessed semantics.
When updating client-derived models:
- preserve known serialized field order / MessagePack keys;
- preserve known union IDs and type identities;
- compare against current client metadata and observed payloads;
- verify MasterMemory changes against a real database;
- use conservative names such as
ReservedXXwhen the meaning of a recovered field is not established; - do not invent secondary indexes or relationships without evidence.
For MasterMemory changes, run the round-trip verification before relying on the updated schema.
Changes to classes under:
src/Sirius.Protocol/Models/Shared/Models/Master/
change the generated MasterMemory database API.
After modifying those models:
dotnet build .\SiriusData.sln -c Release
dotnet run --project .\src\Sirius.Protocol\tools\Wds.MasterMemory.Tool -- `
roundtrip .\mastermemory.db .\rtA successful byte-exact no-op round trip is a strong signal that the model still matches the supplied database structure.
GitHub Actions runs on pushes and pull requests targeting main.
The workflow performs:
- dependency restore;
- solution build;
dotnet test.
See .github/workflows/dotnet.yml.
Contributions that improve protocol accuracy, recover missing schema information, or make shared infrastructure easier to reuse are welcome.
When changing reconstructed protocol structures, include enough evidence to explain why the serialized shape or semantics should change.
Keep OpenSirius-only service contracts under Sirius.Protocol.InternalApi rather than mixing them into client-derived namespaces.
No repository-level LICENSE file is currently included. Source availability should therefore not be interpreted as granting a specific open-source license.
Third-party dependencies such as MessagePack, MasterMemory, and MagicOnion remain subject to their own licenses.
SiriusData is an unofficial community interoperability and infrastructure project.
World Dai Star, World Dai Star: Yume no Stellarium, ユメステ, and related names, data, assets, and trademarks belong to their respective rights holders. This repository is not an official SDK and is not affiliated with or endorsed by the game's developers, publishers, or operators.