💾 Archived View for gemini.bunburya.eu › newsgroups › gemini › messages › 1652811102.bystand@zzo38co… captured on 2024-05-10 at 11:16:00. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-06-11)
-=-=-=-=-=-=-
From: news@zzo38computer.org.invalid
Subject: Re: Gemini is no social network
Date: Fri, 03 Jun 2022 13:35:06 -0700
Message-ID: <1652811102.bystand@zzo38computer.org>
Cyrus Valkonen <cyrus.valkonen@gmail.com> wrote:
I think what will happen with time is simply that people will answer
those shortcomings by methods and protocols on top of Gemini that are
not defined in the standard.
For example, links to images could be automatically expanded, sound
files will show a mini-player, the browser will auto-fetch all links and
show a mini-preview if you hover them, it could show a slideshow gallery
if it finds mostly images in a folder structure and so forth.
An implementation could do this at a user option (possibly with lazy
loading), if wanted. It could also be a menu to select modes, e.g.
document, grid gallery, slideshow gallery, etc.
Also if no other way exists for people to write comments on pages,
someone will eventually write a decentralized Dissenter-alike "plugin"
and put it inside the popular Gemini browsers. This plugin then simply
operates a database (e.g. GunDB) outside of the Gemini network and
allows comments to any arbitrary URL on it.
Anyone who wants comments in their document can add a mailto: or nntp: or
news: link if they want to do. Therefore there is already the way to do.
If you want to make comments for arbitrary URLs, then you could also use a
NNTP set up for such a purpose, with a new header field to specify what
URL it is being made a comment of, I suppose.
The same could be true for polls or any sort of user feedback.
I had made up a file format for survey/poll; like Gemini format, it is a
plain text file, and can also be suitably displayed and printed out even
with software not understanding this specific format. I also made up the
answer format, for submitting answers. It is independent of the protocol.
I wrote a parser but not the further parts of it yet, such as the storage
of the answers in a SQLite database (then it is possible to make queries
to calculate statistics that you want, such as mean, median, histogram,
correlations, and more).
I think this is a much more preferable way to have user interactions,
and one that is much safer from a democratic perspective, than if all
the housekeeping, form building and authority was left to the website
operator.
Both ways have their own advantages and disadvantages, although it is
also possible to do both.
However if we are talking about non-standard tags becoming popular to
display inline content, like tables, images sound files and maybe even
stuff like webassembly and Javascript-ed webapps, then it gets kind of
messy and shady.
Pictures/sounds do not necessarily have to be inline; they can also be
user settings (and may also be lazy loading).
Tables for data can be useful, but you might also link to a CSV or SQLite
file with the data; the user might also be able to make sort orders,
filters, SQL queries, etc. Some implementations might be made, which can
have the built-in capability of CSV.
I have read about TerseNet which has WebAssembly but not JavaScript, and
must be explicitly executed by the end user; it won't automatically execute
it, and is not needed to display the document.
I also have my own idea which is VM3 (which I had partially written about),
which has its own markup format and instruction set, and many of its design
decisions are made in ways which I think might be better; like TerseNet it
also requires the user to explicitly execute it. We will see what it is
once it is done, and others who are interested can try to help.
I think it cannot be ignored that there is a critical need for people to
be able to interact with a website, e.g. in the form of giving feedback
or submitting forms (for example a poll, advanced searches with multiple
variables and parameters, inputting data like addresses and statements).
This must be done in a way which is good for advanced users.
For searching, having data accessible as a file, or using a searching API
(which might be usable as a SQLite virtual table module), can allow to do
some kinds of customized searches; a form is still helpful too in order to
make the common uses. (Downloading as a CSV or SQLite is also possible.)
Data input can have some sort of file format that you can make up the form
and the format of the filling in, that you can also save/recall on disk as
individual files too.
An implementation that can autocalculate some form fields should have an
option for auto or manual recalculation; if manual then you must push the
recalculate command (which might be bound to a key, or a menu item or a
toolbar icon) to recalculate the form.
Also there is a critical need to eliminate click-mazes, hence a need to
be able to auto-load and display inline content.
This should be a user option. A user might not want to auto-load content.
Gempub allows inline pictures (using the usual Gemini link syntax) for
pictures that are included inside of the ZIP archive, but this should also
be subject to user configuration.
If those needs are not met by the protocol, eventually people will
basically just ignore sticking with it and find ways around it.
You can use different protocols and file formats for different purposes.
One protocol or file format will not help everything. (The same should be
true of character encodings; Unicode is not suitable for everything, nor
can everything always be converted to/from Unicode effectively. TRON also
is not always suitable, but has some advantages and disadvantages over
Unicode for some purposes.)
Possibly, implementations could be made where different protocols and file
formats may be loaded as .so files, and may be written in C. Adding new
character encoding conversions could also be implemented similarly; it may
use a font with that encoding if it exists otherwise convert it and specify
which settings to use if necessary.
For example, an implementation could be made with:
Protocols:
File formats:
Different implementations may vary in which protocols and file formats, and
which features of them, and may allow a common C interface to add other
formats and change their capabilities. The core system may also then be
modified independently to change the user interface and features which are
separate from the protocols and file formats.
We might also ahve different ideas than the above, too. All of the above is
just my current ideas, and we can have improvement in future, too.
--
Don't laugh at the moon when it is day time in France.
Parent:
Start of thread:
Gemini is no social network (by David <david@arch.invalid> on Thu, 18 Nov 2021 22:40:59 +0100)
Children: