Privacy-First Architecture
How student anonymity is cryptographically and architecturally guaranteed at Peerly.
Database-Level Separation
To prevent exposure of personal identity, the database contains two completely separate identity systems:
- User credentials (university email, password hash, role) are strictly isolated.
- Anonymous identity (generated animal name and avatar seed) is used for all peer features.
| Feature Table | Identity Reference | Direct User Access |
|---|---|---|
| Discussion Forum (Posts & Replies) | anonymousIdentityId | Blocked |
| Peer Chats & Messages | studentIdentityId / senderId | Blocked |
| Workshops & Meetings | hostIdentityId / attendeeId | Blocked |
Service-Layer Boundaries
Only the Core Auth Service and Identity Service are allowed to map your logged-in credentials to your active session. All other student features (discussions, chats, group meetings, and emotion logs) run exclusively using the generated pseudonyms.
Mentor Transparency
To build trust and verify professionalism, mentors are not anonymous. Their real names, departments, and "Verified Mentor" status are displayed to all users. However, mentors never see the real emails, names, or backend user IDs of the students they chat with.
Automated Privacy Regression Audits
Every API build runs an automated anonymity suite which asserts that student-facing payloads never return emails, password hashes, or internal database identifiers.