URL/META length

I read a very interesting discussion between Petite Abeille,
Solderpunk, Luke Emmet 2-3 weeks ago, regarding how to upload small
content to Gemini servers (eg. wiki page updates, comments,...)

The idea revolves around using the URL to upload small content (or
chunked content in several requests)

Petite Abeille
gemini://gemi.dev/gemini-mailing-list/messages/001644.gmi

Solderpunk reply
gemini://gemi.dev/gemini-mailing-list/messages/001672.gmi

and Luke Emmet
gemini://gemi.dev/gemini-mailing-list/messages/001681.gmi

Quoting Solderpunk:

>Well, look - 1024 bytes as a maximum URL length is a value I more or
less plucked out of the air without deep consideration, simply because
the elements passed around by a protocol *should* have a well-defined
maximum length so people can allocate appropriately sized memory
buffers, etc.  I certainly *wasn't* thinking about using queries to
upload content, I was thinking of "ordinary URLs" and so 1024 bytes
seemed hugely generous.

> According to GUS, currently more than half of the text/gemini content
out there is less than 1.2 KiB in size.  If URLs were allowed to be 2048
bytes long, all that content could be uploaded as a query.

> Can we solve a lot of these issues by bumping up our maximum URL length?

I suggest bumping the URL maximum length to 8KB.

- it allows creative uses of _mechanisms already in place_ in Gemini,
- it doesn't change the definition of the protocol and protocol elements,
- it doesn't impact existing clients,
- the impact on existing servers is very limited (allocating a 8K
instead of 1K buffer...), and an existing server should just refuse
too long a request.
- 8K vs 1K doesn't make a difference for a client today in terms of
RAM footprint - after all, let's not forget that TLS is mandatory here
;-)

What do you think?

Phil

On Sat, Jul 04, 2020 at 07:17:37PM +0000, Phil Leblanc wrote:
 
> > Can we solve a lot of these issues by bumping up our maximum URL length?
> 
> I suggest bumping the URL maximum length to 8KB.
> 
> - it allows creative uses of _mechanisms already in place_ in Gemini,
> - it doesn't change the definition of the protocol and protocol elements,
> - it doesn't impact existing clients,
> - the impact on existing servers is very limited (allocating a 8K
> instead of 1K buffer...), and an existing server should just refuse
> too long a request.
> - 8K vs 1K doesn't make a difference for a client today in terms of
> RAM footprint - after all, let's not forget that TLS is mandatory here
> ;-)

I'm still open to something like this.  And for the record, I still
think the idea of "uploading by hosting" and passing the URL used for
that in response to a status code 10 is too beautiful not to explore, if
we really, really need to be able to upload in band.  I get that not
everybody can host publically, but this could be worked around in
various ways: pubnixes could offer this facility to their users.
Somebody could setup a lightweight public web upload point which
then rehosted the resource one a one-use Gemini URL - Sloum has already
demonstrated with gemlog.blue how this kind of thing can work.

Cheers,
Solderpunk

On Sat, Jul 4, 2020 at 9:33 PM solderpunk <solderpunk at sdf.org> wrote:

> > > Can we solve a lot of these issues by bumping up our maximum URL length?
>
> I'm still open to something like this.  And for the record, I still
> think the idea of "uploading by hosting" and passing the URL used for
> that in response to a status code 10 is too beautiful not to explore, if
> we really, really need to be able to upload in band.

A longer URL doesn't prevent at all exploring / implementing  the
uploading by hosting approach. It only addresses some use cases where
the existing input mechanism can be used as-is (e.g. comments, small
document updates).

I think it could also be useful for simple gemini applications,
typically the applications "by me, for me" you describe here
=>gemini://gemini.circumlunar.space/users/solderpunk/cornedbeef/a-vision-fo
r-gemini-applications.gmi

It is _not_ a modification in any way of the Gemini protocol - Just a
different size limit.

Phil

On Sat, Jul 04, 2020 at 09:59:23PM +0000, Phil Leblanc wrote:
> On Sat, Jul 4, 2020 at 9:33 PM solderpunk <solderpunk at sdf.org> wrote:
> 
> A longer URL doesn't prevent at all exploring / implementing  the
> uploading by hosting approach. It only addresses some use cases where
> the existing input mechanism can be used as-is (e.g. comments, small
> document updates).
> 
> It is _not_ a modification in any way of the Gemini protocol - Just a
> different size limit.

Sure, I get all that, didn't mean to imply otherwise.

Just doing "my thing" of urging people to think hard about and perhaps
even actually implement and test solutions to problems which don't
involve extension/modification in preference to those which do...

Cheers,
Solderpunk