💾 Archived View for rawtext.club › ~sloum › geminilist › 007596.gmi captured on 2023-11-14 at 08:29:07. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Balázs Botond balazsbotond at gmail.com
Fri Nov 12 05:57:52 GMT 2021
- - - - - - - - - - - - - - - - - - -
On Fri, Nov 12, 2021 at 5:03 AM Alex <alex at alexwennerberg.com> wrote:
However, one idea I had was to use Gemini itself, without modification, to handle uploading content, ie a file. I have a couple of ideas:
1. sending several <META> In 1024 bytes to write an entire file.
2. For a text file, sending a diff including a line number and a line of text up to 1024 bytes. Repeat this for each diff.
While both of these are technically feasible, they are a bit wonky, and for large files would involve many requests. What I’m wondering is whether these are ideas worth considering — ways to upload files without extending or replacing Gemini. Any thoughts?
Skyjake linked something Solderpunk wrote about 1,5 years ago(https://lists.orbitalfox.eu/archives/gemini/2020/001672.html) inanother thread:
It should also be very easy to write an app targetted at "non-technical"
authors which lets them submit chunks of writing up to 2 KiB or so, with
an "append" link at the submission confirmation page to submit a follow
up chunk. It wouldn't necessarily be the smoothest experience in the
world, but if most content could be written in a single request and 99%
with one or two "append" requests, I think it would be usable enough.
Heck, this is the "slow internet", right? A little bit of inconvenience
as part of a careful and deliberate process should not scare us away.
In general, solving perceived problems with the limitations that Gemini
imposes by combining the "primitives" which are already there in
creative new ways, even if they are very slightly clunky, makes me far,
far happier than adding in additional more advanced features to remove
those limitations. If we discover really useful and generally
applicable constructions that can be built in this way, we can give them
names, standardise them, and clients can choose to impelement them in
ways which hide the clunkiness from the user. It would be wonderful,
though, if they were still usable in a clunky way by a knowledgable
users in clients which didn't support them explicitly.
What his and your ideas have in common is that they push complexity tothe client. In my opinion, this complexity should be in theserver-side application, keeping both servers and clients simple.Simplicity of client and server implementation is one of the coreideas of Gemini. If there are multiple competing clients and servers,each with at least some market share, this ensures that no client orserver can unilaterally extend the protocol or the gemtext format(with e.g. tracking, making multiple requests behind the user's backetc.). If a capsule - a wiki or a gemlog or whatever - decides toexpect chunked input or diffs that only certain clients can provide,then some clients will be "more equal than others", to quote aclassic.
But if we want the complexity of uploading/writing/editing content toreside in the application, and we also want to avoid the problemdetailed above, we have two options left:* Use a "back channel" different from Gemini (e.g. an HTTP API, Titan,FTP, etc.) to upload* Introduce a new, POST-like way to upload via the Gemini protocol itself.
While ideas to do the second have been consistently rejected in thepast, let me try to argue for why we should reconsider it. The FAQsays:
Alternative, simple-by-design protocols like Gopher and Gemini create
alternative, simple-by-design spaces with obvious boundaries and
hard restrictions. You know for sure when you enter Geminispace,
and you can know for sure and in advance when following a certain
link will cause you leave it. While you're there, you know for sure and
in advance that everybody else there is playing by the same rules. You
can relax and get on with your browsing, and follow links to sites you've
never heard of before, which just popped up yesterday, and be
confident that they won't try to track you or serve you garbage because
they *can't*. You can do all this with a client you wrote yourself, so you
*know* you can trust it. It's a very different, much more liberating and
much more empowering experience than trying to carve out a tiny,
invisible sub-sub-sub-sub-space of the web.
I believe this is another core value of Gemini - that it should be aself-contained space. But if the protocol itself doesn't allow asimple way to author content, people will need to either use backchannels or purpose-built clients that implement chunking, chunkeddiffs or whatever. If the protocol itself defined a (very simple butconvenient for both implementers and end-users) method to do so, itwould solve the self-containment problem. Making the protocol a tinybit more complex is well worth it in my opinion to avoid ad-hoc,convention-based client implementations that would make simplerclients incompatible with some server side apps (or at least extremelyinconvenient to use - you would need to manually chunk the content,create a diff etc.).
I'm relatively new to Geminispace so maybe this discussion has alreadybeen had. If so, please disregard what I wrote, I don't want to repeata debate that has already come to a conclusion.
What do you think?