According to the feedback by @geargat, the Aeon Timeline 3 file format has been changed in the meantime, so this script might not work for you.
Since I still use Aeon Timeline 2, I cannot develop my Aeon 3 tools further, I’m afraid.
However, anybody who wants to adopt the code can update it.
Hey - I created an account just to comment here and say that there is demand for your beautiful work. I am sure there are tons of others like me who stalk this thread and keep hoping there is a solution. I would be eternally grateful to you if you figure it out. Lots of love and cheering.
Another stalker of this thread as well. Very impressive work being done here; am tempted to dive into this … I imagine there are more stalkers and lurkers in the shadows.
It might behoove us to understand how everyone uses AT and Obsidian and how they expect to use and manage the interface between the two products. In my workflow, Scrivener comes into play as well. I suspect a wide variety of desires and intentions.
In my case, I am a essay, short story, and novel writer and use AT to outline events (scenes) across plots, story arcs, characters (at a cursory level), location (cursory), and timeline. It is an incredible tool for this. AT is meta data rich.
Obsidian is my data and information & research repository and drafting environment.
Once I have a draft that is worthy of further writing, I use Scrivener for manuscript development. I still use AT and Obsidian as research and first drafting. Both AT and Obsidian are extremely useful in the early, planning phases and then tapers off during drafting.
My hesitancy in pursuing this interface is due to the one way nature between AT, Obsidian, and Scrivener. Granted I do all of my crafting on a large monitor, so I can have all three open and usable; why bother with this interface. I can see where it would become messy, quickly.
However, the idea of this interface won’t leave my interest. The most powerful attraction is in the relationships that AT has between all of these attributes and how that can translate into links in Obsidian. But what is the value in doing this. I can see @Peter_T has a need to use a andoid phone in his workflow.
Thoughts?
Thank you very much for your kind words, @Broken. Many people find the idea of transferring data from Aeon Timeline 3 to Obsidian cool. It was an interesting study to realize something like this, but so far I haven’t received the feedback “It actually works for me” from anyone. And now it’s too late: The file format of Aeon Timeline 3 has been silently changed, and since I haven’t got the app, I no longer have the possibility to reverse-engineer.
As far as the hope of synchronizing unsupported third-party software with Aeon Timeline 3 is concerned, I have to bring some sober facts to the table here:
- A project in Aeon Timeline 3 forms a network structure via its relationships.
- As far as I can tell, this network of relationships can only be fully reconstructed from the original .aeon file.
- The CSV files that Aeon Timeline exports and imports, on the other hand, are two-dimensional arrays. To find out the relationships here, additional knowledge about the user-defined structure of the project is required.
- This makes it seem impossible for me to write a generic conversion tool based on the CSV export that is as powerful as aeon3obsidian.py.
Just to be clear: For me, aeon3obsidian.py was a programming exercise, inspired by the feature requests here in the forum.
I only had access to the .aeon file format version 6 from the beta test phase, since I don’t use Aeon Timeline 3 myself. And I tried Obsidian because of the general enthusiasm, but I keep using Zim Desktop Wiki myself, which is more advantageous for me.
As for my workflow, if I were to actually use Aeon Timeline 3, I would need both an export of the narrative and the synchronization of the event dates with my writing program.
During the beta test phase, I programmed a converter to yWriter and a LibreOffice extension. However, because I was unable to synchronize in both directions, I decided to stick with Aeon Timeline Version 2, where I can do so.
I just got into Obsidian recently. Right now I use it for building a Zettelkasten and notes in general. I will probably use it as a repository for all short form texts as well. At the moment I am not planning on doing long form texts in there, I guess I’ll stick with Scrivener for that. My current workflow is brainstorming in AT, building an outline there, then start syncing to Scrivener and keep on working in both.
That’s why right now I don’t think I’ll start mixing AT with Obsidian, but it’s possible that some day I’ll switch and maybe then I’ll be making use of something that started in this thread. Maybe we’ll have a dedicated AT plugin in Obsidian some day. Or AT will officially sync with Obsidian (which would mean syncing to a folder of Markdown files, actually).
+1 / fingers crossed for this same use case @Rob mentions! Sync would absolutely skyrocket the already-high value both AT and Obsidian have for me too.
A general Markdown export is something I have been requesting from the very early days of alpha testing Aeon Timeline. I want to be able to take an outline from AT3 and put it into Ulysses. But an export to Markdown would also work as the basis for an Obsidian integration, no doubt. There has been some teasing of adding further ways to export in future beta versions of AT3. But whether Markdown is one of those formats I have no idea. With Ulysses I can take word files and convert them easily and accurately into Markdown. So I have a few options for possible Ulysses integrations from AT3 in the future.
On a personal note I have no need of Obsidian. I have a copy of the app and hold an insider license, but I find the whole back link approach too much for my fiction workflow. Obsidian is a hugely impressive piece of software but now Ulysses has its own powerful internal linking with backwards and forwards navigation, I can’t ever see me needing Obsidian’s feature set.
I do hope those seeking Obsidian integration get what they want from AT3 though. Especially if it means we all get a solid, flexible markdown export.
For whatever it is worth: I think it is very difficult to write an export or sync script as every need is very different. It would be nice if Aeon either confirmed that the file format is frozen and won’t change, so no effort is wasted, or if they even would provide documentation to help write a generic module (probably in Python) to read the files. I did some research earlier this summer but it was simply too much for me to spend time on.
I use Aeon to plan a roleplaying campaign and in that I have a lot of events which I want to refer to in my text. I write in Markdown, which I process using Python and GPP to generate HTML. I export the timeline to CSV and have a Python class parsing that. I then write things like
Frodo left Bag End on the
@aeon(Frodo Leaves Bag End)(start:dth)of@aeon(Frodo Leaves Bag End)(start:mmm), the@aeon(Frodo Leaves Bag End)(start:mth)month.
and in the HTML I will get
Frodo left Bag End on the 23rd of September, the 9th month.
The code is quite simple but extensive since it adopts the output to if I write in Swedish or English (@aeon(Frodo Leaves Bag End)(start:dth) would render in English as “23rd” but in Swedish as “23:e”).
What a great idea! I’ve got to try this because Obsidian is my canon repository of knowledge for my saga and I’m just now getting started with AT3.
However, I’ve run into a snag when trying to use your script.
Could you please have a peek at this Grok conversation and let me know what I’m doing wrong?
Might the .aeon file format have changed? Is this script still compatible with the current format?
There nothing you’re doing wrong, except ignoring the Requirements section on the aeon3obsidian home page. As stated there in bold, as well as in a recent post in this thread, the AT3 file format has changed since I figured it out during the Beta test phase. Because I don’t have an AT3 licence, I wouldn’t do any further development on the script. However, it’s Open Source, waiting for someone to adopt the code.
Anyway, LLM’s response provides some useful hints on where to start when adapting the code to the new file format. The first step is to extract and analyze the JSON structure of your .aeon file. Then adapt the read() method of the Aeon3File class in the aeon3_file.py module so that it finds the elements in the right place in the data tree.
If we are lucky, the required JSON elements will all still exist, but they will have been moved to other hierarchy levels in the structure. However, the file format can be silently changed again at any time.
Thanks for the reply! So the short of it is that the script is currently broken until someone can pick apart the AT3 project file format and teach the script how to find the relevant information.
I might be able to do it if I put a lot of time into it. I’ve done some crazy stuff with Python in the past, but it’s been a while. LLM might be able to refresh my memory, but it’d be a time commitment. The script does sound like a fantastic tool though! I could really use the ability to export Aeon data into Obsidian. Thanks for your work with it. I’ll have to do without for now.
“Broken” is too harsh a word. I’d rather call it “outdated”.
Crazy stuff with Python is not necessary at all, and I would never rely on LLM-generated code. How to deal with JSON files is very well explained in the Python documentation and is not rocket science. Probably the biggest learning achievement is to fork the GitHub repository, commit the changes in a properly documented way, build the release package and create a pull request.
That’s cool. I might give it a shot.
I do like to use LLM to point me in the right direction when dealing with unfamiliar techniques. Like I used it at work last year to create a JSON parser that extracts our company’s sale data from our ERP’s API. It was quite a learning experience since I had zero experience with any of that.
At any rate, I just created a sample AT3 file with a single test event and gave it to Grok to see if it could find the event and point out anything notable about the structure. Here’s what it found.
You can of course do it the way you are used to, but be aware that there is no intelligence behind the LLM. The answer I saw merely reflects the complexity and redundancy of the .aeon file format. Better to start from the Python code, where you can immediately see what the required tags are called and in which parts of the structure to look for them.
It looks like it’s fun to play around with LLM-generated code. Maybe you’ll even manage to publish your own tool.
To give you a reference, I just uploaded the zipped Obsidian vault created with Aeon3obsidian from the “Murder on the Orient Express” sample project to my GitHub repository:
Good luck!
A look at the LLM answer shows that it’s not quite that simple. In the new AT3 file format, the JSON elements of interest have been both restructured and renamed.
For instance, the old item dictionary in aeon3obsidian.py is
jsonData['data']['items']['byId']
whereas the new one in the LLM-generated script is
json_data["data"]["itemsById"]
But since it seems to follow a pattern, it could be quite easy to update aeon3obsidian.py. However, this should be done from a proper understanding of the JSON data.
You’re correct that LLM doesn’t have any true intelligence, but it’s pretty good at generating code if you provide iterative feedback. Check out this conversation where I work with Grok to fix the script for the new AT3 project format and also enhance it to handle multiple eons rather than limit to the Gregorian A.D. calendar. Also working on enhancing it to provide item types and custom properties.
And to be clear, I haven’t written a single line of code here. It’s just me giving Grok the debug results of the script run. Going to put it on the shelf for the moment as I have some more pressing things to work on, but this was a pretty impressive test to see if LLM could solve the issue all by itself. 
But you can, if you add Scrivener to your workflow. Just sync AT3 metadata to Scrivener, then use Scrivener to compile the metadata into markdown files. You can even write the metadata to YAML if you want.
In disclosure, I’ve only confirmed this with the Scrivener folks, but haven’t done this step because I came up with another approach that I’ve already written about: AT3, Scrivener, and Obsidian - Q & A - Aeon Timeline
Yes, it is interesting to see how such an LLM generates code. However, I found some unmotivated refactoring, as well as scattered changes where, for example, instance variables were replaced by parameters, which is a difficult source of errors to find.
Also, an obvious hallucination that wouldn’t go unnoticed with a decent IDE.
Original:
self._write_file(f'{self.folderPath}/__index.md', text)
LLM:
self._write_file(f'{selfaveringfolderPath}/__index.md', text)
Then the LLM contradicts itself: In the first iteration, it claims that the problem is the scan function and replaces it with a regex function. However, in the follow-up comment, it recommends replacing regex with a scanner. In the last iteration, I then see a scanner, which is a cumbersome variation of my code. I also see a test for Zipfile, which seems completely unnecessary to me.
Something like this shows me that with the LLM we have a counterpart who pretends to have superior knowledge, but in reality understands nothing.
The final version of the code is quite pimped out and a bit opaque and may or may not work for a particular example, but I don’t want to have to look for bugs in it. Instead of fiddling around with the code until it somehow works, I still stick with the good old programming skills.
Whatever the case, can you use it to convert the “Murder on the Orient Express” example satisfactorily?
Everything you’re saying is completely true. I’ve had LLMs (like Cody) take me down some pretty insane rabbit holes when trying to learn a new technology. It seems to get worse the longer the conversation goes on. Often just starting fresh will make it think clearly again.
One time it tried building for me some truly absurd generic JSON parsing methods in C# when I explained that our API endpoints all returned vastly different fields. It got the bright idea that we could make a generic import that would try to determine field names and set up a series of rules on what to do with them. Ended up wasting hours before I gave up and made my own solution.
But despite its flaws, I have to say it’s invaluable in specific cases. It’s superb at writing quick SQL queries to give you a custom result set you’re after if you just give it some example relationships and say “now make it do this”. It’s also really good at giving a summary of a new tech you’ve never used just to get you up to speed.
One Python script it made for me from scratch via me explaining a really customized video editing need and going through 10 versions to get it perfected is a script I’ve used hundreds of times since. It just works.
But ultimately, if you don’t have a technical brain that can take over for it once it starts going off the rails, it’s going to just make a huge mess of everything.
The same is true for writing fiction, for what it’s worth.
LLMs are awful at generating story prose. Like don’t even bother. But what it’s actually quite good at is giving honest feedback (if you ask it to be honest) on your story text. The prompts have to be worded in specific ways or you’ll get nothing but garbage flattery of course. But I’ve had some incredibly helpful conversations with LLMs to give feedback on my writing techniques.