TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

JSON Canvas – An open file format for infinite canvas data

841 点作者 nickmain大约 1 年前

44 条评论

kepano大约 1 年前
Whoa! Didn&#x27;t expect this to bubble up to the top of HN. Some context about why we created JSON Canvas:<p><a href="https:&#x2F;&#x2F;obsidian.md&#x2F;blog&#x2F;json-canvas&#x2F;" rel="nofollow">https:&#x2F;&#x2F;obsidian.md&#x2F;blog&#x2F;json-canvas&#x2F;</a><p>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:<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=34066824">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=34066824</a><p>The spec is conservative, and definitely does not support many features canvas apps will want to implement (yet).<p>The purpose of giving JSON Canvas a name and site is to encourage an interoperable ecosystem to grow around this format. We&#x27;re definitely looking for feedback of all kinds!<p>It&#x27;s great to see all the suggestions already shared in this thread because it starts to provide a roadmap for how this could become a more useful format for other apps.
评论 #39672161 未加载
评论 #39672204 未加载
评论 #39677027 未加载
评论 #39672401 未加载
评论 #39693555 未加载
gcr大约 1 年前
This is a great idea. For now though, the spec is under-specified and ambiguously terse. A few points that could be clarified:<p>- 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?<p>- What’s the difference between a file node and a URL node linking to file:&#x2F;&#x2F;.&#x2F;? 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 &lt;img &#x2F;&gt; element?<p>- What HTML tags are allowable in markdown? Is JavaScript allowed?<p>- 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?<p>A couple feature requests for extensibility or interoperability with Excalidraw and TLDRaw and friends: drawings &#x2F; 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&#x2F;end points, etc.
评论 #39674678 未加载
评论 #39676380 未加载
评论 #39702054 未加载
asa400大约 1 年前
I&#x27;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&#x27;t write to it concurrently, etc.<p>This strikes me as <i>exactly</i> the type of application data that would benefit from being represented in SQLite. Of course, JSON is a `JSON.parse` away, but now you&#x27;re building your own...everything else. Storage&#x2F;retrieval, validation, querying&#x2F;filtering&#x2F;indexing, graph traversal, etc. It&#x27;s all yours.<p>There&#x27;s so many benefits to building this kind of thing in SQLite. You get data validation, atomic transactions in memory and on disk, a high-level query interface, lazy loading (i.e., only load nodes at most 2 edges away), triggers (when I delete this node, automatically delete edges that point to it), and a stable on-disk format, to say nothing of the fact that SQLite itself is just about the most stable software there is.<p>By the way, no disrespect to JSON Canvas, it looks like good work, just trying to offer the perspective of someone who has done stuff like this in the past.
评论 #39672071 未加载
评论 #39672909 未加载
评论 #39673123 未加载
评论 #39672224 未加载
评论 #39672808 未加载
评论 #39674596 未加载
评论 #39693719 未加载
apitman大约 1 年前
Obsidian is one of the few closed-source applications I would consider relying on, due to their commitment to building around simple, open file formats.<p>Sure, they could screw me over and start charging absurd amounts of money for their app, but high quality open source alternatives would pop up immediately.<p>Meanwhile, as long as they <i>don&#x27;t</i> screw me over, it&#x27;s unlikely an open source alternative is going to be able to catch up to a profitable business that keeps their users happy.<p>It&#x27;s an interesting approach, focused on incentive alignment, which is the best way to ensure quality long term.
评论 #39673143 未加载
评论 #39674745 未加载
评论 #39673037 未加载
iainmerrick大约 1 年前
This looks a little pre-1.0, it&#x27;s quite short on detail. For example:<p><i>file (required, string) is the path to the file within the system.</i><p>What kind of path, within what system? It&#x27;s not clear that the &#x27;file&#x27; type couldn&#x27;t just be another kind of &#x27;link&#x27;. If various fields like &#x27;background&#x27; were defined to be URLs, that would offload a lot of complexity onto existing web specs.
评论 #39671728 未加载
jakelazaroff大约 1 年前
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.<p>It looks really promising though! I&#x27;m definitely interested in seeing this grow.<p>[1] <a href="https:&#x2F;&#x2F;kinopio.club" rel="nofollow">https:&#x2F;&#x2F;kinopio.club</a>
评论 #39671604 未加载
评论 #39704233 未加载
treflop大约 1 年前
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.<p>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 visual aspects than this spec.
评论 #39672362 未加载
lovasoa大约 1 年前
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.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;lovasoa&#x2F;whitebophir">https:&#x2F;&#x2F;github.com&#x2F;lovasoa&#x2F;whitebophir</a>
评论 #39672925 未加载
heleninboodler大约 1 年前
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&#x27;s redundant information and it needs to be kept in sync with the nodes and edges, but it&#x27;s very useful for applications working with your data.<p>Also, this is not very json-ish, but optimizing your serializer so your metadata is always written first is pretty handy for embedding, since it allows you to use a pull parser and do useful things before the entire doc is parsed. (e.g. picture a huge doc being embedded and starting out as just a box and having its elements filled in async. You can&#x27;t do that well if you don&#x27;t know the bounding box ahead of time)
评论 #39675854 未加载
ramses0大约 1 年前
The spec basically fits on a page: <a href="https:&#x2F;&#x2F;jsoncanvas.org&#x2F;spec&#x2F;1.0&#x2F;" rel="nofollow">https:&#x2F;&#x2F;jsoncanvas.org&#x2F;spec&#x2F;1.0&#x2F;</a><p>Summary: &quot;node: { type: ..., x&#x2F;y&#x2F;color }; edge: { from&#x2F;to: ..., color&#x2F;label&#x2F;... }&quot;<p>Refreshingly simple, especially paired with their &quot;gif of usage&quot;: <a href="https:&#x2F;&#x2F;obsidian.md&#x2F;canvas" rel="nofollow">https:&#x2F;&#x2F;obsidian.md&#x2F;canvas</a>
Caddickbrown大约 1 年前
Just realised this is by the Obsidian guys! Good on them!
simonw大约 1 年前
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.<p>UPDATE: Figured out how to create one:<p>1. Install and then open Obsidian<p>2. Click the &quot;Create new canvas&quot; icon - third down of the icons on the left<p>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<p>4. In the ... menu on the top right click &quot;Reveal in Finder&quot;<p>You can then open the file it reveals in a text editor to see the JSON Canvas format.
评论 #39672443 未加载
评论 #39701969 未加载
politelemon大约 1 年前
&gt; The JSON Canvas format was created in hopes of providing longevity, readability, interoperability, and extensibility to data created with infinite canvas apps.<p>If I&#x27;m reading between the lines, this is only supported by Obsidian (as it&#x27;s by Obsidian)? Considering the complexities and &#x27;malleability&#x27; 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.
dleeftink大约 1 年前
Good to see this moving ahead, but doesn&#x27;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&#x2F;git workflow.<p>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](# (&quot;x:25,y:50&quot;))`. 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]<p>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:<p><pre><code> - [root](# (&quot;x:25,y:50&quot;)) - leaf - [link](#^id) - another leaf^id </code></pre> You&#x27;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.<p>[0]: <a href="https:&#x2F;&#x2F;argdown.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;argdown.org&#x2F;</a><p>[1]: <a href="https:&#x2F;&#x2F;github.github.com&#x2F;gfm&#x2F;#link-reference-definition" rel="nofollow">https:&#x2F;&#x2F;github.github.com&#x2F;gfm&#x2F;#link-reference-definition</a>
catapart大约 1 年前
Oh sweet! I was in the middle of building my own version of a node-graph component (ref: <a href="https:&#x2F;&#x2F;github.com&#x2F;catapart&#x2F;Magnit.NodeGraph">https:&#x2F;&#x2F;github.com&#x2F;catapart&#x2F;Magnit.NodeGraph</a>), 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!<p>As far as the spec, I don&#x27;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 &#x27;type&#x27; property as a key, as well as arbitrary data types linked to arbitrary nodes. For instance: one of my use cases is an &#x27;addition&#x27; 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.<p>If the spec were to include a &#x27;pin&#x27; 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.<p>Anyway, I assume all of that is out of scope for initial offerings, but that&#x27;s my two cents on a generalized node spec. Regardless, thanks again for the sweet, simplistic node graph implementation!
wongarsu大约 1 年前
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.<p>This is instead about whiteboard-style graphs. Which is useful, but I find the branding &quot;An open file format for infinite canvas data&quot; to be confusing. Nothing in it implies whiteboards or graphs to me. The fact that the canvas is infinite doesn&#x27;t even have an obvious influence on the file format, apart from the absence of a canvas size property.
mcqueenjordan大约 1 年前
Exploring the concept of files &gt; app deeper, it would be interesting if we were able to foster a culture of website apps writing to local storage with files (in a similar manner to Obsidian), and if we had a common format for doing so, with an open-source daemon that sync&#x27;d writes to and from that directory to e.g. some other folder. That would unlock ownership of data even in web apps. The daemon could be app-agnostic and just dutifully sync all the things.
GuB-42大约 1 年前
Why make so many fields required?<p>Node: only id, x, y would be necessary. This would allow for point nodes. We could even imagine letting go of x and y to signify that the position of the node is not fixed and could be recomputed in real time by the program.<p>Even ids could be optional, why require them if they are not referenced?<p>An added bonus of having point nodes is that you get freehand drawings for free: every stroke is a series of connected dots. Maybe it is an anti-feature though, depending on your vision.
mock-possum大约 1 年前
Love obsidian and it’s cute that the site itself is presented as a ‘canvas’ interface element, but…<p>not a great experience on mobile (iOS&#x2F;safari) - pinch to zoom and drag to scroll are both a bit busted, the zoom ui controls can disappear altogether, and there’s no ui indication that the box on the right, that contains the details of the spec, is actually a scrollable container (ie no scroll bar visible)
评论 #39671439 未加载
theogravity大约 1 年前
It would be nice to see actual examples. We use an infinite canvas (<a href="https:&#x2F;&#x2F;switchboard.app" rel="nofollow">https:&#x2F;&#x2F;switchboard.app</a>), but it&#x27;s hard for me to map the objects we have on our virtual-desktop-like-canvas with the file format described here.<p>The items on our infinite canvas are more akin to a desktop app, where most objects are application windows.
评论 #39671471 未加载
adamfeldman大约 1 年前
This was released (and originally implemented) by Obsidian: <a href="https:&#x2F;&#x2F;obsidian.md&#x2F;blog&#x2F;json-canvas" rel="nofollow">https:&#x2F;&#x2F;obsidian.md&#x2F;blog&#x2F;json-canvas</a> (see also <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=39670684">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=39670684</a>)
评论 #39671624 未加载
tiborsaas大约 1 年前
I really like that you commit to keep this stable and open.<p>Do you plan to make the TypeScript definition part of this new site?<p><a href="https:&#x2F;&#x2F;github.com&#x2F;obsidianmd&#x2F;obsidian-api&#x2F;blob&#x2F;master&#x2F;canvas.d.ts">https:&#x2F;&#x2F;github.com&#x2F;obsidianmd&#x2F;obsidian-api&#x2F;blob&#x2F;master&#x2F;canva...</a><p>For me it&#x27;s easier to read TS format.
评论 #39672099 未加载
Macha大约 1 年前
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 &quot;a folder full of markdown&quot;, I&#x27;d get 90% of the value without relying on any convoluted importers&#x2F;exporters.<p>I&#x27;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.<p>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.
评论 #39673197 未加载
Retr0id大约 1 年前
If ids are unique strings, then why are `nodes` and `edges` arrays, as opposed to id-string-keyed maps?
评论 #39671776 未加载
评论 #39672193 未加载
评论 #39672686 未加载
regus大约 1 年前
What is the upside of using an infinite canvas? I tried playing around with them in the past but I think my brain&#x27;s mental model of how to parse data is incompatible with &quot;clutter&quot; (for lack of a better term) of an infinite canvas.
评论 #39671731 未加载
评论 #39672304 未加载
darkteflon大约 1 年前
How interesting. I was just this weekend looking to implement a DAG&#x2F;multitree-based tasks app as a side project, and my first thought was to do it as an obsidian plugin with D3 for rendering. I ended up canning that idea because it felt like a bridge too far to cram nodes and links into a human-readable format like markdown. I went with SQLite and a TUI instead. Seeing this spec emerge makes me think that Obsidian might be a good place for that kind of plugin after all. It’s becoming something of an emacs, Obsidian is!
ianbicking大约 1 年前
There&#x27;s some questions about interoperability, which I imagine to be hard since any canvas app involves viewing and editing and probably has unique entities and approaches which other apps wouldn&#x27;t be able to handle.<p>BUT, I imagine this being more useful for creating non-frontend tools. For instance a server that returns subsets of nodes for a particular viewport. Or something that may index nodes, or produce search results. Or tools that simply generates canvases from other data as a one-way operation.
ivanjermakov大约 1 年前
Actual spec: <a href="https:&#x2F;&#x2F;jsoncanvas.org&#x2F;spec&#x2F;1.0&#x2F;" rel="nofollow">https:&#x2F;&#x2F;jsoncanvas.org&#x2F;spec&#x2F;1.0&#x2F;</a>
skadamat大约 1 年前
Curious to know which projects &amp; companies were involved in creating this. Ideally an open standard has a bunch of folks involved &amp; informed of the design process so we get a design that lasts!<p>Braintree payments did this well when they were still a startup. They had to collaborate <i>with</i> their direct competitors to create a standard for the entire POS induustry.<p>What prevents us from doing this here as well?
henrun12大约 1 年前
I&#x27;d love to see this get adoption, I use a few different whiteboarding apps for the different features they offer, but would be great to have more portability between them. e.g. I find tldraw great for creating diagrams, but when I have to share them with people I end up screenshotting and pasting into figma
iJohnDoe大约 1 年前
I’m confused by the comments. This seems really cool.<p>Are there other solutions that take JSON and do the same thing just as easily?
curtisblaine大约 1 年前
What I would expect from an infinite canvas app would be a streamable data structure, that can be rendere on demand on a &quot;virtual&quot; canvas - let&#x27;s say you have a window from 0,0 to 100,100 - you can query the data structure to give you only the nodes in the viewport + the nodes connected to them.
dekhn大约 1 年前
Is this infinite canvas similar to QGraphicsView?<p>I&#x27;ve been looking for a good equivalent to QGraphicsView and HTML Canvas is not it (HTML Canvas is a raster image, QGraphicsView is a size-independent fixed-sized, scrollable canvas with indexed objects).
评论 #39673579 未加载
raggi大约 1 年前
I would love to see this and excalidraw converge feature &amp; spec wise.
评论 #39672983 未加载
airstrike大约 1 年前
This is neat, I&#x27;ll definitely try it out. I do have a related question: what are people using to implement high performance canvases on React these days?
评论 #39676110 未加载
darkest_ruby大约 1 年前
Is that what nodered uses for its diagrams?
RyanHamilton大约 1 年前
I would like to take this opportunity to implore everyone to not invent a new format. Avoid it at all costs. First try to follow an existing standard or say that you will support a subset. When you invent a new standard, you start small and say oh users just need to know this and look it&#x27;s so simple. Then you find all the edge cases, add all the features and voila you have created a half baked implementation of an existing standard. Only if you can explicitly say many reasons why you haven&#x27;t used standard X or Y create something new.<p>To take this specific example, some of it feels very similar to HTML. label, links, sections, groups, anchors, background fill options...I would have been tempted to define as a subset of HTML that is supported. Then if I wanted JSON, say how JSON maps to HTML. voila suddenly everything is standardly named and creatable. This means backgroundStyle is replaced by background-size = cover or contain. It means that those six preset colors are replaced by all HTML standard colors. Voila no one needs to learn different concepts or definitions. Try that existing standard, try 2 more and only if they don&#x27;t work invent a new one. Please. I say this as someone that inherited standards invented by teams that I then had to try and train hundreds of users on. Funnily enough the previous people left when the coding was done, without teaching the users. THey probably left to implement version 2 elsewhere. :)
account-5大约 1 年前
In a similar vein I prefer Treesheets to this sort of thing. I like grids better.
mywacaday大约 1 年前
FYI only the spec canvas is black on chrome mobile with dark mode enabled.
dorian-graph大约 1 年前
I was hoping this would include infinite _nesting_!
CubsFan1060大约 1 年前
Is there any control over the routing of the edges?
hacker_88大约 1 年前
Never Let Software kill your data. Excellent
sigmonsays大约 1 年前
this seems like vendor lock in and hardly solves anything complicated
cyanydeez大约 1 年前
need, but on mobile I want to double tap to zoom and fit content