This policy governs the privacy of the hosted Chatstronomy Hub.

This document was last updated on 11 September 2026.

Chatstronomy Hub is a hosted service operated by Yann Ramin. Unlike the self-hosted application, it receives account information and observatory data so it can connect your N.I.N.A. installations to Discord.

This policy applies to hub.chatstronomy.com and to N.I.N.A. profiles paired with that hosted service. The self-hosted privacy policy applies separately when you run Chatstronomy locally without connecting to the Hub.

The Hub collects account and Discord information.

The Hub uses Discord to authenticate users. Discord OAuth requests the identify, email, and guilds scopes. Depending on what Discord provides, the Hub stores your Discord user ID, username, email address and verification status, avatar URL, and the names, identifiers, ownership flags, and management permissions of your servers. Discord OAuth access tokens are used during sign-in and are not retained as persistent Hub account credentials.

The service also stores telescope names, ownership and server attachments, Discord channel names and identifiers, command and role policies, image delivery preferences, and the N.I.N.A. node and profile identifiers needed to recognize each paired installation. Pairing codes and long-lived rig credentials are stored as cryptographic hashes, not as reusable plaintext.

The Hub processes specific observatory information.

While a rig is connected, the plugin can transmit live N.I.N.A. information over an encrypted WebSocket so the Hub can reconstruct state, answer read-only queries, render updates, and post to the channels you select. Depending on your equipment and the event families, location sharing, and log levels you permit in the plugin, this information can include:

The plugin transmits status information, which includes connection state, equipment display names, celestial target coordinates, permitted mount-position fields, durable safety status, and details regarding the telescope, camera, mount, focuser, filter wheel, rotator, and guider.
The plugin can transmit permitted session details, including Sequence and Target Scheduler names and progress, user-authored sequence annotation and message text, sequence-item and image-save failure summaries, completion outcomes, built-in wait and plate-solve results, exposure metadata, autofocus and guiding measurements, plots, previews, images, timestamps, and explicitly selected log messages. A permitted Hocus Focus report can add fit-quality statistics, accepted-star counts, normalized crop-region geometry, validation status, and selected algorithm settings. Raw Hocus settings objects, filesystem paths, device IDs, autofocus images, and star lists are not included in that report. Failure summaries can contain sanitized N.I.N.A. operational error text; local path-shaped strings are redacted before transmission.
Permitted observatory-device events can include separately controlled mount-slew and rotator-move start/end diagnostics, dome/shutter actions, flat-panel cover, light, and brightness changes, and connection state for weather and switch devices. Both motion-diagnostic controls are disabled by default. When enabled, the plugin watches live N.I.N.A. motion state. When it observes both moving and idle edges, it pairs them and reports the interval between them. Slew records include a requested target when N.I.N.A. provides one and observed moving and idle RA/Dec positions; state-observed start/end altitude and azimuth are included only when observatory-location sharing is enabled. N.I.N.A. does not expose the requested rotator target at its public start-state boundary. State-observed rotator starts report available sky and mechanical angles; a recovered start carries the callback's available logical or mechanical From angle. An ordinary ended record means N.I.N.A. first reported the device idle, not that settling finished or the operation succeeded. If a short move completes between live updates, Chatstronomy reconstructs the pair from N.I.N.A.'s completion callback, marks the capture as Recovered after motion began, and omits a duration it could not observe. A recovered mount start contains callback RA/Dec but no historical altitude or azimuth because the callback has no start timestamp; its end uses the available live idle snapshot. Neither recovery record implies success. Structured weather reporting also has two independent local controls, both disabled by default. Meaningful weather changes are grouped and rate-limited; high-wind notifications compare wind speed or gusts with a user-selected threshold in meters per second and report alert and recovery transitions. General weather-change posts can contain numeric temperature, dew-point, humidity, pressure, cloud, rain, wind, sky, and seeing readings. High-wind records contain only wind speed, gust, threshold, and alert state. An active alert may be resent after reconnecting or changing the threshold to synchronize status without another chat alert; missing readings do not clear it. Weather-station names and device or driver identifiers are omitted. The plugin does not capture switch values or LiveStack data. Enabled popup notifications and opt-in raw N.I.N.A. logs remain unstructured text and may contain operational details.
The plugin transmits site information, which includes the latitude, longitude, elevation, and location-derived mount readings, but only if you explicitly enable the local observatory-location setting.

Event switches are transmission and privacy controls. Most ordinary event categories, images, and N.I.N.A. popup notifications start enabled. The two motion-diagnostic and two weather-reporting controls start disabled. Review every setting in N.I.N.A. before pairing with the Hub. When you disable an event family in N.I.N.A., its underlying event records do not leave the plugin: they are not sent to the hosted Hub or to a local Chatstronomy runtime. This also applies immediately to previously buffered records. Events that occur while a family is disabled cannot be released later by re-enabling it, and there is no state-maintenance exception. Disabling images also blocks image history, previews, thumbnails, and automatic image delivery, including previously captured images. Other permitted events, equipment-status snapshots, and non-image information explicitly requested by a slash command can still be shared. Once N.I.N.A. accepts a locally permitted command, its terminal failure is always delivered as part of that command exchange and is not controlled by optional event switches. Raw N.I.N.A. log forwarding starts disabled, is controlled separately by level, and is opt-in; disabled levels stop being transmitted.

Weather notifications are informational telemetry, not a safety system. Sensor readings and Hub or Discord posts may be delayed, missing, or inaccurate because of sensor, N.I.N.A., plugin, network, service, or Discord behavior. Do not rely on these notifications to protect equipment or people.

The application provides location sharing and redaction controls.

Observatory-location sharing is off by default. When it remains off, the plugin redacts explicit site latitude, longitude, and elevation together with location-derived readings such as local sidereal time, altitude, azimuth, and meridian timing. Enabling the one local location-sharing setting can disclose those observatory-related fields. Hardware device and driver identifiers are always redacted, even when location sharing is enabled; persistent plugin node and profile identifiers are still required to authenticate the paired installation.

Redaction does not make a rig anonymous. The network must still disclose its IP address to connect, and IP addresses can indicate an approximate location. Telescope or equipment display names, image or file metadata, target coordinates, timestamps, free-text N.I.N.A. notifications, and optional logs may independently reveal a location, observatory, equipment, or local filesystem details. Celestial target coordinates describe where a telescope points and are not the same as the observatory's terrestrial coordinates.

Review image and notification contents before sharing them. Do not enable raw log forwarding unless you are comfortable with the additional details it may contain. Data already posted to Discord must be managed through Discord and the relevant server or channel administrators.

The service uses specific infrastructure and service providers.

The Hub application and its primary database run on Amazon Web Services in the United States, primarily the Oregon region (us-west-2). Amazon CloudFront proxies browser and rig traffic, so requests may traverse global edge locations. Database backups are stored in a private, server-side-encrypted Amazon S3 bucket. AWS provides the hosting, network, content-delivery, and backup infrastructure.

Discord provides account authentication, server and channel information, bot connectivity, and the destination for the messages and images you choose to publish. Discord processes and retains that information under its privacy policy. Authorized Discord server members and administrators may see messages posted to their channels. Server managers can manage the routing and permissions available to their server, subject to telescope ownership and the plugin's local hardware-control master switch and individual command approvals.

The service operator and administrators who maintain its infrastructure can access operational systems and stored service data when necessary to operate, troubleshoot, secure, or restore the service. The Hub does not archive images or full observatory-event payloads in its SQLite database; live telemetry is processed for current state and delivery. It retains limited autofocus delivery records to prevent duplicate posts, as described below. Discord messages, operational logs, and account or configuration records have their own retention characteristics.

The Hub uses sessions, cookies, and operational logs.

The Hub uses a signed browser session cookie containing a random session identifier. Server-side sessions normally expire after 30 days, and expired sessions and short-lived Discord login state are cleaned up periodically. A one-time telescope pairing code is valid for one hour; a telescope share code is valid for seven days. Code expiration limits use, but does not guarantee that every expired hashed database record is immediately deleted.

Web server access logs record information such as your IP address, request path, timestamp, response status, and browser or client user-agent. Operational and security logs may also record connection errors and administrative activity. No specific automatic log-retention period is currently guaranteed.

The Hub does not load the marketing website's Google Analytics tag. Some separate pages at chatstronomy.com use Google Analytics and its cookies as described in the marketing website privacy disclosure. This hosted-policy page does not include that analytics script.

The operator retains, backs up, and deletes data.

Account identity, telescope ownership, server and channel routing, rig credential hashes, and configuration remain in the live database while they are needed to provide your account and telescope connections. Administrative audit entries can include account or server identifiers and descriptions of management actions. There is currently no fixed automatic expiration schedule for account records or audit history.

To prevent duplicate autofocus posts after a restart, the Hub stores report timestamps, delivery times, and associated telescope, N.I.N.A. profile, and Discord channel identifiers. These records contain no images or report measurements. They remain until the telescope is deleted, including when a plugin disconnects or a channel route is removed. The backup retention described below also applies.

The database is backed up approximately hourly to versioned, encrypted S3 storage. Previous backup versions expire after 90 days. Consequently, information removed from the live database can remain in existing backup versions for up to 90 days after subsequent backups replace them. Backups are maintained for disaster recovery, not as an end-user data archive.

The Hub currently has no self-service account-deletion endpoint. You can remove individual telescopes, disconnect or revoke rig credentials, and remove channel routes using the available Hub controls. To request account deletion or discuss associated audit records, contact the operator through the Chatstronomy issue tracker. GitHub issues are public: do not post pairing codes, credentials, private location information, or other sensitive account details. The operator can arrange any necessary verification separately. Removing data from Discord requires using Discord's own controls.

The application provides remote control settings.

The hardware-control master switch and every individual equipment-command permission are disabled in the N.I.N.A. plugin by default. A command is allowed only when both the master switch and that command's local permission have been explicitly enabled; the master switch alone grants no commands. Skipping sequence validation requires separate local approval. A Hub setting, server manager, Discord role, or service operator cannot change these local permissions remotely. For enabled commands, related attempts and operational or audit information may be processed by the Hub and Discord. Once N.I.N.A. accepts a locally permitted command, its later terminal failure is sent through the Hub as part of the command exchange. Review the hosted Hub terms before enabling control.