I’m so impressed with the ongoing work to AnyType. It keeps getting better! I really wish I could come back to using it and so I’m begging, as a strong supporter and early paying member (even though I cannot use it) please please please prioritize fixing the data loss problems, which includes copy/paste and export of properties/relations as well as truncated link names.
These problems present a significant barrier to adoption not just in my own experience but others have mentioned these in the forum and bug reports.
ISSUE/RECOMMENDATION
Relations/properties and their associated data cannot be copied/pasted nor can they be exported to markdown/YAML. This means that data we store in AnyType cannot be preserved or transported outside of AnyType, which realistically results in data loss. Additionally, the truncation of link names from object to object means that we lose data every time those are exported to markdown (or copy/pasted into an e-mail for example). A markdown file that is missing the full title of a linked page is not useful. A markdown file that omits all of the relation/property data I’ve stored is not a reliable or accurate way of preserving and accessing my data down the road.
At the moment, using AnyType implies accepting data loss (I’m ignoring the potential of API work or protobuf possibilities because these are not solutions for the common user that needs straightforward interface functionality built-in).
HOW IT COULD BE DONE
We really need all information fully exported to markdown/YAML from the existing export user interface. The Space export interface currently implies that it will do this but it does not.
USE CASES
In every day use, these issues make it so that I cannot copy text from things I’ve put in AnyType and paste it into other applications such as e-mail, word-processor, web pages, etc.
In the case about ensuring I’m able to preserve my data, it’s 100% critical that I can export all information from AnyType, which necessarily includes relation/property data.
ADDITIONAL CONTEXT
It’s not currently safe to rely on AnyType without this ability. I already experienced one severe problem that led me to decide to stop relying on AnyType because I couldn’t get my data out during my little catastrophe. Solving these data loss problems would make all the difference in the world. Here are some of the bug reports and forum posts that I’ve noted. I’m pasting them here, in a well-meaning effort to try and keep awareness around this issue.
Data loss is not the appropriate word IMHO. Because it’s a local first app, available on every OS, so your data may be locked to Anytype (until they fix the issues you mentioned) but this is certainly not a data loss.
I don’t know if the Space export still have issue tho, which may be problematic in itself.
I agree that thoses issues needs to be adressed at some point, but I don’t agree with the wording.
I agree that the data remains in AnyType and thus on my local storage. However I provided several examples of real cases in which you undeniably lose data through expected use-cases of AnyType. I suppose my title is misleading, I should have titled it “…losing data from AnyType” not in to be accurate.
Nah, I’m with you. Splitting words don’t help people access their data.
If I have an actual physical vault and have information in there and can’t get in, that information is as good as lost to me.
I did an export recently to markdown. There was so much data missing, it was honestly unusable. It’s in terrible shape.
The average user does not care their data is still there. If he can’t access it, it’s as good as lost. AT team does not seem to prioritize this unfortunately and this does give an uneasy feeling to people that they may be locked in for who knows how long. Not a good feeling.
Putting all the attributes (or is it fields…forget the new name) into the frontmatter is the most logical thing to do.
to be fair every SaaS has this issue
the markdown export for example. it is just not possible to replicate everything Anytype does in markdown.
either one uses a standardized file based system where the files have a universal format (Obsidian, Logseq) or one is locked into a service that uses it’s own editor has a database backend and a lot of custom functionality.
Anytype can export to a JSON format and users can then create a custom application that could translate this into something different, that the new target application supports.
If Anytype gets bigger perhaps other services will have importers that support this.
Sorry but I don’t think that is fair. One need not replicate everything in markdown but that is not the issue. SaaS (which if it refers to software as a service, AnyType is not) also does not inherently have this issue.
The issues here are that things that appear as text do not copy or export, or in some cases only do so partially. That should not be an issue. Fundamental and basic data portability and preservation should not require users to create custom applications. It needs to be simple and built in so that the application can be safely used as expected. And especially when the application itself tells the user it is doing something, it should actually do it.
I agree with this
What I more or less wanted to say is that Anytype uses a client-backend structure that does not necessarily translate into file based exports and that this is an issue with all software that doesn’t use a file based structure with standardized formats. that’s why other software or services have their own importers for various other services.
I hope someone can write a tutorial titled “Building the Anytype Desktop Client from Open Source Projects”, detailing the completeness of the open-source code and the obstacles encountered during the build process.
This would help community members understand whether we can truly own our data in the event that Anytype ceases operations.
“I don’t understand technology, so I hope to see a third party verify Anytype’s commitment to data sovereignty.
It’s not that I don’t believe Anytype’s promise — I question everything.”
I just tried an export in the latest version 47.6 and I see that the properties (relation) values, wherever they appear in an object, now seem to be included in markdown exports at least within the YAML properties at the top! This is a really great and reassuring development!
There’s been really nice progress on ensuring we can get our data out of AnyType for use in other tools, I’m hopeful to see more in the future. Since this original post was kind of lengthy and addressed three different things under the same concept, I would like to keep some attention on the part about long links getting truncated (thus leading to a user losing some data).
This one keeps catching me when I don’t expect it and I feel like it might not be a difficult fix (but admittedly I don’t have a clue what’s involved so I might be entirely wrong).
For example, I go to copy the content of a note and paste it in an email to someone BUT then realize that some of it is missing because instead of wrapping a long link, the text is cut off and replaced with ellipsis. Also, for example, I export to markdown to keep a backup for myself but, oh no, I’m missing information because it was long so AnyType cut it off instead of wrapping it.
