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. Each chat is designed as a 1:1 conversation between exactly two users, not as a group chat or public chat room.
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.
The platform is hosted on Hetzner infrastructure. This also means that some basic server-side access data can exist at the hosting level, for example in the form of traffic statistics or server and web logs that are relevant for stability, debugging, and security. According to Hetzner's own documentation, this kind of hosting-related logging can include technical request data such as timestamps, requested resources, status codes, referrer information, and browser user-agent data. Hetzner also describes that IP addresses in webserver logs are anonymized there and that statistics tools such as AWStats or Report Magic can be used on hosting level to evaluate log data in aggregated form. This is not the same thing as building additional personal behavior tracking into the platform itself, but it is still part of the technical environment in which the website runs and should therefore be mentioned transparently.
In addition to hosting-level logs, the platform now also keeps a small internal analytics table for a limited set of public product pages. This is currently restricted to the main navbar pages such as About, Onboarding, Rules, Feedback, Tagsearch, Chats, Posts, Get Help Now, and Data and Privacy. The goal is not to inspect private content, but to understand basic usage patterns of the platform itself.
What is stored there is intentionally narrow: the visited page key, the matching path, the visit duration in seconds, a generated visit token to prevent duplicate records, the timestamp range of the visit, and, if the visitor is logged in, the internal user id. This analytics table is not meant to store chat content, post content, search text, or message bodies.
Just as important is what is not stored there. This internal analytics is not designed to collect message content, profile text content, tag-search input, email addresses, passwords, abuse-report text, contact-form text, or private chat metadata at the level of individual conversation content. It also does not create a personal dossier about a user's thoughts, problems, or support requests.
Some basic safeguards are built into this tracking route as well. It only accepts the predefined tracked pages, checks that the request comes from the same origin, rejects path / page-key combinations that do not fit together, limits the stored duration to a reasonable maximum, and ignores duplicate visit tokens. That does not make it mathematically impossible to manipulate, but it is meant to keep the tracking narrow, lightweight, and harder to pollute accidentally.
Also important: this internal analytics currently counts visits, not unique persons. This means that the same user can appear multiple times in the statistics if they visit the same page repeatedly or return later. The current internal analytics table also does not use IP addresses to deduplicate visitors there.
That also means that I am not using this analytics to identify individuals through IP-based tracking, fingerprinting, cross-site profiling, advertising logic, or hidden personal behavior scoring. The point of the analytics is simply to understand which core pages are used, whether usage comes more from public or logged-in access, and whether the platform is being used more from mobile or desktop contexts.
In addition, administrator / host visits are excluded from the visible analytics evaluation, so that the operator's own testing and maintenance behavior does not distort the usage overview shown there.
The visible analytics overview can also distinguish between public visits and visits from logged-in accounts. That distinction is based on whether a stored internal user id is attached to the visit record, not on public identity display or IP-based tracking.
In practice, the analytics is used as an aggregated product-health view, not as a tool to exploit user vulnerability or curiosity. It is there to answer questions such as whether onboarding is being opened, whether people find the rules page, whether the chat area is used, or whether most visits come from mobile devices. It is not there to mine sensitive personal patterns out of users who come here for support.
The dedicated feedback form for the test phase is designed to stay low-threshold and as anonymous as possible. When feedback is sent through that page, the user's email address is not forwarded in the feedback message. If a user is logged in, only the generated anonymous username is included with the feedback, not the email address behind the account.
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.
