About this notice
Streamfiesta supports learning in cohorts through scheduled sessions, learner work, small accountability groups called pods, and visible progress. This provisional notice describes the data used by the current software during internal staging testing.
The operator’s legal name, country, and privacy contact remain undecided and must be supplied before external pilot onboarding, together with the applicable legal grounds for processing your data.
Data used to provide the service
- Account details: email address, a username (generated at signup and editable), optional display name, profile visibility, short bio and professional links, account creation and verification records, and a password hash if you register with a password. If you choose Google or GitHub sign-in, we use your provider account identifier and email information to sign you in and link your account.
- Profile photo, if you upload one: we crop it to a small square and remove location and camera details before storing it. It is public only when your learner profile is public. Removing it deletes the stored image.
- Account security: login sessions, device and browser information, IP addresses, and session activity. If you enable two-factor authentication, we store an encrypted authenticator secret and protected backup-code verification records.
- Learning activity: cohorts and pods you join or create, optional commitments, session attendance and recovery, checkpoint submissions and project links, instructor reviews, check-in responses, private checkpoint-help questions and replies, support preferences, lesson completion, progress, completion records, and notifications.
- Service operations: invitation use, email delivery records, and operational logs used to run the platform, investigate failures, and protect accounts.
Account information is needed to sign in. Learning records support participation, feedback, reminders, and completion decisions. Commitments, public profile visibility, and publishing a public completion proof are optional.
Who can see your learning activity
This is a social learning service. Authorized cohort learners and creators can see learner names and progress information. Your cohort creator can review your checkpoint submissions and project links. Pod progress is visible to authorized pod members and the cohort creator; commitments are shared with your current pod and the creator. Private checkpoint-help conversations are visible to the requesting learner and cohort instructor, while the learner remains enrolled. Requesting help requires explicit sharing consent; these conversations are not shared with peers or included in public proofs.
Private submissions are not included in public completion proofs. Creating an unlisted cohort restricts discovery and joining; it does not make your activity invisible to people authorized to participate in that cohort. Avoid including passwords, confidential information, or other people’s personal data in your work or commitments.
Public discovery
Published public cohorts expose their description, schedule, instructor display name (or username when no display name is set), learner count, and attached course summary to visitors without signing in. Lesson contents, learner identities, work, and meeting links are not part of public discovery. Publishing a course alone does not list it publicly.
If you make your learner profile public, anyone can view your chosen name, username, profile photo, bio, professional links, current enrollment in public cohorts, and any completion proofs you separately publish. Unlisted cohorts, private submissions, Rescue history, reflections, help requests, and support preferences are excluded. You can make the profile private again at any time, but people may already have copied public content.
Video, classrooms, and recordings
When native video is enabled, Mux processes uploaded course videos, captions, and private classroom replays. When native classrooms are enabled, Cloudflare RealtimeKit processes live audio, video, screen sharing, participant identifiers, and connection activity; its classroom tools can also handle chat and shared files. These provider connections can expose network and device information. Attendance verification uses connection intervals, and instructors can confirm fallback attendance with a reason.
Recording is separately enabled. A recording-enabled classroom requires acknowledgment of a versioned recording notice before joining; an instructor explicitly starts capture. Recordings may include voices, cameras, and shared screens. The service stores that acknowledgment and recording-request metadata. Eligible recordings can transfer from temporary Cloudflare storage to private Mux storage when ingestion is enabled.
Current authorized cohort learners and instructors can watch available private replays; instructors can export or delete them. Replay access expires 30 days after cohort end, when stored media is queued for deletion. Provider failures can delay physical cleanup. Earlier deletion blocks new playback credentials; existing credentials can remain valid for up to five minutes, never beyond replay expiry. Downloaded instructor copies are outside the platform’s automatic deletion. Original Cloudflare files and recording audit/consent records have separate retention policies that still require verification or a decision before hosted activation.
Viewing material never automatically awards attendance or recovery. Lesson completion and session recovery require explicit learner actions.
Public completion proofs
After completing a cohort, you can choose to create a public proof. Anyone with its link can view the learner and cohort names saved at publication, completion date, and completion statistics. Your email, private submissions, and project URLs are excluded.
Publication saves a snapshot of your display name, or your username if you have none: changing either later does not change that proof. You can withdraw a proof without deleting your private completion record. Publishing it again creates a new public link; the old link remains unavailable. People may already have copied or shared public content, and search-engine exclusion does not make a public link private.
Measuring progress and service reliability
We record sampled learning milestones associated with your account and cohort, such as participation, falling behind, recovery, and graduation. These records help evaluate whether cohort learning improves completion. Progress rules also determine reminders, recovery guidance, and eligibility for completion; they are based on participation and completed requirements.
Sentry error monitoring is optional; hosted pilot activation remains deferred. When enabled, error reports include code locations, error type, release, and environment. The app removes error messages, user and request details, private submissions, and browsing breadcrumbs from those reports. Network connections can still expose an IP address to the provider. Session replay, advertising trackers, and Sentry performance tracing are not enabled in the current integration.
Cookies and browser storage
A refresh-token cookie keeps you signed in and has a 30-day lifetime when set or renewed. A separate cookie remembers whether this browser had a session, for up to 400 days when set or renewed; it contains a yes/no hint, not a sign-in credential. Signing out clears these cookies. Access tokens are held in memory.
Starting Google or GitHub sign-in sets an HttpOnly cookie named oauth_browser_binding, scoped to the API’s OAuth routes. It ties the sign-in attempt to this browser to prevent login substitution. Its lifetime is 10 minutes from being set or renewed. It remains after the callback until expiry; signing out does not clear this OAuth cookie.
Your appearance preference (System, Light, or Dark) is saved in local browser storage across visits and sign-out until changed or cleared in this browser.
If you follow an invitation, tab-scoped browser storage preserves it while you sign in. The app stops accepting the saved invitation after one day and clears it when consumed or found expired.
If you select a public cohort before registering or signing in, tab-scoped browser storage saves the cohort ID and the time of your choice so we can return you to that cohort after authentication. The choice is valid for one hour and is removed when the app checks it after authentication, including when it has expired. Selecting another public cohort replaces it; following an invitation clears it. An unused choice is not automatically removed at the one-hour boundary.
Blocking cookies or storage can prevent sign-in or returning to your selected cohort or invitation. These browser lifetimes do not describe how long server records are retained.
Providers and external services
Hosting and backup providers process stored platform data. Resend is the supported email delivery provider for account messages and learning notifications when email delivery is enabled. Google and GitHub handle sign-in if you choose their buttons. Sentry will process filtered error reports if monitoring is activated.
Opening an external lesson, session meeting link, or submitted project link takes you to an external service with its own privacy practices. The final notice will identify the selected hosting and backup providers, processing locations, and any applicable international transfer arrangements before external pilot onboarding.
Retention and your choices
Staging accounts and content may be reset during testing; resets are not a guaranteed deletion schedule and do not necessarily remove backups or provider copies. Apart from the replay policy above, retention periods for account and learning records, security and delivery logs, backups, and error reports are still being decided. The final notice will state those periods or the criteria used to determine them. Ending a cohort or signing out does not delete its stored learning records.
You can edit your username and display name, sign out, and choose whether to publish a proof. The pilot does not currently offer self-service account deletion or data export. Before external pilot onboarding, we must provide a contact and process for access, correction, deletion, and other privacy requests, along with rights and complaint information appropriate to the pilot’s jurisdiction.