Live data from Hacker News

JSON Canvas – An open file format for infinite canvas data

jsoncanvas.org

41–50 of 168 posts

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

#41
Based on the title I would have expected this to be about describing images on an infinite canvas, where different parts have different zoom levels.

This is instead about whiteboard-style graphs. Which is useful, but I find the branding "An open file format for infinite canvas data" to be confusing. Nothing in it implies whiteboards or graphs to me. The fact that the canvas is infinite doesn't even have an obvious influence on the file format, apart from the absence of a canvas size property.

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

#43
Oh sweet! I was in the middle of building my own version of a node-graph component (ref: https://github.com/catapart/Magnit.NodeGraph), but the `canvas.js` implementation from this JsonCanvas repo is exactly what I was trying to build. I really, really like how elegantly uncomplex it is. Could not have been more exactly what I was looking for. So thanks for this!

As far as the spec, I don't really like the idea of forcing well-known types for the nodes. A generic spec should allow for entirely generic nodes that can represent themselves to consuming functions with a 'type' property as a key, as well as arbitrary data types linked to arbitrary nodes. For instance: one of my use cases is an 'addition' node, which would take two number values and produce a number value. This node would also use an entrance execution pin as well as an exit execution pin.

If the spec were to include a 'pin' data type and capture the type keys and labels for pins, those pins could be stored as a list on the node. Then, the type property could just tell the executing context how to route the node data and the pin properties would bring type safety to the functional inputs passed to the mapped function.

Anyway, I assume all of that is out of scope for initial offerings, but that's my two cents on a generalized node spec. Regardless, thanks again for the sweet, simplistic node graph implementation!

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

#44
post #29

Since a whiteboard is much more a visual thing, I imagine the spec should spend a lot of space defining the visual elements like specifying the control points of the Beizer curves because where a line is drawn and what it overlaps matters a lot on a whiteboard. But to be a total downer, this spec looks like an extremely rudimentary graph file format, of which there are already like a hundred and all define more visua…

From my Analysis, GraphML, although specified in XML, seems to be one of the most widely used exchange formats, especially with the yWorks extensions for yEd.

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

#45
One of the big reasons I use Obsidian is the data portability - while it provides some nice enhancements, if Obsidian went evil tomorrow and I had to use my notes in VS Code tomorrow, then even reduced to just "a folder full of markdown", I'd get 90% of the value without relying on any convoluted importers/exporters.

I've stayed away from their Canvas feature largely because it is.. not that. Not because the Obsidian developers have kept it locked down in some crazy proprietary format, but like a JSON file representing the canvas is pretty useless without something to interpret it and these days Obsidian is still the only implementation.

So I kind of hope this takes off. Having a second source available would make me feel a lot more comfortable trying out the canvas feature.

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

#46
Curious to know which projects & companies were involved in creating this. Ideally an open standard has a bunch of folks involved & informed of the design process so we get a design that lasts!

Braintree payments did this well when they were still a startup. They had to collaborate with their direct competitors to create a standard for the entire POS induustry.

What prevents us from doing this here as well?

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

#47
post #36
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.

What do you concretely gain from embedding the id within the object?

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

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

I agree with a lot of comments that it's minimal, but in my opinion that is a good thing. I'm a big fan of Obsidian, and of the things I like about it is the data source is all markdown files. Markdown is meant to be very lightweight and portable, and overcomplicating it will limit adoption and extensibility (imagine markdown vs pdf).

JSON Canvas seems to follow in that spirit by being very lightweight, so a lot of implementation details (i.e. how are files rendered, what file formats are supported, etc), edit tags, etc) are left open to implementation.

Markdown and JSON are meant to be non-opague file formats that prioritizes portability and human readability over other features. An application format like Sqlite has a lot of benefits over markdown, but it loses the benefits of text based formats like being compatible with git and is less portable.

What I would like to see is a convention for extending the node and edge definitions, similar to frontmatter in markdown files- something that is not required for basic rendering but is a nice-to-have for applications to consume) - that way portability between apps of varying complexity can be maximized while still allowing for more complex features that some apps might implement. Markdown has the benefit of supporting extensions (for example like tables in GFM) - apps that are not compatible can still render the unsupported markup. But there should be an explicit way to extend open JSON formats.

Some feedback off the top of my head and from reading the comments:

1. *Specifying node ordering*. Obsidian seems to just send whatever is last touched to the top, but this makes a common feature in many apps (move up/down/back/front) more difficult to impement

2.*More explicit definition for line shape*. Adding a way to "bend" a line in a specific way. Useful for creating more complex diagrams.

3. *Relations between nodes*. Group nodes contain child nodes, but the spec doesn't specify how the child nodes are defined. I would expect it to have a `children` property to nest nodes. Obsidian seems to implicitly link nodes to groups based on whether their bounds intersect. This makes it difficult to implement some common features:

a. nodes that exist outside of the bounds of its group, for example a node that "floats" just outside of the edge of the group's borders.

b. nodes that are not part of a group even though it exists within the bounds of that group.

There are many different ways for a canvas app to extend the spec to implement those features, but it seems like something that should be defined in the spec to maximize portability

4. *Extensibility.* Either explicitly support or provide a standard for defining more styles for nodes and edges, such as stroke width, stroke style, rotation, etc. It seems like "color" should be a part of this as well, rather than being an explicit property of a node.

5. *Embeds.* Supporting "embeds" as a node type. I even think the "file" node should be redefined as `embed` with a `uri` property to support different schemes (`file://`, `oembed://`, `https://`) and maybe a `mime-type` (`text/markdown`, `image/webp`). The file node's "subpath" property seems to be only relevant for markdown files, so I think that should be an extension rather than an explicitly defined.

6.*YAML* :) (Should just seemlessly convert from json, but yaml is more readable than json)

Being able to design standards that evolve over time and making tough decisions about what what to make explicit and what to leave implicit is a skill I want to improve on as a developer this year. Does anyone have any resource recommendations or best practices to recommend for me to research?

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

#49
post #19

This looks a little pre-1.0, it's quite short on detail. For example: file (required, string) is the path to the file within the system. What kind of path, within what system? It's not clear that the 'file' type couldn't just be another kind of 'link'. If various fields like 'background' were defined to be URLs, that would offload a lot of complexity onto existing web specs.

Yeah, other details are missing too. For example backgroundStyle : > cover fills the entire width and height of the node. Does that work like the CSS background-size: cover; or background-size: 100% 100%; ? > ratio maintains the aspect ratio of the background image. Does that mean CSS cover ? contain ? Something else?

    Colors can be specified in hex format, e.g. "#FFFFFF". Six preset colors exist, mapped to the following numbers:

    1 red
    2 orange
    3 yellow
    4 green
    5 cyan
    6 purple
I'm sure everyone will infer the same color codes here.

Maybe the file format isn't meant to reproduce the exact same look in different software, but merely communicate user intent. Your guess is as good as mine.

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

#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? What filetypes are allowed? The home page seems to have an image — was this done using a file node or a markdown node with an element?

- What HTML tags are allowable in markdown? Is JavaScript allowed?

- Why does the group node allow a background image? If both image and color are specified, which takes precedence? How are children of the group specified?

A couple feature requests for extensibility or interoperability with Excalidraw and TLDRaw and friends: drawings / scribbles, predefined shapes like circle or rectangles, ability to specify fill style, edge width, transparency, ability to embed images, more detailed placement for connector start/end points, etc.

Post reply on HN