Re: Uploading content over gemini

On Fri, Nov 12, 2021 at 5:03 AM Alex <alex@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
(gemini://gemi.dev/gemini-mailing-list/messages/001672.gmi) in
another 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 to
the client. In my opinion, this complexity should be in the
server-side application, keeping both servers and clients simple.
Simplicity of client and server implementation is one of the core
ideas of Gemini. If there are multiple competing clients and servers,
each with at least some market share, this ensures that no client or
server can unilaterally extend the protocol or the gemtext format
(with e.g. tracking, making multiple requests behind the user's back
etc.). If a capsule - a wiki or a gemlog or whatever - decides to
expect chunked input or diffs that only certain clients can provide,
then some clients will be "more equal than others", to quote a
classic.

But if we want the complexity of uploading/writing/editing content to
reside in the application, and we also want to avoid the problem
detailed above, we have two options left:

FTP, etc.) to upload


While ideas to do the second have been consistently rejected in the
past, let me try to argue for why we should reconsider it. The FAQ
says:

> 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 a
self-contained space. But if the protocol itself doesn't allow a
simple way to author content, people will need to either use back
channels or purpose-built clients that implement chunking, chunked
diffs or whatever. If the protocol itself defined a (very simple but
convenient for both implementers and end-users) method to do so, it
would solve the self-containment problem. Making the protocol a tiny
bit more complex is well worth it in my opinion to avoid ad-hoc,
convention-based client implementations that would make simpler
clients incompatible with some server side apps (or at least extremely
inconvenient 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 already
been had. If so, please disregard what I wrote, I don't want to repeat
a debate that has already come to a conclusion.

What do you think?

---

Previous in thread (1 of 7): 🗣️ Alex (alex (a) alexwennerberg.com)

Next in thread (3 of 7): 🗣️ Alex Schroeder (alex (a) alexschroeder.ch)

View entire thread.