Asobu 0.1.7

Show friend requests as they arrive, instead of a minute later

The list polled once a minute, so a request sent to somebody sitting on the
friends page took up to sixty seconds to appear. Reopening the drawer forced a
fetch, which is why it looked like nothing arrived until you did.

The server now holds a watch request open until something changes, and every
change wakes every watcher at once by closing a channel they are all waiting on.
Measured against a running instance: a request reaches the other side nine
milliseconds after it is sent, against sixty seconds before. A quiet spell ends
after twenty seconds and is asked again, which doubles as the heartbeat that
keeps presence fresh, so nothing is left running on a timer.

Presence deliberately does not wake watchers, except when somebody comes back
from being offline. A launcher left open all day would otherwise wake everyone
once a minute to tell them nothing.

A watch waits only while the caller is exactly up to date. Behind means there is
news now; ahead means this server restarted and began counting again, and
waiting there would leave a launcher holding a number this server will not reach
for hours.

Verified through Caddy as well as against the backend directly, since a request
held open for twenty seconds is the sort of thing a proxy decides to have
opinions about.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Asobu 0.1.6

Say on the website that instances can be shared

The launcher gained sharing and the site did not mention it. More to the point,
the privacy page listed everything the server holds and that list is no longer
complete: share codes are kept there too.

Codes get their own section, because what is in one is the part worth knowing.
It holds an instance's mods and packs by hash and no download addresses at all,
which is why importing one can only ever fetch files Modrinth or CurseForge
already serve. Worlds and the config folder do not travel, so a code cannot
carry a save or a server password somebody forgot was in there. Seven days, then
deleted rather than archived, and a code can be withdrawn early.

Also says plainly that whoever holds a code can pass it on, which is obvious
once stated and easy not to think about beforehand.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Asobu 0.1.5

Share an instance as a file or as a code

Sharing now asks which, in the same two doors as the new-instance and sign-in
sheets. The left one saves the zip that already existed, which any launcher can
open. The right one asks Asobu for an eight character code that lasts a week.

A code is a list of files identified by hash and by nothing else. Importing one
resolves each hash at Modrinth, then asks CurseForge by fingerprint about
whatever is left, and downloads from there. The manifest contains no addresses,
so a code cannot make somebody else's launcher fetch a file of the sharer's
choosing; the worst it can name is something that does not exist, which is
reported rather than skipped.

Only mods, resource packs, shaders and data packs travel. Worlds and config stay
put: a world is not the recipient's to receive, and config is where people keep
server addresses and passwords.

Paths are checked again here even though the server checked them when the code
was made. The two are not the same trust, and this is the side that creates
files. A path that escapes the instance is the difference between a shared pack
and a way to write anywhere on a stranger's disk.

Verified against the live API end to end: a code comes back and lasts seven
days, asking again returns the same code with its week wound forward, a renamed
copy shares as the original, adding one mod produces a different code, and
withdrawing one takes it away. Separately, seventeen checks that config and
saves never leave the machine and that eight hostile paths are refused.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Asobu 0.1.4

Scope Explore to a Minecraft version rather than an instance

Explore is for finding out what exists, which is a question about a version.
Asking for an instance first meant a fresh install opened it to an empty page
and a note telling them to go away and make something before they could look
around -- exactly the person most likely to be looking around.

It now offers a version the way Browse does, drawn from Mojang's manifest with
whatever your instances run pushed to the front, and defaults to the newest
release when there are no instances at all. Where a mod ends up is asked when it
is added, by the sheet every other page already uses.

No loader filter comes with it. A version is not a loader, and Explore no longer
knows one -- so it shows what exists for that version and leaves the fit to the
install sheet, which checks it properly.

The startup warm-up is keyed to match: it primed the old query including a
loader, which after this change would have warmed a search the page never makes
and quietly cost the instant first paint it exists for.

Verified against a launcher with no instances: 70 mods for 26.2, and switching
version re-queries.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Asobu 0.1.3

Copy the sign-in code from the welcome, automatically and by hand

The device code has to be typed into a page in another window, which is the one
fiddly step in the whole welcome. The Accounts page has copied it for you since
it was written; the welcome, which is where most people will meet the flow for
the first time, made you read eight characters off the screen.

Same behaviour, same wording, same button: copied the moment it appears, with a
button to do it again and a line saying which happened. The clipboard hangs off
the window rather than the view model, so the copying lives in the view and the
view model only hears that it happened.

Both views can watch the same accounts page safely -- only one of them is ever
mounted while a sign-in runs, since the welcome covers the whole window and the
Accounts page is not built until it is navigated to.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Asobu 0.1.2

Make the installer splash the launcher's own opening

The splash led with the logo and its own wording, so installing Asobu and first
running it read as two screens that happened to share a colour. It is now the
same two lines the launcher opens with -- "Welcome to" over the name -- in the
same sizes, the same weights and the same pink.

The launcher animates those lines in; this holds them. Velopack shows the image
for as long as the install takes and loops it, so a fade-in would restart over
and over in front of whoever is watching. What moves instead is a glow behind
the name, breathing on a sine across the frame count so the loop has no seam.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Asobu 0.1.1

Give Asobu an icon, an installer splash, and a dotted data folder

The launcher had no icon at all: Explorer, the taskbar and Alt-Tab all showed a
generic one. assets/make-brand-assets.py draws the mark the sidebar already
draws -- same rounded square, same offset play triangle, same accent -- at every
size Windows asks for, so the icon cannot drift from the app it belongs to.

The same script draws the installer's splash. Velopack's setup is one-click by
design, with no wizard to design: what it does show is a picture, so that is
where the welcome starts. Dark, pink, the mark and the name, with a halo that
breathes on a sine over the frame count so the loop has no seam -- an install
lasts a few seconds and the image is shown throughout, so anything that
restarted visibly would blink at whoever is watching it.

Data moves from %AppData%\Asobu to %AppData%.asobu, next to .minecraft and by
the same convention. An existing folder is renamed rather than left behind, and
a folder something still holds open is used where it lies rather than being
abandoned for an empty one.

ResolveIn takes the roaming folder as an argument so this is testable. It was
not before, and the test that appeared to cover it set the APPDATA variable --
which Environment.GetFolderPath ignores, so the test read the real profile and
proved nothing about the code.

Asobu 0.1.0

Fix the release guard that would have failed every build

The step that checks a built release actually contains the CurseForge key used
Select-String -Encoding Byte to grep the DLL. There is no byte mode: -Encoding
takes a character encoding and rejects "Byte" by validation, so the step would
have failed on a parameter error before checking anything -- and taken every
release with it, whether or not the key was there.

Reads the file as bytes and searches the raw text instead. Verified both ways:
it finds the attribute in a build that has one, and does not in a build that
does not.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>