12 comments

[ 2.4 ms ] story [ 51.9 ms ] thread
Apologies I hate it. A scene graph should be a data structure. Web data structures should ideally be DOM.

This is a bunch of code & APIs. This isn't web-ish.

I'm glad there's community effort here on spatial, but I don't have a lot of hope they end results will have many of the advantages that have made the web medium the most powerful malleable pro-user software medium on the planet.

> A scene graph should be a data structure

The data structure here is glTF.

> Web data structures should ideally be DOM.

WebSG is very close to DOM, as is obvious if you look at https://thirdroom.io/docs/websg-js/classes/WebSG.Node.html - complete with addChild, getChild etc. However, it's tuned for 3D scene graphs rather than ending up shoehorning graphics into the DOM API like SVG does.

Just a Canvas is also not DOM, but instead focuses on the specific problem of providing an API for immediate-mode graphics.

Thinking more on this: the DOM API is built for XML and SGML. It’s not remotely obvious that XML is a good format for representing 3D scene graphs: X3D has hardly taken over the world, Collada has joined glTF now, nobody uses FBX etc.

Meanwhile, glTF is gaining major traction and allows for 3D documents to be designed in a number of industry standard programs which 3D artists use to ship billions of dollars of games.

Hence providing a dedicated API for glTF rather than trying to pretend that it’s XML.

(Come to think of it, this is a pretty similar situation to JSON v XML in Matrix itself…)

DOM was a mistake to say. Being html & hypermedia was my main point. Being a part of the page, not the JS that livens the page.
It is HTML. It's a canvas element, rendering WebGL (already a Web API), optionally using WebXR if on a headset (already a Web API). WebSG is just providing a standardised higher level API on top of WebGL, as fun as manually programming WebGL is.

If you want that contents to be modelled in the DOM instead, go look at A-Frame, I guess - but, trying to coerce glTF into XML so it's part of the HTML of the page would be as crazy as telling JavaScript that it's only allowed to store its state in the DOM and isn't allowed a heap any more.

Aframe is very much the angle I'm looking for here.

What you are talking about is not hypermedia. It has no user malleability. You can't as a user go change a vertex. You can easily do that in aframe.

Canvas may be an html element but it's an opaque portal no better than Flash was. It's a low level hack to jump outside of the hypermedia page. The actual web is higher level elements.

The inspector which ships in TR TP2 literally gives you the user malleability that you’re looking for - while also supporting properly sandboxed WASM apps. Sure, the glTF isn’t literally part of the HTML DOM - but why should 3D content be part of the HTML DOM? Bitmaps aren’t; Fonts aren’t; JavaScript and WASM state isn’t; video and audio aren’t either. The DOM is for manipulating XML documents.

Meanwhile, WebSG gives you malleability alongside a perfectly matched API to manipulating glTF. Okay, to browse the resulting object graph you use TR’s inspector rather than your browser’s devtools, but a dedicated 3D editor UI is obviously going to be better than flailing around in the HTML DOM.

This is such limiting minded thinking. The whole 2d space is visible in the DOM. Fuck yes of course 3d space should also be a user visible integrated piece of the hypermedia document. Ideally experiences should blend the two! There was the whole Mozilla Flight of the Navigator demo in 2009 where video elements were nicely integrated into a 3d scene (sandboxing concerns killed this then but with element-capture spec it should be possible again!). This stuff needs to be integrative, not separate universes, dumb opaque canvases driven by code.

Fonts & bitmaps seem like bad counter examples to me, disingenuous. Whether we use every outside resource as an excuse to say this doesn't need to be hypermedium, or whether we look opportunistically to build hypermedium as we can seems like a clash of dispositions.

I can try to check out this TR TP2 but I really think you are being extremely resistant to what makes the web excellent & throwing chaff. There's a lot of shallow prejudice that html should be kept small, is only for X or Y but not Z, and we keep getting better and better & making more & more excellent componentry that defies this eternal limited-minded doomsaying.

There's still something I can't wrap my head around. Over 6 months ago, Element laid off the entire Matrix trust & safety team, citing budget and funding concerns (and kinda throwing them under the bus at the same time, but that's a separate matter). And this seems to imply that a similarly sized team has been kept on payroll at the same time to work on a Matrix-powered metaverse experiment (Third Room).

Given the blog post mentions that Matrix and Element are still suffering from lack of funding, it would mean that Element and the Matrix.org Foundation are considering that niche experiment as way more mission-critical for Matrix than moderation/trust & safety. Which feels absolutely insane to me. And it definitely does not make me confident in the fact that, should I decide to provide financial support to the foundation and/or Element, they would spend this money wisely in a way that improves Matrix as a whole rather than trying to make a niche point (that metaverse/AR use cases are possible on Matrix).

I love Matrix, and have been for years, but this does not make me feel confident in the future of the project.

The reason Third Room has persisted is because there are enterprise folks willing to pay for it and support the team as a standalone thing - you can see the enterprisey showreel video at the end of the OP. It’s also very useful when fundraising for Element and Matrix to be able to point at an exotic shiny project to show Matrix’s long-term potential - a bit like Beeper have their Beepberry device. You can almost think of it as a marketing tool.

Separately, “the entire Matrix trust & safety team” was not laid off - today there are somewhere between 3 to 5 people working one way or another on T&S (between tooling and operational) on behalf of Matrix at Element. I don’t blame folks who are laid off for feeling aggrieved though, but we categorically did not throw anyone under the bus (or, if we did, it wasn’t intentional).

> The reason Third Room has persisted is because there are enterprise folks willing to pay for it and support the team as a standalone thing - you can see the enterprisey showreel video at the end of the OP. It’s also very useful when fundraising for Element and Matrix to be able to point at an exotic shiny project to show Matrix’s long-term potential - a bit like Beeper have their Beepberry device. You can almost think of it as a marketing tool.

That makes sense, thanks for the details. Though I would still argue that the way Third Room is communicated on sends mixed signals to anyone somewhat familiar with the space.

For example, having entire foundation-authored blog posts dedicated to updates to Third Room (which I did not think was a project owned and maintained by the foundation?), with demos published on foundation-owned channels, where other projects (e.g. Synapse, bridges, etc) don't get as much as a tweet nowadays (apart from the spec, i.e. Matrix itself), really sends me the signal that Third Room is one of the few projects the foundation is heavily investing on, with a higher priority than anything else. I'm aware that this blog post does mention where the project sits with regards to the foundation's resources, but I'm not really sure a lone paragraph is enough to shift the balance.

> Separately, “the entire Matrix trust & safety team” was not laid off

You implied otherwise back in December though: https://news.ycombinator.com/item?id=34130243

To be clear, I'm not commenting on the situation as it is right now (and I'm in no position of doing so, I'm only operating on publicly-available info and there isn't much to describe what's going on at the moment). What I'm commenting on is the decision back when Element laid off part of its staff to, according to the information available publicly, lay off the trust and safety team, but keep the third room team on board. Which imo sounds like Third Room being prioritised over moderation/t&s.

> having entire foundation-authored blog posts dedicated to updates to Third Room (which I did not think was a project owned and maintained by the foundation?)

TR is a Foundation project - its repo is github.com/matrix-org/thirdroom (not github.com/vector-im); its copyright is by the Foundation, etc. And the point is to provide spatial collaboration building blocks for Matrix (just like Olm provides e2ee building blocks; matrix-js-sdk provides IM & VoIP building blocks) etc.

> where other projects (e.g. Synapse, bridges, etc) don't get as much as a tweet nowadays (apart from the spec, i.e. Matrix itself)

That’s my bad; the projects seem to have fallen into the habit of publishing and tweeting/tooting/skeeting their updates in TWIM (eg friday’s 1.0.0 release of the IRC bridge) rather than via individual tweets and blog posts like we used to. The reason is that the various projects prefer to write software than blog posts/tweets, and I’ve lapsed in writing the posts/tweets myself (given I spend my life trying to fix funding and get Element X shipped) and haven’t successfully handed over to someone else to do it. It doesn’t mean the work isn’t happening though; we’re just failing to show off about it.

> Which imo sounds like Third Room being prioritised over moderation/t&s.

The rationale is that if TR generates money, that money can be put to more T&S and the rest of Matrix. It’s a way of trying to fix the funding nightmare. If it doesn’t generate money (by attracting innovation funding from people who actually like the idea of open spatial collaboration), then obviously folks won’t be able to work on it as their dayjob as there won’t be $ to do so.

I guess one way of thinking about is that we model TR’s funding as separate from the rest of the Foundation - it has to be able to fund itself, and it is not stealing resources from elsewhere. (You could argue it steals focus, but in turn it exercises large chunks of Matrix - VoIP, Hydrogen SDK, SFUs etc, which I believe compensates for that, in combination with the marketing value).

TL;DR: if TR doesn’t pay for itself via its own funding or by generating cash, then we won’t have $ to pay for it.