Signing in on a fresh install said "Your session expired. Sign out and back
in to keep going." — advice that cannot work, because signing in again hits
the same rule and says the same thing. There is no way out of that loop from
inside the app.
RelayAccounts mapped 401 and 403 to the same Unauthorized. They are not the
same: 401 means the token was refused and signing in again IS the fix; 403
means a rule refused this — too many devices, a retired device, an
unverified address — and the relay writes a sentence naming which one and
what to do about it. RelayClient already made this distinction; RelayAccounts
did not, so which client a path happened to use decided whether its refusals
were legible.
The 403 sentence now reaches the screen instead of "That isn't allowed on
this server", which replaced an answer somebody could act on with one they
could not. Only when it is really a sentence: a JSON fragment or a bare code
keeps the generic line rather than putting a payload on screen.
Predates tonight's merges — checked against fa92581 — and is why a sign-in
failure could not be diagnosed from the device.
🔴 **Off by default, and that is the honest default rather than the lazy
one.** An unsealed send is still end-to-end encrypted; what leaks is
that this account sent something to that one. Refusing turns a metadata
leak into an undelivered message, which for most people is the worse
outcome — so the default degrades and says so, and the refusal is there
for the people who would rather a message did not go than go
attributable.
The counters answer a question nobody could ask before. `Sent.sealed`
says whether one send was sealed; the record says how often this happens
to you, which is what somebody actually needs to decide whether the
switch is worth throwing.
⚠️ Refusing costs nothing: `sealed` is false exactly when neither a
capability nor a key was found, so there is no token to hand back.
⚠️ Both the policy and the counters are wired in ONE helper called from
both sign-in paths. Two call sites building a `Session` and only one
applying the policy is how a setting silently stops working on one of
them.
Taken by hand rather than cherry-picked — the original also rewrote a
ChatScreens that has since changed underneath it. The settings switch
for it is UI work still to come.
The reporting path, taken by hand — the original commit also rewrote 318
lines of ChatScreens against a story feed that no longer looks like that.
The UI control comes next; this is the part underneath it.
🔴 **A report is the one thing in this app that leaves readable.** The
relay cannot open a sealed story, so a report about one is only
actionable if the reporter hands over what they saw. That is the point
and the cost, and it means the consent has to name the consequence —
`reportStory` does not ask, and must never be reached from a control
that does not.
⚠️ It sends only what it is passed, and never reaches into the thread
for surrounding context. §6.25 forbids including anything the reporter
did not choose to include.
⚠️ The reasons are enumerated to match the relay. A reason the relay
rejects is a report somebody believed they had filed.
The message afterwards says what will and will not happen: whoever runs
the server sees it, and you are not told what they do. Promising an
outcome we cannot observe would be worse than saying nothing.
Taken by hand, like the two before it — the original was cut from a tree
whose text stories and story replies differ from this branch's.
🔴 The group's roster is the audience, and the story audience does NOT
apply. Those are two different lists making two different statements —
who may see this account's stories, and who is in a conversation — and
they will disagree. The roster wins, because a story addressed to a
group that silently dropped members would be a group message part of the
group cannot see.
`groupStoryReach` returns that overlap rather than a warning. A sender
who believes their story audience still applies is being misled by the
interface, and a disclosure that cannot name the consequence is not one.
The two categories deliberately do not double-count: somebody who is not
a contact was never on that list to be excluded from.
🔴 On receipt, a claimed group id is checked against our own roster. A
story is caught before the group-message branch, so without that check a
sender could attach the id of a group they are not in and have their
story shown as having come from it. The claim is dropped to null rather
than the story refused — the story is legitimately theirs; only the
claim about where it was posted is unverified.
⚠️ `gid` names the audience, never a destination. Rendering a group
story into the group's messages would make a story into a message, and
one that never expires out of it.
Taken by hand rather than cherry-picked, for the same reason as the
archive: the original was cut from a tree where text stories looked
different from the version rebuilt on this branch, and applying it whole
would have added a second `isTextStory`/`storyExpiry` beside the
existing `textStoryExpires`.
What came across is the sequence and nothing else — the `StorySet` wire
shape, the field on a story, and the two rules that decide how a set
behaves when it does not all arrive.
🔴 One envelope per item, sharing one set id. An array of attachments in
a single envelope is the obvious encoding and degrades badly: a client
predating §6.23 requires a single `att`, fails the guard, and renders
the whole set as a message in the conversation. Separate envelopes
degrade to several stories in order, which every existing build already
draws correctly.
🔴 `setExpiry` takes the EARLIEST. Every item is required to carry the
same `exp`, but a sender can write different ones — and if the latest
won, the difference would be a way to keep part of a sequence alive
after the rest had gone. A text story has no attachment and contributes
nothing, so one in a set cannot drag the shared expiry to zero.
⚠️ `groupedStories` renders what arrived. `n` is the sender's claim and
any item can fail to arrive, so a set is never held back or shown as
incomplete — a missing item is indistinguishable from one never sent.
777 tests green across app, engine and client, up from 648.
Reinstates ios#54, taken by hand rather than cherry-picked. The original
commit was cut from a tree where story mute, text stories and story
replies all looked different from the versions rebuilt on this branch
today, so applying it whole would have left two implementations of each
under different names — no compile error, and exactly the kind of
divergence that rots quietly.
What came across is the archive and nothing else: the `archive()` rule,
the store, the sweep, and the setting.
🔴 The rule refuses anything not the author's own, and it does so in the
engine as well as at the caller. An archive holding somebody else's
expired story breaks the promise the app made to them, and "it is
private to you" does not repair that.
⚠️ The sweep runs at the one moment it can. Expired stories leave on
write, so if they are not caught before `saveStories` they are gone —
which is correct for everybody else's and wrong for your own.
`archiveEnabled` is injected rather than read from a context, because
this layer has no Android dependency and an unset value has to read as
OFF. This is a feature that keeps something the interface said would
disappear, so it stays off until somebody asks for it.
Vault story serialisation is now shared between the live set and the
archive rather than written twice.
Android half of ios#34. A story disappears from its author's own device
too, so there was no way to keep something you made.
🔴 Only ever your own, and the rule is `Vault.isSaveable` rather than a
condition on the menu item. Saving somebody else's story keeps a copy of
something they were told would disappear — the opposite of what the
feature promises them — and a guard living in a composable is one
refactor away from being lost. Tested from both directions.
⚠️ Written through MediaStore, so no storage permission is asked for. An
app inserting its own entry needs no runtime grant on any version this
app supports; asking for WRITE_EXTERNAL_STORAGE in order to save one
picture would request read access to everything the person has, to
perform a write.
⚠️ The message says the copy has left the disappearing model and names
where it went. "Saved" alone would be true and useless — somebody not
told that may reasonably assume the expiry still covers it.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Codec only — the app does not pin yet — but without this branch an
inbound pin falls through parse to the attachment path and comes back
renderable, so every pin the iPhone app sets would draw an empty bubble
in the conversation.
isRenderable excludes it for the same reason it excludes a reaction, and
it is NOT in Kind.CONTROL: a build that swallowed it as generic control
would drop every pin while looking like it worked.
🔴 The envelope carries an id and never a copy of the message. A pin
carrying the text would keep a message readable after its own timer had
removed it, so pinning would quietly defeat disappearing messages.
Refs paulhitt/flamenet-messenger-ios#50
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
🔴 There is no index, and that is a decision rather than an omission. An
index derived from decrypted history is plaintext by another name: it
would have to be sealed as carefully as the vault, taken by
forgetEverything, and kept consistent with the threads — a second copy
of everything anybody ever wrote, with its own ways to go wrong. This
reads what already exists and throws the plaintext away.
⚠️ It costs more here than on iOS, and the code says so. The iPhone app
keeps the whole decrypted history in memory; Android decrypts each
thread on demand. Hence a two-character minimum, a bound, a 250ms
debounce, and Dispatchers.IO.
🔴 Folding is length-preserving on purpose: the snippet slices the
ORIGINAL string at an index found in the folded one, so a fold that
dropped characters would cut in the wrong place — and for an accented
character, mid-character. There is a test with accents before the match.
Accent-insensitive because somebody typing "cafe" means "café", and a
search that knows the difference quietly fails in every language with
accents — Spanish is next on the localisation list.
Refs paulhitt/flamenet-messenger-ios#25
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The rule that keeps this from making the product worse: the shorter
timer always wins. Without it a sender could defeat the recipient's
conversation timer by putting a long secs on every message — turning a
setting the recipient chose, on their own device, into something the
other party overrules.
🔴 pruneExpired returned early when the CONVERSATION had no timer, so a
timed message in an untimed thread would have been kept for ever — the
feature working on the sending phone and doing nothing on the receiving
one. Pruning is per message now.
⚠️ Content.text returns raw bytes with no envelope when it has nothing
to carry, so the timer had to join that decision or it would be dropped
and the message would live for ever.
The sender's own copy expires too: a timer that only cleared the
recipient's phone would leave the message with the person who set it.
Refs paulhitt/flamenet-messenger-ios#29
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Android half of ios#36, spec §6.27. `shot` joins the control kinds, so a
build that does not know it stays quiet rather than rendering JSON.
🔴 The care is in refusing to let the absence of a notice mean anything.
The device that took the screenshot reports it, so a modified build, a
second phone, or a screen recorder produce nothing. A notice means one
was probably taken; no notice means NOTHING, and nothing counts them.
⚠️ Android's half of the asymmetry is stated rather than hidden. There is
no screenshot callback at all before API 34, and the one added there does
not cover screen recording — so the disclaimer says that, in those words.
Claiming a symmetry with iOS that does not exist would be worse than the
gap, because somebody would rely on it.
⚠️ Only where a timer is set, and the timer check comes before the
rate-limit check so a suppression window cannot make an untimed
conversation start reporting.
⚠️ Last-notice times are in memory. Persisting them would store who
screenshotted whom on disk to enforce a five-second window.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
🔴 The wire always carried both and Session.Line never stored them.
Content.groupText has taken a messageId since §6.9 shipped and parse
reads it back — the transcript was where it stopped. So nothing here
could name an earlier message: no replies to resolve, no reactions to
fold, no edits to apply. All three were "codec done" and none worked.
A reply from the iPhone app arrived as a bare message with the quote
silently removed, which is worse than the missing id: the reader had no
way to know anything had been dropped.
🔴 Also fixes a real bug in sendGroup. It built the envelope twice —
once to send, once for the outbox — so an id minted inside either would
differ between them, and a member who was offline would eventually
receive a DIFFERENT message from everybody else, which nothing could
reconcile with a reply or a reaction. One id, minted by the caller, used
by both.
Both fields written only when present: a null on every message would
grow the transcript for nothing and make "no id" indistinguishable from
"an id of nothing".
Refs paulhitt/flamenet-messenger-ios#58, #10
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
An inbound forward is shown as one rather than as the sender's own
words. Both flag shapes accepted, like ctl: org.json's optBoolean does
not coerce a number, so an engine reading one shape would silently miss
every forward the other two send.
⚠️ The subtle one: Content.text returns raw bytes with no envelope at
all when there is no id, reply or link to carry. A forward that was not
counted in that condition would lose its flag and arrive looking like
the sender's own composition — so is part of the test for
whether an envelope is needed, not just a field inside it.
Codec only. Originating a forward needs the transcript work in #10.
Refs paulhitt/flamenet-messenger-ios#28
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Without this branch an edit falls through parse to the last case, which
returns the caption as text — so an iPhone correcting a typo appears on
Android as a SECOND bubble beside the original, with nothing to say
either replaced the other. That is the bug this fixes today, before any
of the applying half exists.
isRenderable excludes it for the same reason it excludes a reaction, and
it is NOT in Kind.CONTROL: a build that swallowed it as generic control
would drop every correction silently, which is worse than the duplicate
because nobody would notice.
⚠️ Codec only. Session.Line records no mid, so nothing in an Android
transcript can be named by an edit and the app cannot apply one. That is
the same gap reactions have been sitting behind (PARITY.md "codec done,
no UI") and one transcript change unlocks replies, reactions and edits
together — filed separately.
Refs paulhitt/flamenet-messenger-ios#26
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Sealed in the vault, not in SharedPreferences — and that is the whole
point. A draft is plaintext the person has not decided to send, very
often the most sensitive text in the app because it is the thing they
are still weighing. SharedPreferences writes readable XML that survives
into backups; the vault seals it under the conversation's own key with
the record name bound into the AAD, and forgetEverything takes it on
sign-out. There is a test that asserts the bytes on disk do not contain
the text, because the wrong implementation would pass every other test
here.
Keyed by the same threadFor* ids the transcript uses, so a group called
"7", the contact who is user 7, and the address "7" are three
different drafts.
Every write to the composer state goes through one setDraft: send clears
it by assigning directly in three places, and any one of those that
forgot to clear the stored copy would bring the message back next time
as a draft of something already sent.
Closes#47 on iOS side; Android half of the same feature
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The two live sign-up tests guarded themselves with a bare `return`, so
without `-e live true` they finished immediately and reported PASSED. A
test that did nothing and says it passed is worse than one that did not run:
a suite of those is indistinguishable from a suite that works, which is the
only reason to run it.
`assumeTrue` instead, with the message saying how to opt in. Assumed-out
shows as skipped, so the count reflects what was actually exercised.
The iOS side already had this reasoning written down; Android had the
comment's opposite.
Compiles: :app:compileDebugAndroidTestKotlin.
The relay can charge a few seconds of arithmetic before an account
exists — cheap for one person, expensive for a farm, and unlike a
CAPTCHA it hands nothing to a third party. This is the Android half,
matching the iPhone app.
Asked for only when the relay refuses without one, so a relay with the
feature off — every relay running today — still sees exactly one
request. Rethrown rather than swallowed when this app cannot answer: a
difficulty above the cap leaves it genuinely unable to sign up here, and
"update the app" is then the true sentence.
Two refusals get their own sentences. challenge_required means the app
is behind its server; challenge_failed is nearly always a challenge that
expired while somebody was typing. Sharing one message would send half
these people to the Play Store for nothing. Decided by the relay's code,
never the status, because a 400 is also a bad email.
The bit counting is pinned to exact vectors. A byte-counting
implementation still SATISFIES a 9-bit difficulty — it overshoots to 16
and does 230x the work — so an assertion about "at least 9 leading
zeros" cannot see the bug.
Refs flamenet-relay#39
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Client half of flamenet-relay!13, which gates a relay token on a proved
email address.
🔴 **Without this the refusal is indistinguishable from a broken
password.** An unverified account arrives as a bare 403; `RelayAuth` logs
"minting failed" and falls back to Basic, which the e2e routes refuse. So
the person sees calls that do not work and an inbox that does nothing —
and nothing anywhere says the remedy is a code sitting in their inbox.
⚠️ **The status alone is not enough.** 403 is also "that device belongs
to another account". Telling somebody to check their email for that would
send them looking for a message that was never sent, so the relay's own
`code` decides, not the number. A 403 with no code, an unparseable body,
and the same code on a 500 all stay generic — three tests hold that.
`RelayAccounts.verifyEmail` spends the code. Unauthenticated on purpose,
exactly like reset confirm: the code IS the proof, and requiring a
session would mean somebody kept out *because* they are unverified could
never get in.
⚠️ **Kotlin nests block comments**, so a slash-star written inside a
KDoc — as part of a route glob — opens a comment that never closes and
takes the module down with ninety unrelated errors, none of them near the
real line. Cost twenty minutes here; there is now a note in the file.
Five tests, proven able to fail: removing the code check turns three red.
All three Android suites pass.
🔴 **A 409 is not always a taken handle, and this said it was.** The relay
answers 409 for a taken handle, an already-registered email, AND — since
flamenet-relay!11 — a handle too close to an existing one. Three problems
with three different fixes, all reported as "that handle is already
taken".
Somebody whose EMAIL was already registered was told to pick a different
handle. Doing so cannot work, and nothing anywhere would have told them
why. That is a pre-existing bug, not something the new refusals
introduced; adding a third meaning to 409 is what made it visible.
400 was worse. Every format refusal — a short passphrase, an unusable
email address, a disallowed handle — became "the account service returned
400", which is not a sentence anybody can act on.
The status is the transport's opinion. The `code` in the body is the
relay's, and it has always been sent; nothing here ever read it.
⚠️ **Unknown codes still refuse.** A relay newer than the app is the
normal case, so an unrecognised code falls back to the status rather than
to success — an account the server never created would be a much worse
failure than a vague message.
⚠️ **An unparseable body cannot throw.** A proxy returning HTML on a 409
must still be a refusal, not a crash.
Five tests, proven able to fail: collapsing 409 back to a single meaning
turns four of them red. All three Android suites pass.
Pairs with flamenet-relay!11 and flamenet-messenger-ios!45.
Reactions, edits and pins have all sat in the codec with no way to reach
them, and the reason was the same in each case: they say "this one", and
an Android message had no id to point at. 1:1 text went out as the raw
body — cheaper on the wire, and it cost all three features.
Every message now carries one. The sent copy, the copy written into our
own transcript, and the copy queued for retry all share it: three
constructions that disagreed about the id would be three different
messages, and anything said about one would land on nothing. Inbound
messages keep the SENDER's id rather than one we invent, because that is
what they will use when they refer back to it.
Old lines keep no id and must not be given one on read. Two devices
would invent different ids for the same message, and a reaction would
land on nothing — or on the wrong thing. Those messages simply cannot be
reacted to, and the emoji row is absent on them rather than inert.
Reacting is one long-press and one tap: the five emoji are the menu's
first row, not behind a "React" item that opens a second menu. One emoji
per person, so tapping another replaces it and tapping the same one
takes it back. Applied locally before the send, because waiting on a
round trip to see your own tap register makes it feel broken — and a
failed send restores what was there before, not "nothing", which would
be wrong for somebody replacing or removing one.
Reactions render under the bubble, not inside it. They are what other
people said about the message, not part of what was written.
648 unit tests green across app, engine and client; 8 new ones pin the
id and the one-emoji-per-person rule.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The story features existed in the codec and nowhere a person could reach
them. ＋ went straight to the file chooser, so a story of words was
unreachable even though the engine could carry one; there was no way to
react, reply, mute, or see what anybody had said back.
＋ is a menu now. Reactions are a fixed row of five — a story is glanced
at and scrolled past, and anything that takes two taps to say "nice"
does not get used. Your own story shows the tally instead, because you
cannot react to yourself and a row of dead buttons is worse than none.
Mentions get an `@` picker in the group composer, matching iOS down to
the rule that matters: the id is recorded when somebody is PICKED, never
re-derived from the text at send time. Deriving it would mean typing a
name reached that person whether or not they were chosen, and renaming a
contact would silently unmention them. Only the ones still named in the
body are sent, so picking somebody and then deleting their name doesn't
ring them about a message that no longer mentions them.
A group member who isn't in your contacts has no name to show, so they
appear under their id. Un-mentionable would be worse than ugly — it
would mean a group where some people cannot be reached.
Mentions on Android are carried and rendered but override nothing: there
is no per-conversation notification mute here to override yet.
640 unit tests green across app, engine and client. PARITY.md updated —
mentions and the story features move to ✅, and Files and Wallet get rows
saying plainly that Android has none of either.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
🔴 The file bubble committed earlier today DID NOT COMPILE. It reached for
Icons.Filled.InsertDriveFile in a file that imports no Material icons at
all, and I reported it as building.
The reason it went unnoticed matters more than the mistake: ANDROID_HOME
was unset, so `:app:compileDebugKotlin` failed on "SDK location not found"
before Kotlin ran — and the check for errors was a grep for lines starting
`e:`, which a build that never reached the compiler does not produce. A
green-looking check that never compiled anything. Every Android app-side
claim I made today rested on it.
It now uses the kit's own icon set, like the rest of the file, and the app
compiles with the SDK on the path.
Alongside: Vault.Story.ref is nullable, so a story can be words. Every
path here assumed a picture, which is the same shape that made a text
story impossible on iOS rather than merely unbuilt.
⚠️ `loadStories` used `getJSONObject("ref")`, which THROWS. A single text
story would have taken down the load of every story — a feed that is
simply empty, with nothing to say why. It reads the optional accessor now,
and tells "no ref at all" (a text story) apart from "a ref that would not
parse" (a corrupt row), because those deserve different treatment.
Expiry moved onto the story, falling back to the attachment for everything
already stored.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Engine parity for the five features iOS regained: text stories, mentions,
story reactions, story replies. This build could already receive them —
legibly, because each degrades to its caption — but understood none of
them as what they are.
🔴 Every envelope in the test is the shape **iOS** assembles, not this
engine's own output. Two implementations that each only test against
themselves agree right up to the day somebody sends a real message, and
the symptom is a mention that never rings or a story that arrives as
"[unsupported attachment]", with nothing in either log to say why.
Two things the tests caught that reasoning would not have:
⚠️ Kotlin prints a Double in scientific notation, so this engine writes
`"exp":1.8E9` where iOS writes `1800000000.0`. Both are valid JSON and
both sides read either — but a story's expiry decides whether it shows at
all, and "arrived already expired" is indistinguishable from "never
arrived". Now pinned on both sides. Not a new risk: picture stories have
carried `exp` this way all along, which is the reason it works.
⚠️ An earlier version of one test built a JSONObject from an assembled
envelope and re-serialised it — which reordered the keys and moved `fnc`
off the front. It failed, correctly, and is a neat demonstration of why
both engines hand-assemble these strings instead of encoding a map.
UI comes next; this is the layer that decides whether the two apps agree
about what a message means.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
iOS can now send a document from Files. This build treated `file` as a kind
from a newer peer: legible, because a file envelope always carries a
caption naming the document, but only as text.
The engine now knows the kind, parses the additive `fn`/`cls`/`cmp` keys,
and can assemble them — so sending works in both directions, not one.
🔴 The interop test parses an envelope produced by the iOS build rather
than by this engine. Two implementations of one format that each only test
against themselves agree right up to the day somebody sends a real file,
and the symptom is "[unsupported attachment]" with no clue why. It also
pins the two rules that keep older peers working: a file envelope is never
captionless, and a photo envelope still carries none of the new keys.
⚠️ The bubble shows the classification as a MARKING. It says how the
sender had it filed; it does not mean this device was cleared for it, and
whoever can read the message already has the key.
⚠️ No "Save to Files" on this side yet — this build has no Files of its
own, so the button would be one that cannot work. Showing what arrived is
the honest half of parity while the other half is built.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Every instrumented test died with "No compose hierarchies found in the
app". MainActivity.onCreate asks for POST_NOTIFICATIONS before it calls
setContent, and the permission dialog is a separate activity that takes
focus — so the Compose rule attached to a window with no hierarchy yet.
GrantPermissionRule at order = 0, outside the Compose rule at order = 1, so
the grant happens first and no dialog ever appears.
With this, the three fixes in the previous commit, and a relay on the host,
aPersonCanCreateAnAccountOnASelfHostedRelay passes: a real account created
on a real relay, driven by test tags. That is the first end-to-end pass this
harness has produced.
./gradlew :app:connectedDebugAndroidTest \
-Pandroid.testInstrumentationRunnerArguments.relay=10.0.2.2:18810
Three separate reasons these suites could never catch a regression, all
fixed here. None of them are about the app; all of them are about the tests
being unable to report the truth.
1. A skipped test reported as a pass. Thirteen guards were bare returns —
`if (!relayReachable()) return` — so with no relay the method returned
immediately and the runner recorded PASSED. Now `assumeTrue`, which
reports SKIPPED, and the run says "(2 skipped)" where it used to say
nothing at all. Only the guards that abandon a whole test were changed;
helper loop exits like `if (found) return` are control flow and were
left alone.
2. The relay was hardcoded to relay1.flamenet.io — production. Every run
that did work created real accounts there. Now `-e relay <host>`, still
defaulting to production so an unqualified run is unchanged.
3. Android blocks cleartext HTTP, so a debug build could not reach a relay
on the developer's machine even when one was running. A debug-only
network security config permits cleartext to 10.0.2.2, 127.0.0.1 and
localhost, and nothing else. src/debug, so no release APK is affected.
Together these took the sign-up suite from "2 skipped, reported green" to
"2 run, 2 failed" — which is worth more, because it is true. What it
fails on now (no compose hierarchy at launch) is the next thing to fix.
./gradlew :app:connectedDebugAndroidTest \
-Pandroid.testInstrumentationRunnerArguments.relay=10.0.2.2:18810
Paul Hitt