Universal Doclets is a vision on how to achieve re-usable data and code over the current web. Building a new world-wide infrastructure might yield a more optimized experience, but the likelyhood of getting any kind of market share is low. Aims: make it possible to create applications by re-using existing and untrusted components, over the network. make it simple enough that unsophisticated developers can create their own applications make it live, no dead code, no API's make it collaborative applications should be able to run anywhere

KrakenJS/post-robot is a full fledged postMessage bus protocol, that we might use as-is for a new hope. We might even use KrakenJS/zoid as a complete library to implement decoupled components based on iframes. However, both libraries are fairly complex and have drifted towards a different use-case than what we'd minimally need for a new hope. So instead we might use them as inspiration. In that case, we could also use JSONTag as the default message format over the bus, since we can then create our own bus implementation. JSONTag has these benefits: more specific typing/tagging of data allows internal links, even circular

An open reply to "The lost apps of the 80s" There is an 2021 article about The lost apps of the 80s in which Dave Winer and Ray Ozzie[1] discuss apps from the eighties that were lost in the transition to the web era. they seem to be gone. Seemingly forever One quotes from the article stands out to me especially: Now, we don't have choice. If I want to write on Facebook, I have to use their awful buggy editor. If I want a Substack newsletter or a Medium blog, or whatever -- I have to use their editors, which vary in quality, but none of them would have stood a chance in the 80s software market. This made me think of the Solid project and its promise to return choices and ownership back to the user. Not just for data, but also for applications, especially with things like Semantic Components and our own New Hope ideas.

Hello, my name is Auke, 48 years old and I've been building software, mostly web related for a long time. As anyone doing this for any time will tell you, the work is rotten. Programming sucks. API's are inconsistent. Standards proliferate and are incorrectly implemented. And in general everything is more complex than it should be. And that is just from a programmers perspective. At least I can generally understand how stuff works. How other people cope with the mess we made of the web and software in general, I can only imagine. While contemplating my life choices I was re-introduced to Alan Kay, specifically this talk: Alan Kay, 2015: Power of Simplicity. In it he succinctly explains how to invent the future. As someone who has done just that in the 1970's at Xero PARC (Palo Alto Research Center), he speaks from experience. The main point Alan makes is that to invent the future you must first imagine it, and you must do so further into the future then you might think. At Xerox PARC they imagined a future about 30 years into the future. Then they asked themselves what things would then be absolutely possible or even common, that today is impossible. Then extrapolate from those things to something that might be possible in about 10 years. Then set a target, and set out to achieve that target in about 5 years. Don't try and slice it up any further, do not expect any deliverables before the 5 years are done. Although he suggests that if you aim for 5 years, you will probably achieve your goal earlier, in about 3 years. Then take a year to reorient and do another 5 years. And in about 7 years you will have changed the world. So, here I am, trying to change the world since 1994, or at least the part I love, the web. Its 2020, 26 years with no real progress. Can I do better? Can we do better?

A new working name for the universal document that is both application and document. A doclet contains application to render the information it contains and to allow the user to interact with it. The doclet may also refer to the application code, if that reference is guaranteed to exist and to contain the correct and immutable application code. For instance, an IPFS hash is a hash over the referenced content. If the content changes, the IPFS hash will change. In addition the storage service providing the doclet can also pin the IPFS hash for the application code, so guaranteeing the availability of the application code. The problem is that IPFS is not a natively supported protocol in most web browsers, so we'll need a bridge. e.g. https://ipfs.io/. However, there is no guarantee that that website will be accessible in the future. So imagine a situation where IPFS support is now standard in the browser, but https://ipfs.io/ is no longer up. Or imagina a future that no longer supports IPFS directly, but there is an archive or translation service for important content, like the application code your old doclet is referencing.

show a (vertical) list of doclets start / stop edit mode add/move/remove a doclet save to new url or current url add/edit host scripts show a list of doclets A doclet is just an iframe with a name and a url. So a list of doclets is just a number of iframes after each other. But you must be able to:

basic hope IDE List available API's in a doclet (or host) Show methods in an API Create a new Code editor Log view debugger Data display

Data Portability is a broad term. You can apply it to document formats, as in office file formats. In this way you specify the structure of the data, but not the meaning. Solid (solidproject.org) goes beyond just the structure and makes the meaning of data explicit, using RDF ontologies. The problem is that each of these seperately seems insufficient to make the proverbial 'killer app'. The promise of Solid is that your data won't be tied to a single application. You get data portability for free, if you use the same ontology. But there is another approach we could take that has proven successful in the past, and that is the SmallTalk approach. What would happen if instead of static file formats, a document was instead a living running application. Each document having one or more API's you could query. One of these API's could support queries based on RDF Ontologies, perhaps using LDflex (https://solid.github.io/ldflex-playground/). But it might also have additional API's. And if you know the document type, you might find translation programs that connect to the document using a supported API and translate to a different API.

This document expands on the concept of Universal Documents, as introduced in A New Hope. When using IPFS as the universal storage system for documents, you must be aware that an IPFS address is tied to the contents of a document. If the contents change, the address changes. The advantage is that any version of a document exists side by side with any other. And if two versions of a document are identical, they by definition have the same address. So deduplication is build into IPFS. But version tracking is not. There is a way to keep track of the latest version of a document, using IPNS. This uses a similar looking address as an IPFS document, but specifically allows changing content, without a changing address. It does this by pointing to an IPFS address. You can update the pointer, without changing the IPNS address. The problem then becomes, how do I find older / other versions of the document?

Goals: simple UI minimal code, fast load responsive collaborative and live updates url parameters to show only a (rectangular) selection (inc. row and column headers) UI

A Chess Game A chess game is an example of an ephemeral application, its contents change over time. Untill the moment the chess game is finished, then its contents are fixed. So a chess game starts by two people connecting and starting the same application. This application must have an ephemeral address, as it will change its contents. Each move one of the players make is appended to a log. Each position in this log has a content adressable address. You can go to each position in the log and get an accurate representation. When the game is finished, the last position in the log becomes the final, fixed address of the game. Each position in the game should be aware of its full version list. So that you can move to the final position. Now in reality the application will probably optimize this, so that you only load the application once and it will get all the moves in one go, instead of switching the application to each position entirely. But by building the base system this way, any ephemeral application that can log changes can be supported in this way, and make each state addressable.

To build a Universal Document, we need a universal application environment. A universal document is also an application. There is no distinction. You don't need an app to read/show/interact with a universal document. For the first version of universal documents, we choose to use the web browser as a bootstrap environment, and IPFS and IPNS as storage. The Universal Document has a future-proof format, in that we only specify the first line of the document: <script src="//baf...hwq.ipfs.dweb.link/cobalt.js"></script><!-- The exact URL in the script depends on the document. But this line is needed to make sure that the browser can render the document. Since this is just part of the HTML standard, you could add more lines, but the render script must be the last and should be followed by a comment-open token, unless the universal document is entirely HTML, which is possible and explicitly supported.

Cobalt is an attempt to write a markup language the way Ted Nelson suggests - using an Edit Decision List (EDL). It is an evolution from an earlier attempt, called Hope. I've worked on this of and on for about 8 years. Hope is in fact in use, as the core of SimplyEdit, which is a product my company makes. A cobalt document currently is a combination of different documents, glued together using mime encoding. There is no way to interpret this format unless you already know the format. However in 'A New Hope' I stated that in the future all documents (or all information) will not need an application or specific code to interpret it. Just like the web today, all information should come with all the code that it needs to display and interact with it. To do this there must be some universal application environment. For now I'm going to assume that this is a web browser. In that case the format of any document should start with the code that helps render, manipulate and interpret it. There is a simple way to do that for any HTML document: <script src="https://example.com/document.js"></script> Any web page can include a piece of javascript, that will run when you view the page. For this process I will disregard situations where javascript is disabled.

Programs are a prison - hackernews discussion Membrane.io - Blog post Hope and Cobalt Vega and Vega Lite Nushell HyperCard Lively-Next Oberon OS Killing Apps, Unifying Web and Native Systems - Humane Computer Webstrates

There are no documents or document formats, only applications. This means that mimetypes are no longer relevant. The mobile app metaphor is already leaning this way. Any application may use or contain another application. You don't need permission to use or contain another application. Applications live online, not on your disk. There is never a need to install or download something. Each application has a stable address. There will be applications that have ephemeral data, data that will disappear. But most applications will be static, comparable to documents today. Those applications should be content addressable. Meaning that if you have a content address, you are sure that content will not change in the future. In addition applications may provide an ephemeral address. This address will point to the most up to date content and provide links to older versions. Without using a specified data format, but by providing an application. Applications should have an API that can be interrogated. Since we'll be using message passing, that means we have an initial interrogation phase between the host (another document or the root web kernel) and itself. Here the document can list the kinds of API it supports, and the host can filter that, or the host can send a list of API's it supports. There should always be a low level API of last resort.

This documents the design of an experimental UAE (Universal Application Environment) API, called 'hope'. The goal is to see if we can achieve a simple, intuitive API that allows us to build a real live universal document system on top. parts initialization bus connect pub/sub call/reply

What can we build in the next 5 years to get closer to that 10 year and 30 year vision of A New Hope? A Universal Application Environment will be tricky. By starting with the browser as the prototype for this, we may focus too much on current technogy. However we need some starting point to get to Universal Documents and Universal API's. So for the next 5 years, we'll use the browser as the bootstrap for a prototype UAE. Meaningful Data is something that a lot of people have been working on for a long time. I don't see a direction that will speed this up. So let's not focus on this, and just use the tools available now. Solid and Linked Data should certainly be a part of that. Universal API's are also a tough problem. API's are consumed by client software that can run in any and all environments. Supporting them all is impossible, I think. So picking just one is probably the best bet, for a first version. If we see WebAssembly (WASM) as a converging technology, then supporting Node.js (or Deno) looks like a good fit. But there is still a lot of research necessary, and Universal API's are not visible or sexy.

The most secure way to embed doclets is by using an iframe. However an iframe has a fixed size and doesn't resize to fit its content. Google supported a 'seamless' attribute in Chrome 20-26, but has since dropped it. There are a number of attempts to implement it in javascript. All of them need the iframe.postMessage channel to allow cross domain communication. There is no way to implement a seamless iframe without both the host and the child frame working together. Issues DOM elements obviously cannot extend outside the iframe borders. So you cannot create a DOM based popup or pullout, unless you keep careful track of the iframe size. Browser controls however can extend outside. That means the contextmenu, a select list, a datalist, etc. So if you want to use a pulldown menu, that may be too high for the iframe, you can use a select list for the options and a label to open/close it. hope.seamless.js calculates the needed height for the iframe using the body.offsetHeight. This doesn't keep track of absolutely positioned elements. hope.seamless.js should probably allow you to inject your own height calculator function.

Specifically, kill RPC or REST API's. Any APi that forces you to pipe queries through a very limited syntax sucks. Why can't you use your entire programming language constructs as your API? It turns out you can. If you write your software in Prolog, you could use 'Pengine' as your server API. Now you can send a prolog program to the server to run a query and return results, as prolog primitives. Not everyone wants to learn Prolog, though you probably should. But we can do this with javascript as well. In the case of Hope, each doclet is running in your browser already. It is trivially simple to add a script to a doclet and run it. Now you have access to the data and programming interfaces and libraries in the doclet, with full javascript goodness. The security concerns are limited as well. All code is running in your browser, not on some server. The browser is already sandboxing your code. You can't mess up any data for other people, only your local copy.

Hope needs a simple UI to allow anyone to build hopde doclets by combining existing doclets and wiring them together. This UI should be simple enough that users that today use office software are able to build similar documents using Hope. So let's describe a possible UI for Hope. A user opens a Hope doclet by entering a URL in the browser. (Or clicking on a link somewhere). The doclet is not in editmode yet, but there is an icon that is faintly visible, say in the top right corner. This icon is only visible in the host doclet. The user can click this icon and a dropdown menu shows an edit option. Click that and, if the user is authorized, the doclet will turn on the editmode features of that specific doclet. Each doclet must define its own editing features. So here I'll describe a doclet that only allows you to add, move and remove other doclets. And ofcourse write scripts to connect them. The list doclet has html, css and javascript code that shows an empty page at first. In edit mode it shows a (+) icon on the left. If you click that, it will show a popup menu with a list of favourite doclets, as well as one or more doclet marketplaces where you can select other doclets. You can also add a doclet marketplace.