Orbit
Deutsch
Anmelden
← Alle Versionshinweise
1.6.0-Public-Beta12 Min. Lesezeit

Orbit 1.6.0 Public Beta: Less Mystery, More Orbit

Orbit 1.6.0 Public Beta brings durable guild event history, clearer Pulse delivery, Creator Notifications, stronger Forms and feedback workflows, linked identities, better moderation tools, public health reporting, and a rebuilt Dashboard that has finally agreed to explain what its buttons are doing.

public-betadashboardevent-loggingpulseformsfeedbackmoderationcreator-notificationsidentityaccessibilityreliability

Welcome to the Public Beta

Version 1.6.0-Public-Beta is the release where several Orbit features stopped being promising individual rooms and started behaving like one building. There are clearer doors, fewer mystery cupboards, and a surprisingly detailed fire-exit diagram. We would like to claim this was always the master plan. The commit history has asked us not to.

Highlights

  • Durable guild Event Logging with optional full-content capture, delivery diagnostics, retention controls, and channel and voice insights
  • Pulse surveys with visible lifecycle states, eligibility rules, result controls, response review, recall, and bounded reward correction
  • Creator Notifications for configured Twitch, YouTube, and separately approved providers
  • Account-bound feedback history, optional progress updates, and discretionary rewards
  • A more readable and responsive Dashboard with clearer loading, empty, degraded, rejected, and retry states
  • Richer Forms authoring and review queues that are more tolerant of older submissions
  • Linked external identities with clearer provider availability and more human-readable history
  • Public Health reporting that combines service checks, incidents, maintenance, and availability history

The Public Beta is now large enough to need chapters. This is either product maturity or our documentation finally catching the application in the act.

A completely objective release assessment

The Dashboard has agreed to communicate

The shared Dashboard surface system has been rebuilt across cards, navigation, dialogs, tables, forms, status panels, toasts, and responsive layouts. The practical result is less visual noise, clearer hierarchy, and fewer moments where a panel appears to be wearing another panel as a hat.

  • Cards, dialogs, inputs, tables, navigation, and toasts now use a consistent surface and elevation hierarchy
  • Important controls keep visible keyboard focus and remain usable with forced colours and reduced motion
  • Long localized labels and values wrap instead of being quietly sacrificed to the ellipsis gods
  • Selected-channel chips stay inside their field and scroll or wrap instead of attempting horizontal migration
  • Narrow workspaces respond to their actual container width rather than assuming every screen is a cinema
  • Public headers, content, and footers keep their own layout rows instead of negotiating territory at runtime

Loading, empty, slow, stalled, degraded, and failed queries now have distinct presentation. Error states can include a safe request reference and an explicit retry action. Previously, some pages offered the timeless diagnostic classic: nothing changed, but in red. We have expanded the vocabulary.

Event Logging became an actual history

Guild Event Logging can now retain configured events as a durable source history instead of existing only as a delivery pipe to Discord. Administrators can keep events without assigning a destination channel, inspect delivery separately, and understand what Orbit observed even when a notification destination was unavailable. The logs have, in a bold career move, started logging.

  • Delivery Insights includes success rates, latency, destination health, grouped failures, and searchable delivery history
  • Activity insights cover whole-guild and per-channel views with clearer participation trends
  • Voice analytics expose richer session facts without requiring a ceremonial spreadsheet
  • Retention controls show the effective plan-aware window and reconcile stored history when settings change
  • Event routing and source history are presented separately so a Discord delivery failure is not mistaken for an observation failure
  • Configured viewers and destinations remain explicit administrative choices
What Event Logging now separates — Observation, storage, and delivery are related, but they are not the same job.
AreaWhat it answersAdministrator control
Source historyWhat Orbit observedEvent switches and retention
Content modeWhether configured message content is retainedExplicit opt-in and viewer scope
Discord deliveryWhere a notification was sent and whether it succeededDestination and routing settings
AnalyticsHow activity changes over timeAvailable reporting windows and filters

Pulse stopped answering lifecycle questions with vibes

Pulse surveys now expose why they are available, unavailable, scheduled, paused, expired, unpublished, or limited to a fixed audience. This replaces an older and less rigorous state machine known to everyone as ‘maybe refresh’.

  • Survey availability reflects publication state, schedule, audience, membership, account age, and standing requirements
  • Authors can build richer question sets and configure result and selected-answer visibility
  • Individual responses can be reviewed through controlled author workflows
  • Eligible responses can be recalled where the survey policy allows it
  • Reward-backed surveys calculate their required budget before publication
  • Bounded reward corrections preserve an immutable reward history instead of editing the past until it becomes cooperative
  • Replacing a reward-backed survey can reuse eligible unspent escrow rather than funding the same intention twice

Reward decisions are clearer before and after publication. Authors can see the budget requirement, responses keep a traceable reward outcome, and corrections are bounded rather than magical. Finance remains one of the areas where we resist comedy-driven accounting.

Forms are less of an escape room

The Forms editor and response review experience now use clearer sections, validation, save feedback, and recovery behavior. Authors can spend their time designing a useful form instead of discovering which accordion contains the one field currently objecting to their life choices.

  • Form settings and field configuration use clearer grouped surfaces
  • Validation feedback points to actionable problems before publication
  • Save states distinguish pending, successful, rejected, and conflicting writes
  • Response queues tolerate supported legacy submission shapes more defensively
  • Review surfaces keep answers readable across long content and smaller screens
  • Managed placements and access-request flows retain their existing authorization boundaries

Validation should identify the problem. It should not host a scavenger hunt and award the error message as first prize.

The new editor philosophy

Feedback can now have a second chapter

Signed-in members can keep submitted feedback in a private account history and optionally receive in-app progress updates. A report no longer has to disappear into a submit button with the dramatic finality of a message in a bottle.

  • Members can opt into account-bound tracking when submitting feedback
  • Public progress updates can be shown without exposing internal review notes
  • Notification preferences can be changed after submission
  • Safe request references make follow-up and support conversations more precise
  • Eligible feedback may receive a discretionary reward with a traceable outcome
  • Submission diagnostics remain bounded so feedback does not become an accidental secret-export feature

Creator Notifications, now with fewer duplicate entrances

Guilds can organise multiple public creator accounts into groups, choose separate live and content destinations, preview messages, send tests, and retry failed deliveries. Live activity is coalesced into one editable Discord message while new content is posted once per external item. One stream should no longer arrive like it brought twelve identical friends.

  • Configured Twitch and YouTube accounts can participate in creator groups
  • Separately approved providers can appear when their production readiness requirements are satisfied
  • Live and new-content notifications can use different Discord destinations and mention roles
  • Preview and test actions show the configured presentation before activation
  • Failed deliveries expose retry behavior and destination health
  • Provider availability, polling behavior, and external rate limits remain visible operational constraints

Accounts look more like people and less like database evidence

Orbit can present additional approved sign-in providers and keep verified identities connected to one account. Supported history and audit surfaces prefer human-readable names while retaining stable identifiers for disambiguation. UUIDs remain available for computers, support work, and anyone paid by the hexadecimal digit.

  • Approved external identity providers can participate in the account-linking flow
  • Existing verified links remain visible when a provider is paused or disabled
  • Provider availability and policy restrictions are shown separately from account ownership
  • Linked identity synchronization keeps supported profile facts current without silently moving ownership
  • History surfaces use readable display names first and stable identifiers when precision is required
  • Locked, denied, expired, and unavailable states describe the actual condition more accurately

Guild moderation workflows

Guild moderation cases now support a more complete review lifecycle with clearer ownership, severity, deadlines, resolution, filtering, and a durable timeline. These changes are intended to make decisions easier to review and correct without weakening existing permission or audit boundaries.

  • Cases can move through explicit review and resolution states
  • Assignment and due dates make active responsibility visible
  • Severity and filters help administrators prioritise the queue
  • Timeline entries preserve material actions and state changes
  • Resolution details remain attached to the case history
  • Platform Trust and Safety decisions retain a separate human appeal and correction path

Access and policy states say what they mean

Several controls previously looked like ordinary disabled inputs even when a platform policy, plan limit, missing dependency, or unavailable service was responsible. Orbit now distinguishes more of those conditions. This is useful because ‘grey’ is a colour, not an authorization model.

  • Core Tool switches show when platform policy has locked an effective setting
  • Plan-aware limits are displayed near the affected configuration
  • Missing dependencies and unavailable services use dedicated states
  • Rejected saves retain the user's draft and explain the effective constraint
  • Permissions remain enforced by the server even when the interface can predict the result
  • Revision conflicts stay visible instead of allowing the last browser tab to win a surprise election

Public Health is usefully public

The public Health experience combines service checks, incidents, maintenance, availability history, and the status shown in the public header. Status transparency works considerably better when the status is somewhere people can see it; this insight arrived only slightly after the feature name.

  • Current service health is presented with clearer healthy, degraded, unavailable, and unknown states
  • Active incidents and scheduled maintenance are visible in the same public experience
  • Availability history provides context beyond the latest check
  • The public header status links the headline signal to the detailed Health view
  • Missing or delayed health data is identified instead of being presented as success

Accessibility and reliability are part of the interface

The Dashboard now treats focus, live status, readable errors, responsive content, and reduced motion as shared behavior rather than optional decorations applied when a page remembers. Consistency is less glamorous than a new button, but it is also less likely to move the button while someone is trying to press it.

  • Query failures announce useful state changes through accessible live regions
  • Action-only icons use explicit accessible names
  • Maximizable dialogs report whether the action will maximise or restore them
  • Focus rings remain visible across shared controls and high-contrast environments
  • Reduced-motion preferences disable non-essential transitions and atmosphere
  • Long content, tables, chips, and action groups degrade more safely on narrow screens
  • Loading placeholders and empty states remain distinguishable from loaded content

Privacy and control

Terms of Service and Privacy Policy version 3.1 describe the supported identity-provider model, optional full-content Event Logging, aggregate platform telemetry, Pulse review and reward correction, feedback follow-up, Creator Notifications, moderation records, human appeals, recipients, retention, exports, and user rights. The legal text requires the operator's formal approval before production publication.

  • Optional guild content capture is distinguished from mandatory aggregate platform telemetry
  • Creator Notifications identify configured public creator metadata and relevant external recipients
  • Pulse documents eligibility, selected-answer and result visibility, individual review, recall, and reward correction
  • Feedback follow-up remains optional and account-bound
  • Moderation and appeal records preserve human review and correction paths
  • Retention and export descriptions reflect the verified public feature behavior

For Guild Administrators

  1. Review Event Logging source history, content mode, viewers, Discord destinations, and the effective retention window
  2. Check creator accounts, destination channels, mention roles, preview output, and provider readiness before activation
  3. Review Pulse audience, schedule, result visibility, response controls, and reward-correction settings before publishing
  4. Confirm Forms validation and managed placements before accepting responses
  5. Read the updated Terms and Privacy Policy before enabling the matching Public Beta capabilities
  6. Tell members what you enable, especially where a feature changes visible results, notifications, or retained guild history

For members

  • Most members do not need to take an immediate action for the Public Beta
  • Survey pages now provide more detail when participation is unavailable
  • Signed-in feedback submitters can choose whether to follow future progress
  • Account and history views show clearer identity and provider states
  • Public service health and release information are easier to inspect without signing in

Things we have stopped pretending were fine

  • Silent save failures now have more visible and useful explanations
  • Empty pages are less likely to resemble a frontend that simply forgot the second half of its job
  • Long channel selections no longer attempt to widen the browser until a second monitor appears
  • A loading request and an empty result are treated as different events, because they are
  • Policy-locked controls no longer impersonate missing permissions
  • Human-readable identities lead more history surfaces instead of requiring recreational identifier memorisation
  • Public service status no longer expects users to infer platform health from the general emotional tone of the header
  • Forms validation is less likely to communicate exclusively through one distant red border

Known limitations

  • Orbit cannot reconstruct Discord events that were never delivered to it or occurred before durable history was enabled
  • Creator Notifications depend on external providers and Discord, so polling, metadata, and delivery can be delayed or unavailable
  • TikTok support remains disabled unless its separate production approval and readiness controls are satisfied
  • Data-backed Public Beta features become available only after the operator completes the matching migration, rollout, and storage-readiness checks
  • Plan, permission, provider, guild, and regional availability can differ between accounts
  • The Public Beta may change as verified feedback is incorporated; breaking or action-requiring changes will be called out explicitly

What happens next

The Public Beta gives us one connected foundation for improving guild operations, member workflows, creator delivery, public transparency, and content authoring. We will keep tightening the places where Orbit still asks for unnecessary interpretation. Software should contain complexity so users do not have to perform it live on stage.

If a control can block an action, it should explain why. If a page can fail, it should say how. If we designed the confusing bit, the joke is on us — preferably only once.

Our operating rule for 1.6.0