Live data from Hacker News

JSON Canvas – An open file format for infinite canvas data

jsoncanvas.org

131–140 of 168 posts

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

#131

Earlier quoted context omitted.

The big gap I would love to be solved is a, preferably selfhosted, browser based view into my notes. That way I could access my notes from computers you can't or won't install obsidian on. If it was open source that would be more likely to happen

Do you mean how your notes are connected, and organized? Otherwise, they are plain-text Markdown files. Any app that renders Markdown should be able to do it. In-fact, I don’t really like Obsidian on Mobile, so I use iA-Writer to edit/view the Markdown files that I managed with Obsidian on the Desktop.

> Any app that renders Markdown should be able to do it.

Sure but I can't interact with them the same way as I do in Obsidian. It's an electron app so it's already heavy on the web based tech.

Currently I export my notes as a webpage and edit using my Nextcloud instance. It works, but it's not very nice.

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

#132
post #108
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…

The SQLite docs have a great page on the use case `asa400` describes. SQLite as an Application File Format, https://sqlite.org/appfileformat.html

What's the best example of this format used for complex docs, has anyone implemented their OpenDocument replacement idea?

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

#133
post #67
post #18

As a maintainer of an open source JavaScript infinite canvas application [1], I was very interested, and now I am a little disappointed. The set of supported objects on the canvas is quite minimal. [1] https://github.com/lovasoa/whitebophir

It's an early revision. Now sounds like the perfect time for you to share your experience and suggestions to improve it.

0.1 is early revision, 1.0 is long past that prefect improvement time

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

#134
post #50

This is a great idea. For now though, the spec is under-specified and ambiguously terse. A few points that could be clarified: - How do coordinates work? Does +Y point up (OpenGL) or down (web)? Is the origin meaningful? What are the units - how does this interact with font sizes? High-DPI displays? - What’s the difference between a file node and a URL node linking to file://./? Are files supposed to be transcluded?…

> Is the origin meaningful?

I assume yes, as it makes placement of things much easier if they're all relative to a known origin. The limits of the canvas would be "realistically infinite" in all directions though I assume...

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

#135
post #115

Earlier quoted context omitted.

Obsidian's own file format might have merit, but posting it as an "open file format", "created to provide (...) interoperability, and extensibility to data created with infinite canvas apps"... and then publishing 1.0 without consulting with anybody else... is rather egregious, I think. I agree with you that posting Obsidian's spec to start the conversation would have been welcome, but this is not what they did.

This is an odd bit of gatekeeping and I really don’t understand your position here. Calling this egregious seems odder still. It suggests that companies that choose to publish how they do things have some obligation to do so under a specific framework or shouldn’t do so unless they’re willing to get public buyin. Many of the best projects that become defacto standards start as a solution to a very specific and real p…

And indeed, there are many projects that spend so long trying to gather and process feedback that it becomes a talking shop with no useful output. Better to share something early and then iterate.

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

#136
post #93

Earlier quoted context omitted.

YAML is kind of like C++: > You like C++ because you're only using 20% of it. And that's fine, everyone only uses 20% of C++, the problem is that everyone uses a different 20% :) https://eli.thegreenplace.net/2009/10/17/the-c-bashing-seaso... The YAML footguns are too numerous to reproduce here, so here are some sources: https://stackoverflow.com/questions/3790454/how-do-i-break-a... https://www.arp242.net/yaml-confi…

Point taken, but you can mitigate a lot of this with yamllint.

That's pretty sad that you need to lint your config lang.

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

#137
post #134
post #50

This is a great idea. For now though, the spec is under-specified and ambiguously terse. A few points that could be clarified: - How do coordinates work? Does +Y point up (OpenGL) or down (web)? Is the origin meaningful? What are the units - how does this interact with font sizes? High-DPI displays? - What’s the difference between a file node and a URL node linking to file://./? Are files supposed to be transcluded?…

> Is the origin meaningful? I assume yes, as it makes placement of things much easier if they're all relative to a known origin. The limits of the canvas would be " realistically infinite " in all directions though I assume...

I don't know if "realistically infinite" does or doesn't work here. A lot of video games with huge worlds start to break down with big coordinates due to loss of precision in the floats I presume.

If using integers, I'd cap it at 2^53 to align with js's max safe integer which I think is just a double.

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

#138
post #83
post #34

Earlier quoted context omitted.

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/...?

Yeah, didn't see any discussion in the other thread, do you have any notes on why this isn't SVG?

SVG is a very poor format by all measures so if you can start from scratch for your use case you should definitely avoid it. I'm still glad SVG exists because it's available on the web for free, but this file format is really a mess (very hard to parse, the feature set is so broad it's never entirely implemented and the implantations diverge making it surprisingly hard to support multiple browsers).

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

#139
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…

Great work & thanks for doing this.

I built a library at AWS for a general canvas editor called Diagram Maker. It recently got archived so I stood up a fork here: https://github.com/sameergoyal/diagrammer and the data format we use is strikingly similar. Check it out here: https://sameergoyal.github.io/diagrammer/?path=/docs/docs-us.... The key differences are panels, workspace & editor.

I dont actively work on the project outside of bugs, but maybe there are ways to collaborate here, like moving my project to use & extend the JSON canvas spec.

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

#140
post #124
post #119

Earlier quoted context omitted.

Obsidian's philosophy is file over app [1] and releasing a spec for their Canvas feature is fulfilling that promise. It's a strictly positive 'today is better than yesterday' thing for them to have done so. You shouldn't need to ask permission or consult anyone to do this. That's a silly bar, 'egregious' even. When markdown was created, Gruber wasn't asking all his friends making text editors whether they'd support i…

I’m glad Obsidian is publishing this, even though the spec clearly isn’t ready yet. If I had the final say for how this format were to be publicized, I would probably just include the JSON schema “as-is” in the Obsidian developer docs. Then, it’s just as usable by third parties without making promises about interoperability. But Obsidian is thinking ahead here. They’ve intentionally given us a duck to poke at[1], kno…

> Then, it’s just as usable by third parties without making promises about interoperability.

I'd say this is the point.

If it's "published as part of Obsidian" it implies Obsidian can break it at any time and the interop anyone else has built will need updating. But "published as a standalone spec" means Obsidian is saying "we won't change this without warning" (at the very least).

Post reply on HN