https://sctlib.gitlab.io/space-element/#input=hello is web-component space-element that generates a simple web-space, which DOM and content are stored in the URL, as encoded data, as well as in sharable QR code (and "printable" version).
Generate a website, which content (a combination of: plaintext, markdown, HTML) are stored in the URL (as encoded data), and shared as QR code (pointing to the goog.space instance; and having the data in the URL).
An instance of this webcomponent is available at goog.space.
<style></style>
tags<space-element/>
is a web component container the logic<matrix-room-element/>
<qr-code/>
etc.)It also allows, experimental, and maybe not here to stay:
The RTC code (ours) has dependency to matrix-room-element as well
(code is currently in double, nee to work with peer
dependencies). Also the RTCCode and QRCode have a dependency to wasm
mode zbar
to decode the qrcodes from images/videos (and that is
heavy). So we gotta reflect on the trade offs.
In all examples, the "data of the site", is stored 100% in the URL (no server needed). This is why the URLs are so long!
If you would like to use this project on your own website, it is possible to import the project from npm or a cdn
<script src="https://unpkg.com/@sctlib/space-element" type="module"></script>
<space-element></space-element>
<style>
/* for a full height space-element */
html,
body {
display: flex;
flex-direction: column;
flex-grow: 1;
}
html {
min-height: 100%;
}
</style>
With gitlab pages hosting, we get a http error 401, Request URL is too long (so we host on cloudflare pages).
#input=
with a string of text as input#data=
with a goog.space encoded data (see #data-encoding)goog
The goog
(ol) is a large number (wikipedia).
The encoding is here to stay, and should never change to keep the "old URL data" decodable.
From the space-element.js
code:
/**
* Unicode to ASCII (encode data to Base64)
* @param {string} data
* @return {string}
https://base64.guru/developers/javascript/examples/unicode-strings
It preserves all unicodes characters (including emojis) when in a URL parameter
*/
function decode(data) {
return decodeURIComponent(escape(atob(data)));
}
function encode(data) {
return btoa(unescape(encodeURIComponent(data)));
}
If this one day changed, we should keep backward compatibility with "migrations", but hoping we never have to.
Somehow, maybe this application should be rewritten with a <body contenteditable/>
, and edit.goog.space
subdomain, so the resulting
HTML is as clean as possible (and archive.is or archive.org can almost
have the "raw user content" withtout any goog.space content).
Archive.is is free, works from the URL, is super practical, works with goog.space (archive.org had troubles with web components, and very slow URLs).
The application, as "simple" as it is, tries to define the inputs and outputs it can accept and provide, and its mime type "as a protocol".
The idea is to somehow get a clear and predictable pattern to communicate with the URL API of a goog-space application.
The protocol
is space.goog
following the JAVA (and Matrix.org;
reversed domain name) naming conventions, so it can be written
space.goog:
(as in new URL().protocol
format).
Goog.space accepts currently two forms of input, "unencode text data" and "raw text data".
#input=
url search (hash) param for user text, e.g.: hello world
.#data=
for the encoded data, decode to the user text, e.g.:eyJ2YWx1ZSI6ImhlbGxvIHdvcmxkIn0%3D
For more information on them see the rest of the documentation.
We could therefore imagine representing the user input
URL content
(in a JSON "event file" format) as:
{
"mimetype": "space.goog://input+text",
"space.goog://input+text": "hello world"
}
As for the encoded data
representation, since its decoded result
infered from the mimetype URL schema "space.goog:" of type "data",
threfore encoded:
{
"mimetype": "space.goog://data+json",
"space.goog://data+json": "eyJ2YWx1ZSI6ImhlbGxvIHdvcmxkIn0%3D"
}
For
encoding
anddecoding
functions, see docs section.
Note: the "file event" representation is an inspired variant of a matrix event specification