@joespano.near [Posted on DevHub](https://near.social/#/devgovgigs.near/widget/Post?id=1435) ## Idea: Anonymous email relayer so component owners can be contacted As the number of components on BOS grows, we are already seeing an issue where it is unclear if a component is deprecated, where to get support for it, and sometimes who even owns it (since it is tied to a wallet address). The idea I am suggesting is a Craigslist style anonymous email relayer so that users/developers can contact component owners and still protect their privacy. Additionally, I would suggest an automated "check-in" system where through a simple yes/no click a component owner can mark their component as "active, not-active but functional, not-active and deprecated". Here is roughly the structure needed to achieve this: ### Components Needed 1. **Database**: Stores the mapping between the anonymous email addresses and the real email addresses of the users. 2. **Email Server**: Handles incoming and outgoing emails. 3. **Application Server**: Manages the logic for email anonymization, forwarding, and other functionalities. ### Workflow 1. **Ad Posting**: - User submits a component to mainnet. - The system generates an anonymous email address (e.g., `foo@near.org`). - This anonymous email is displayed on the component. - A mapping between the anonymous email and the user's real email is stored in the database. 2. **Email Forwarding**: - The application server looks up the real email address corresponding to the anonymous email in the database. - The email content is forwarded to the real email address, possibly after stripping out or modifying certain information for added privacy or security. 3. **Replying to Emails**: - When the original poster replies to the email, the reply is sent back to the application server. - The server looks up the anonymous email address for the potential buyer and forwards the reply to that address. 4. **Automatic Check-ins**: - On a set interval, an email is sent to component owners to check if their component should be marked as "active, not-active but functional, not-active and deprecated" ### Security Measures & Benefits - **Rate Limiting**: To prevent spam, the system may implement rate limiting on the number of emails that can be sent through the relay. - **Content Filtering**: The system could scan emails for malicious content or phishing attempts. - **Expiration**: Anonymous email addresses may expire after the component is marked as deprecated. - **Two-Way Anonymization**: Both the developer and the user/dev have their email addresses anonymized in this manner, allowing for two-way anonymous communication. ### Challenges - **Spam and Abuse**: The system needs robust mechanisms to prevent misuse. - **Data Consistency**: Ensuring that the database that holds the email mappings is always available and consistent. - **Privacy**: Ensuring that the real email addresses are not accidentally disclosed. While this would not be a decentralized system, tools like this are needed to help make the developer experience better. It could help eliminate confusion and remove clutter by having a simple method to mark components as deprecated.