Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSON Canvas – An open file format for infinite canvas data

jsoncanvas.org

Post reply on HN
Print view View original

31–40 of 168 posts

Re: JSON Canvas – An open file format for infinite canvas data

#31

Post by simonw »

It would be neat if the README or spec included links to some real-world examples of files - would be easier to start playing with building simple tools on top of this if there was already an example file to start experimenting with, without me having to learn Obsidian first.

UPDATE: Figured out how to create one:

1. Install and then open Obsidian

2. Click the "Create new canvas" icon - third down of the icons on the left

3. Add some stuff to the canvas - I double clicked to create a few boxes, put some text in them and then dragged lines between them

4. In the ... menu on the top right click "Reveal in Finder"

You can then open the file it reveals in a text editor to see the JSON Canvas format.

Re: JSON Canvas – An open file format for infinite canvas data

#32

Post by simonw »

asa400 wrote: post #30

I've worked a few jobs now where application data was stored in text files of various kinds (homegrown as well as well-defined formats, JSON included) and it pretty quickly becomes a mess when you start talking about modifying it over time, evolving its schema, validating it in the face of end-user edits, ensuring threads don't write to it concurrently, etc. This strikes me as exactly the type of application data tha…

I'm usually the first person to suggest SQLite for just about anything, but in this particular case I do feel like JSON is a better default format.

Interacting with SQLite from different programming languages is easier than most other formats, but you still need a SQLite binding. They're available for every language but that's still a not-completely-trivial dependency.

I expect most tools that people build against JSON Canvas will run in a web browser. Adding SQLite as a dependency means you need SQLite running in WebAssembly - totally possible, and even officially supported these days (the SQLite team run their own WASM builds now) but still a sizable piece of extra complexity over just using JSON.parse(...)

Also: SQLite files aren't very easy to diff, so they're not great for collaboration in version control. JSON is better for that.

I'm 100% with you on the schema changes and versioning challenge. The best way to address this IMO would be for the spec to include a top-level "version": key which indicates the version of the spec that a file was created against.

Handled carefully and introduced right at the start of the project this could ensure an ecosystem grows up around the standard such that older spec versions can always be opened by newer implementations, and any implementation can fail-fast if it is given a file that it doesn't yet know how to handle.

Re: JSON Canvas – An open file format for infinite canvas data

#33

Post by egeozcan »

tiborsaas wrote: post #23

I really like that you commit to keep this stable and open. Do you plan to make the TypeScript definition part of this new site? https://github.com/obsidianmd/obsidian-api/blob/master/canva... For me it's easier to read TS format.

I didn't know about this and made ChatGPT prepare me a typescript definition form the markdown: https://gist.github.com/egeozcan/27db06f6771dcf214f0f92bce8c... :) Perhaps I shouldn't be too lazy to google things.

Re: JSON Canvas – An open file format for infinite canvas data

#34

Post by remram »

kepano wrote: post #15

Whoa! Didn't expect this to bubble up to the top of HN. Some context about why we created JSON Canvas: https://obsidian.md/blog/json-canvas/ We just released it today, so this is still a very nascent project. A little over a year ago we released Obsidian Canvas. The .canvas file format has felt stable enough to give it a name and resources that other apps can freely use. See the original Show HN: https://news.ycombin…

Who was involved in this open spec? Or was it built by Obsidian with a hope that it works for everyone else?

Which existing formats were considered before building your own, e.g. SVG/Excalidraw/draw.io/...?

Re: JSON Canvas – An open file format for infinite canvas data

#35

Post by politelemon »

> The JSON Canvas format was created in hopes of providing longevity, readability, interoperability, and extensibility to data created with infinite canvas apps.

If I'm reading between the lines, this is only supported by Obsidian (as it's by Obsidian)? Considering the complexities and 'malleability' of infinite canvas tools, it would have been prudent to have involved or approached some of the major players in this space, like Excalidraw, Draw.io, Microsoft, Figma. Or at least started at version 0.1 and once it gained a wider consensus, release 1.0.

Re: JSON Canvas – An open file format for infinite canvas data

#36

Post by eropple »

Retr0id wrote: post #21

If ids are unique strings, then why are `nodes` and `edges` arrays, as opposed to id-string-keyed maps?

This is always a tough spot in JSON, I think. You want the `id` in the node or edge object, but you also want uniqueness. I don't think there's a great way to get this any be able to just `JSON.parse()` and go without further fixup.

Re: JSON Canvas – An open file format for infinite canvas data

#37

Post by altairprime »

kepano wrote: post #15

Whoa! Didn't expect this to bubble up to the top of HN. Some context about why we created JSON Canvas: https://obsidian.md/blog/json-canvas/ We just released it today, so this is still a very nascent project. A little over a year ago we released Obsidian Canvas. The .canvas file format has felt stable enough to give it a name and resources that other apps can freely use. See the original Show HN: https://news.ycombin…

For those having difficulty viewing the spec at the linked jsoncanvas.org site, the spec/1.0 pane on the right has the scrollbar hidden; there's more content if you scroll that pane down.

Re: JSON Canvas – An open file format for infinite canvas data

#38

Post by chrisweekly »

asa400 wrote: post #30

I've worked a few jobs now where application data was stored in text files of various kinds (homegrown as well as well-defined formats, JSON included) and it pretty quickly becomes a mess when you start talking about modifying it over time, evolving its schema, validating it in the face of end-user edits, ensuring threads don't write to it concurrently, etc. This strikes me as exactly the type of application data tha…

Crucial context: its provenance is embedded infinite canvas in Obsidian (amazing markdown-based notes app++), which supports JS but has no external datastore per se. SQLite is fantastic, but inappropriate for this use case.

Re: JSON Canvas – An open file format for infinite canvas data

#39

Post by cmgriffing »

iainmerrick wrote: post #16
jakelazaroff wrote: post #3

I really like the idea of a format for interchange between infinite canvas apps, but the preset colors and list of node types makes this spec feel strangely opinionated. You could build something like Kinopio [1] but not much beyond that. It looks really promising though! I'm definitely interested in seeing this grow. [1] https://kinopio.club

Thinking about it, I'm not sure any interchange spec would leave useful room for innovation. This isn't like EPS or PDF or something where the kind of output is well-defined (printable graphics + text) and the innovation is in the editing interface. The innovation in canvas apps is surely in the semantics of the nodes themselves; but if you add some new node type with special behavior, how can you usefully export tha…

I think a baseline spec would be really useful.

I like to think of it like the unist ecosystem for ASTs. Unist provides a baseline spec that compatible tools can use to comb an AST. Then, specific AST tools like hast for HTML or sast for CSS/SCSS can add their own metadata on top.

I'm imagining an ecosystem of "adapters" that would help you translate some of the metadata across providers.

Re: JSON Canvas – An open file format for infinite canvas data

#40

Post by allenu »

regus wrote: post #6

What is the upside of using an infinite canvas? I tried playing around with them in the past but I think my brain's mental model of how to parse data is incompatible with "clutter" (for lack of a better term) of an infinite canvas.

I've always wanted to build an infinite canvas idea to try it out, but whenever I've used implementations of it (such as in the Muse app), it just feels wrong. It feels like a beautiful way to interact with essentially fractal information, but in practice it doesn't quite work to me.

I agree with you that I don't think it maps well to the mental model of the brain. Seeing the youtube video link in the sibling comment, when the user is completely zoomed out and can see everything, I just feel overwhelmed looking at it all. Maybe it's the nature of the boxes having different scales that you can't compare them as easily to each other compared to just a regular canvas where things just place in two dimensions. Each time you zoom into a canvas, the transition causes a lost sense of place and space, akin to walking into a doorway to a room and wondering why you walked there to begin with.

Post reply on HN