Rendered at 22:54:11 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
kepano 1 days ago [-]
I'm not sure why it popped up today, but it's nice to see it on HN again! A brief timeline with some links to past discussions:
- 2022: The .canvas open format was created for Obsidian Canvas [0].
- 2024: Official 1.0 spec of JSON Canvas [1].
- 2024-2025: A number of apps/libraries built up around conversion, storage, and import/export [2].
- 2026: Obsidian Skills [3] includes support for .canvas (along with .md and .base) to make it easy for LLMs to read/write JSON Canvas, and opens interesting visualization/interaction patterns with agents.
Hey thanks for [3] obsidian-skills, I've been using Obsidian for years and Claude for months and it's time for them to meet! Stoked to check it out. :)
bryanrasmussen 1 days ago [-]
It would be useful to have examples of data and the representation this would result in.
Although you can go to https://jsoncanvas.org/ itself and see an example rendering, you cannot see the exact data that created it - I think, although you can sort of guess since the element names are stuff like node.
I sort of doubt this is the best data structure for representing this kind of thing. Maybe I'm wrong though but I would think I would go for something like https://github.com/jsongraph/json-graph-specification which strikes me as closer to graphml which I have some experience with, and maybe give it ability to embed videos etc. (which for all I know someone already has)
This is all an initial feeling though, like hmm, no I think it's wrong, and maybe I am just not seeing why this would be better than another solution.
kepano 1 days ago [-]
You can see the data it created. Just click "Toggle output" in the bottom right corner.
crazygringo 1 days ago [-]
Oh, thanks. Those buttons seem designed to be as inconspicuous as possible.
This just looks like a pretty normal homepage. It was not obvious to me at all that the homepage was an actual dynamically rendered canvas, as opposed to just canvas-"themed".
bryanrasmussen 1 days ago [-]
ah ok, sorry about that. I didn't really look at that part of the UI much, noticed it had some zoom stuff, noticed I couldn't zoom normally and scroll to where I wanted to read, was somewhat miffed.
phatskat 1 days ago [-]
Curious to know what “zoom normally” means for you. For me, it’s ctrl+mouse wheel or maybe two finger pinch/pull on trackpad. I am thoroughly confused as to why GitHub’s mermaid integration doesn’t seem to support any zoom outside of the overlay controls which…ick
bryanrasmussen 17 hours ago [-]
zoom normally for me is cmd+, the and in my statement meant that when I zoomed I could not scroll to where I wanted to read, hence "I couldn't zoom normally AND scroll to where I wanted to read", I didn't try the zoom buttons and see if I could scroll because I just checked if I could zoom normally, could, but could not scroll to read parts that were now outside the view.
But later I did check using the buttons and it still doesn't allow you to scroll to read parts of the screen that have moved outside of the view because one has zoomed in too far.
Browser was Firefox Dev, OS MacOs. Did Not check if it was specific to the browser OS combination but that is because I doubt it, given my experience that most of these kinds of applications always end up screwing with the scrolling to some extent.
Notice that the JSON spec box on the front page could scroll up and down, but the readme part could not, furthermore the json spec box if I was zoomed in too far was also rendered partially outside of the view horizontally, and could not scroll horizontally. This is of course on the whole window, not individual parts, that scrolling did not work as it should. I'm sure I could go into the page code and find why I could not scroll and then fix it so I could scroll, but I would rather that the whole thing allows scrolling on the window without my help.
GICodeWarrior 1 days ago [-]
ctrl+mouse wheel triggers the application zoom in most cases. However, if my mouse is over the scrollable node, it invokes the Google Chrome window zoom (so I end up with two competing zoom transforms). It also zooms relative to the upper left corner, rather than relative to my cursor (seems the app doesn't support panning?). The background dots also move and change size as I zoom (subtle but somewhat distracting).
mort96 1 days ago [-]
I feel like this page does a good job of telling me nothing. It's a representation of a graph? Where each node can be a text string or a file or a URL or a container of other nodes? And somehow these links and files and containers have a color? What is the purpose of this? Why would I want my file to be blue?
kepano 1 days ago [-]
Perhaps the home page is more useful than the spec to explain the purpose of the file format: https://jsoncanvas.org/
It's a reinvention of SVG with all the same problems. JSON is not any better in terms of data efficiency or fast updating. It's like these people have never done graphics programming.
jessmartin 1 days ago [-]
Really cool to see JSON Canvas getting attention. (Hi, kepano!) It was one of the inspirations for OCIF (Open Canvas Interchange Format), which we've been working on since JSON Canvas came out.
JSON Canvas nails the simplicity-it's easy to read and easy to implement. We wanted to build on that spirit while tackling some of the challenges showing up in this thread: nested canvases, extensibility for custom app data, text styling, coordinate systems, and round-tripping between different canvas apps without data loss.
OCIF v0.7.0 just came out. It's designed to be an interchange format — so different canvas tools (Excalidraw, TLDraw, Obsidian, etc.) can export/import each other's canvases.
Some highlights:
- Extensible: apps can attach their own data via extensions, so nothing gets lost even if the features aren't supported
- Nested canvases via parent-child node relationships
- Local coordinate systems (addresses the pixel positioning concerns raised in another comment here)
- Text styling, viewport control, and more via built-in extensions
If JSON Canvas isn't quite meeting your needs, OCIF[1] might be worth a look.
It's interactive, for starters. You can do that with SVG, of course, but the boilerplate required would be larger than the `.canvas` file. You can externalize the boilerplate, but then you're no longer creating portable SVG files, and if we're going to create an SVG-like DSL we may as well try out this JSON-like DSL.
rendaw 20 hours ago [-]
This isn't obvious to me. You can have javascript external to the svg for making it interactive, it doesn't have to be embedded in the svg. And the interactivity for json canvas isn't embedded in the canvas json either.
itishappy 10 hours ago [-]
If we're adding external interactivity, we're treating each as a custom DSL format and need to evaluate them as such:
JSON Canvas:
graph primitive
easier to read, write, and reason about
harder to render
SVG:
path primitive
easier to render
harder to read, write, and reason about
Yes, I'm being pedantic, but that was the point of my comment. SVGs aren't interactive by default, you need to bring your own interactivity.
For static content, SVGs work great, but for interactive content the additional sematic layer of JSON Canvas has a clear benefit. SVGs represent connections using paths, while JSON Canvas uses a graph. This means SVG cannot connect a single node to more than 2 adjacent nodes. If I want to draw arrows from Alice, Bob, and Charlie all to Dave, then I need to create a second Dave or reference to that location somehow. (You can see this in your sword example by moving one of the edge points. The sword delaminates because only two of the four edges at that point can be connected together.) SVG provides limited tooling for this, but it gets rather complicated rather quickly.
StilesCrisis 10 hours ago [-]
Cool, now show me a codepen with an interactive JSON Canvas?
itishappy 9 hours ago [-]
Fair point, SVGs are more portable. They're also more capable (and complicated). JSON Canvas is a more specific tool.
Both of the following examples show the same thing, but the SVG representation doesn't convey the structure:
An "infinite" canvas without some notion of recursion such as viewports feels incomplete.
kepano 1 days ago [-]
A file node can be a .canvas, so a .canvas can have nested canvases.
Obsidian's implementation of JSON Canvas supports this.
oersted 16 hours ago [-]
Check out charkoal.dev it has nested canvases and a few other extra features.
It is a great VSCode extension as-is, but the maintainers have abandoned it and they keep refusing to make it open-source. Someone is bound to make an open-source copy soon.
atentaten 1 days ago [-]
I don't use canvas in Obsidian. Tried it when it was released, but haven't used it since. I like Obsidian and want to get the most out of it. I'm curious as too how folks are using canvas in Obsidian.
gglitch 17 hours ago [-]
Might just be a question of taste or personal predisposition. I’m only in Obsidian for the canvas, and I spend almost all my time in it. It’s extremely helpful for me to be able to put all of my buckets up in front of me at once, resize them, rearrange them, color-code them.
24 hours ago [-]
obsidianbases1 1 days ago [-]
I've used canvas quite a bit since it was release in Obsidian. It's good, not great, but the simplicity of the file type opens up a lot of opportunities to build on top of it.
big_toast 1 days ago [-]
It took me a while to start using canvases. But now I think they should be a much more common UI pattern. They really shine on large (40"+ non-retina 4k) screens. The simplicity at launch made me feel more confident in using them at all. I don't use most of the other obsidian features/plugins.
kepano 1 days ago [-]
What would make it great in your eyes?
bnj 1 days ago [-]
Not OP, but I use canvas all the time (Thank you!) in preference to something like Miro because I really value the open format and being able to keep the file. Something that really holds me back is the inability to use different shapes for the nodes - a use case for me is creating flow charts and process diagrams, so being unable to use the standard shapes for those is a challenge.
Still the best option though!
kepano 1 days ago [-]
Yeah I agree! In the meantime Advanced Canvas plugin might help:
Looks cool. I recently hit some limits with mermaid and this seems a little more flexible.
MoonWalk 1 days ago [-]
Are pixels really the best way to encode position at this point?
Garlef 1 days ago [-]
Agreed.
The upside is that it does not leave the most important aspect open to interpretation.
But it prevents this from being text-only at the point of creation:
You'll most likely need some programmatic environment to create non-trivial diagrams.
But then the question is: Why not just an SVG instead?
tkzed49 1 days ago [-]
It strikes me as odd that boxes are placed precisely using pixels, but the size of text is not specified, as far as I can tell. So you use real pixels to specify boxes, but still can't render a canvas exactly/consistently?
9wzYQbTYsAIc 1 days ago [-]
I’m playing with 3d positions derived from higher dimensions, right now.
- 2022: The .canvas open format was created for Obsidian Canvas [0].
- 2024: Official 1.0 spec of JSON Canvas [1].
- 2024-2025: A number of apps/libraries built up around conversion, storage, and import/export [2].
- 2026: Obsidian Skills [3] includes support for .canvas (along with .md and .base) to make it easy for LLMs to read/write JSON Canvas, and opens interesting visualization/interaction patterns with agents.
[0]: https://news.ycombinator.com/item?id=34066824
[1]: https://news.ycombinator.com/item?id=39670922
[2]: https://jsoncanvas.org/docs/apps/
[3]: https://github.com/kepano/obsidian-skills
Although you can go to https://jsoncanvas.org/ itself and see an example rendering, you cannot see the exact data that created it - I think, although you can sort of guess since the element names are stuff like node.
I sort of doubt this is the best data structure for representing this kind of thing. Maybe I'm wrong though but I would think I would go for something like https://github.com/jsongraph/json-graph-specification which strikes me as closer to graphml which I have some experience with, and maybe give it ability to embed videos etc. (which for all I know someone already has)
This is all an initial feeling though, like hmm, no I think it's wrong, and maybe I am just not seeing why this would be better than another solution.
This just looks like a pretty normal homepage. It was not obvious to me at all that the homepage was an actual dynamically rendered canvas, as opposed to just canvas-"themed".
But later I did check using the buttons and it still doesn't allow you to scroll to read parts of the screen that have moved outside of the view because one has zoomed in too far.
Browser was Firefox Dev, OS MacOs. Did Not check if it was specific to the browser OS combination but that is because I doubt it, given my experience that most of these kinds of applications always end up screwing with the scrolling to some extent.
Notice that the JSON spec box on the front page could scroll up and down, but the readme part could not, furthermore the json spec box if I was zoomed in too far was also rendered partially outside of the view horizontally, and could not scroll horizontally. This is of course on the whole window, not individual parts, that scrolling did not work as it should. I'm sure I could go into the page code and find why I could not scroll and then fix it so I could scroll, but I would rather that the whole thing allows scrolling on the window without my help.
See also the original inspiration for the format: https://obsidian.md/canvas
JSON Canvas nails the simplicity-it's easy to read and easy to implement. We wanted to build on that spirit while tackling some of the challenges showing up in this thread: nested canvases, extensibility for custom app data, text styling, coordinate systems, and round-tripping between different canvas apps without data loss.
OCIF v0.7.0 just came out. It's designed to be an interchange format — so different canvas tools (Excalidraw, TLDraw, Obsidian, etc.) can export/import each other's canvases.
Some highlights:
- Extensible: apps can attach their own data via extensions, so nothing gets lost even if the features aren't supported
- Nested canvases via parent-child node relationships
- Local coordinate systems (addresses the pixel positioning concerns raised in another comment here)
- Text styling, viewport control, and more via built-in extensions
If JSON Canvas isn't quite meeting your needs, OCIF[1] might be worth a look.
https://canvasprotocol.org
JSON Canvas:
SVG:I still don't see your point. Why wouldn't I always choose SVG? What problem or pain point is being solved?
https://codepen.io/ItIsHappy/pen/vEXrXxg
Yes, I'm being pedantic, but that was the point of my comment. SVGs aren't interactive by default, you need to bring your own interactivity.
For static content, SVGs work great, but for interactive content the additional sematic layer of JSON Canvas has a clear benefit. SVGs represent connections using paths, while JSON Canvas uses a graph. This means SVG cannot connect a single node to more than 2 adjacent nodes. If I want to draw arrows from Alice, Bob, and Charlie all to Dave, then I need to create a second Dave or reference to that location somehow. (You can see this in your sword example by moving one of the edge points. The sword delaminates because only two of the four edges at that point can be connected together.) SVG provides limited tooling for this, but it gets rather complicated rather quickly.
Both of the following examples show the same thing, but the SVG representation doesn't convey the structure:
JSON Canvas:
SVG:An "infinite" canvas without some notion of recursion such as viewports feels incomplete.
Obsidian's implementation of JSON Canvas supports this.
It is a great VSCode extension as-is, but the maintainers have abandoned it and they keep refusing to make it open-source. Someone is bound to make an open-source copy soon.
Still the best option though!
https://github.com/Developer-Mike/obsidian-advanced-canvas
The upside is that it does not leave the most important aspect open to interpretation.
But it prevents this from being text-only at the point of creation:
You'll most likely need some programmatic environment to create non-trivial diagrams.
But then the question is: Why not just an SVG instead?