Updates
Platform Updates
Public-facing release notes for meaningful changes across Furries PH operational systems.
First created Last updated
Friend Requests Respect Member Availability Privacy
Repositories: partners-api, rego.furries.ph, social.furries.ph
Status: Local implementation only; Git-connected release remains required
What’s Changed
- When a member has disabled Friends, a request now receives the same unavailable-target result as a nonexistent handle in both Social and Regosite. Guessing a handle cannot reveal that person’s connection preference.
- Members still receive a clear message about their own Friends setting. No identity, profile, contact, event, Social safety, moderation, or relationship information is returned for another unavailable target.
Validation
- The five-assertion request-privacy contract and API TypeScript check pass locally. Paired-account and Git-connected release evidence remain pending.
Friend Requests Now Have One Shared Safety Limit
Repositories: partners.furries.ph, partners-api, rego.furries.ph, social.furries.ph
Status: Local implementation only; migration/RLS and Git-connected release remain required
What’s Changed
- Regosite and Social now share one limit of ten successful new friend requests per member in a rolling hour. The limit lives with the single canonical relationship command, so changing products cannot bypass it.
- Repeating a request after a lost response remains safe: its existing idempotency key returns the original result and does not consume another request slot. When the limit applies, both products receive the same clear temporary-cooldown response.
- This does not add a browser timer, polling loop, counter service, new Worker, Pages Function, database browser access, or any change to follows, Social-only blocks/mutes, posts, event data, moderation, or notifications.
Validation
- The nine-assertion request-velocity contract and API TypeScript check pass locally. Database/RLS, paired-account concurrency, and Git-connected release evidence remain pending.
Members Can Block a Shared Friend Connection Everywhere
Repositories: partners.furries.ph, partners-api, rego.furries.ph, social.furries.ph
Status: Local implementation only; migration/RLS and Git-connected release remain required
What’s Changed
- Social and Regosite now offer a deliberately confirmed Block everywhere action for an accepted connection or incoming request. It changes the single shared relationship, removes the connection in both products, and prevents a new request until the blocker deliberately unblocks it.
- The blocker has a private list of their everywhere blocks. Unblocking does not recreate a friendship; either member must send a new request.
- This is not the same as a Social-only block or mute. It does not change Social follows, public posts, event attendance, account access, registrations, or moderation, and it does not notify the other member.
- The feature stays within the existing static Pages and API boundary: one explicit request reaches
partners-api; there is no new Worker, Pages Function, direct database access, synchronization job, or polling loop.
Validation
- The 16-assertion everywhere-block contract, 16-assertion canonical-summary contract, 13-assertion Friends-audience contract, API TypeScript check, Social typecheck/60 tests/production build, and Regosite production build pass locally. The database migration, RLS exercise, paired-account test, and Git-connected release remain pending.
Social Page Changes Reach the Moderation Dashboard Reliably
Repositories: partners.furries.ph, partners-api, social.furries.ph, moderation.furries.ph
Status: Local implementation only; migration/RLS and Git-connected release remain required
What’s Changed
- Creating a Creator, Organization, or Event Page, changing its public profile, and an owner’s confirmed archive or restore now save the Page change, audit receipt, and one privacy-minimized moderation update together. Social profile setup and public profile edits use the same atomic update path. A successful change cannot leave the dashboard without its matching update.
- Moderators see the existing Social Page and profile activity through the dashboard’s single bounded poll. The update identifies only the affected object and change category; it does not include Page or profile text, Page membership, partner-verification details, or the person who made the change.
- Adding verified images to an already-visible Social post now adds one post-media update for the whole attachment action. Private image upload preparation does not notify moderation, and the update has no image bytes, asset URL, filename, or alt text.
- Moderators can start a post, profile, or Page review directly from its update when no case exists. The dashboard sends the update reference to the API and enters the returned case without putting a Social target identifier in the review URL; an archived Page remains unavailable from public Social.
- Publishing a post with selected topics or a poll is now all-or-nothing: the post and its single moderation update appear only after those requested parts save together. Post edits and member-authorized deletion also create their own privacy-minimized update, while archiving a Page stays one aggregate update instead of a burst for its historical posts.
- A partner-authorized Event Page verification change now appears as one Page update for moderators. It does not include the event, partner, verification proof, decision reason, or staff information.
- This remains a static Cloudflare Pages integration: the Social and moderation apps use the existing
partners-apiWorker, with no Pages Function, browser database connection, realtime subscription, or direct upload.
Validation
- The 104-assertion Page-moderation contract, 12-assertion profile-activation contract, nine-assertion post-lifecycle contract, five-assertion post-media contract, dashboard typecheck/tests/build, a fixture-backed browser capture, and API TypeScript validation pass locally. The migration, database/RLS exercise, hosted dashboard check, and Git-connected release evidence remain pending.
Social Friends Respect an Explicit Profile-Presence Choice
Repositories: partners.furries.ph, partners-api, social.furries.ph
Status: Local implementation only; migration/RLS and Git-connected release remain required
What’s Changed
- Regosite and Social still use one shared friend relationship. An accepted friend now receives a Social-profile link only when that person has activated Social and currently chooses visible Social presence.
- Members can change that choice in their Social profile settings. Hiding a profile removes its Social link without removing friendships, changing follows or posts, exposing event details, or affecting the Rego account.
- Pending requests remain relationship-only: they do not reveal whether the other member has a Social profile. The static Social app makes one existing capped friendship-summary request; no database browser access, sync job, polling, or Pages Function was added.
Validation
- The 15-assertion canonical-summary contract, eight-assertion Social-activation contract, API TypeScript validation, Social typecheck, 60 unit tests, production build, and a responsive setting fixture pass locally. Hosted database/RLS and Git-connected release evidence remain pending.
Signals Local Account and Reward Flow Is Certified
Repositories: partners.furries.ph, partners-api, signals.furries.ph
Status: Local integration certificate passed; Git-connected release of the schema and certificate updates remains required
What’s Changed
- Signals now has a repeatable local certificate for the full account boundary: an FPH staff member creates and publishes an FPH-owned survey, an anonymous visitor completes it, then signs in with the same Furries PH account to claim a configured digital reward.
- The certificate also verifies the owner analytics projection and removes its disposable local Auth account. Its synthetic published survey is archived so immutable version history remains intact.
- Fresh databases now give the trusted API only the read access it needs for canonical partner scope, partner labels, and account-to-reward resolution. A completion-command repair also prevents an internal SQL naming collision from blocking public survey submissions.
- Deleting an account now preserves an already-published survey version while removing its publisher reference, so historic survey content does not retain the deleted account identifier.
Validation
- A clean local Supabase reset replayed every migration. The local certificate passed FPH staff authorization, anonymous completion, sign-in reward handoff, digital reward issuance, owner analytics, and disposable-account removal. API TypeScript validation passed.
Social Page Owners Can Restore an Archived Page
Repositories: social.furries.ph, partners-api
Status: Local implementation only; migration/RLS and Git-connected release remain required
What’s Changed
- A Page owner can now deliberately restore an archived Creator, Organization, or Event Page from the Social Pages workspace. The confirmation explains that restoration returns only public Page discovery and ordinary Page publishing.
- The API independently checks the current owner role and archived lifecycle, records an immutable restoration audit entry, and rejects stale or already-active Page requests. It does not restore separately removed posts, alter Page roles, reissue a Partner-verified Event Page link, or change canonical event data.
- This remains a static Cloudflare Pages flow: one explicit request reaches the existing
partners-apiWorker, with no Pages Function, browser database access, extra poll, or direct upload.
Validation
- Social API-client tests, Social typecheck/tests/build, the nine-assertion Event Page certificate, API TypeScript validation, and a responsive fixture render pass locally; hosted database/RLS and Git-connected release evidence remain pending.
Public Social Event Browse Makes Its Ordering Explicit
Repositories: partners-api, social.furries.ph
Status: Local implementation only; migration and Git-connected release remain required
What’s Changed
- The public Social Event catalogue now offers visible Soonest and Recently announced orders, both backed by the same bounded public-event projection. After a member enters a keyword, an optional Keyword relevance order can rearrange only the public titles, topics, organiser names, and excerpts already on screen. It does not use member interests, activity, friends, location, registrations, RSVPs, or attendance.
Validation
- The Worker type check and 17-assertion event-discovery contract pass locally. Social type checking, 60 unit tests, and a production build pass; a browser fixture verified the sort selector, ordering explanation, and keyword result order. No migration, deployment, Pages upload, or direct release occurred.
Social Moderators Can Add a Post Content Warning Without Removing It
Repositories: partners-api, moderation.furries.ph, social.furries.ph
Status: Local implementation only; database migration and Git-connected release remain required
What’s Changed
- The moderation dashboard now exposes a receipt-backed action to add, replace, or remove a short presentation warning on the exact post in an active case. It is intentionally narrower than a removal or account action: the post remains published unless a moderator separately takes an authorized action.
- Moderators choose from a fixed, reviewed set of enforcement reasons and must record their notice decision and rationale where required. The API enforces these choices; changing browser code cannot bypass them.
- Restriction and suspension remain Social-only, reversible actions. A timed restriction may now last 24 hours, 7 days, or 30 days; the API calculates its expiry and evaluates it on every protected Social action, without relying on a browser timer or a background worker.
- The moderation queue and case view show the exact current expiry. Once the canonical expiry has passed, the API returns the account as effectively active, matching the Social write gate without generating a fake live-expiry alert.
- A moderator’s case claim now lasts two hours. The queue shows its deadline; assignment returns the server-authoritative deadline immediately, and after expiry the case is reclaimable on the next authorized read or claim without a background job, extra poll, or forced dashboard interruption.
Validation
- API and dashboard typechecks, the dashboard test suite/build, and 96 focused Page-moderation assertions pass locally. Remote migration parity found a substantial existing local backlog, so no database migration, Worker deployment, Pages upload, or direct release was performed.
Social Page Drafts Gain a Safe Markdown Preview
Repositories: social.furries.ph
Status: Local implementation only; Git-connected release remains required
What’s Changed
- New and saved private Page announcement drafts now use the same Markdown toolbar and safe, local preview as post composition. Page operators can confirm formatting before saving a draft or moving it into the existing Page composer; this adds no preview request or public disclosure.
Validation
- Social type checking, 56 unit tests, production build, diff checks, and a Page-workspace browser fixture passed locally. No deployment or direct upload occurred.