Hacker News new | past | comments | ask | show | jobs | submit login
Getting to Xanadu (mimix.io)
67 points by mimixco on Dec 8, 2018 | hide | past | favorite | 55 comments



Basic problems with Xanadu, from someone who visited there a few times when it was under development:

- Everything is pay per view in Xanadu. There isn't that much content people will pay for. Especially user-editable content. One proposal was expensive investment newsletters. The Bloomberg terminal is the exemplar of that model.

- Ted Nelson had strong ideas about how the implementation should work, and he's a terrible database architect.

- Nelson was very text-oriented. Pictures? Video? Not even considered.

- Search? What's that? This was pre-Alta Vista, let alone Google.

- The original design was very centralized. This was pre- world wide web.

- If you're not doing the micropayments thing, trying to pay every contributor for their few words, a wiki does most of what you need. Git does the rest.

- In a distributed implementation, keeping all those "transclusion" links in sync requires elaborate distributed database synchronization. A dead link in Xanadu means a gap in the text.

- Disk got a lot cheaper and the incentive to have only one copy of something is gone.


>Git does the rest.

No, it doesn't. But this does, kind of:

https://discourse.pijul.org/t/patching-patches/212


> Disk got a lot cheaper and the incentive to have only one copy of something is gone.

Not only that but thanks to simple regexp (such as 's/source/target/g/') it is much easier to replace copies of the same text. With proper tools (which Wikipedia undoubtedly has) it should be easy to change text with one click of a button.


Exactly! Today we have room for everyone to have his or her own copy of every document he or she needs to access. Client/server has changed and now you can serve-up your own copies of stuff. RegEx, though hateful, is functional and it can be used to grab and quote or grab and manipulate any piece of an existing document. We don't need to invent those parts. :-)


This is a somewhat interesting discussion about reviving Xanadu if you ignore the silly attempt at shoehorning blockchain into an application that doesn't need it.

A decade ago, I also tried and failed to create a compelling transclusion based system: http://www.bookvoid.com

I'm not sure why transclusion isn't popular. I think partly, it's because you get 90% of the benefits from using existing hyperlink based systems, partly because having visible URLs at the top of pages identifying a unique source of trust is necessary and mixing content from different sources into a single page would be too confusing and introduce too many security issues, and partly because it is too much of an effort for typical readers to navigate a hierarchical and intertwined structures of information.

While I may like to explore information by uncollapsing fragments and hyperlinked documents to reveal a level of details and collection of sources that I choose myself, a lot of people seem to prefer to be shepherded through linear top to bottom narrative tailored to their level of proficiency and purpose. This explains the popularity of video sources like Khan academy.

Reference websites such as wikipedia would be prime candidates for the use of transclusion and Xanadu like layouts and I suppose they use some of it already. For example, last time a used wikipedia's mobile app, it collapsed sections and allow them to be opened inline. But for some reason I can't pinpoint, more genuine Xanadu like integrations fail to catch on.


I mention the blockchain because it (potentially) serves a purpose. It's a verifiable, write-only storage method that can be easily shared among people yet still remain privately controlled. Those are unique attributes!

If we look beyond cryptos to blockchain apps that store textual data (as they all really do), there might be a use case for blockchain with what we call canonical documents in Mimix. I'm not married to the idea and there's no buzzword fishing here. Mimix does not involve a token economy or altcoin.

I must disagree that linking is a 90% substitute for what Ted called tranclusion. Linking is nothing more than the electronic version of the library card catalog. Linking does not help the user find the context of the referenced material nor help him or her to "link" back to his or her own writing later from that reference material. These were the goals of Nelson's transclusion and they're also part of what we're building with Mimix.

As to the paucity of modern education, I agree with the results but not the reason. I don't think people prefer low-quality information. But I do think that corporations and governments prefer to supply that. We need tools to help us Think Better, as we have since Vannevar Bush first proposed his Memex in the 40's. The opportunity to give students and teachers more fine-grained and more accurate access to information can only help raise up the individual to a more powerful place in society.

You are 100% right about Wikipedia. It's low-hanging fruit for canon. Many other datasets are, too, such as the legal documents, free books, and artworks offered by academic institutions. The trick is to integrate those works into the Mimix users' new, original, writing and the purpose of Mimix is to enable and simplify that integration in a way that was never before possible.


> I'm not sure why transclusion isn't popular. [...]

Perhaps the tool-and-community bootstrap challenge is sufficient explanation?

It was clear for years that USENET news needed comment voting, but its community never really made the attempt. Progress came from moving elsewhere, eg HN.

Consider selective comment display as a limited form of transclusion. Why doesn't HN have more highly personalized views? Sometimes you want quality, but it's obscured by chatter. Sometimes you would like to chat, but that would obscure quality from others. So we're at very not 90% of benefit; not a security issue; and far more effort for both readers and mods. But the better code doesn't exist yet. And community expectations don't demand it -- users might abandon a "no comment voting? - so broken" site, but "I can't even do basic reputation filtering?" isn't an expectation yet.

Or consider the largely unsuccessful effort of the late-80's hypertext community to shape the development of the "that's not right" WWW. Including "this has become funny" multiple Xanadu attempts. Path-dependent local incentives seemed to dominate instead.

But if one bottleneck is ease of exploring non-linear information, perhaps help may come from VR's relaxing of screen real estate constraints, providing more elbow room for low-overhead speculative UI content and associated assistive agents?


The author makes two errors in his analysis. First, cryptographic signing and identity management exists today, and long before blockchain was ever even proposed. It’s SSL and other public key encryption systems.

However, that’s relatively minor when compared to equating “Permission to link to a document is explicitly granted by the act of publication”, to copyright enforcement. It’s not. It’s literally no different from the web today. You give something a URL, I can link to it without your permission. It may be couched in legalese, put it’s defining existing behavior and existing norms.

Fine, the author doesn’t like micropayments. That’s their right. But it seems like the author’s frequent stark pronouncements of “copyright enforcement should not be in a tool for readers or writers” is a bit naïve in light of digital distribution, or honestly distribution by any method. A physical bookstore selling physical books, can be considered a tool for readers and writers as well.

Perhaps the author can weigh in, and illuminate what forms for monetary compensation would be acceptable. Patreon style tip jars, and advertising, but nothing more?would that even scale? I personally doubt it.


>First, cryptographic signing and identity management exists today, and long before blockchain was ever even proposed. It’s SSL and other public key encryption systems.

Which fail to provide the capability based security required for a Xanadu-like project.

You might want to read about the Confused Deputy Problem for starters:

https://en.wikipedia.org/wiki/Confused_deputy_problem

There exist other approaches for avoiding the confused deputy problem, but these don't have mutual exclusivity with capability based security, one such approach consists of something like this:

https://github.com/phvogt/NoMoXSS

Which basically uses this concept:

https://en.wikipedia.org/wiki/Taint_checking

However, that leads us right back into another Xanadu related problem:

https://en.wikipedia.org/wiki/Trademark_(computer_security)

Think about why we call this a "Trademark", and what that means for concepts like transcopyright licensing such as the one required for Xanadu.

If you look into who advised on & worked on Xanadu, you'll find names like Mark S. Miller:

https://en.wikipedia.org/wiki/Mark_S._Miller

...whose name you'll find popping up all over the object capability security literature. That ain't a coincidence.

The shortcomings Xanadu tries to address and which conversely Xanadu requires to have addressed before it can come about pervade computer science, everywhere.


Mimix isn't about copyright enforcement in the same way that MS Word and Atom aren't. It's simply not the purpose of the tool. How you monetize your work with Mimix is up to you. It's not a publisher's clearing house, either, which is what Nelson wanted for Xanadu and most likely killed it.

I am aware of encryption before blockchain. The idea is mentioned simply because it meets the requirements of an write-only system with lots of backups that don't depend on a central source. It could be useful for storing and sharing canonical documents but it's not something I'm married to.


8. Permission to link to a document is explicitly granted by the act of publication. This is the first example of a Xanadu feature we don’t need. A tool for readers and writers should not get involved in the concerns of platform or content providers.

i disagree. the idea of a link tax that is becoming law in europe shows very much that this permission needs to be spelled out explicitly. it is a crucial component of an open network.


A tool for readers and writers should not be a lever for copyright enforcement. I really think Nelson's insistence in being a publisher is what killed the tool he was trying to build.


the issue is not to support copyright enforcement but to prevent it from interfering with a necessary operation.

the issue is this: you build a system that connects pieces of text in a certain way, and then someone steps in and tells you: hey that connection over there, you have to pay for.

but since not everyone will be willing or able to pay, your system is now broken.

therefore it needs to be made explicit that linking is not a publishing action that could trigger copyright enforcement.


None of that belongs in a tool for readers and writers and it won't be part of Mimix.


What is Mimix in a nutshell? I found [1], but there is hardly a summary in this PDF.

[1] https://mimix.wpengine.com/wp-content/uploads/2018/08/On-Mim...


Thanks for asking. A better summary is definitely needed. I short, Mimix is a tool for reading, writing, learning, and teaching which makes it easier to include and share factual information in you're writing.


You REALLY ought to learn about transcopyright:

https://www.youtube.com/watch?v=x3l7CpnpyGw


No, because that's not part of what we're building. It was Ted's dream to control a copyright and publishing empire. It is my dream to enable and empower individual creators and consumers of textual information. Mimix will not engage in copyright issues for the same reason that VS Code does not involve itself in the licensing aspects of the code you write. It's simply the wrong tool for the job. Our tool is focused on helping writers and readers to Think Better. It has no functions related to intellectual property enforcement.


I'll try to make my point via a completely different avenue:

Would you use Mimix to utilize transclusion to edit the code of Mimix & to distribute it?


i think what they are talking about is to provide technical means for the xanadu features, while leaving the legal questions to others.

so i suppose that mimix will support transclusion, but it's up to the user to figure out whether transcluding a certain document is a copyright violation or not.

interestingly, iframes in html are an example of transclusion, so this is not exactly a new feature, and there are discussions on copyright about it:

https://www.plagiarismtoday.com/2009/04/07/is-the-diggbar-co...

https://policyreview.info/articles/news/eu-ruling-embedding-...

(funny how that seemingly contradicts the link-tax which started this branch of the discussion. i can transclude but i have to pay for a link?)


What about a tax for citations? Or a tax for reading! Why can't we pass some more copyright legislation?


"link tax" is not actually a tax but something to be paid to the copyright owner. just like we already pay them for reading.

i wonder if citations are covered too. i didn't check. would be quite ironic. when is a citation a link, and when is it not?


We're sorry you've used up your allowable viewing time this month. You can remove the temporary blindness we've inflicted upon you by upgrading your sight account to platinum status. For an extra $30 a month you get an extra 30 hours of vision to use however you like.*

* Some exceptions apply. Content produced outside your home country may need additional fees to see. Some content may be unavailable for seeing in your country. We reserve the right to terminate your vision account at any time at our discretion if we feel you have violated the terms and conditions of having vision and you may be liable for damages upon breaking the terms and conditions set out for you upon receiving vision shortly after birth. By continuing to use your vision you implicitly agree to abide by those terms and conditions.


This is a pretty weird idea: "Much of the data that children would find in a library could be called canonical in computer terms, or simply 'correct.'"

Has the author ever read an old encyclopedia or textbook? Most supposedly canonical information gets revised.

At best we can have a immutable version of a file (such as when using git), but you hardly ever want a hard link to a particular version. Dependencies inevitably change and need to be updated.


I would say that most canonical information is not actually revised very often. Yes, the dashboard facts of a business operations are revised. Your novel in progress is revised. But the distance to the Sun and the chemical formula for water are not revised.

A surprising amount of our everyday writing is comprised of these shared, canonical facts. Walt Disney's birthday will never change, and neither will Apple's market cap for November, 2018. When we write about those facts, we can rely on our own copy of correct, canonical data -- not a link to anything. An ideal research and writing program, as we aim Mimix to be, would also be able to alert you when and if your canonical information changes. In that case, you'll be able to retain and reference both versions in your writing. Most importantly, your future readers will, using the Mimix software, also be able to see where you got your facts. These capabilities simply don't exist in any of today's software.


>such as when using git

I'd more suggest something like pijul, since it soon will implement something transclusion-like natively:

https://discourse.pijul.org/t/patching-patches/212


That "screenshot" showing the two linked documents is actually a terrible example.

It might have made sense in the early 1970s when Gerald Salton was doing text retrieval experiments with punchcards and those two pages of text were about what computers could handle.

In real life if you had a page of text you might have bidirectional hyperlinks to 20 or so paragraphs which might be spread out through a book-sized document or perhaps 10 books.

A demo of that user interface produces an entirely different reaction than that mockup. (eg. "When can I buy it?" as opposed to "Isn't that swell?")

Building an entirely new format and server architecture for text almost might have seemed rational in 1970s when we hadn't even settled over ASCII or EBDIC but today if you can't find the Xanalogical structure that is hidden in plain text, HTML and PDF you are blowing smoke.


The examples are from Nelson and, yes, they're terrible. Mimix will have an entirely different and modern UI which we look forward to showing soon!


Re: atomicity and the regex hack, https://github.com/abingham/spor (based on https://www.researchgate.net/publication/259892218_Metadata_... ) seems like a better solution that manages to keep annotations "stuck to" a logical piece of text (well, code) even if it changes position/form throughout history.

There's a very short presentation about the method at https://doc-00-24-docs.googleusercontent.com/docs/securesc/d... (or https://drive.google.com/drive/folders/167z6GWl_mehmUdi6Qlkj... if those google docs download links aren't stable)


Mimix atoms are based on the actual, typed text -- not the logical values, and changes to that text or its formatting are kept separate from the original text by virtue of the MSL, Mimix Stream Language, which is used to describe them. Although I hate RegEx, I can't see any compelling advantage in the Spor toolkit. In any case, I'm predisposed to use things that folks already know for simplicity and lowering barriers to entry.


After watching some of Nelson's videos a while back, and now reading this, it sounds like the real goal is just:

1. Document Versioning 2. A universe in which all content creators properly cite their source material. 3. A better way of publishing text so that it's easier to parse.


No, Yes, and Yes!

Most importantly, Xanadu and Mimix are very different products. Nelson envisioned Xanadu as a publishing and copyright enforcement system. Mimix is aimed at the opposite group of users: those who create and consume textual content.

Mimix is about more than document versioning. In Mimix, there are no documents. There are only atoms and streams. A stream is a sequence of atoms which can be presented in its original order (chronologically, as it is created) or remixed or extracted without limitation. A "document" that you read in the wild and later write about is, in Mimix, a stream of unalterable atoms, recorded in a write-only database. This is vastly different from today's document and paper metaphor, which is really an artifact of the printing press that can be dispensed with.

Proper citation is half the goal of Mimix's implementation of what we call canonical data -- making sure that the reader knows what came from where. But the other half lies in assisting the writer in finding and organizing these sources in the first place. Today, research and writing are separate tools done in different programs. A great economy would be realized if these functions were intelligently combined.

And YES! to a better method of publishing (I would say "representing") text. Everything that happens during a Mimix session is recorded in MSL, the Mimix Stream Recording language. Instead of files of dumb data that get interpreted by different programs in different ways, MSL upgrades the data to include instructions about what's going on -- as it's being written. This allows the next user to rewind and fast-forward (as you would with a video) but also to extract and remix (which are not possible with video.)

Thanks for giving me a jumping-off point for discussion! :-)


> it sounds like the real goal is just

No.

I suspect you have the kind of point of view where we might better first discuss the proposed data structure and THEN what we'll do with it. First, you'll want to learn about zzstructure/hyperthogonal structure:

http://xanadu.com/zigzag/

https://scholar.google.com/scholar?q=zzstructure

for a comparison of the above with Ubergraphs (a generalization of Ultragraphs, themselves a generalization of Hypergraphs), you'll want to check here:

https://github.com/JeffreyBenjaminBrown/digraphs-with-text/i...

Once you think you comprehend the above, consider spending some time thinking about how you could come up with a 'canonical', graphical user interface AND user experience for a Ubergraph that uses hyperthogonal structure.

Then imagine how you'd implement such a data structure in a distributed, peer to peer, UNCENTRALIZABLE (not just decentralized!), secure manner.

If you can imagine all of that and think you comprehend at least one tiny part of the implications of such a thing, then you comprehend about 1/10 of "the real goal" of Xanadu, and I invite you to consider continuing to ponder the possibilities.


You are entirely right that the data structure is paramount. But I'm not using Xanalogical documents nor any front or backend designs from Ted. I actually think he didn't do a very good job with those. Instead, Mimix records a user's interactions in MSL, a domain-specific language (not Turing complete on purpose) which describes a forward-write-only experience of reading and text composition.

I'm glad you brought up the UI because it's an area ripe for innovation and one we're seriously excited about. UI is one of my specialties and I'm looking forward to sharing our designs for interacting with canonical documents in a modern and approachable way. HN is my favorite place to post this kind of stuff, so you'll "Hear it here first."


> 6. Every document can contain links of any type including virtual copies (“transclusions”) to any other document in the system accessible to its owner.

What does this mean? What are the different “types” of links? What is a “virtual copy”/“transclusion”? Why are these links only accessible to the its “owner” (the “its” at the end seems like it could refer to 5 different things)?


Nelson suggested that everything you quoted would be linked back to where you got it and also linked back to you, from there. The first part of this idea is fantastic. The second part, ludicrous.

In Mimix, your writing is linked to your reference materials and these are available for your readers to see, too. But your writing is only linked back from those materials when you are viewing them -- not for anyone else in the world.

Ted's suggested system would have the Declaration of Independence linked to every schoolchild's paper that wrote about it. In Mimix, you would see the relationships only between your writing and the documents you referenced -- not anyone else's.



IPFS and Filecoin could solve many of the persistence and distribution problems.


Neither of those use TIGHT Proofs of Replication, and neither of these have not just a decentralized startup configuration but an uncentralizability guarantee, that makes them significantly less useful than they seem. This so far affects pretty much all DLT implementations in general.

And none of them have certified deletion from untrusted devices.


> And none of them have certified deletion from untrusted devices.

We don't want that.


I agree. IPFS is the closest thing we have to a sharding file system right now.


I don't understand why transclusion has to be so hard.

Any developer can probably implement it on the web in a weekend by adding some metadata to some <blockquote> tag and creating a browser extension that displays the source page on the side, locate the copied text in it, and scroll to it.

Heck, you probably could brute force it by doing a Google search for every <blockquote> or "some text" patterns in a document, and link to whatever is the #1 result.


Some things people interested in Xanadu likely would wish to look into: https://github.com/JeffreyBenjaminBrown/digraphs-with-text

Why?

See here: https://github.com/JeffreyBenjaminBrown/digraphs-with-text/i...

See also here: https://en.wikipedia.org/wiki/Topic_map#RDF_relationship (Why the W3C didn't standardize on this, a bloody ISO standard, and instead decided to roll their own, weaker system, well... I'll leave you to boggle your mind about this one.)

See also this video by Ted Nelson on transcopyright:

https://www.youtube.com/watch?v=x3l7CpnpyGw

See also: https://en.wikipedia.org/wiki/Miller_columns (Previous HN discussion: https://news.ycombinator.com/item?id=18118798)

See also this: https://en.wikipedia.org/wiki/Tumbler_(Project_Xanadu)

Which, as an addressing scheme, strongly resembles the enumeration scheme Niklas Luhmann used for his infamous Zettelkasten, which I'd strongly encourage you to look into if Xanadu interests you at all.

And to stick with the Zettelkasten comparision for a moment, see also "Martha Stewart’s File Cabinet" here: http://bit-player.org/wp-content/extras/bph-publications/AmS...

(Note that the information, like most information, about "Radix economy" [an extremely ill-defined concept] given there by Hayes ignores the fact that Balanced Ternary in fact has a higher capacity than unsigned ternary, for a demonstration of this basically ignored-everywhere fact, see here: https://web.archive.org/web/20090312094241/http://abhijit.in..., and before you think that page looks weird, here, have Marvin Minsky commenting positively on it: https://archive.fo/gL2Bv; OR simply try to think about how digit sums & digital roots work in Balanced Ternary vs. in Ternary)

Why bring up "Martha Stewart's File Cabinet"? Because one of the mistakes with the Xanadu Tumbler scheme consists, in my opinion, of the fact that it doesn't use balanced ternary for the addressing, making the addresses unnecessarily long AND more difficult to handle in general. (Cf. the properties of the file cabinet as outlined by Hayes in the article)

See also here:

https://en.wikipedia.org/wiki/Enfilade_(Xanadu)

And here:

https://en.wikipedia.org/wiki/Docuverse

My current hope for a Xanadu-like system rests, in a way, on this new feature of Pijul 0.11, which basically "solves" transclusion & versioning:

https://discourse.pijul.org/t/patching-patches/212

For a newer status on the above issue, see here:

https://discourse.pijul.org/t/preparing-pijul-0-11-0/203


All of these implementation methods that Ted proposed have failed. Mimix will not include transcopyright, tumblers, or enfilades. It will, however, address many of the original goals of Xanadu and some Ted didn't think of.


Why is Html ugly?


It’s inappropriate for data. It’s basically text layout and controls, no matter how many DIVs you put.

JSON (which has its own problems) would be a more appropriate format.


This could be partially fixed by promoting "data" to be a new general HTML word:

<DATA type=application/foobar encoding=base64> .... </>

which could include application/json, application/epub+zip, application/pdf, whatever. If the browser knew how to handle it natively, great; if it knows how to invoke a helper for that, good; if nothing else a link appears to save it as an individual file.

If you give a DATA entity a name tag, you can use it inside the same page anywhere a suitable use occurs:

<DATA name=parrot.jpg type=image/jpeg encoding=base64> ... </DATA>

<IMG SRC=#parrot.jpg>

Best if you make all the attributes of the original tag follow along, so:

<DATA name=#parrot.jpg alt="Parrot Rights Now!">...</>


Why would you embed an image file, instead of just link to it? That’s not the problem at all.

The problem is just simply knowing that “1935” is a number, and a date. Microformats somewhat address this, but it has limited uptake.

But relying on people to tag stuff correctly, isn’t going to work. Just look at the mess that META tags are, especially those outside of share card population. I’m not talking about reading the spec. I’m talking about seeing how they’re actually used. People can’t even get “tags” right, let alone “author” or “date”


Very true. We feel like this is an area where better tools can help. I hesitate to use the term "AI" because I don't think artificial intelligence is real. But I do believe that tools can be designed to act more intelligently, including identifying the source and context of our writing without us explicitly having to take a hand in it.


Not just an image file. A spreadsheet. A database extract. A genealogical record.

The tagging problem is constant across all formats.


Type theory.


> It’s basically text layout and controls, no matter how many DIVs you put.

Except...it's not. Current HTML is mostly (entirely, in principle, but there are a couple holdout tags where that is strained) semantic rather than presentational, and there's very little layout-related in it (except insofar as all tags have overridable default presentation, and some of that is layout-related.)


“In principle” is meaningless. Even the semantic tags that do exist are ineffective, as they aren’t used in practice (see TIME), completely ill defined (see CITE), or correspond to common use cases.

In practice — and that’s all that really matters — what you get are a mass of DIVs and SPANs where if there is any semantic information, it exists in the open vocabulary of CSS style classes.

https://www.w3.org/TR/html52/textlevel-semantics.html#elemen...

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ci...


It was not meant for data - it is a presentation tool. It is the result of consuming data, not the data itself. For that purpose it's not ugly and it fits its purpose. No idea why my comment was downvoted...


Some people seem to think downvoting is for everything you don't agree with. Well, I don't agree with that, lol!

You are right, but HTML is a descendant of SGML which IBM invented specifically to make sure that data and formatting were represented separately. It was both a representation and presentation tool. Unfortunately, SGML hatched XML for data representation and HTML for presentation and never the twain shall meet.

While Mimix will ship with an HTML-based user interface, the underlying structure of data in Mimix is not HMTL (or XML) but MSL, the Mimix Stream Language, a domain-specific language designed to describe writing. Owing to the open source nature of our product, we expect that the community will write new MSL engines with different interfaces and this is one of the most exciting aspects of the work.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: