> It all sounds a though it aught to be great and wonderful, but I can't actually visualise how it would be useful every day. What actual value would I get out

> It all sounds a though it aught to be great and wonderful, but I can't actually visualise how it would be useful every day. What actual value would I get out of it, constantly on an ongoing basis? There are a couple of releases you can use, if you want to get a feel for it. The integrated editor we had planned out isn't implemented in any of them, unfortunately, so editing is still awkward. Most of the big benefits will only come out of having a community using this stuff, and because Ted keeps tweaking formats & there's no compatibility between the released implementations, even those of us within the Xanadu group can't really experience that. > It doesn't even sound all that hard to implement. As a former implementer, yes: none of the core concepts are hard to implement. Ted is a stickler for smooth UIs, & nearly 100% of the difficulty has been in trying to convince existing UI libraries to display his interesting visualization and input ideas in a performant way. For instance, the XanaduSpace demo used OpenGL to display everything in 3d but internally a lot of stuff was hardcoded, & when I took over development of it, we found that we had a lot of overhead when editing text, so we switched from the OpenGL 1.1 API to the current API & idioms, which let us do faster rendering. However, we had to completely rewrite glyph rendering in order to fit more than about 20 pages of text in GPU RAM (and cards didn't expose standard API calls for freeing these allocations). Our super-elegant proposed method of storing text in GPU RAM ended up never quite working (and we got burnt out by our day jobs at the same time as trying to wrangle with OpenGL), so we never met the benchmark of displaying an entire copy of the King James Bible in real 3d. We plugged the same backend into a TK frontend, which was usable but ugly. Then we drifted away from the project. The code is still around, but I don't think anybody picked it up. Currently-available web-based Xanadu systems (OpenXanadu and Xanadu Cambridge) are cripped by same-origin policy. Xanadu doesn't want to host arbitrary user data locally (at least, not unless and until customers pay for storage). I wrote a caching proxy for OpenXanadu back in 2013 or 2014, but it wasn't used for basically the same reason: storing arbitrary user data costs us money & makes us liable for takedown requests & other such stuff. While desktop-based systems like XanaSpace could fetch from arbitrary remote hosts using arbitrary protocols (mostly HTTP, but I snuck ftp and gopher support in, and pushed for IPFS support as well), OpenXanadu is stuck only fetching from xanadu.com & a handful of sites that have whitelisted us (and attempts to get project gutenberg & the internet archive to whitelist us for SOP failed, I think). Again: trying to work around SOP was a lot harder than the actual implementation. I wrote an experimental span-based editor for XanaSpace, and I was asked to port it to javascript for use with OpenXanadu. How it worked was that you selected text in a 'source document' panel (some text or stripped HTML fetched from the wild blue yonder), the text you highlighted would be colored & a copy would be inserted into a kind of visible pastebin, and you'd insert chunks from that bin into an accumulating new document in another panel. Then, in a box below, the EDL format for the document you're creating would be listed, which you can copy into a file to be loaded by OpenXanadu. Unfortunately, there was a hard to find off by one error in the code for ignoring color tags in the source document -- in other words, when highlighting, the character offsets would get less and less accurate the more you go along. It was an intermittent problem. I didn't end up fixing it before I left the project. The XanaSpace version worked fine. This editor was supposed to be a stopgap, & the eventual editor we planned to make would involve dragging selections directly out of existing documents, snapping them together to form new documents, & being able to then insert or delete text from within these composite documents directly. Existing GUI toolkits, to the extent that they allowed dragging of widgets, didn't show the dragged item as it crossed widget boundaries (and anyway, couldn't show beams between scrolling text things), so we were going to have to write our own text rendering/editing code (which isn't so bad -- we did it for XanaduSpace and again for XanaSpace) and make it handle mouse events reliably on arbitrary unicode text using proportional truetype fonts (substantially more complicated), make that handler differentiate click from select from drag, etc. It was gonna be complicated, & every little noodle of text needed to store its own arbitrarily-complex history, with the beams it was attached to animating along with the drag and such. We put it off, and it looks like everybody else also put it off. We knew that if it wasn't sufficiently pretty, it would never see the light of day (even as open source). I prefer to develop in public, so after I left Xanadu I started developing my own (less pretty, but at least conceptually-pure) implementations. I also wrote down software-engineer-centric descriptions of concepts we used, so that other people can do the same. (They can be found here: https://hackernoon.com/an-engineers-guide-to-the-docuverse-d080cdbb73a6 https://hackernoon.com/an-engineers-guide-to-the-docuverse-d... ) None of this stuff is actually hard to implement, but for a backend guy like me, making it pretty was a lot harder than making it usable.