v0.9.7

Added

• Privacy settings you can actually set
  (#367,
  stellar-api#586) —
  the Privacy tab now carries the five show* controls: email address,
  last-seen time, contributed stats, consumed stats, and ratio/buffer.

  These existed in the contract and were accepted by the api all along, but no
  control could ship: PUT /profile/me cascaded the paranoia level over them
  on every save, and this form posted a level every time — so five checkboxes
  would have arrived inert. api#586 removed the level, so a ticked box now
  reaches the database.

  Four preset buttons tick the boxes as a starting point, matching the levels
  members had before. They leave no trace: the server stores only the five
  booleans, so a preset is a convenience, never a mode you are stuck in.

Changed

• The paranoia level radio is gone
  (#367,
  stellar-api ADR-0046) —
  UserSettings.paranoia no longer exists in the contract, so the four-level
  radio and its "Current: Level N" readback are replaced by the checkboxes
  above. No privacy setting changes value; the level was only ever a way of
  writing these five.

  showMatureContent stays where it is, on Appearance. It governs what you
  see rather than what others see of you, and that separation outlives the
  level it was originally excluded from.

• The vendored contract catches up with stellar-api main — it picks up
  the registrationFull description added by
  stellar-api#657,
  which stopped conditioning reported capacity on registrationStatus.

  No generated type changes shape: src/types/api.ts gains one JSDoc
  line and nothing here needed rewriting. The sync is owed all the same, so
  that the vendored contract does not sit behind main untracked.

  It also retires a comment in Register.test.tsx that had gone false. The
  "closed site that is also full" case was written as a defensive check on a
  state the api could not then produce. The api produces it now, so that test
  covers a real state and its branch ordering is load-bearing.

• The vendored contract picks up the seventh invite send gate
  (#358) —
  stellar-api#673 added
  registration_closed to the invite eligibility reason enum, and named the
  new refusal in the 403 on POST /profile/referral/create-invite.

  No component needed changing. InviteForm renders the api's msg and
  never switches on reason, which is what stellar-api's ADR-0043 intends —
  the api owns the words, so the member-facing string arrives for free.

• The vendored contract catches up with stellar-api 0.9.7
  (#358) — it picks up
  two api changes that need no UI code yet:

  • POST /communities/{id}/members takes an optional role
    (stellar-api#709).
    It defaults to consumer, which is what the current form admits. The
    picker that sends it is
    #373.
  • GET /contributions/{id} no longer declares a 403
    (stellar-api#700).
    A contribution the viewer cannot see is now the same 404 as a missing
    one. Nothing here branched on that 403.

  The notification-filter operations #358 listed were already vendored by
  #372. This sync clears
  the rest of that drift.

Fixed

• The invite key from the emailed link now reaches the form
  (#359,
  #360) — the invite
  email carries the key only inside /register?inviteKey=…, and nothing
  here read the query string. Every invited member landed on an empty,
  required Invite Key field and had to pick the key out of their own
  address bar. That is the whole invite flow on an invite-only site.

  The field is now seeded from the link and stays editable. Mail clients wrap
  and truncate long URLs, so a member who can see a mangled key is one who can
  correct it — which is why the key is prefilled rather than used invisibly,
  as the recovery token is.

  The key is also sent on an open site, where no field is rendered to hold
  it. Since
  stellar-api#675 an
  open site honours a presented key and records who invited whom, instead of
  losing the relationship; a bad key is harmless there, because the api drops
  the edge rather than refusing the registration. An open site still shows no
  invite field, since a member arriving without a key should not be left
  wondering what they are missing.

  A link with no key behaves exactly as before.

• A closed comment thread says so, instead of offering a form that fails
  (#371,
  stellar-api#697,
  stellar-api#701) —
  the api now answers 404 for a thread on a page the viewer cannot see, or on
  a deleted page. The comments panel showed "No comments yet." with a live
  form, and posting failed. It now reads "Comments are closed." with no form.
  Staff see this on a deleted collage they can still open.

• Featured shelves on a profile open for every viewer
  (stellar-api#706) —
  a personal collage linked from someone else's profile answered 403. The api
  now lets any member read one; changing it is still for its owner or staff.
  This needed no UI code, only the re-vendored contract.

Security

• Sentry no longer receives the query string of any URL
  (#361) — two routes
  here carry a credential there: /recovery?token=…, a password-reset token
  that grants account takeover, and /register?inviteKey=…. The browser
  client attaches the full page URL to every captured event, the previous
  page's URL as a Referer header, and URLs to navigation and network
  breadcrumbs. Nothing removed them, so an error captured anywhere near either
  page sent a live credential to a third party, where it is retained and
  searchable.

  All four are stripped from the first ? now. The path survives, so an event
  still says which route it came from.

  The Referer header mattered most and is the easiest to miss. It holds
  the page before this one, so a member who registers and lands on the
  homepage carries the invite key into the next error thrown there — scrubbing
  only the current URL would have left the common case open.

  Query strings are stripped wholesale rather than by name. stellar-api
  redacts its one credential parameter by name; doing that here would
  reproduce the bug being fixed, since this gap exists precisely because
  nobody revisited the scrubber when a second credential-bearing URL appeared.
  The query strings in this app are browse filters and page numbers.

  beforeSendTransaction is wired to the same function. It does nothing today
  — no sample rate is set, so no spans are sent — but the same integration
  writes full URLs onto spans, and enabling tracing later would otherwise
  reopen this silently.