Just like all other files in Obsidian, canvas files are your own and local to your device. You're still linking to your own Markdown files which are just as future-proof as ever.
We decided to create the .canvas format because there wasn't any pre-existing canvas-type format we could find that fit our priorities around longevity, readability, interoperability and extensibility.
The .canvas format is designed to be as easy to parse as possible. We've already seen a few plugins take advantage of it, and we hope that more tools will become available that can use the .canvas format.
The local first approach is the primary reason I use Obsidian. I trust that I can _depend_ on Obsidian because of this.
On the other hand, this has also caused some headaches around using it on mobile.. but so far this has been a worthwhile tradeoff. Thanks for all the hard work!
Syncing bytes is easy, many solutions exist (and syncthing / syncthing-fork is good at it).
Syncing by merging changes and resolving possible conflicts is a much harder task. Theoretically git has all the right bits, including the pluggable diffing and merging. In practice, I haven't seen it seriously used in this capacity.
This is to say nothing about files you only want on one node but not on another (heavy stuff lives on server and laptop, but not mobile, etc.)
This is why special-case syncing tools that know how to sync semantically are indispensable.
Most apps aren't built to use it, especially on mobile. Think of the use case of your grocery list--you want one tap, open the list, type type type, and done. Anything else--having to tap save, sync, write a commit message, etc... anything, is a fail in my opinion. Git is great to use behind the scenes but I don't want to see it in the UI or slow down my workflow.
Indeed, this can be done, but usually isn't. And when it is done, it looks like another proprietary syncing protocol.
The thing is that you should not expect a user to explicitly host a git repo somewhere to for a grocery list app. Most apps are designed for users who are unwilling to do that, and are actually ready to pay to avoid whatever technical hurdles.
OTOH I see a niche for an app geared towards more technical users, chich would, among other things, allow you to point at a git / hg / whatever repo to use as the synchronization point.
Does it not ultimately have the same problem? i.e. when you open obsidian, there's no guarantee the files are up to date as Android may have killed the third party sync program. And on iOS, there's no way for the sync program and obsidian to share the same filesystem short of the obsidian devs explicitly integrating
Android does have Content Providers [0], basically apps can provide a "filesystem" which isn't locally stored on your phone and act like Network Shares. Caveat is that you need an internet connection.
Good question, because it is indeed the default behavior.
But you can always tweak settings to run the 3rd party sync app always in the baclground, and override the battery optimization setting for that particular app.
Syncthing works well on Android for photos, music, movies, and downloads. Not so much for notes. You'll end up with conflicts, and there aren't many great ways to merge changes on mobile.
Obsidian Sync is by no means cheap, but I've never used a better syncing service. I'm on my second year and can't think of a single issue I've had across laptops, desktops, an Android phone, and a Chromebook.
I can think of a number of other notes syncing that's better -- probably even Evernote's. As a happily paying Obsidian Sync customer, I'll drop some reality, so new people aren't caught off-guard.
- Obsidian Sync is pretty slow.
- Obsidian Sync doesn't happen in the background, at present. That means, if you just made a bunch of updates in Obsidian, or you haven't opened the Obsidian mobile app in a while, you're in for a wait.
- Obsidian Sync occasionally has sync errors that involve manual interaction.
That said, it's fine and the overall Obsidian experience makes it worth it (well, if you can swing a discounted price).
I use Microsoft Word’s multi-editing feature at work. The sync is essentially real-time (setting aside other opinions in Microsoft Office). You can see every change that your co-editors make as they make it. You can work on one file on two different devices at the same time. That is the kind of sync that I’d like.
More realistically, I used to use a custom sync setup with a WebDAV server I set up and Goodsync software. You can set it to sync in file change, and it was fast, with changes replicating in a few seconds.
As it is, the Obsidian sync takes a few minutes. And if you edit the file on another device before sync goes through, you’ll lose the changes from one device or the other.
> As it is, the Obsidian sync takes a few minutes. And if you edit the file on another device before sync goes through, you’ll lose the changes from one device or the other.
Clearly we have had very different experiences. I have mainly markdown notes, PDFs, and screenshots and it syncs everything continuously as I work. As for "losing" the changes, I'll have to push back on that. You have full version history, so while you might have to look at an old version, you won't lose anything. There's certainly nothing unique to Obsidian with respect to conflict resolution. If version history isn't working, you'll have to talk to the developers because there's a serious bug.
> "As it is, the Obsidian sync takes a few minutes. And if you edit the file on another device before sync goes through, you’ll lose the changes from one device or the other."
This has been my biggest fear using sync. So far I haven't had any issues, but I just get a" feeling" (maybe it's the lag between syncs) that this could definitely happen.
Can you explain in a little more detail how it might actually occur? Maybe so I can prevent it from happening.
Usually, I've had it happen when I try writing stuff on a device that's been offline and I haven't brought it online to pull in the latest changes. We essentially have a merge conflict. Thankfully, they're not a pain to resolve.
OK, got it. Thanks. So, to prevent from happening in the first place, it'd make sense to give the recently sleeping device a moment or two to catch up.
It significantly improved for me a few months ago. The syncing seems to start much more quickly after I open the app. Not perfect but much better than it had been when I had to keep the app open by constantly touching my screen and hoping it would even start the syncing process.
I love Obsidian Sync as well but to be devil's advocate, it doesn't "just work" as a lot of people claim. It's still a bit rough around the edges. For example, it doesn't sync settings or starred files immediately. I've also noticed it dropping some text if I edit the same file on multiple devices simultaneously (or even in quick succession before sync is able to catch up). I'm sure these issues and more would exist with a 3rd party syncing solution but Obsidian sync still needs some work before it's perfect.
When I say simultaneously I mean typing something on a file on my laptop and then putting that away and making more change on my phone a few seconds later (sometimes the gap is even longer than that). Sync is pretty slow especially since it doesn't sync in the background.
It depends on your workflow. I use git to sync my obsidian vault. There's plugins to automate this, but doing it manually isn't that bad either. I use mobile mostly to read notes, and occasionally I'll write down a short line or two which I can sync over and edit and organize on desktop.
I went for the paid syncing because I want it to "just work" while still having the futureproof way of storing the data locally in an accessible way.
So far it has worked absolutely flawless. If I change a file it's changing on my connected device in seconds. Not exactly like working on a shared google doc but close enough that I would even use it as a hack to quickly share links between my mobile and my desktop
So simple, they combine the best of all eras: local first, open, published formats and pluggable/byo multi-device sync/backup – Cloud if you wish, but not required. It gives me hope for the future, I wish more software these days followed this model.
Caveat: not an obsidian user (although I am a big step closer after this)
Just as a data point. This feature of one-note (text boxes where you click) is the single reason I’m looking for something else. I absolutely hate any interface that has me fiddle with layout when I’m trying to focus on semantics.
Not that this should impact Obsidian much, since I assume the canvas thing is optional there, just a data point.
Related to infinite canvas _do_ checkout “The Humane Environment” [1] it has a few interesting takes
As for a more semantic approach to layouting, I think Flying Logic[2] makes a decent job of it
I use OneNote extensively and as I understand each page is like a white board where you can write anything anywhere. If I wanted a linear interface I would be using Word instead.
Markdown was never intended for data with a graph structure, so I think it's the right decision to use a different simple format instead of creating yet another bloated non-standard Markdown variant.
Yes! Compliment the standard, don't obfuscate it even more.
As someone who mostly write org rather than md, but sometime have to write md in various places, it's confusing that they're not all the same.
Agreed here too. This was a poor choice IMO. They call it canvas but it looks like a poor hybrid between mind mapping and UML. Markdown already supports hierarchy. I am guessing this let's you set coordinates for how to lay the canvas out but this is exactly why I'd never use it.
You say you agree but then state the opposite opinion?
> I am guessing this let's you set coordinates for how to lay the canvas out but this is exactly why I'd never use it.
You wouldn't like a text editor that automatically rearranges source code or sections of a document without you having a say in it, and for the same reason I find manual layout for this graph feature absolutely necessary. And beside that it's very likely you'd want some other metadata that just have no place in standard Markdown. Maybe a viable alternative would have been generating graphviz dot code and embedding it in Markdown code blocks, which would make it compatible with other tools as well - that could still be added via plugins.
What does it mean to open-source or MIT-license a "file format"?
The MIT license is a license about copyrighted software, allowing people to use/modify/publish that software. But a file format isn't a piece of software.
Are you open-sourcing the specification document for the file format? (people are still free to write software that reads+writes the file format even if the specification document isn't open-sourced).
Are you open-sourcing your particular library for reading the file format? (I'm confused here, because you stressed that the file format was so simple, so I'd have expected it easy and maybe even desirable for many people to come up with libraries for reading+writing the file foramt?)
Anyone is free to write software that modifies a file - there is no copyright law protecting that. This is one of the reasons why many large corporations are pushing hard towards cloud - they can protect the format AND the platform then monetize it at will. End users lose control.
I will give them points for putting it in a readable file format. But placing it under an MIT license and "open sourcing" it, doesn't do anything - and they know that. It's just fluff to market their new features.
Edit: Re-reading what I posted, In case it's taken the wrong way, I am not disparaging the team at Obsidian in any way:
I think they do good work and make great software.
IANAL
> The file itself is considered instead to be an idea or a system and is therefore not protected by the laws of copyright. So the description of a file format is copyrightable, but the format as it exists in its medium is not.
I wish I could edit my post to simply say open format for now. The MIT license currently refers to the spec and the documentation. Over time it will also include any tooling we open source (e.g. validator, linter, migration tools). The intention here is to work towards a shared format for this type of relational+spatial data, and we're hoping to collaborate with other members of the ecosystem to make something that can have interoperability and longevity.
Trello boards export to JSON, would you consider it open? OneNote notebooks are also an open and well-documented specification, as well as local first and backed by a very reliable company, which makes them just as open as Obsidian by those standards.
The Canvas JSON is not an export format, it is the file that the app actually reads and edits. Being explicitly MIT licensed also gives permission to other people/companies to build their own tools using that format.
OneNote and this canvas format might be equally open and interoperable, but it's a hard claim to justify that onenote notebooks are as open as a folder of mostly standard markdown (the two exceptions being wikilinks and embeds)
I peeked at the onenote format standard [1] and the obsidian canvas standard. The difference is hilarious. The onenote standard is painfully complex, provided as a .pdf, and binary to boot. Compare to an example obsidian canvas - this is obvious, text-based (I could read it with notepad++) and easy to understand just by reading it:
{
"nodes":[
{"id":"6c711bf8c24c4f5b","x":-226,"y":-62,"width":400,"height":400,"type":"file","file":"testin/2022-10-14.md"},
{"id":"4dd7d04cdd0b379c","x":-530,"y":-209,"width":250,"height":60,"type":"text","text":"this is a note"}
],
"edges":[
{"id":"0c589a4d6bbb06aa","fromNode":"4dd7d04cdd0b379c","fromSide":"bottom","toNode":"6c711bf8c24c4f5b","toSide":"left"},
{"id":"eda9f3edb3ec232a","fromNode":"6c711bf8c24c4f5b","fromSide":"top","toNode":"4dd7d04cdd0b379c","toSide":"right"},
{"id":"abf404722ba48c3b","fromNode":"4dd7d04cdd0b379c","fromSide":"top","toNode":"6c711bf8c24c4f5b","toSide":"right"}
]
}
We're using whatboard.app for this at present. A bit different in approach, but a more more manageable and less infinite canvas. That said, this looks really cool and may be worth the desktop-app install.
I don't think you would need either sync or publish at work. I haven't used canvas yet, as it's a new feature, but obsidian is a key app at work for me. Up to this point at least, it's been free :)
Make a private repo, and git commit / push / pull your obsidian notes and canvases just like you would any other shared repo
I was just researching graph representations. I would have used dictionaries for edges and nodes indexed by their IDs.. because that representation is json-merge patchable, which is useful for specifying atomic bulk graph operations.
Yes, I much prefer local and do my own backups (rclone to backblaze) on just about everything. I only drop stuff on iCloud when I need to share it and a couple of ongoing spreadsheets I use to track stuff.
small thing but downloading and installing the obsidian snap package requires the `--dangerous --classic` arguments with snap (since it's not coming from a repository); may want to add that to the instructions
Photoshop is proprietary software with a well documented file format anyone can read and write.
So is this software. "Open source" is not branding, it means something.
It's okay to make and promote and sell proprietary commercial software. That's what you are doing, be proud and clear about it. Pretending your efforts have anything to do with free software is deceptive.
You are confusing two different ideas here. The Canvas format is MIT licensed in the same way that Markdown uses a BSD-type license. That means we are giving explicit permission for anyone to use the format and build apps, scripts, plugins on top of it.
This is a pretty grating response, given how pointed it is. It's not made any better by the first sentence; it seems that you are the one confusing two different (types of) things:
> The Canvas format is MIT licensed in the same way that Markdown uses a BSD-type license.
In no sense are these two things comparable. "Markdown uses a BSD-type license" is a true statement because "Markdown", in the context where it makes sense to say this, is a Perl script—a program, licensed in a way that is not uncommon for open source programs to be licensed. Your canvas format is not a program. It's a 70-line TypeScript interface definition, going by your own link:
To call this "open source" (let alone open source "in the same way that Markdown" is) is a very odd choice. It's less odd for anyone who recognizes that it follows a common pattern, where folks with something to sell often openwash what it is that they're selling based on the (not unfounded) perception that having it be thought of as more open than it really is tends to confer certain positive benefits. It's why Steve Jobs lied about FaceTime being an open standard, for example.
Whether or not you're giving any explicit permission to build apps, scripts, plugins, etc. is largely moot—to be frank, you don't have the power to dictate otherwise. On the other hand, if you're saying that you're aiming to steward and participate in what (you hope) turns out to be a vibrant ecosystem built on a common format, then that's cool. But say what you mean, though. Calling it an open format or an open standard would be fine; "open source", however, this is not.
I appreciate the distinction you're making. I could have been more accurate in my description. Markdown states in its own documentation that the name refers to two things, and "Canvas" to date fits mostly in (1)
> Thus, “Markdown” is two things: (1) a plain text formatting syntax; and (2) a software tool, written in Perl, that converts the plain text formatting to HTML.
What we have done so far is shared an open spec for the .canvas file format, with a type definition that helps developers understand how to create properly formed Canvas files. We also are giving permission to people/companies to use this format with the freedoms that come with the MIT license. In addition we're also putting forward the intention that there should be a free and open format for this type of canvas data, with some similar properties to Markdown. Perhaps in the future there will be more open source tooling fitting into definition (2).
The goal here is simply to help people feel more comfortable that the canvas files they create are their own, and can eventually accrue longevity as more tools get built around the format. I hope this will lead to a rich ecosystem outside of Obsidian. We're committing to keeping it an open format, and hope to collaborate with other people who might want to adopt it.
The same can't be said about the PSD format, so I do think there is a difference in the level of openness that we're aiming for.
Yeah and its developed by Adobe which creates a walled garden around there products making file format interoperability very difficult.
Obsidian on the other hand uses open formats with open standards. The difference is NIGHT and DAY.
And if the goal is taking freedom away from the people who are using your product, or to artificially keep people using your product because you know you are making the world a worst place to live in, making that type of propriety software is not OK, even though there are plenty of misguided organizations and people who do it.
https://github.com/obsidianmd/obsidian-api/blob/master/canva...
Just like all other files in Obsidian, canvas files are your own and local to your device. You're still linking to your own Markdown files which are just as future-proof as ever.
We decided to create the .canvas format because there wasn't any pre-existing canvas-type format we could find that fit our priorities around longevity, readability, interoperability and extensibility.
The .canvas format is designed to be as easy to parse as possible. We've already seen a few plugins take advantage of it, and we hope that more tools will become available that can use the .canvas format.