The claim that Anytype’s export options are really weak and/or don’t provide you with full access to the data held in relations is concerning. I haven’t run the tests myself but assume folks are telling the truth about the limitations. Are there any plans to address the limitations?
Being able to export data in relations is critical otherwise the data is just a bunch of text notes at the end of the day.
Much of this post stems from this Reddit post which really highlights my latent concerns about investing so much time and energy into any single platform with lock-in of any sort. https://www.reddit.com/r/Anytype/s/ZsT2mGa3cb
I don’t have any plans to leave Anytype, but I think this is a legitimate concern. I agree with @888 that at least the relations should (maybe optionally) be added to the base of each .md file - could be a simple table.
Without relations, if I export one of my book collection objects, the export contains very little of use - author, genre, date purchased, reading status, description would all be missing leaving me only with the title, the book cover and any text I have keyed into the object.
I believe it’s not entirely fair to say that Anytype creates a lock-in. Anytype allows users to export notes in widely used formats like Markdown and PDF, and there’s no proprietary “Anytype format.” The “Anyblock” format is open-source, self-descriptive, and built with Protocol Buffers (Protobuf), so anyone can create a converter for it. In fact, a community member has already developed a converter.
We are transitioning to a new storage foundation based on SQL, where all objects will be stored as JSON. This format is highly standard, making interoperability much easier. Our upcoming API will also be based on this structure.
Moreover, all Anytype builds are available on GitHub, allowing users to install them and interact with their data freely.
So, rather than a lock-in, the current limitation is simply a lack of easy-to-use tools for format conversion, something we’re actively working on solving.
sorry, i would disagree. in general: results matter, not announcements. and as for announcements go – this one is vague at best.
let’s take “SQL”: who cares where the data is saved? that’s a technical detail, which no one cares about. (it might be incredibly important, technically, for the development of the product – the user does not care at all …)
then JSON: while “JSON” surely is super simple and standardized, the structure you use is … neither. you can change it any time, and at will – and it’s everything but “simple”.
the API is not even planned.
download anytype: well, even if you do, you can only export the data in the aforementioned JSON structure, which is of absolutely no use to anyone not willing or able to download and run source code from github – not knowing whether it will work or not.
I myself have already been burned by that export limitation, and there are severalrequests already to mitigate.
(for me, the exporter mentioned by @Filiphere – thanks for the link – might be a solution, but that’s just a stop-gap, and a non-starter for non-tech-folks anyway …)
so yes, if you ask me, there most definitely is a “lock in” –at least at the present moment.
so “solving” this as @anton apparently did … a bit premature, and i fully understand @anytype_guru – i “only” created a massive list of watches and watchmakers, and already i am feeling the limitations up to the point where I cannot realize something I wanted to do.
I’m sorry that my initial explanation came off as vague; I hear your concern about wanting concrete details. I’d love to clarify where we are in development so you can see exactly how it impacts your use case
Wasn’t it mentioned in the context of the JSON file format? As proof that we are heading in this direction, most of the people here are technical, and this speaks volumes.
I am not sure I got what you mean here. Current JSON made via converter form Protobuffers. Future JSON will be native JSON. In the next release we are moving to a new datastore. Initially it’ll be used only for messaging functionality, but we well move all app to it over time.
The first version of the API has already been developed. In the next release, there will be a Raycast extension based on this API. After we see how it works, we’ll publish it for everyone. If you’re interested in early access, please let me know. This API will make creating imports/exports, even with AI integration, a breeze. It’s just around the corner.
If you use the native format ANYBLOCK, it just works. I have an artifact: a laptop with a version of Anytype from 2020, and it still works. All data is saved, even though the network it was syncing through is no longer supported.
I feel what you mean. In my view - there is no black and white. If you ask me whether we give people autonomy from us as a software provider—certainly, yes. If you want a 100% seamless export flow—it’s not fully there yet. But at the same time, it is possible. So, saying we are lockin users-in is not entirely fair.
I hope the upcoming API will eliminate your concerns completely.
I’m more the “it’s not there until it’s there” kinda guy . A really good example of that cynic approach would be WikiJS, which is announcing a beta version “any time” now for … about four years.
That was … not very discernible “from the outside”. Any docs available?
an API is nice and good but what could my non-tech-savvy relatives do if they want to export their entire vault to human readable files that they can open and use elsewhere?
Because of this
I cannot recommend Anytype to anyone who fears they will lose data if Anytype is not there anymore or they want to try something else.
sorry, I read the subject from afar and every time someone says that, I ask myself the question… so I ask it.
What do you recommend as an application?
Because I don’t know of any with exports offering universal compatibility, I’m curious to go and see how it’s done.
Just doing those can significantly make exports more usable. Right now .md files are almost unusable with all the fluff .md files that gets exported that does not mean anything, along with the actualy .md files that do not include type and properties; it’s almost as good as not usable for how complicated non JSON files are when exported, therefore a lock-in.
With usable md files, there are many apps that accepts that file type, namely Obsidian.
I used Standard Notes before Anytype. It uses it’s own editor based off one developed mainly by Meta (forgot it’s name). It allows to export to markdown while having some frontmatter and keeping its supporting elements somewhat intact.
Sure if those elements are interactive they translate in just text form.
But what we can expect is at least that all the data is there.
Another example would be Notesnook that doesn’t leave out data when exporting to Markdown.
While Capacities has other portability issues it at least does a good job with its type exports. It even exports Database tables as CSV. And for properties it even exports all properties and tags of objects as frontmatter within its markdown exports. It’sa very great base for using capacities exports directly with obsidian.
I mean when we look at bookmarks in Anytype, the URL is a property. It just doesn’t get exported. There is no reason for it to strip out the most important information about that type.
There you have some examples that come to mind.
For simple note taking I would recommend Notesnook as Standard Notes is essentially stale and dead.
For flexibility I recommend Obsidian or Logseq.
My recommendations are based on the focus on privacy and data portability.
I think I know where you coming from, yet this is not a helpful question, because it answers a valid concern with an overblown technical requirement.
The goal is:
to export all (or at least most) of the information within AnyType to a format that is easily worked with
… so that you can start re-importing somewhere else (or simply re-formatting for long-time local / backup storage)
The Any JSON data type does not solve this. A markdown export which at least includes all links and all object metadata would. And the (technical!) question about “universal portabililty” is not what is required.
Why?
(true question, I’m happy enough with what AT offers but I’m curious about such an intense attachment)
Json export is complete and easy to work with (I’ve build the Evernote converter with it, it’s not a problem to reverse).
And Json, like markdown, is an open, universal format.
And it seems to me that json is better suited to structured data (markdown has its uses too, but for exporting my databases I like to keep everything, including the structure).
By the way, from memory, markdown doesn’t have a single basic standard, but since I only use it occasionally, I could be wrong..
Exactly
Each has specific elements that will pose problems when importing into another application (since they’re not built in the same way). Above I was talking about JSON, but thanks for the question, I agree: “What would a non tech person do with it, without a markdown converter"?
The imports that work without loss are those developed (by the developers of the destination application or by others), to adapt the data to the output format, whatever that format may be.
It’s the reason of my previous question.
Each application has its own specific data (data type, format, structure, nesting, etc.). I’m curious to see a universally usable export (I definitely plan to look at your suggestions to see how it’s done). I used Standard Notes, but I’m not convinced it’s a good example — I didn’t have enough data in it to really dig into it.
Without that, it seems essential to have an export that preserves all the data (including the structure) in a recognized, easily readable and usable format, so that the community can make use of it. A complete but unusable export in Markdown format is just as appealing as a complete but unusable export in any other format. The difference is that Markdown allows you to export fewer things — its only real advantage (again, not an export of Markdown, correct me if I’m wrong) is that it can be read as-is. But I’m not planning to replace Anytype with Notepad .
sorry, wrong answer and not accessible. if you need to do this you failed your mission.
sure, but the app should at least give me the content in a human readable format.
everything within an object can get translated into something else.
if an inline set for example doesn’t work well in another format, then it can at least give me a separate CSV or a normal table within the new format.
properties can just be frontmatter within the markdown headers.
I don’t talk about app specific formats. I talk about universal formats that are not tied to specific applications. Markdown is one.
For example I can use all the exports from the applications I mentioned earlier in another app I want (Typora, Logseq, Obsidian, Marktext - even a simple text editor).
This is what accessibility is all about. It is not nacessary that every element looks the same if the data is at least there. And this is not the case with Anytype right now.
–
edit:
It is not feasible that a normal user needs to find ways to work with a random JSON format that no other application supports. This is a part of lock in - you need money (if you hire someone), the community (we know how reliable community contributions can be cough abandoned projects everywhere) or knowledge and programming skills to work with the JSON file.
I think I understand your need — it’s not truly a complete export in the broad sense, but rather an export of all text-based data (contents, tags, properties) in an easily readable format.
Our needs are just different — that’s not what I’m looking for at all. My knowledge base contains (or will contain) typed and heavily structured data. I spend a lot of time organizing it that way, and I don’t want to lose that given the time invested.
Markdown is just a presentation format — for my needs, it’s useless,that’s why I was questioning your request and wondering what you were actually planning to do with these more complete Markdown files.
An application that offers to export my data in CSV? I’d run away. Sure, it’s also readable in a plain text editor, but if I’m switching to another app, I want my data in that app — not just a spreadsheet. Just look at CSV import in Anytype…
Some applications also offer HTML export (Evernote, for example). It’s nice and very readable, but again, if I want to migrate to another application, it becomes a problem and I lose the structure.
. A really good example of that cynic approach would be WikiJS, which is announcing a beta version “any time” now for … about four years.
.