starhaven.dev
+467
Diff
round #2
+467
text/0001-appview.md
+467
text/0001-appview.md
···
1
+
# Summary
2
+
3
+
Build starhaven.dev as an [atproto](https://overreacted.io/a-social-filesystem/)
4
+
appview with a community forum and mod browser. Users sign in with any atproto
5
+
account or sign up for a `*.starhaven.dev` handle via the Star Haven PDS.
6
+
Forum threads, replies, and mod listings are atproto records stored in users'
7
+
repos. The source lives at `starhaven.dev/appview`.
8
+
9
+
In this RFC, "end-users" refers to people who play mods (as opposed to modders
10
+
who create them). Modders are also users of the site, but the distinction
11
+
matters for the mod browser and patching sections.
12
+
13
+
# Status quo
14
+
15
+
Currently, Star Haven is used as a central hub for Paper Mario modding, except
16
+
for when it is not and breaks off into smaller sub-communities (Modern Paper
17
+
Mario Modding, WUA, NicTube and Lily's mods, etc.) or when modders migrate to
18
+
larger platforms (Itch, or formerly romhacking.net).
19
+
20
+
Star Haven facilitates general chat, private chats, individual mod and game
21
+
discussion, general modding assistance, mod release notifications and community
22
+
events.
23
+
24
+
Some modders have the social capital to promote, release and discuss their mods
25
+
in their own bespoke communities and have no need for a centralised modding hub.
26
+
However, such modders are the exception rather than the rule. Initially, most
27
+
modders bounced around various forums until landing in Star Haven's Discord
28
+
server, where they continued to develop and release their mods.
29
+
30
+
Star Haven's Discord Server holds the largest repository of modding advice,
31
+
through years of Discord chats and real-time assistance from experienced modders.
32
+
Star Haven also acts as an aggregation service for modders to publish their
33
+
creations to a wider audience with relative ease, providing either a thread or a
34
+
bespoke channel dependent on the mod's popularity. On top of that, Star Haven
35
+
aggregates and hosts modding tools, as well as similar help channels for said
36
+
tools. Star Haven also uses Discord and Itch.io to host regular jam events,
37
+
where modders create teams to create themed mods in a certain timeframe.
38
+
39
+
Modders use GitHub to collaboratively develop their mods, private Discord
40
+
servers to facilitate development chats and voice-calls, and Itch.io to publish
41
+
their mods. Offline, modders use a wide variety of tools such as Star Rod,
42
+
Mamar, Unsimplifier and more.
43
+
44
+
For players, Star Haven provides an avenue to discuss mods, the Paper Mario
45
+
games, ask for help on a per-mod or a general basis, or have a general chat.
46
+
Additionally, a list of mods is available in the Discord, and the
47
+
(currently broken) mod browser on starhaven.dev/mods.
48
+
49
+
The community is splintered across multiple technologies and platforms that do
50
+
not neatly integrate with one another, limiting most modders' reach to a single
51
+
medium-sized Discord server. That, and everyone quite dislikes Discord.
52
+
53
+
# Motivation
54
+
55
+
We add Star Haven Forums (built atop atproto) as a slower-paced complement to
56
+
the Discord server, replace GitHub with Tangled, and add a mod browser at
57
+
starhaven.dev. Discord remains the place for real-time chat and voice calls -
58
+
the forums are for longer-form discussion, modding guides, and announcements
59
+
that benefit from being permanent and searchable.
60
+
61
+
Critically, forums get important modding knowledge out of the walled garden
62
+
that is Discord and onto the open web, where search engines can index it.
63
+
Years of modding advice currently trapped in Discord messages becomes
64
+
discoverable by anyone with a web browser - no Discord account required.
65
+
The best place for agreed-upon knowledge is docs.starhaven.dev, but updating
66
+
that is out of scope for this RFC. The
67
+
use of open-source, federated technology also allows other communities to fork
68
+
the work for their own purposes.
69
+
70
+
A non-Discord mod browser allows for much greater modder control of how their
71
+
mods are promoted and advertised, providing descriptions, updates and
72
+
promotional material all on the same page. Integration with PM-DX (and further
73
+
tools down the line) enhances the developer experience.
74
+
75
+
For end-users, a modern, professional mod browser removes the reliance on
76
+
Discord for viewing, downloading and playing mods.
77
+
78
+
## Why atproto?
79
+
80
+
We already run a PDS at pds.starhaven.dev and a knot (git server) at
81
+
knot.starhaven.dev. Most community members still use GitHub, and some Star
82
+
Haven infrastructure (e.g. papermario-dx CI) still depends on it, but the
83
+
aspiration is to self-host community things over time. The question is whether
84
+
building on atproto is worth it versus a traditional forum with Discord OAuth
85
+
or similar.
86
+
87
+
The core benefit is **data ownership**. Forum posts, mod listings, and profiles
88
+
are atproto records stored in users' own repos. If starhaven.dev goes down or
89
+
the maintainer disappears, users still have their data - they can take it to
90
+
another appview or export it. With a traditional forum, all content lives in
91
+
the site operator's database. The content may remain accessible, but users have
92
+
no independent copy and no way to move it. For a small community maintained by
93
+
volunteers, reducing the bus factor matters.
94
+
95
+
Beyond that:
96
+
97
+
- One identity system - no new accounts to make. A `*.starhaven.dev` handle
98
+
works on Bluesky, Tangled, and any future atproto service.
99
+
- We don't have to maintain a user/password system. atproto OAuth handles it.
100
+
- The PDS can support Discord OAuth via
101
+
[tranquil](https://tangled.org/tranquil.farm/tranquil-pds), so Discord users can
102
+
sign up without learning what atproto is. They get an atproto identity for
103
+
free.
104
+
- Other communities can run the same appview software against their own PDS and
105
+
get a fully independent instance with zero data migration needed.
106
+
107
+
Existing forum software (Discourse, phpBB) doesn't really fit the vibe we want,
108
+
and we'd need to write a custom auth plugin for atproto OAuth anyway.
109
+
110
+
# Explanation
111
+
112
+
## Migration from current site
113
+
114
+
starhaven.dev is currently a SvelteKit site on GitHub Pages (star-haven/starhaven.dev).
115
+
It has a homepage and a /mods page that renders a JSON file of mods with download
116
+
links. The /mods page is broken (500 error). The appview replaces this entirely -
117
+
we should not regress from the existing functionality, so the homepage and mod
118
+
listing need to be carried over.
119
+
120
+
Migration is not about shutting Discord down. Forum-style channels (mod
121
+
releases, guides, showcase) move to the appview over time, while real-time
122
+
chat stays on Discord. Optionally, a #forums channel on Discord can post messages for new forum
123
+
threads via webhook to help with early adoption, though this should be
124
+
turned off once the forums have enough activity on their own.
125
+
126
+
## How it works
127
+
128
+
starhaven.dev is an atproto **appview** - it subscribes to the firehose,
129
+
indexes records that match our custom lexicons, and serves a web frontend.
130
+
131
+
```
132
+
browser --> starhaven.dev (appview + web server) --> database
133
+
| ^
134
+
| | firehose
135
+
v |
136
+
relay / PDS
137
+
```
138
+
139
+
You sign in with atproto OAuth. When you create a forum post, it writes a
140
+
record to your PDS repo. The appview picks it up from the firehose and indexes
141
+
it.
142
+
143
+
## Auth
144
+
145
+
### Signing in
146
+
147
+
`/login` asks for your handle (e.g. `luigi.starhaven.dev` or
148
+
`someone.bsky.social`) and initiates atproto OAuth. Same flow as tangled.sh.
149
+
150
+
### Creating an account
151
+
152
+
Users who don't have an atproto account can create one on pds.starhaven.dev.
153
+
`/signup` collects an email and a captcha, then calls the PDS admin API
154
+
(`com.atproto.server.createAccount`) to create the account. The user picks a
155
+
handle (`*.starhaven.dev`) and authenticates via passkey or Discord OAuth
156
+
(supported by the PDS via
157
+
[tranquil](https://tangled.org/tranquil.farm/tranquil-pds)). No passwords.
158
+
159
+
## Routes
160
+
161
+
```
162
+
/ Homepage (community landing page)
163
+
/login atproto OAuth sign-in
164
+
/signup Create a *.starhaven.dev account
165
+
166
+
/mods Mod browser (browse/search/filter)
167
+
/mods/:game Mods for a specific game
168
+
/mods/:game/:slug Mod page (description, media, downloads)
169
+
/mods/new Upload a new mod listing
170
+
/repo.json Homebrew App Store / Universal Updater compatible
171
+
endpoint for on-device mod browsers
172
+
173
+
/search Search across threads, mods, and profiles
174
+
175
+
/forums Forum index (hardcoded categories/subcategories)
176
+
/forums/:subcategory Thread list for a subcategory, paginated
177
+
/forums/:subcategory/new New thread form
178
+
/forums/thread/:id Thread view, paginated (?page=n)
179
+
180
+
/:handle Actor profile (avatar, posts, mods)
181
+
```
182
+
183
+
Mods don't require a source repo - closed-source and legacy mods are welcome.
184
+
The mod browser is git forge agnostic; modders can use GitHub, Tangled, or
185
+
anything else. If a mod team happens to use Tangled, the appview can provide
186
+
tighter integration (linking to repos, showing recent commits), but it is not
187
+
required.
188
+
189
+
## Lexicons
190
+
191
+
Everything under `dev.starhaven.*`. Record types use `key: "tid"` unless
192
+
noted. References to other records use at-uri strings; references that need
193
+
to pin to an exact version (e.g. to prevent replying to a since-deleted
194
+
revision) use `com.atproto.repo.strongRef`.
195
+
196
+
```
197
+
┌──────────────────┐
198
+
│ actor.profile │
199
+
│ key: self │
200
+
└──────────────────┘
201
+
202
+
┌──────────────────┐ ┌──────────────────┐
203
+
│ forum.thread │◄───│ forum.thread │
204
+
│ │ │ .post │
205
+
│ title, tags │ │ │
206
+
│ subcategory │ │ body │
207
+
└──────────────────┘ └──────────────────┘
208
+
209
+
┌──────────────────┐ ┌──────────────────┐
210
+
│ mod.listing │◄───│ mod.release │
211
+
│ │ │ │
212
+
│ has: media[] │ │ has: deliverable│
213
+
│ (PDS blob) │ │ (S3 URL) │
214
+
└──────────────────┘ └──────────────────┘
215
+
```
216
+
217
+
```
218
+
dev.starhaven.actor.profile key: "literal:self"
219
+
displayName: string (maxGraphemes: 64)
220
+
description: string (maxGraphemes: 256)
221
+
pronouns: string (maxGraphemes: 20)
222
+
223
+
dev.starhaven.forum.thread
224
+
title: string (required, maxGraphemes: 300)
225
+
subcategory: string (required, maxLength: 64)
226
+
tags: string[] (maxLength: 8, items maxLength: 64)
227
+
createdAt: datetime (required)
228
+
229
+
dev.starhaven.forum.thread.post
230
+
thread: at-uri (required) → dev.starhaven.forum.thread
231
+
body: string (required, maxGraphemes: 30000)
232
+
createdAt: datetime (required)
233
+
234
+
dev.starhaven.mod.listing
235
+
title: string (required, maxGraphemes: 300)
236
+
slug: string (required, maxLength: 64) URL-safe identifier, e.g. "master-quest"
237
+
description: string (required, maxGraphemes: 1000)
238
+
details: string (maxGraphemes: 30000) extended description (markdown)
239
+
game: string (required, maxLength: 32) e.g. "pm64", "spm", "pmss"
240
+
platform: string (required, maxLength: 32) e.g. "n64", "wii", "3ds"
241
+
category: string (maxLength: 64)
242
+
tags: string[] (maxLength: 8, items maxLength: 64)
243
+
license: string (maxLength: 128)
244
+
media: #mediaItem[] (maxLength: 16) images and videos, ordered
245
+
createdAt: datetime (required)
246
+
247
+
#mediaItem
248
+
file: blob (required, accept: image/*, video/*, maxSize: 50MB)
249
+
alt: string (maxGraphemes: 1000) accessibility description
250
+
251
+
dev.starhaven.mod.release
252
+
mod: strongRef (required) → dev.starhaven.mod.listing
253
+
version: string (required, maxLength: 32)
254
+
changelog: string (maxGraphemes: 30000)
255
+
deliverable: string (required, format: uri) URL in object store
256
+
createdAt: datetime (required)
257
+
```
258
+
259
+
Mod releases are separate records so they appear individually on the firehose
260
+
and don't require rewriting the listing on every update. The deliverable URL
261
+
points to the object store - the type of deliverable (patch file, zip, etc.)
262
+
depends on the game (see Mod browser below). Media blobs (screenshots, videos)
263
+
are stored on the PDS like any atproto blob. Mod deliverables are too large
264
+
for PDS blob storage, so they go in the S3 object store and are referenced by
265
+
URL.
266
+
267
+
The `game` and `platform` fields are split so the `/repo.json` endpoint can
268
+
group mods by console (which the on-device app stores need) while the web mod
269
+
browser can filter by game. The `author` field isn't stored in the record -
270
+
the record's DID identifies the author, and the endpoint generator resolves it
271
+
to a display name. The Homebrew App Store `name` field (used for update
272
+
tracking) is derived from the DID + record TID, which is immutable. Fields
273
+
like `license`, `details`, and `changelog` (on releases) map directly to their
274
+
Homebrew App Store equivalents.
275
+
276
+
## Tech
277
+
278
+
- **Language:** Rust.
279
+
- **Frontend:** Server-rendered HTML + htmx (like tangled.sh).
280
+
- **Database:** SQLite (like tangled.sh).
281
+
- **Search:** SeekStorm (see Search section below).
282
+
- **Blob storage:** S3-compatible object store, configured via environment
283
+
variable (endpoint, bucket, credentials). Used for mod deliverables, media
284
+
(screenshots, videos), and any other uploaded files. The appview doesn't
285
+
assume a specific provider - any S3-compatible service (MinIO, Tigris,
286
+
Cloudflare R2, AWS S3, etc.) works.
287
+
- **Hosting:** kuribo, behind Caddy.
288
+
- **Repo:** starhaven.dev/appview on tangled.
289
+
- **Nix:** Flake with a NixOS module (for kuribo/infra) and a devshell.
290
+
291
+
## Visual design
292
+
293
+
TBD, but the forum area should feel like a 2000s web forum while meeting modern
294
+
accessibility and mobile standards. Discourse is a good reference for how a
295
+
modern forum can work - the aesthetic is retro, the UX should not be.
296
+
297
+
## Firehose and backfill
298
+
299
+
The appview subscribes to the Bluesky relay's Jetstream for live events.
300
+
301
+
Jetstream only provides live events and a short replay buffer (a couple of
302
+
days at most). A fresh database (new developer setup, or recovery from data
303
+
loss) needs to be seeded from PDSs directly using `com.atproto.sync.getRepo`,
304
+
which returns every record in a user's repo. On first startup with an empty
305
+
database, the appview:
306
+
307
+
1. Lists all repos on each configured PDS via `com.atproto.sync.listRepos`.
308
+
The default config includes bsky.social and pds.starhaven.dev, since most
309
+
users will be on one of those.
310
+
2. For each repo, calls `com.atproto.sync.getRepo` and processes every
311
+
`dev.starhaven.*` record as if it came from the firehose (inserting into
312
+
both SQLite and the search index).
313
+
3. Saves the current Jetstream cursor.
314
+
4. Switches to live firehose consumption from that cursor.
315
+
316
+
This backfill runs automatically on first startup.
317
+
318
+
## Search
319
+
320
+
Search uses [SeekStorm](https://github.com/SeekStorm/SeekStorm), a Rust
321
+
full-text search crate that embeds in the appview binary. No separate service.
322
+
323
+
The ingester writes to both SQLite and the SeekStorm index on every firehose
324
+
event (create, update, delete), so records are searchable immediately.
325
+
326
+
Indexed content:
327
+
- Forum threads and posts (title, body). Filterable by category, tags.
328
+
- Mod listings (title, description, details). Filterable by game, platform,
329
+
category.
330
+
- Actor profiles (display name, description).
331
+
332
+
`/search` is a single search bar across all record types. Facet filters let
333
+
you narrow by type (thread, mod, profile), game, platform, or category.
334
+
Results ranked by BM25F.
335
+
336
+
SeekStorm has built-in typo tolerance (edit distance 1, so "stikcer star"
337
+
finds "Sticker Star") and query auto-completion.
338
+
339
+
## Mod browser
340
+
341
+
The mod browser is the primary way to discover and download mods. Modders sign
342
+
in and create a `dev.starhaven.mod.listing` record with a title, description,
343
+
media, and one or more versioned releases. The appview indexes these from the
344
+
firehose like any other record. Mod deliverables (patches, zips, etc.) are
345
+
uploaded to the S3-compatible object store. For games that need patching, the
346
+
patching pipeline runs in the browser.
347
+
348
+
### Patching
349
+
350
+
Paper Mario mods can't just ship a ready-to-play ROM or ISO - that would
351
+
require distributing copyrighted game data. Instead, mods are distributed as
352
+
patches or file overlays that are applied to a user-supplied copy of the
353
+
original game. The mod browser handles all of this transparently: end-users
354
+
provide their base ROM/ISO once (stored in the browser's IndexedDB for reuse)
355
+
and then just click "download" on any mod. No separate patching program
356
+
required. The patching strategy varies by game:
357
+
358
+
**PM64 (N64)** - Mods are distributed as `.bps` patch files targeting the US
359
+
ROM (the only supported base for now). The `.bps` patch is fetched, applied to
360
+
the base ROM entirely client-side using JavaScript, and the patched ROM is
361
+
downloaded to the end-user's machine. No game data ever leaves the browser or
362
+
touches the server.
363
+
364
+
**TTYD (GCN)** - Patching strategy TBD. Needs input from existing GameCube
365
+
modders.
366
+
367
+
**SPM (Wii)** - Like PM64, the end-user supplies a base `.iso` or `.wbfs`.
368
+
There are multiple regional revisions (3 US,
369
+
2 JP, ~1 PAL) but mods ship a single patch - the tooling uses symbol-based
370
+
replacement so it handles revision differences automatically. The existing
371
+
Flipside Mod Manager uses the C libraries
372
+
[wiimms-szs-tools](https://github.com/Wiimm/wiimms-szs-tools) and
373
+
[wiimms-iso-tools](https://github.com/Wiimm/wiimms-iso-tools) to apply
374
+
patches. Rather than porting these to JavaScript, the patching runs client-side
375
+
inside CheerpX (WebVM), a browser-based x86 virtual machine. The output is an
376
+
`.iso` (WBFS filesystem) that works with both Dolphin and USB loaders on real
377
+
hardware. As with PM64, no game data leaves the browser.
378
+
379
+
**Modern PM (3DS, Wii U, Switch)** - Mods are zip files containing replacement
380
+
assets that get extracted to console-specific paths (e.g.
381
+
`sdmc:/luma/titles/<title-id>/romfs/` on 3DS). These don't require patching
382
+
against a base ROM - the zip is the deliverable. Modders upload the zip to
383
+
starhaven.dev and end-users download it directly, either through the web mod
384
+
browser or through on-device homebrew app stores (Universal Updater on 3DS,
385
+
Homebrew App Store on Wii U/Switch) via the `/repo.json` compatibility endpoint.
386
+
387
+
### `/repo.json` compatibility endpoint
388
+
389
+
The 3DS/Wii U/Switch modding communities already use on-device homebrew app
390
+
stores that read from a `repo.json` file listing available mods. starhaven.dev
391
+
serves a `/repo.json` endpoint that is compatible with these formats, generated
392
+
from the indexed `dev.starhaven.mod.listing` and `dev.starhaven.mod.release`
393
+
records. This means existing on-device mod browsers continue to work - they
394
+
just point at starhaven.dev instead of a GitHub repo.
395
+
396
+
The 3DS community uses Universal Updater, which reads a `.unistore` file (a
397
+
JSON format with a different extension). The Wii U and Switch communities use
398
+
the Homebrew App Store, which reads `repos.json`. starhaven.dev generates both
399
+
formats.
400
+
401
+
The mapping from lexicon records to these formats:
402
+
- DID + record TID → `name` (Homebrew App Store package identifier, stable)
403
+
- `title` → `title` / unistore `info.title`
404
+
- DID → resolved to `author`
405
+
- `description` → `description`, `details` → `details`
406
+
- `license` → `license`
407
+
- `category` → `category` / unistore `info.category`
408
+
- `platform` → unistore `info.console`
409
+
- Latest `mod.release.version` → `version` / unistore `info.version`
410
+
- Latest `mod.release.changelog` → `changelog`
411
+
- Latest `mod.release.deliverable` → download URL
412
+
- `media` → filtered to images only (on-device app stores don't support video)
413
+
414
+
For the unistore format, the appview also generates per-region install scripts
415
+
(download, extract, cleanup) using a lookup table of title IDs per game per
416
+
region (e.g. `00040000000A5E00` for PM:SS USA). This is appview logic, not
417
+
stored in the lexicon.
418
+
419
+
420
+
## Moderation
421
+
422
+
Appview-level: we choose what to display. Can remove content from the index,
423
+
ban handles, pin/feature stuff. Doesn't touch user repos.
424
+
425
+
# Drawbacks
426
+
427
+
- It's a lot of work compared to just deploying Discourse.
428
+
- We'd be maintaining custom forum software forever.
429
+
- The PM modding community is small - might be overkill.
430
+
- atproto custom lexicons are still early days, things might change.
431
+
- atproto is fully public. Modders who want to work in secret (e.g. for mod
432
+
jams) cannot use Tangled private repos yet. Until atproto adds permissioned
433
+
data, private work should stay on whatever git forge the modder prefers.
434
+
- If users delete records from their repos, forum threads get holes.
435
+
436
+
# Alternatives
437
+
438
+
**Discourse/phpBB with atproto auth plugin** - still need a custom auth
439
+
plugin, doesn't give us the retro look without heavy theming, forum data
440
+
isn't on atproto.
441
+
442
+
**Don't do this** - keep everything on Discord. Works for real-time chat but
443
+
important knowledge stays trapped behind a login wall, unsearchable by search
444
+
engines and unarchivable.
445
+
446
+
# Future Work
447
+
448
+
- Integration with tangled, so that mod source repos can be linked from listings.
449
+
- Build integration with papermario-dx CI.
450
+
- Mod reviews with a `dev.starhaven.mod.review` lexicon.
451
+
- Reactions with a `dev.starhaven.feed.reaction` lexicon (applicable to threads,
452
+
replies, mods, etc.)
453
+
- Multi-region PM64 patch support via a custom patch format for papermario-dx.
454
+
- Mod collections and events (jams, curated sets like Master Quest, Paper Dank
455
+
Rave, the Holiday Specials).
456
+
- Additional PDS auth providers beyond passkeys and Discord (e.g. GitHub OAuth).
457
+
458
+
# Unresolved questions
459
+
460
+
- Rich text: facets or Markdown? Markdown is familiar, facets are atproto-native.
461
+
- Thread ordering: chronological or upvote-based?
462
+
- Notifications: atproto has no push for custom lexicons. Email? Bluesky DMs?
463
+
Just check the site?
464
+
- TTYD (GCN) patching strategy: needs input from existing GameCube modders.
465
+
- Lexicon namespacing: before 1.0, ensure lexicons aren't overly specific to
466
+
Paper Mario if the platform may open to other modding communities in future.
467
+
- Homepage design: what should it look like? The current one isn't great.
History
3 rounds
2 comments
expand 0 comments
bates64.com
submitted
#1
1 commit
expand
collapse
add appview RFC
expand 0 comments
bates64.com
submitted
#0
1 commit
expand
collapse
add appview RFC
expand 2 comments
thank you!
- I really like your summary of the status quo and I think we should incoporate into the RFC, perhaps verbatim
- 'GitHub with Tangled' I think you mean replacing our git forge, GitHub, with Tangled - but I'm being kinda pedantic
- In the long term we could look at dropping itch.io for our own mod browser and jam system but thats a long way off and not really necessary
- "all that other communities would need to do is fork our software solution" - yep! if we provide decent docs for how to set up the infra. we could potentially design the appview/scopes in a modular way if you could see this being useful for other communities of a particular archetype (e.g. we make "steam for atproto" as the backend and then just skin that, rather than making paper mario specific features), although im hesitant on this because it means designing for users that dont exist (yet)
- The Case for Privacy: yes, this is a problem. it's one that the bluesky team are working on ('permissioned data') but there is no roadmap yet. I think we can encourage people to use whatever git forge they prefer (e.g. github) until this feature is done, and we can revisit it later down the line instead of trying to solve a problem that should get solved for us eventually.
- Slow Adoption: 100% i see this being an issue for forums part. it may be that, with the discord admin team's support, we close down some channels here and direct people to the appview (the work in progress mods channels, for instance, is better served with a kind of devlog system similar to itch). we should do this later down the line instead of forcing people to migrate while its still in alpha. for the mod browser thing, we close down the released channels here and then have a steam-like homepage and player UX is much better than 'join discord and download a bps and put it on this patcher website', and people will come to use it, I think
- Legacy Mod Support - yeah, uploading legacy content is a fun one that we should think about eventually, but i dont think it would block an MVP
- "requiring an open-source repository for mods" - I don't think we need to make open source mods a requirement - just highly encouraged. if there is a tangled repo attached then thats great, but it can be optional. this allows closed source mods from the past to exist
- We Can't Fully Replace Discord, But That's Okay - 100% agree, and this isnt a goal
- 2000s Forums Are Called That For a Reason - worth looking at Discourse as an example of a modern forum. https://users.rust-lang.org/
- Optional GitHub Support - I see some complexity with this but it highly depends on exactly what counts as a "mod" in the lexicon, and is something we can solve in a later RFC I think
- Event Support / Mod Collections - yep. scratch has these and they work well
- Discord <-> AT-Proto Bridge - I think I disagree with this. it's a lot of work for little gain and discourages people from actually checking the site. at best we could have a #forums channel that posts a message for new forum posts via a webhook. maybe down the line we can have our own discord bot that provides deeper integration (e.g. if there is a ranking system on the forums, we can map it to discord roles). chat can remain on discord, and we can do mobile support on the site as a first class feature
- What about the docs? - yes, it makes sense to keep it as it is for now besides migrating the source to tangled. we can talk about making it easy to edit the docs pages on the site directly (like mediawiki) at a later stage
- Scalability - "for the short-term it is likely best to focus on what would make this work for Star Haven specifically" I agree, although before a 1.0 we should be careful to not set any lexicon in stone that is super specific to us if we intend to open it up in future
Summary#
I'm on board! But, a lot to consider for a project of this magnitude and for a community as unique as the Paper Mario Modding scene.
Current Solution#
Synopsis#
Currently, Star Haven is used as a central hub for Paper Mario modding, except for when it is not and breaks off into smaller sub-communities (Modern Paper Mario Modding, WUA, NicTube and Lily's mods, etc.) or when users migrate to larger platforms (Itch, or formerly romhacking.net)
Star Haven facilitates general chat, private chats, individual mod and game discussion, general modding assistance, mod release notifications and community events.
How Did We Get Here?#
Some modders have the social capital to promote, release and discuss their mods in their own bespoke communities and have no need for a centralised modding hub. Some modders even get news coverage when they release their mods!
However, such modders are the exception rather than the rule! Initially, most modders bounced around various forums until landing in Star Haven's Discord server, where they continued to develop and release their mods.
How does Star Haven facilitate mod development?#
Star Haven's Discord Server holds the largest repository of modding advice, through years of Discord chats and real-time assistance from experienced modders.
Additionally, Star Haven acts as an aggregation service for modders to publish their creations to a wider audience with relative ease, providing either a thread or a bespoke channel dependent on the mod's popularity.
On top of that, Star Haven aggregates and hosts modding tools, as well as similar help channels for said tools.
Star Haven also uses Discord and Itch.io to host regular jam events, where modders create teams to create themed mods in a certain timeframe.
What else do modders use?#
Modders use GitHub to collaboratively develop their mods, private Discord servers to facilitate development chats and voice-calls, and Itch.io to publish their mods.
Offline, modders use a wide variety of tools such as Star Rod, Mamar, Unsimplifier and more.
How does Star Haven assist mod players?#
Star Haven provides an avenue to discuss mods, the Paper Mario games, ask for help on a per-mod or a general basis, or have a general chat for most players.
Additionally, we offer a list of mods in the Discord, and the aforementioned broken mod browser on starhaven.dev/mods.
Is any of this ideal?#
Not really! The community is splintered across multiple technologies and platforms that do not neatly integrate with one another, limiting most modders' reach to a single medium-sized Discord server.
That and everyone quite dislikes Discord.
The Proposed Solution#
Synopsis#
We replace the Discord Server with Star Haven Forums (built atop at-proto), GitHub with Tangled, and Itch.io/GitHub with Star Haven Mod Browser 2.0. All of this is hosted at starhaven.dev!
What's Good For Star Haven Modders?#
The removal of reliance on closed-source, walled garden technologies allows us to exist as a self-sustaining community indefinitely, tailoring the platform we use to our individual community needs!
The use of open-source, federated technology also allows other communities to fork our work in their own endeavours to replace Discord in their usage.
Hosting all of Star Haven on the open web allows for easy searching of modding information, mods, and to contribute to our community without a Discord account.
We can have a bespoke theme for our forums, making the user feel more at home.
A non-Discord mod browser allows for much greater modder control of how their mods are promoted and advertised, providing descriptions, updates and promotional material all on the same page!
Integration with PM-DX (and further tools down the line) makes this a no-brainer as a future goal, because it enhances the developer experience.
What's Good For Star Haven Players?#
A modern, professional mod browser removes the reliance on Discord for viewing, downloading and playing mods, and allows users to find mods without scrolling up through discord channels to find them!
Would this be good for the greater Paper Mario Modding Community?#
It's likely! If the forums and mod browser are federated, then other sub-communities will be free to host their own PDS, allowing them to leverage our mod browser and forums while still maintaining separate communities.
Would this be good for other modding communities?#
Also likely! If I'm understanding correctly, all that other communities would need to do is fork our software solution, adapt the theming for their own game or platform, and then they would be able to host a similar solution!
Many modding communities are stranded in Discord servers that become difficult to find over time, and so a federated, web-based solution such as this could breathe new life into otherwise forgotten modding communities, as well as allow their mods to live on post-shutdown.
The scalability and federation of at-proto would allow for even larger mod aggregate sites, that aren't at the risk of shutting down and losing all mods like romhacking.net.
Considerations#
The Case for Privacy#
Most modders work in secret until they're ready to release their mods. An open, fully-public platform such as Tangled (and at-proto at large) removes the ability for modders to do so.
This clashes with the approach taken for Jams, where modders all keep their repositories private until it is time to release their mods.
Slow Adoption#
I say this with love, but the Paper Mario Modding Community is very slow to adopt new technologies. Decomp has been out for years and years, yet modders prefer to backport features from Star Rod Decomp to Classic in many cases!
This (typically) isn't due to modders being stubborn, but oftentimes older solutions have answers to problems that the newer solutions don't account for.
Classic->Decomp is a conversation that's been done to death, with every second person providing a reason to stick with Classic despite the technological superiority in most aspects of Decomp.
If users cannot access the full suite of features they have come to appreciate about even inferior platforms such as Discord, it is unlikely that they will move over, partially or in full. As a community platform is only as good as its users, if nobody moves, the work would not benefit Star Haven!
That, and the closer we stick to the Discord model, the less we benefit from the move. For example, if we were to port #pm64-modding directly over as a forum thread, people would be able to search for strings of text, but not for topics. This is not that much better than using Discord!
Additionally, channels like #star-kids may also need to be dropped entirely, as they don't really map to the forum model, which creates friction which some may object to.
As such, user behaviour would need to change slightly - instead of talking in a general modding thread, they might need to create a thread to ask questions. Thankfully, with control over the appview, we can make this as obvious, simple, and fast as we need to. Off-topic conversation may coalesce into one general thread (or even an IRC channel...), which likely doesn't need to be scrapable by search engines.
Legacy Mod Support#
As users require accounts to publish mods, it is unlikely that we will see the full Paper Mario Mods catalogue available on Star Haven for some time, unless we reach out to other communities or retired modders.
Additionally, requiring an open-source repository for mods released years before this became standard practice limits the ability for us to serve legacy mods to users, which is something the Discord Server still supports (i.e. the Pro Mode download link is still hosted with us.)
We Can't Fully Replace Discord, But That's Okay#
Star Haven Forums would not be able to support voice chats, screen-sharing or private modding chats. That's okay, because people tend to do this in private modding servers anyway! It does however mean that modders will be using Discord to mod collaboratively, and Star Haven to publish mods.
I don't think there's a way to fix that short of hosting a federated Discord alternative (that also supports invite-only servers and mobile support), but we're already hosting three services as is and I don't want to keep stressing out poor Kuribo.
2000s Forums Are Called That For a Reason#
I love the 2000s forums look! However, it fell out of favour for a variety of reasons, notably accessibility reasons and mobile support.
We can still achieve a personalised, homely look - Mario Fan Games Galaxy and Spriters Resource achieve this with custom icons, banners, fonts and palettes, but it would be wise to take cues from modern sites to ensure that Star Haven remains as accessible as it can be for all players and modders.
That, and a bespoke design gives us the opportunity to create a modern, mobile-supported look to go alongside the modern technologies we're employing.
Potential Addendums#
Optional GitHub Support#
To my understanding, while private repos are in the works for Tangled, they are not yet available. If we happen to release a version of starhaven.dev before they are available, we should allow users to link GitHub repositories to their mods until we can properly replace GitHub's functionality.
Event Support / Mod Collections#
Events are really just collections of mods with a synchronised release date. We have a lot of mod collections anyway (Master Quest, Paper Dank Rave, the Holiday Specials) and so we would benefit from including support for them, as it's something that the Discord and Itch facilitate that this proposed solution does not, yet.
Discord <-> AT-Proto Bridge#
If we can't bring Discord users to the site immediately, we can still absolutely bring over their messages! And vice versa, with webhooks.
However, this bridge would mean that, in the early days, nobody would be punished for using the site as an early adopter, which would accelerate adoption of the site.
Inversely, a Discord bridge also allows mobile users to remain able to post to the forums while we sort out a suitable solution for a mobile version of the forums.
In the event that Star Haven chat remains on Discord, this also allows us to have the best of both worlds, leveraging the only thing that Discord is really good for!
Moderator Simplicity#
I assume the same people who moderate the server will be moderating the forums. We should strive to make doing both as seamless as possible for them.
What about the docs?#
Will we be including Star Haven's tool documentation in this solution, or will that remain as a unique system?
Scalability#
Because we're already making considerations for seven different games, each with their own modding tools, it is likely that our forums and mod pages are game-agnostic.
Similarly, if we provide the ability to host mods and users from separate PDS servers, this technology may easily be of great use to every modding circle looking for a Discord replacement!
This justifies the time-sink it would take to create a bespoke software solution for about 20 users, as all of a sudden our work becomes useful to Every Modder Ever.
However, this does mean that some unresolved questions (hardcoding categories makes less sense in this context) become easier to solve, but provide us with less flexibility in making changes for ourselves.
As such, for the short-term it is likely best to focus on what would make this work for Star Haven specifically.
Conclusion#
Yeah this is something I'd like to contribute my time to setting up this community is just a little unique with it sometimes 👍