6 ms·

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/ https://obsidian.m

• remram 3y ago
  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/...?
  • eichin 3y ago
    Yeah, didn't see any discussion in the other thread, do you have any notes on why this isn't SVG?
    • npunt 3y ago
      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.
      • remram 3y ago
        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.
        • rat9988 3y ago
          I'm not sure I agree with you here at all. They can start a format that serves their own purpose, and make it open for interoperability and extensibility sake. Nothing wrong with it.
          • remram 3y ago
            "egregious" was a strong word, apologies. Still the silence is deafening here.
        • npunt 3y ago
          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 it. He just released it, and others chose to adopt it on its merits. I don't meant this to sound harsh, but just to call it as I see it - your comment is basically creating a 'damned if you do, damned if you don't' scenario and an example of why people building things shouldn't worry much about comments in forums. [1]: https://stephango.com/file-over-app https://stephango.com/file-over-app
          • gcr 3y ago
            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/ https://bwiggs.com/notebook/queens-duck/
    • naikrovek 3y ago
      SVG is great and you are the first person I have ever seen who would (and did) imply that SVG might be or would be better than JSON for this kind of thing. SVG really stretches the “human readable” thing to its limit, and I personally would not adopt an SVG-like format for anything that isn’t SVG.
      • dev_0 3y ago
        [dead]
      • eichin 3y ago
        Looking at the samples, this isn't human readable either (long opaque id strings for linking dominate the syntax) and both syntaxes have vast amounts of punctuation and whitespace. And neither of them are particularly human writable. But something svg-based would have lots of existing options for additional processing in consistent ways, that would be ad-hoc for a json-based syntax. (Given that this is coming from obsidian, I kind of expected something actually markdown-like - which would certainly be a challenge, but not an impossible one.) Granted, this notation is a little higher level than SVG, so the model mismatch might be a bigger problem anyway?
        • ornel 3y ago
          I opened a JSON created with the Obsidian canvas thing and renamed the long ids with human readable names and it keeps working without re-renaming. So they or whoever uses this format could maybe come up with a way of using some form of human-readable ids[0] to make it easier to modify the JSON by hand [0] https://pypi.org/project/hrid/ https://pypi.org/project/hrid/
    • littlestymaar 3y ago
      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).
    • rootlocus 3y ago
      Looking at the JSON, I assume this is a higher level format that may output SVG. For instance, the arrows between nodes are defined by reference to node names and node sides. In SVG that would be a hardcoded curve and shape for the arrow which loses the semantic meaning "there's a relation between two nodes", where nodes may also have semantic meaning such as "idea" or "book". A tool may parse the json canvas file and extract information such as "there are three ideas linked to this book". Another tool may output an SVG.
  • Idiot211 3y ago
    Relevant XKCD: https://xkcd.com/927 https://xkcd.com/927
    • kepano 3y ago
      I can't believe it took this long for someone to post this haha
• altairprime 3y ago
  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.
  • hiccuphippo 3y ago
    Click the spec link, it shows the same content in a full page.
  • dolmen 3y ago
    Direct link viewed on GitHub: https://github.com/obsidianmd/jsoncanvas/blob/main/spec/1.0.md https://github.com/obsidianmd/jsoncanvas/blob/main/spec/1.0....
• desmondl 3y ago
  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:// 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?
• tylerdurden91 3y ago
  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 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-usage-state--docs 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.
• dolmen 3y ago
  I wonder why this document has been labelled "1.0" while it is so poorly specified (many ambiguities).