Hi All,
Here you’ll find some info on user emails, data privacy, security, and anonymity when it comes to Anytype. First we’ll start with some high level points, then we will go into a specific email-related post mortem.
High Level Summary
-
All content inside the app is secure and private; it is not possible for Anytype to access your content, and this is verifiable in our code. There’s no need to trust us—it’s a fact.
-
Data security, privacy, and anonymity are not the same thing, although it’s easy to slip up and use the terms synonymously. In very simple terms, secure means protection from unauthorised access. Private means choice of who has access. Anonymous means traceability to your identity. Naturally, these are on spectrums and are not binary states.
-
For members on free and paid plans on Anytype, content is synced on our nodes—that’s how the app gets updated across devices and shared channels. This inevitably means that user data is transferred to Anytype. Importantly, the data is transferred by our protocol in a way that maintains data security and privacy—user content still cannot be accessed. For self-hosted users, data is not synced to Anytype servers whatsoever.
-
Unfortunately, with data being synced on our nodes, it inevitably means that we cannot guarantee anonymity across the board. A simple example is when a user submits a support request, this can lead to both an email address and Anytype ID being on our system, which is used to communicate and resolve issues.
-
Even in the case when a user’s Anytype account is connected to their email address, which is some loss of anonymity, their content in the app still remains entirely private and secure. What does become possible in this scenario is that we’d be able to trace the user’s abstract product usage data, such as what type of devices, what’s the account age, etc.
-
Product usage data is complex and requires a separate rundown, however the general point is that high level and abstract user activity is tracked and viewed in aggregate. For example, today, we can understand if a user creates a custom type (feature adoption), but we can’t distinguish between custom types and track how many of them are used. And it goes without saying, product usage data does not allow for tracking anything related to the content itself, such as object titles, chat messages, etc.
-
Anytype uses Amplitude and Metabase for product usage data. For email marketing, SendGrid and Loops.so are used. These tools are compartmentalised from each other and there is no linking of user identifiable data between them. That is, emails collected on the website, during in-product onboarding, and newsletter signups go to SendGrid or Loops.so and do not get tied with user accounts on Amplitude or Metabase.
-
As a tangible example, even though we can see all the users who have stopped using Anytype, we are unable to send them a marketing email to engage with them because the data is not linked.
-
Hopefully it goes without saying, all product usage data is not sold on to third parties. It’s used purely to inform product development decisions.
-
Anonymity is a spectrum and in Amplitude and Metabase, we strive to minimise the product usage data we collect that create high risk of inferences. For example, the Anytype app does not share channel IDs with Amplitude, we create a synthetic ID that abstracts the data so correlations cannot be made. This means Anytype is unable to see what kind of activity happened in which space, we can only see users have X number of spaces and they create X number of objects. Again, visibility of abstract product usage data does not compromise the privacy or security of any content in user spaces.
-
Although associating emails to user accounts is the standard practice in cloud products, this is not the standard we strive for. Anytype tries to minimise how much personally identifiable information we collect to minimise anonymity loss. Unfortunately, it is not a simple exercise and must be constantly worked on. We can and will get things wrong, but we will own up to it when we mess up and fix it.
-
Today, Anytype’s account creation process is permissionless with its seed phrase—no email required. Thus, it’s possible to spam create free accounts and fill up our network resources (costing us performance and money). To mitigate this issue, we currently analyse network data to combat suspicious activity. This is a threat vector that we must eventually address as it’s a progressively larger problem each day. Email verification is industry practice for limiting this misuse; however, we are exploring alternative solutions.
-
Importantly, the practice of collecting emails to create user accounts is something that we may choose to do in the future. It’s not completely off the table. However, doing this does not necessarily mean there will be a permanent connection between email and user account—high levels of anonymity can be preserved.
-
Beyond account verification, there are obvious incentives for Anytype to collect the emails of free users to send onboarding and marketing emails to improve product adoption. Again, this also does not necessarily mean there will be a connection of free user emails to user accounts.
-
In summary, users on the Anytype network have high levels of security, privacy, and anonymity—but there is variability across many dimensions. All content inside user spaces is fully private and secure, this we can guarantee with our code. However, we cannot guarantee full user anonymity across the board and don’t optimise for it.
-
For example, your user account is anonymous in creation, but immediately loses anonymity to other users once you start interacting with them because you must share your Anytype ID to be in the same space. Additionally, when users are in email correspondence with us there is also some loss of anonymity. We try our best to minimise this, however it is not prioritised like we treat data privacy and security.
-
To improve anonymity, there are reasonably easy steps that a user can take such as using different email addresses and VPNs. For stronger approaches, looking at self-hosting and other measures is recommended.
Below we will outline a recent conversation in our community that triggered us to review our email collection system. I want to say that it is amazing to have a community of inquisitive, engaged, and conscious people who volunteer their time to not only push our product to be better, but ourselves as well. We have learned a lot throughout this review and have made relevant updates.
Our plan is to take all our learnings from the community’s feedback here, adapt, and then outline these items in a future blog post for better accessibility and persistence.
Email Collection - Post Mortem
Summary
-
A community member pointed out that there was an in-product dialog that was forcing users to provide an email to get a free membership. This was a mistake due to old code being triggered from our new membership system, the reasons outlined in the post-mortem, and has since been fixed. The emails collected were sent to SendGrid, deleted automatically after 24 hours, and was not connected to a user’s Anytype ID.
-
A community member pointed out that we used to collect emails during user onboarding without the possibility to skip. Although this was already changed prior to the most recent conversation, we’ve outlined the reasons in the post-mortem for those who are curious.
-
A community member pointed out that we wrote a blog post in the past that was inaccurate (https://blog.anytype.io/notion-alternative). It stated, "Anytype is fully anonymous as we don’t collect your email or any personally identifiable information which is connected to the contents of your space.” This is was a mistake as ‘fully anonymous’ is too strong of a statement and set too high of an expectation to our community. We’ve temporarily taken it down.
Email Collection Overview
Currently, there are three primary reasons to utilise user emails in Anytype and we will outline our thoughts on them.
-
Verify legitimate and unique users.
-
Marketing to users.
-
Providing user convenience.
Verifying Users
Today, Anytype’s account creation is permissionless with no email required; you can generate a seed phrase entirely offline and use the product. However, for those who aren’t self-hosting, you must connect to Anytype nodes to sync your data (free and paid plans). Once you do that, you consume network resources. It’s possible to spam account creation which would directly impact our finances and performance. There are multiple solutions to address this, email verification is one of them and is a proven approach that helps.
Marketing
Onboarding emails to provide resources, guides, and an open line of communication with new users is a proven strategy to help with product adoption. Anytype is a product and getting users to adopt it is the goal. Additionally, when we release new features, announce town halls, and have relevant information, having a communication channel is helpful. This must be in compliance with consent and GDPR regulations.
User Convenience
A seed phrase is intimidating to the vast majority of users, they expect an email and password when creating an account. Additionally, many users may want single sign-on with their accounts on Google, Apple, etc. A seed phrase may be simple for those familiar and with password managers, but it’s easy to mishandle for the average user—which leads to lost accounts without any means for recovery.
–
Due to this variety of considerations, email collection is always on the table for Anytype—even if it is not implemented today. This has no effect on the data privacy and security of your spaces, all your content remains safe from external actors. Collection of emails may have varying effects on anonymity, however there are methods to mitigate this. As an example, we disassociate emails addresses from user accounts on our compartmentalised internal systems.
Email Dialog
A community member pointed out that there was an in-product dialog that was forcing users to provide an email to get a free membership. We’ve investigated and here is an outline of what happened:
-
In Feb 2024, there was an idea to have email verification for free plans.
-
This was implemented in the Anytype app, but there was a decision to not launch it widely.
-
In Dec 2025, we released a new membership system with new capabilities such as seats and addons. We also updated our applications to support this new system. As the new app versions have fully refactored membership flow, they didn’t have ‘left-overs’ from the verification flow.
-
We provided backwards compatibility (legacy support), so that users on the older version of the Anytype app should still be able to access the new membership system and upgrade their plan.
-
What was forgotten is the logic surrounding ‘require an email for a free plan’ which was sleeping in the code of older versions of the application. This trigger was sleeping because we hardcoded membership levels IDs the application should ignore (all of those which existed in the previous membership system).
-
Hence, when we released the new membership system with new membership level IDs, the sleeping ‘feature’ in older versions of the app was triggered and displayed to users.
-
Emails collected in this dialog were sent to SendGrid and deleted automatically after 24 hours.
-
We have now removed the verification-related logic from our nodes—submitting an email won’t work anymore. However, the dialog exists in older versions of the Anytype app and will always exist.
What was the reasoning behind this dialog in the first place?
To reduce spam account creation and to collect emails for marketing was its original purpose. However, this membership dialog didn’t fully survive in production because we addressed the initial goals differently—hence why it was not launched widely. To mitigate this malicious account creation, we currently analyse network data to combat suspicious activity. For email marketing, an email collection field was introduced as part of the onboarding flow instead.
How the process logic for this dialog was designed originally:
-
User is prompted for an email in the app.
-
The app sends this email & id to our node. A temporary link between email & id exists.
-
Node creates a verification code.
-
Node adds the email address to SendGrid, triggers the API to send an email with the verification code to the email address. SendGrid does not have the user’s Anytype ID for the email.
-
User enters the verification code in the app.
-
App sends the code to the node.
-
Node verifies the code: if correct, assigns the Anytype ID with explorer membership level.
-
Node removes the email address from the database, no link between email & Anytype ID anymore thereafter. The email address is also removed from SendGrid.
-
Corner Case #1: If the user doesn’t enter the verification code within 24h after it’s requested, the node removes the email address from its database and SendGrid automatically.
-
Corner Case #2: If the user marked that they want to subscribe to our updates & email, the node doesn’t remove the email from SendGrid.
What happened when the dialog reappeared on older versions of the app after we updated the membership system:
-
Before 8th Jan 2026: the node received the email address sent from the app, the node added them to the database and SendGrid for 24 hours, and then removed the email address, because the verification logic was turned off.
-
After 8th Jan 2026: node was updated to the refactored version without membership v1 leftovers, including this SendGrid-related logic. In short, the app can’t trigger the methods it’s looking for and displays an error to the user.
What were our learnings:
-
If we discontinue features or shutdown experiments, we should completely remove it from the code asap.
-
We should have better internal documentation and regular reviews of our systems surrounding emails.
-
Investing time in good process flows is worthwhile. This bug that triggered email collection ultimately did not lead to unnecessary emails being stored in a forgotten database because it was being deleted automatically. Additionally, it avoided having a persistent link between email and Anytype ID on both internal databases and SendGrid.
Email Collection in Onboarding
This is not a ‘bug/fix/mistake’ post-mortem in the traditional sense, however it is a share of our decision making around email collection during account creation and expectations we set to the community.
In April 2025, an update to the onboarding flow on Anytype was made and email collection was updated to be mandatory with the goal to improve product adoption. Importantly, email collection during onboarding was in no way tied to user accounts and had no effect on the privacy or security of our users’ content in Anytype. This decision had some pushback from both the community and our internal team members.
On 11 Dec 2025, one of our engineers reasserted the suggestion that we make email collection less mandatory because a friend of theirs did not like it. Without much deliberation, we decided to remove it. Although not explicitly discussed, the logic is likely that our potential users would more turned off from email collection than the potential gain that email onboarding would provide—especially given our how lacking our email onboarding is today. We didn’t do any deep testing or evaluation on this and probably should have. It was a decision based on intuition. That being said, our basic retention metrics did improve with mandatory email collection on.
Where we messed up: in finding the right balance between vision/marketing statements, matching it to the reality of our product decisions, and communicating accurate expectations for our community. If Anytype is meant to be permissionless, but users are immediately confronted with a mandatory email sign up, this isn’t aligned. If we collect emails mandatorily, we should adjust how permissionless we promote ourselves to be; in other words, we should not have promoted expectations of permissionless account creation.
If there is a decision in the future to add email account collection, then we must better communicate the reasoning and adapt our communications to match.
Inaccurate Blog Post
A community member pointed out that we wrote a blog post that was inaccurate (https://blog.anytype.io/notion-alternative). It stated, “Unlike Notion, Anytype is fully anonymous as we don’t collect your email or any personally identifiable information which is connected to the contents of your space.”
-
This is was a mistake and gave the wrong expectations to our community.
-
We’ve temporarily taken it down, and should edit it to be more accurate. “Unlike Notion, your content in Anytype is fully private and secure, meaning it can only be accessed with your permission.”
-
Internally, we did not properly educate our team members on the difference between privacy, security, and anonymity. Additionally, we did not properly review material before it went out.
-
What did we learn: content we put out sets expectations and we should put more care into communications.
–
We apologise for the delay of releasing this post-mortem; it took quite some time to dig through the code and tools from years ago to understand the dynamics and decision making surrounding past work. In the future, our communication should be better to quickly alleviate any user concerns around the handling of their emails.
We will have more to share soon on other learnings and updates we’re making to other areas of Anytype. However, we want to provide some space for questions and feedback in the meantime.
Because you’ll probably also enable 2FA then, and this makes it sooo much more secure, which I’d prefer.
You’ve truly outdone yourself 
