Shengal Terms of Service — English working draft DRAFT — NOT FOR PUBLICATION OR RELIANCE. This is an engineering informed source draft for product and counsel review. It is not a contract, legal advice, or a compliance representation. Text marked TODO requires an explicit decision before this document can become operative. 1. Parties, service, and acceptance TODO — counsel: identify the legal entity providing Shengal, its address, contact method, applicable law, and the legally effective acceptance mechanism. Shengal is an authenticated social/community application. The current backend supports account creation and sign in, profiles, follows and blocks, posts, stories, comments, direct and group messaging, calls, live streams, community language contributions, community verification workflows, notifications, reporting, and account export/deletion features. The backend uses versioned API routes and documents health and operational routes separately. Most product routes require authentication, and the backend treats “public” product content as visible to authenticated app users, not anonymous internet visitors. TODO — product/counsel: state the supported countries, eligible users, whether access is invitation only or public, and when these Terms are accepted. 2. Eligibility and accounts The Service is intended only for individuals age 13 or older. Individuals under 13 may not create or use an account. The current signup implementation requires a date of birth and rejects a user whose calculated age is below 13. This draft wording remains subject to counsel review and does not make broader child law or market age conclusions. TODO — counsel/product: confirm the final age restriction, notice, verification, and account handling process before publication. This draft does not state that parental consent is supported. Users may authenticate by email OTP/password or, where configured, Apple or Google sign in. The reviewed backend has no phone/SMS signup route. Account records include a username, email where supplied, profile fields, locale, date of birth, lifecycle state, and account standing state. Users are responsible for providing accurate information and protecting account credentials only if and to the extent approved by counsel. TODO — counsel: add the final account security, impersonation, eligibility, and unauthorized use obligations. 3. User content and community conduct The service accepts text, images, video, audio linked posts, stories, comments, messages, live comments, community contributions, and optional live replays. Users can delete some content; the service also has safety takedown, report, suspension, ban, and restoration controls. The reviewed language branch adds contribution workflows for text, transcription, translation, validation, correction, and optional voice/audio recordings, with progression and trust activity records. Availability, user eligibility, moderation, content permissions, withdrawal, and any licence for these contributions remain subject to the final product rules and counsel review. The backend currently uses consent gated eligibility checks for certain language text and voice contribution candidates. The reviewed repository does not evidence a training run or model lineage record, so these Terms do not promise that a contribution will be used for training, that a user can identify whether it was used, or that it can be removed from an external dataset or trained model. Any training use, withdrawal effect, audit retention, and post account deletion handling require explicit product and counsel decisions. The backend stores content and media metadata needed to route, display, moderate, clean up, and export these features. The current draft does not grant or imply a content licence, ownership transfer, warranty, or publication rule. TODO — counsel/product: insert the approved Community Guidelines, prohibited conduct, intellectual property representations, content license (if any), copyright process, moderation standards, appeal process, emergency/safety exceptions, and law enforcement response language. No license or warranty is asserted by this draft. 4. Privacy and visibility Profiles and content can be subject to privacy settings, follower relationships, blocks, audience rules, and authenticated access checks. The companion Privacy Policy draft describes technical categories and unresolved data decisions. Unauthorized hidden resources generally return 404 to reduce existence disclosure. The backend enforces reciprocal block visibility, but the final public rules for private profile search, recommendations, and group behavior after blocking remain product decisions. TODO — product: resolve private profile search/recommendation behavior and group behavior after blocking before promising a stable user facing rule. 5. Account standing, suspension, and deletion The backend has active, suspended, and banned standing states. It supports deactivation, reactivation before a scheduled deadline, permanent deletion, and a bounded account export. Current implementation defaults include a 180 day deactivation grace period and an export that expires after 72 hours, but these are technical defaults and may change. TODO — counsel/product: define notice, appeal, termination, suspension, legal hold, backup, and post termination effects. Cross reference the approved Privacy Policy for retention and deletion disclosures. 6. Availability, changes, and third party services TODO — counsel: add the approved language for service availability, maintenance, feature changes, third party services, links, fees (if any), disclaimers, liability limits, indemnity (if any), dispute resolution, and termination. The engineering inventory identifies Azure services, PostgreSQL/Redis, Cloudflare, Azure Communication Services email, Apple/Google identity verification, APNs/FCM, Microsoft Entra staff authentication, and LiveKit as technical dependencies or deployment integrations. This draft does not make vendor, location, retention, warranty, or subprocessor representations about them. LiveKit is used for call/live room control and tokens; the repository does not establish provider side retention or processing terms. 7. Contact and notices TODO — counsel: add the approved legal notice address, privacy contact, copyright contact, safety/reporting channel, and any required complaint or regulator language. 8. Approval record This document remains status: draft until the legal repository records the approved version, effective date, locale, reviewer, and counsel approval. The future static site must exclude this file while it remains a draft.
Shengal Terms of Service — English working draft
1. Parties, service, and acceptance
TODO — counsel: identify the legal entity providing Shengal, its address, contact method, applicable law, and the legally effective acceptance mechanism.
Shengal is an authenticated social/community application. The current backend supports account creation and sign-in, profiles, follows and blocks, posts, stories, comments, direct and group messaging, calls, live streams, community language contributions, community verification workflows, notifications, reporting, and account export/deletion features.
The backend uses versioned API routes and documents health and operational routes separately. Most product routes require authentication, and the backend treats “public” product content as visible to authenticated app users, not anonymous internet visitors.
TODO — product/counsel: state the supported countries, eligible users, whether access is invitation-only or public, and when these Terms are accepted.
2. Eligibility and accounts
The Service is intended only for individuals age 13 or older. Individuals under 13 may not create or use an account. The current signup implementation requires a date of birth and rejects a user whose calculated age is below 13. This draft wording remains subject to counsel review and does not make broader child-law or market-age conclusions.
TODO — counsel/product: confirm the final age restriction, notice, verification, and account-handling process before publication. This draft does not state that parental consent is supported.
Users may authenticate by email OTP/password or, where configured, Apple or Google sign-in. The reviewed backend has no phone/SMS signup route. Account records include a username, email where supplied, profile fields, locale, date of birth, lifecycle state, and account-standing state. Users are responsible for providing accurate information and protecting account credentials only if and to the extent approved by counsel.
TODO — counsel: add the final account-security, impersonation, eligibility, and unauthorized-use obligations.
3. User content and community conduct
The service accepts text, images, video, audio-linked posts, stories, comments, messages, live comments, community contributions, and optional live replays. Users can delete some content; the service also has safety takedown, report, suspension, ban, and restoration controls.
The reviewed language branch adds contribution workflows for text, transcription, translation, validation, correction, and optional voice/audio recordings, with progression and trust activity records. Availability, user eligibility, moderation, content permissions, withdrawal, and any licence for these contributions remain subject to the final product rules and counsel review.
The backend currently uses consent-gated eligibility checks for certain language text and voice contribution candidates. The reviewed repository does not evidence a training-run or model-lineage record, so these Terms do not promise that a contribution will be used for training, that a user can identify whether it was used, or that it can be removed from an external dataset or trained model. Any training use, withdrawal effect, audit retention, and post-account-deletion handling require explicit product and counsel decisions.
The backend stores content and media metadata needed to route, display, moderate, clean up, and export these features. The current draft does not grant or imply a content licence, ownership transfer, warranty, or publication rule.
TODO — counsel/product: insert the approved Community Guidelines, prohibited conduct, intellectual-property representations, content license (if any), copyright process, moderation standards, appeal process, emergency/safety exceptions, and law-enforcement response language. No license or warranty is asserted by this draft.
4. Privacy and visibility
Profiles and content can be subject to privacy settings, follower relationships, blocks, audience rules, and authenticated-access checks. The companion Privacy Policy draft describes technical categories and unresolved data decisions.
Unauthorized hidden resources generally return 404 to reduce existence disclosure. The backend enforces reciprocal block visibility, but the final public rules for private-profile search, recommendations, and group behavior after blocking remain product decisions.
TODO — product: resolve private-profile search/recommendation behavior and group behavior after blocking before promising a stable user-facing rule.
5. Account standing, suspension, and deletion
The backend has active, suspended, and banned standing states. It supports deactivation, reactivation before a scheduled deadline, permanent deletion, and a bounded account export. Current implementation defaults include a 180-day deactivation grace period and an export that expires after 72 hours, but these are technical defaults and may change.
TODO — counsel/product: define notice, appeal, termination, suspension, legal-hold, backup, and post-termination effects. Cross-reference the approved Privacy Policy for retention and deletion disclosures.
6. Availability, changes, and third-party services
TODO — counsel: add the approved language for service availability, maintenance, feature changes, third-party services, links, fees (if any), disclaimers, liability limits, indemnity (if any), dispute resolution, and termination.
The engineering inventory identifies Azure services, PostgreSQL/Redis, Cloudflare, Azure Communication Services email, Apple/Google identity verification, APNs/FCM, Microsoft Entra staff authentication, and LiveKit as technical dependencies or deployment integrations. This draft does not make vendor, location, retention, warranty, or subprocessor representations about them. LiveKit is used for call/live room control and tokens; the repository does not establish provider-side retention or processing terms.
7. Contact and notices
TODO — counsel: add the approved legal notice address, privacy contact, copyright contact, safety/reporting channel, and any required complaint or regulator language.
8. Approval record
This document remains status: draft until the legal repository records the approved version, effective date, locale, reviewer, and counsel approval. The future static site must exclude this file while it remains a draft.