This page is here to explain, in a simple and honest way, which data this website uses, why it uses it, and which privacy and safety decisions were made while building CommonRoom. My goal is to keep data collection as small as possible, but not smaller than what is needed for functionality, moderation, safety, and basic abuse prevention.
At the moment, the platform uses your email address, a generated username, a password hash, optional profile text, optional funny fact / icebreaker text, optional profile labels, selected tags, chat requests, chat messages, and basic activity timestamps such as when an account was created or last seen.
Some of this data is required for the platform to function at all, and some of it is optional and only exists because you decide to add it to your profile.
Your email address is used for account registration, login, email confirmation, password reset, email change confirmation, and chat-request emails. It is also the main way to verify that the account belongs to an ETH context. The app currently stores your email internally in the database and does not show it publicly to normal users.
In addition, keeping access to the email address internally is important in case abuse prevention or abuse investigation becomes necessary. If a serious problem is reported, the email address is the internal account anchor that allows the host to react, follow up, and prevent misuse of the platform.
Your password itself is not stored in readable form. The application stores only a password hash, so the raw password is not directly known from the database. Password resets and account confirmation also use signed, time-limited tokens instead of plain links without verification.
Usernames are generated automatically instead of asking users to invent their own public name. The point of that is to reduce personal hints, identity markers, and unnecessary self-exposure. The platform is designed so that your public-facing identity is mainly this generated username and the information you voluntarily choose to put into your profile.
The "About me" field, the funny-fact / icebreaker field, your selected profile labels, and your tags are there to help other users understand whether you might be a good fit for a conversation. These fields are optional or partly optional, and you decide how much you want to reveal. Because this project is meant to be low-threshold and privacy-aware, I strongly recommend not putting directly identifying information into free-text profile fields.
Tags are an important part of how matching works. They are intentionally curated instead of fully user-generated, so that the platform does not fragment into too many near-duplicates, overly specific private tags, or tags that do not fit the purpose of the project. If something important is missing, users can reach out and suggest additions.
Chat data is the most sensitive part of the platform. Messages are stored because the chat must still exist when one user is offline and comes back later. Chat requests are also stored with their status so that the app can distinguish between pending, accepted, and rejected requests.
A chat does not start immediately when one person wants to talk to another. Instead, a request is created first, an email is sent, and the other person has to explicitly accept it. Only after acceptance does the actual conversation become active. This is meant to reduce pressure and give users more control over who can contact them.
Chat access is restricted to the users who actually belong to a conversation. The server checks this both for the normal page request and for real-time chat events. In addition, users can block each other. If a block relationship exists, new chat requests are prevented and messages can no longer be sent in that conversation.
The notification bell currently shows lightweight activity information such as new messages, new incoming requests, or responses to your own requests. This is not implemented as a large permanent notification archive. The app mainly keeps a small session-based "seen" timestamp so it can decide whether an activity should still count as new.
Several important actions use signed tokens with expiry limits, including account confirmation, password reset, email change confirmation, and accept / reject links for chat requests sent by email. This is meant to avoid insecure unauthenticated actions and to make sure that email-based actions are tied to the correct account and valid only for a limited amount of time.
A few basic safety decisions are built into the platform. The app can restrict chat access through block relationships. It uses generic messaging on password-reset requests so outsiders cannot easily learn whether a given email address is registered. New registrations also trigger an internal email notification to the host, which is a simple moderation and oversight measure. This registration notification does not need to expose the registering user's email address to the host as part of the notification itself, but can still point to the newly created user profile.
Block relationships are also stored internally. This means that, if necessary, it is possible to review who blocked whom in order to better understand repeated problems or patterns of misuse. In serious or repeated cases, this can also help identify a user who is being reported or who stands out through unusually frequent blocking by others.
Users also have a dedicated report-abuse contact option while logged in. This is not a fully automated moderation system, but it gives users a direct way to flag a problem.
The app uses a session timeout and supports a "Keep me logged in" login option. In the current configuration, the permanent session lifetime is set to 20 minutes and the corresponding long-lived login duration is set to 7 days. The idea is to reduce the risk of a session staying open forever when someone walks away from their device.
Also important: the current repository is still a development-oriented setup. Some cookie settings that should be stricter in production are not yet hardened in the current config. In particular, secure cookie and HTTPS-only deployment settings still need to be enforced properly when the project is deployed for real.
Normal users do not get to see other users' email addresses. Public profile matching is based on usernames, profile text, tags, labels, and other voluntarily shared profile information. Internal metadata such as confirmation tokens, password-reset tokens, and admin-related mail flows are not publicly exposed.
This page should not pretend that the app already does more than it really does. At the moment, there is no end-to-end encryption for chats, no encrypted email-at-rest system, and no full professional-grade security architecture. There is a serious attempt at privacy-aware design, but there are also clear next steps that would still improve the system. For the current use case and size of the platform, the implemented level of security is considered a practical and sufficient starting point, even though it is not the final possible level of protection.
The practical principles behind the current build are: keep public identity lightweight, require as little data as possible, do not expose contact data publicly, gate chats through requests, allow blocking, use signed email flows, and keep users informed about what is happening with their account and requests.
If you have questions about your data, want clarification about what is stored, or want to report a privacy concern, you can reach out through the contact option on the website. For a project like this, transparency matters, so this page should grow together with the actual security measures of the platform.