Hypermedia document editing environment
The goal of this document is to gather thoughts on a new type of hypermedia editing environment.
For document editing, authoring and formatting with semantic enrichments
Possible names HyDEE, Hyde?? See Ideas for names for the metagraph editor.
Eventually, functionality like Pastegrid, or even image editing could be supported here.
Comment from Seb 2021-10-14. The thoughts and ideas here bear strong resemblance to Ted Nelson’s Project Xanadu, see its Original 17 Rules.
Goals of the project
It should support advanced usages with complex data needs by implementing existing and custom schemas.
It should be based on Linked Data.
It should support individuals as well as small teams (1–100, from the Earthstar github)
It should support simple, non-technical people, typically editors and writers. (Some level of training should be expected – this is not a chat platform.)
It should support the decentralized web and should be portable.
If it uses a format which needs an application to modify the content (due to positional annotations etc.) it could come with a simple command-line editor available on all platforms to make basic editing possible (plain-text).
It should have a clear and intuitive privacy model.
It should support commenting directly in the document, like PDF comments or Google docs comments.
It should not take your data hostage. You should run your own data store with your own backups. (See Zero Data App)
It should support full-text search out of the box. (See Full-text search in JS)
It should support localising the user interface.
It should support localized content.
It should support offline usage. (See offline-first applications)
It should support user-only data, ie. a Zero Data App.
The data it produces (both data snapshots and event data) should be portable and readable by another tool.
It should be fast!
It should only use dependencies that have been designed to last. (See AtJSON).
It should support live previews of predefined schema types.
It should be easily pluggable.
It should have a clear, open-source license.
How can this project be monetized?
Is it even possible to make money? Is the project too ambitious?
Other projects with similar aims
https://github.com/condenast/atjson
https://github.com/cinnamon-bun/earthstar-wikiblocks
https://github.com/gdamdam/awesome-decentralized-web
https://hypercore-protocol.org/
https://github.com/holochain/holochain
https://web.hypothes.is/ (Web annotation)
https://www.understory.coop/ (Added 2021-08-13)
Loose notes
This is more of an event-based editor layer for structured data and file attachments.
Ideas are borrowed from projects such as MediaWiki, TiddlyWiki, Sanity, SirTrevor, Slate, Markdown, Schema.org, Google Docs, etc…
AtJSON or Portable Text could be used for text data. (See AtJSON as interchange format and formats)
JSON-LD could be used for stuctured data.
See JSON Schema
Block based content management system.
There is a single base document type
This type only has a simple block editor with a block type text.
Schemas can be added for more specialised structured content like, Article, Event, EventSeries, Person, Venue… Etc.
These schemas are based on and compatible with schema.org.
If a schema.org isn’t available for your use case, you can write your own schema.
The CMS presents these schemas as forms for you to edit.
A document can have more than one schema attached, but it is probably a good thing to keep it simple, atomic, and rather link to another document with its own schema.
You should be able to embed things like MathML to make this tool as useful for an academic as a non-technically-savvy editor.
Although markdown may be fine as a format for technically proficient users with good prior knowledge of HTML, it is not a great tool for ‘normal’ end users.
Post-hierarcical web
Using a flat structure like this allows a special feature, borrowed from wikis – creating links to pages which do not yet exist!
This is the most important feature of the system. And allows you to easily create a new page for anything, right in the context of editing another document.
The content management system should only deliver the content via a read-only API. It is thus a ‘headless’ CMS.
Content should be delivered as https://json-ld.org/
This API should be available both internally (on the same computer, different port?), And publically, on an available address (DNS).
It would be great if you could log into the backend on one domain, and then access the drafts and unpublished documents on the API endpoint (token?)
It should be available both over http and IPFS is a peer-to-peer hypermedia protocol.
The backend for the system could be an unstructured data store/database like Earthstar, MongoDB or CouchDB see List of databases
It should be built to be relatively portable in that it strives to be as open as possible about formats and standards.
You should easily be able to take the data out, and easily be able to consume it from another ‘client’ or system. Another editor.
Bring your own backend Bring your own front end Just an editor Form builder for schema.org
The above covers a rough sketch for an MVP spec.
- headless CMS for multiple users, but with single-user editing
- wiki-style links (top priority)
- custom schemas for structured data
- including automatic forms for editing them
- read-only API based on JSON-LD
It does not (yet) cover more advanced features like:
- real-time, collaborative editing (using web sockets for events?)
- multimedia backend (should be able to connect to different persistent storages, front end may deal with compression etc.)
Could this be built with Fission? or does that have a different use case?
In the meantime, it might be possible to write a similar system using Sanity as a backend for both data and files. See Wikilinks in Sanity for some loose ideas around how to solve this.