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

121–130 of 168 posts

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

#121

Post by dleeftink »

Good to see this moving ahead, but doesn't a well-defined graph format already exist in Argdown? [0] While its renderer uses auto layouting instead of user defined coordinates, the principle of using Markdown files instead of JSON seems more appealing to me considering the Obsidian/git workflow.

Besides Argdown, Markdown itself provides some built-in features that can be utilised to construct graphs. Coordinates for instance, can be stored as HTML comments or link alt texts, e.g. `[node](# ("x:25,y:50"))`. Edge, shape types and other data could similarly be stored in alt text fields as serialised JSON or in separate blocks using link reference definitions. [1]

One step further, Markdown lists could be used to store subtrees while cycles as Obsidian block links. This also allows you to encode ancestral, sibling and descendant relations:

  - [root](# ("x:25,y:50"))  
    - leaf  
      - [link](#^id)  
    - another leaf^id
You'd then be able to interleave prose and graph structures in a single file rather than dealing with two separate parsing structures. Even better, the end result would still be Markdown compliant.

[0]: https://argdown.org/

[1]: https://github.github.com/gfm/#link-reference-definition

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

#122

Post by haswell »

remram wrote: post #115
npunt wrote: post #95

Earlier quoted context omitted.

It makes sense if you see Obsidian as the starting point - it's a document store. While other canvas products may be more graphics-oriented, Obsidian's is about laying out documents and objects and providing simple relationships between them. For this purpose, JSON's probably a lot easier to work with than XML/SVG.

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 problem that had no public input.

If JSON canvas isn’t a good solution for broad adoption/interoperability, it won’t become one. The world is not harmed by its release, and at worst, it’s now far easier for people building software to understand and make tools that can interact with Obsidian. At best, it becomes a solid foundation and option for tools going forward.

Obsidian didn’t have to do anything here. I’m glad they did.

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

#124

Post by gcr »

npunt wrote: post #119
remram wrote: 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.

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], knowing we’d offer feedback and critique. If the goal is to get people to imagine a better implementation, preying on HN’s “I could implement this so much better” sense is one hecking smart way to get the community to pitch in.

1: https://bwiggs.com/notebook/queens-duck/

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

#125

Post by npunt »

gcr wrote: post #124
npunt wrote: 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…

Yeah, whether or not it's intentional, the approach taken is one that will generate a lot of feedback.

I haven't seen anyone mention it in this thread, but my immediate reaction to seeing JSON Canvas was that it looks like a spiritual sibling to Markdown, a famously (and intentionally) informal spec.

There's a real wisdom to this informal spec approach, and it's worked incredibly well for Markdown despite grumblings about its lack of standardization.

I imagine this is the Obsidian team's intention with JSON Canvas. Obsidian has really benefitted from the informality of Markdown, which meant they were free to extend it in ways that made sense to the product (with things like cross-page ^ references, yaml frontmatter, etc), without triggering the Spec Police. The same perhaps applies here to Canvas products.

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

#126

Post by kijin »

heleninboodler wrote: post #9

Suggestion: add some metadata at the top level, including a bounding box that includes all nodes so that you can encapsulate a canvas and include it within another context before having created all the elements within it. It's redundant information and it needs to be kept in sync with the nodes and edges, but it's very useful for applications working with your data. Also, this is not very json-ish, but optimizing you…

+1 for bounding box. It would save a lot of computation when trying to determine the initial scale for the canvas, especially if text is involved. It would also make the format useful for fixed-size canvases, not only infinite ones.

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

#127

Post by samatman »

exceptione wrote: post #98
samatman wrote: post #91

Earlier quoted context omitted.

Exactly so. SQLite also has a rich collection of CHECK constraints which can raise errors if data is not to your liking in some fashion, this includes validating JSON. Not a JSON schema, admittedly, although (just like for Postgres) this is available as an extension. https://github.com/asg017/sqlite-jsonschema Saying that SQLite doesn't have "real types" is simply false. If one doesn't want to learn how to use a tool…

The author of SQLite is quite open about it. The lack of typing has been part of the design from the beginning. Sqlite has hardly any types: INT INTEGER REAL TEXT BLOB ANY Of course one can program all kind of check constraints, like one can program all kinds of value validations in javascript. Unfortunately, that is not the same as typing. Sqlite lacks typing because, as the sqlite author explains in the docs, flexi…

> Of course one can program all kind of check constraints, like one can program all kinds of value validations in javascript.

I don't consider this a valid distinction where databases are concerned.

If you define a datatype in an ordinary SQL database, and try to pass it invalid data, it will fail at runtime. How else could it work? There's no compile-time interaction between the value and the database.

If you define a field as BOOLEAN in Postgres, then the value must be 0 or 1, or the database will refuse to write it and return an error. In SQLite this is spelled INTEGER NOT NULL CHECK (col_name = 0 or col_name = 1). More verbose? Yes. Identical semantics? Also yes.

It would certainly be nice if SQLite had a datetime validator that could be used as a check constraint! Hold, up, I got you fam: CHECK(date IS strftime('%Y-%m-%d', date)). If you need a different format, those are,, available.

I guess it has a date type after all! Learn something new every day.

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

#128

Post by WuxiFingerHold »

airstrike wrote: post #42

This is neat, I'll definitely try it out. I do have a related question: what are people using to implement high performance canvases on React these days?

The canvas in Obsidian is as the whole app very well made. I wondered what they are using as well. My guess is https://www.xyflow.com/, which is for drawing nodes. More general purpose would be http://fabricjs.com/. Or very low level https://pixijs.com/.

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

#129

Post by eviks »

desmondl wrote: post #65
asa400 wrote: post #52

Earlier quoted context omitted.

Valid points and I generally agree! I think you're probably right that the SQLite dependency is possibly too much for some applications to pull in, though I will ask why we're so often willing to pull in more or less anything else regardless of weight (DOM manipulation, state management, animation, etc.) but a robust data layer is often a bridge too far. I wish I knew why this is, as it seems to be one of the larger…

I think you're talking about the trade offs between supporting features like "DOM manipulation, state management, animation, etc." and "shipping updates" out of the box, versus only storing the data as simple files and leaving everything else to the implementation. Sqlite as an application file format is great [1], but for a knowledge base / note taking app the benefits are not worth the tradeoffs in my opinion. Sqli…

Except the markdown files are tied to a vendor outside of trivial formatting since it's a simplistic underpecified format without extensions, so all these obsidians specify their own extensions to add complexity, which your vscode does not support (and neither would git diff help to see data change in a sea of formatting changes)

And this spec is for complicated layouts, not trivial notes you're comparing it to, so your intuition from simple notes doesn't translate to this use case

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

#130

Post by asa400 »

samatman wrote: post #127
exceptione wrote: post #98

Earlier quoted context omitted.

The author of SQLite is quite open about it. The lack of typing has been part of the design from the beginning. Sqlite has hardly any types: INT INTEGER REAL TEXT BLOB ANY Of course one can program all kind of check constraints, like one can program all kinds of value validations in javascript. Unfortunately, that is not the same as typing. Sqlite lacks typing because, as the sqlite author explains in the docs, flexi…

> Of course one can program all kind of check constraints, like one can program all kinds of value validations in javascript. I don't consider this a valid distinction where databases are concerned. If you define a datatype in an ordinary SQL database, and try to pass it invalid data, it will fail at runtime. How else could it work? There's no compile-time interaction between the value and the database. If you define…

Heh, I haven't seen that particular datetime constraint before, thanks for that!
Post reply on HN