[announce] Delegation of responsibility for spec finalisation

Solderpunk <solderpunk (a) posteo.net>

Howdy Geminauts,

The first quarter of 2021 is passing by rapidly, with less progress on
finalising the few outstanding spec questions before the process of
translating the specification to a more precise and formal format
suitable for standardisation than I had hoped for.

It has become clear to me that for a variety of reasons I am no longer
able to effectively lead this process myself.  Therefore, effective as
of the sending of this email, I am delegating decision-making authority
for finalising the spec to Sean Conner <sean at conman.org>.

There is no change in my long-standing overall stance that Gemini
requires no new features and that remaining work on the specification
should be directed only toward addressing edge cases, removing
ambiguities and increasing overall consistency.  Several issues of this
type have been in discussion on the mailing list for some time now, and
I am empowering Sean to resolve those issues, not to add new features or
make other major changes.  I reserve the right to veto Sean's decisions,
but I don't expect to need to.

Sean is a natural choice for me to delegate this task to.  He has been
involved in the development of the Gemini specification for longer than
anybody other than myself - he was the first person to actually
implement the protocol in software, transforming it from the largely
academic thought experiment that I had created it as into an actual real
world project.  He is the developer of a Gemini server (GLV-1.12556) and
the admin of a server running it (gemini://gemini.conman.org), which
means the details of the specification are of direct and practical
relevance to him.  He has a long-standing presence in Gopherspace, where
the Gemini project was born, and therefore understands and appreciates
the value of simple-by-design systems with limited scope.  Finally, he
has an excellent track record of constructively engaging with the
mailing list even at its busiest and most frantic, which certainly can
no longer be said for me.  For all these reasons I trust him to make
good decisions on the basis of careful consideration.

I am hopeful that this change will bring us more quickly to a point
where there is no more need for decision making and just the slow, quiet
work of formalisation.  I still hope to be actively involved in that
process myself.

Cheers,
Solderpunk

Link to individual message.

Petite Abeille <petite.abeille (a) gmail.com>



> On Feb 28, 2021, at 13:02, Solderpunk <solderpunk at posteo.net> wrote:
> 
> It has become clear to me that for a variety of reasons I am no longer
> able to effectively lead this process myself.  Therefore, effective as
> of the sending of this email, I am delegating decision-making authority
> for finalising the spec to Sean Conner <sean at conman.org>.

Bravo, and congrats to both!

?0?

Link to individual message.

Sean Conner <sean (a) conman.org>

It was thus said that the Great Solderpunk once stated:
> Howdy Geminauts,

  Greetings and salutations, Geminauts.

> It has become clear to me that for a variety of reasons I am no longer
> able to effectively lead this process myself.  Therefore, effective as
> of the sending of this email, I am delegating decision-making authority
> for finalising the spec to Sean Conner <sean at conman.org>.

  I've been spending the day catching up on the list and thnking about what
needs to be done.  St?phane Bortzmeyer suggested setting up an issue tracker
at some place like Gitlab, and I've done just that.  I set up two
repositories there:

	https://gitlab.com/gemini-specification/protocol
	https://gitlab.com/gemini-specification/gemini-text

to track issues related to the protocol and the text format.  I split them
in two because it made sense to me---the issues of the protocol are largely
orthogonal to that of text/gemini and not everyone has interest in both.  A
bit long term is to split the Gemini specification into two along those
lines, so those that want to discuss content generation don't have to wade
through technobabble of networks and ports and oh my!  

  I've created a few issues already, but gitlab is apparently having issues
of its own right now, so for now, the mailing list is still the place to
bring these up.  Anyway, while I'm here I might as well weigh in on some of
the current proposals.

  First up is favicon.txt.  In my opinion, it does NOT violate the letter of
the spec, given that it doesn't require any changes to the protocol or
text/gemini.  It could be argued that it violates the spirit of the spec,
but I am not willing to endorce nor condemn it.  My decision would be that
clients can support it, but it MUST be disabled by default and require user
intervention in some form to enable it.  On the flip side, those who run
Gemini servers MAY configure their server to return "52 Gone" for requests
to "/facicon.txt" if they do not want to participate in such nonsense (thank
God I was able to convince Solderpunk to add this reponse code back in the
day).  Clients that receive a "52 Gone" for such a request SHOULD NOT make
another request for it.  But those who run Gemini servers SHOULD NOT expect
to see no further requests from a given IP address---there might be several
people sharing an IP, or one user might be using multiple clients.  The
whole intent of serving up a "52 Gone" is to add said server to a list of
servers not to query.  Yes, this is more of an "opt-out" than "opt-in"
situation, but it's hard to opt in to a feature when it's distributed.  This
can be extended to further requests of a similar nature should they come up
[1].  I would like to ask Michael Lazar to please add these changes to his
favicon.txt specification to let others know of the options available.

  Second, alt-text for preformatted blocks.  The original spec did not allow
any text past the "```".  It was later changed for reasons of accessibility,
but intentionally left ambiguous for a consensus to form around it.  I think
disallowing text on the closing "```" is too excessive and I will most
likely rescind that decision to allow more options.  But as for specifying
an actual format in the specification?  No.  Best practice, yes, but a solid
convention needs to arise first.

  Third, meta data for text/gemini.  Again, like alt-text for preformatted
blocks, this isn't something for the specification.  Again, it would be best
for the community to define a convention first.  My own opinion here is that
meta data is always nice (Lord knows I have enough in my blog [2]) but
having been through the "Sematic Web" era, not enough content creators care
enough to actually do the work.

  Fourth, I would like to state that newcomers to the mailing list might not
be aware of the history and context that Gemini was developed in, and think
of Gemini as a "stripped down web" instead of the "souped up gopher" that it
is.  Please keep that in mind as new people make proposals, and instead of a
"No" with no further conversation, say "No, because here's how you could do
it" or "No, because we want a privacy-first stance".  In other words,
explain why the "no".  Or, if nothing constructive comes to mind, don't say
anything and let the proposal die quietly.  

  -spc

[1]	This concept will be added to the "Best Practices" document.

[2]	Check the source for http://boston.conman.org/

Link to individual message.

Petite Abeille <petite.abeille (a) gmail.com>



> On Mar 1, 2021, at 03:48, Sean Conner <sean at conman.org> wrote:
> 
>  Greetings and salutations, Geminauts.

Hail to the Chief we have chosen for the nation,
Hail to the Chief! We salute him, one and all.
Hail to the Chief, as we pledge cooperation
In proud fulfillment of a great, noble call.
Yours is the aim to make this grand country grander,
This you will do, that is our strong, firm belief.
Hail to the one we selected as commander,
Hail to the President!
Hail to the Chief!
Hail to the Chief we have chosen for the nation,
Hail to the Chief! We salute him, one and all.
Hail to the Chief, as we pledge cooperation
In proud fulfillment of a great, noble call.

:D

?0?

Link to individual message.

Petite Abeille <petite.abeille (a) gmail.com>



> On Mar 1, 2021, at 03:48, Sean Conner <sean at conman.org> wrote:
> 
> Anyway, while I'm here I might as well weigh in on some of
> the current proposals.

While you are at it... what about the URI ?? IRI mega thread of  yore?

What's the current thinking, if any?

?0?

Link to individual message.

Stephane Bortzmeyer <stephane (a) sources.org>

On Sun, Feb 28, 2021 at 09:48:38PM -0500,
 Sean Conner <sean at conman.org> wrote 
 a message of 79 lines which said:

> I set up two repositories there:
> 
> 	https://gitlab.com/gemini-specification/protocol
> 	https://gitlab.com/gemini-specification/gemini-text

Great. Can we assume that, when an issue will be closed, the text of
the specification in
<https://gitlab.com/gemini-specification/protocol/-/blob/master/specification.gmi>
will be changed too so we can be sure that
<https://gitlab.com/gemini-specification/protocol/-/blob/master/specification.gmi>
is really the current state of the work?

Link to individual message.

Sean Conner <sean (a) conman.org>

It was thus said that the Great Petite Abeille once stated:
> 
> 
> > On Mar 1, 2021, at 03:48, Sean Conner <sean at conman.org> wrote:
> > 
> > Anyway, while I'm here I might as well weigh in on some of
> > the current proposals.
> 
> While you are at it... what about the URI ?? IRI mega thread of  yore?
> 
> What's the current thinking, if any?

  My current thinking is a switch to IRI once some details are ironed out. 
People who are concerned about this can voice their concerns on the list
here, or (more preferrably) in the issue tracker for this:

	https://gitlab.com/gemini-specification/protocol/-/issues/1

  Rational:  Since Gemini is geared around UTF-8, it's weird that the only
aspect that currently can't be UTF-8 are links.  The change from URI to IRI
is pretty minimal except for the use of IDN (International Domain Names) and
DNS resolution.

  -spc

Link to individual message.

Sean Conner <sean (a) conman.org>

It was thus said that the Great Stephane Bortzmeyer once stated:
> On Sun, Feb 28, 2021 at 09:48:38PM -0500,
>  Sean Conner <sean at conman.org> wrote 
>  a message of 79 lines which said:
> 
> > I set up two repositories there:
> > 
> > 	https://gitlab.com/gemini-specification/protocol
> > 	https://gitlab.com/gemini-specification/gemini-text
> 
> Great. Can we assume that, when an issue will be closed, the text of
> the specification in
> <https://gitlab.com/gemini-specification/protocol/-/blob/master/specification.gmi>
> will be changed too so we can be sure that
> <https://gitlab.com/gemini-specification/protocol/-/blob/master/specification.gmi>
> is really the current state of the work?

  That is the intent yes.  For both the protocol and Gemini text
specifications.

  -spc

Link to individual message.

Scot <gmi1 (a) scotdoyle.com>

On 2/28/21 8:48 PM, Sean Conner wrote:
>
>    I've created a few issues already, but gitlab is apparently having issues
> of its own right now, so for now, the mailing list is still the place to
> bring these up.  Anyway, while I'm here I might as well weigh in on some of
> the current proposals.

Regarding Gitlab issue #2 "TLS Close", may we ease client and
server implementations by:

1. Not requiring client applications to send TLS close_notify,
since they indicate end-of-data via the request <CR><LF> ?

2. Only requiring server applications to send TLS close_notify
if all data has been sent? If the TCP or TLS connection is
interrupted by the client or by an intermediary before the server
application has transmitted all of its data, there doesn't
seem to be a benefit to sending a close_notify to the client
and it could also cause various delays which prohibit the server
application from moving on to other work. For example, an
unending streaming response would be closed by the client,
in which case there is no need for a close_notify from the server.

Link to individual message.

Alex // nytpu <alex (a) nytpu.com>

On 2021-03-01 03:18PM, Scot wrote:
> 1. Not requiring client applications to send TLS close_notify, since
> they indicate end-of-data via the request <CR><LF> ?

See this quote from the TLS 1.3 spec:
> Each party MUST send a "close_notify" alert before closing its write
> side of the connection, unless it has already sent some error alert.
> This does not have any effect on its read side of the connection.
https://tools.ietf.org/html/rfc8446#section-6.1 - TLS 1.3

The effect of this is that clients MUST send close_notify after writing
their a request in order to properly comply with TLS 1.3.  I would
operate under the assumption that a server would not send a response
until a close_notify is received (or the request would be allowed to
time out).  Obviously a robust server would work without a close_notify,
but you should still operate within the spec because I'm wouldn't be
surprised if at least one or two TLS implementations require it.

There's even stronger wording for TLS 1.2 which requires a close_notify
after writing is completed and for /both/ the sending and receiving
parties to send a close_notify after the transaction is completed, so
the client would have to send a close_notify after the both request and
the response, not just the request.
See: https://tools.ietf.org/html/rfc5246#section-7.2.1


On 2021-03-01 03:18PM, Scot wrote:
> 2. Only requiring server applications to send TLS close_notify if all
> data has been sent? If the TCP or TLS connection is interrupted by the
> client or by an intermediary before the server application has
> transmitted all of its data, there doesn't seem to be a benefit to
> sending a close_notify to the client and it could also cause various
> delays which prohibit the server application from moving on to other
> work. For example, an unending streaming response would be closed by
> the client, in which case there is no need for a close_notify from the
> server.

The whole point of close_notify is to indicate that the write has
successfully been completed.  I may be misunderstanding your question,
but if the connection is interrupted then a close_notify should not be
sent, as that would erroneously report that the transaction was
successfully completed.  For streaming data I assume that it would be
properly terminated by the client closing the connection since the data
is never completely sent (it's unending).


I'm no TLS expert, I'm just reporting what I found after skimming the
TLS RFCs, feel free to correct me if I'm wrong here.

~nytpu

-- 
Alex // nytpu
alex at nytpu.com
GPG Key: https://www.nytpu.com/files/pubkey.asc
Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B
https://useplaintext.email/

Link to individual message.

Petite Abeille <petite.abeille (a) gmail.com>



> On Mar 1, 2021, at 22:09, Sean Conner <sean at conman.org> wrote:
> 
>  My current thinking is a switch to IRI once some details are ironed out. 

Fantastic.

Second question: is there any reasonable way to decouple the Transport 
Layer Security requirement from the Gemini protocol itself?

?0?

Link to individual message.

Scot <gmi1 (a) scotdoyle.com>

On 3/1/21 4:26 PM, Alex // nytpu wrote:
> On 2021-03-01 03:18PM, Scot wrote:
>> 1. Not requiring client applications to send TLS close_notify, since
>> they indicate end-of-data via the request <CR><LF> ?
> See this quote from the TLS 1.3 spec:
>> Each party MUST send a "close_notify" alert before closing its write
>> side of the connection, unless it has already sent some error alert.
>> This does not have any effect on its read side of the connection.
> https://tools.ietf.org/html/rfc8446#section-6.1 - TLS 1.3
>
> The effect of this is that clients MUST send close_notify after writing
> their a request in order to properly comply with TLS 1.3.  I would
> operate under the assumption that a server would not send a response
> until a close_notify is received (or the request would be allowed to
> time out).  Obviously a robust server would work without a close_notify,
> but you should still operate within the spec because I'm wouldn't be
> surprised if at least one or two TLS implementations require it.
>
> There's even stronger wording for TLS 1.2 which requires a close_notify
> after writing is completed and for /both/ the sending and receiving
> parties to send a close_notify after the transaction is completed, so
> the client would have to send a close_notify after the both request and
> the response, not just the request.
> See: https://tools.ietf.org/html/rfc5246#section-7.2.1
>

Hi Alex. I would like to follow the RFC too.

After writing C and Python client and server implementations
last fall, and examing packet traces, my conclusion was that
this does not work with most TLS libraries. Mostly, they will
close the connection in both directions if they receive a
close_notify. Some of this is documented here [1]. This in
turn causes problems for programming languages which
expect a given library to behave in a certain way. For example,
Python still does not allow sending a close_notify from the
client after the request has been delivered and before
receiving the response [2].

So, in my opinion, the simplest thing would be to utilize the
<CR><LF> of the Gemini request to indicate that the client
is finished sending its request.

Three benefits of this approach would be:

1. All Gemini clients will keep working right now without changes

2. Because the <CR><LF> can be explicitely sent by a client
application and explicetely examined by the server application,
without broken TLS libraries intervening, it is easy to correctly
implement

3. Gemini client authors will not experience intense frustration
at the sad state of TLS library support for half-open close_notify
(this is the voice of experience speaking...)

> On 2021-03-01 03:18PM, Scot wrote:
>> 2. Only requiring server applications to send TLS close_notify if all
>> data has been sent? If the TCP or TLS connection is interrupted by the
>> client or by an intermediary before the server application has
>> transmitted all of its data, there doesn't seem to be a benefit to
>> sending a close_notify to the client and it could also cause various
>> delays which prohibit the server application from moving on to other
>> work. For example, an unending streaming response would be closed by
>> the client, in which case there is no need for a close_notify from the
>> server.
> The whole point of close_notify is to indicate that the write has
> successfully been completed.  I may be misunderstanding your question,
> but if the connection is interrupted then a close_notify should not be
> sent, as that would erroneously report that the transaction was
> successfully completed.  For streaming data I assume that it would be
> properly terminated by the client closing the connection since the data
> is never completely sent (it's unending).
>

Yes I agree. It doesn't matter to me how it is worded, as
long as its clear that a close_notify doesn't need to be sent
from the server to the client unless the server application
has been able to send all data that it wants to send first. So
in the case of streaming, since the server didn't reach the end
of the unending data stream, it would not send close_notify, it
would just immediately close the TCP connection.

[1] https://github.com/openssl/openssl/issues/11378
[2] https://bugs.python.org/issue39951

Link to individual message.

Sean Conner <sean (a) conman.org>

It was thus said that the Great Scot once stated:
> 
> 3. Gemini client authors will not experience intense frustration
> at the sad state of TLS library support for half-open close_notify
> (this is the voice of experience speaking...)

  Frankly, half-open is borked for TCP pretty much as well, due to the
semantics and operation of the Bezerkly sockets API, so that's not new.

  -spc

Link to individual message.

Sean Conner <sean (a) conman.org>

It was thus said that the Great Petite Abeille once stated:
> 
> > On Mar 1, 2021, at 22:09, Sean Conner <sean at conman.org> wrote:
> > 
> >  My current thinking is a switch to IRI once some details are ironed out. 
> 
> Fantastic.
> 
> Second question: is there any reasonable way to decouple the Transport
> Layer Security requirement from the Gemini protocol itself?

  Short answer:  no.

  Long anser:  If you want to explore alternative transport security
methods, go to town with an implementation, get the crypto community to pass
it and *then* present it to the Gemini community.  At that point, the
discussion can commence.

One of the primary motivations of Gemini was adding TLS to gopher, and to
avoid the whole http: vs https: that infests the web.

  -spc

Link to individual message.

Scot <gmi1 (a) scotdoyle.com>

On 3/1/21 6:45 PM, Sean Conner wrote:
> It was thus said that the Great Scot once stated:
>> 3. Gemini client authors will not experience intense frustration
>> at the sad state of TLS library support for half-open close_notify
>> (this is the voice of experience speaking...)
>    Frankly, half-open is borked for TCP pretty much as well, due to the
> semantics and operation of the Bezerkly sockets API, so that's not new.
>
>    -spc

I do vaguely recall seeing some funny things at the TCP level in
those packet traces.

If so, that could be be another reason to not require the server
to send close_notify unless it is able to send all the data first.

Link to individual message.

Sean Conner <sean (a) conman.org>


  To give the "TLS close" issue some context:  The Gemini protocol does not
indicate how big a given response is, mimicking gopher and the very early
HTTP protocol.  In gopher with a non-binary file being transferred, a "." on
a line by itself indicates "end-of-file" and for binary files, it's up to
the client to keep reading until the stream is closed (RFC-1436 states as
much: " Note that for type 5 or type 9 the client must be prepared to read
until the connection closes.  There will be no period at the end of the file
...").  Gemini inherited this model and no attempts to include a reponse
size has been accepted.

  So, all a client has to go by in Gemini that a file was sent correctly, is
to wait for the server to close its side of the connection, as signaled by a
"TLS close".  This means that issues with the network between the two
endpoints (a router crash) are caught, as well as the server crashing before
it can send a "TLS close."

  Then someone noticed that TLS include semantics of "this side is closed"
and thus, why the server is expected to close the connection, not the
client.  Also, it was never an expectation that the client close its side
after making a request.

  Hopefully, this provides enough background on this topic from a Gemini
perspective.

  -spc

Link to individual message.

Juan J. Martinez <jjm (a) usebox.net>



On 02/03/2021 00:23, Scot wrote:
>[...]
> 
> After writing C and Python client and server implementations
> last fall, and examing packet traces, my conclusion was that
> this does not work with most TLS libraries. Mostly, they will
> close the connection in both directions if they receive a
> close_notify. Some of this is documented here [1]. This in
> turn causes problems for programming languages which
> expect a given library to behave in a certain way. For example,
> Python still does not allow sending a close_notify from the
> client after the request has been delivered and before
> receiving the response [2].
> 
> So, in my opinion, the simplest thing would be to utilize the
> <CR><LF> of the Gemini request to indicate that the client
> is finished sending its request.
> 
> Three benefits of this approach would be:
> 
> 1. All Gemini clients will keep working right now without changes
> 
> 2. Because the <CR><LF> can be explicitely sent by a client
> application and explicetely examined by the server application,
> without broken TLS libraries intervening, it is easy to correctly
> implement
> 
> 3. Gemini client authors will not experience intense frustration
> at the sad state of TLS library support for half-open close_notify
> (this is the voice of experience speaking...)

I'm not in any way a TLS expert, but I think you're right: TLS 1.2 uses 
a duplex-close policy (while TLS 1.3 uses a half-close policy, so that 
should work better).

IMHO the spec should probably refer to the RFC when available and 
perhaps make a recommendation, but getting into specific details on how 
the TLS implementation must behave is hairy and probably not practical.

As long as the spec is clear, real world can differ and still work, and 
that's OK.

Regards,

Juan

-- 
Website: usebox.net/jjm/
Twitter: @reidrac

Link to individual message.

Petite Abeille <petite.abeille (a) gmail.com>



> On Mar 2, 2021, at 01:52, Sean Conner <sean at conman.org> wrote:
> 
>> Second question: is there any reasonable way to decouple the Transport
>> Layer Security requirement from the Gemini protocol itself?
> 
>  Short answer:  no.

Let me rephrase the question: would it be possible to edit the Gemini 
specification in such a way that it makes TLS a SHOULD, not a MUST.

This is purely an editorial adjustment, which would leave the door open 
for alternative transport layer  beside TLS.

Thoughts?

?0?

Link to individual message.

Sean Conner <sean (a) conman.org>

It was thus said that the Great Petite Abeille once stated:
> 
> > On Mar 2, 2021, at 01:52, Sean Conner <sean at conman.org> wrote:
> > 
> >> Second question: is there any reasonable way to decouple the Transport
> >> Layer Security requirement from the Gemini protocol itself?
> > 
> >  Short answer:  no.
> 
> Let me rephrase the question: would it be possible to edit the Gemini
> specification in such a way that it makes TLS a SHOULD, not a MUST.
> 
> This is purely an editorial adjustment, which would leave the door open
> for alternative transport layer beside TLS.
> 
> Thoughts?

  If you want to explore alternative transport security methods, go to town
with an implementation, get the crypto community to pass it and *then*
present it to the Gemini community.  At that point, the discussion can
commence.

  Until such time and discussion show the new method to be viable, safe and
easy to implement, TLS will remain a MUST.  I do NOT want to encourage
anyone to create some halfbaked crypto scheme and make things worse.

  -spc

Link to individual message.

Petite Abeille <petite.abeille (a) gmail.com>



> On Mar 2, 2021, at 09:21, Sean Conner <sean at conman.org> wrote:
> 
> I do NOT want to encourage anyone to create some half-baked crypto 
scheme and make things worse.

Very motherly of you. Thank you for your concern. :)

As already mentioned several times over the last several months: in my 
case, everything runs over wireguard+tailscale [1][2] ? making TLS 
redundant and unwelcome.

"Remembering the LAN" explains the operating principle:
https://tailscale.com/blog/remembering-the-lan/

In short, this is not about (re)inventing some "half-baked crypto", but 
rather to use existing ones, which happen not to be TLS at all.

No drama though... I do not mind one way or another as for as Gemini goes 
? I have fully moved on and adopted+adapted Mercury for my own needs.

Just thought it would be polite to explicitly point out the corner you are 
painting yourself into :)

No worries though... all good :)

Wish you a very pleasant day.

[1] https://en.wikipedia.org/wiki/WireGuard
[2] https://tailscale.com/blog/how-tailscale-works/

?0?

Link to individual message.

Sean Conner <sean (a) conman.org>

It was thus said that the Great Petite Abeille once stated:
> 
> 
> > On Mar 2, 2021, at 09:21, Sean Conner <sean at conman.org> wrote:
> > 
> > I do NOT want to encourage anyone to create some half-baked crypto 
scheme and make things worse.
> 
> Very motherly of you. Thank you for your concern. :)
> 
> As already mentioned several times over the last several months: in my
> case, everything runs over wireguard+tailscale [1][2] ? making TLS
> redundant and unwelcome.

  I only have one question for you then---IF I allowed TLS to be optional,
how would a client know to use TLS, Wireguard or say, Tor?

> Just thought it would be polite to explicitly point out the corner you are
> painting yourself into :)
> 
> No worries though... all good :)

  Good luck with your endevours.  And if I find myself painted into a corner
with Gemini, I know who to call.

  -spc

> [1] https://en.wikipedia.org/wiki/WireGuard
> [2] https://tailscale.com/blog/how-tailscale-works/

Link to individual message.

Petite Abeille <petite.abeille (a) gmail.com>



> On Mar 2, 2021, at 10:32, Sean Conner <sean at conman.org> wrote:
> 
> how would a client know to use TLS, Wireguard or say, Tor?

multiaddr + dns-sd for example

> And if I find myself painted into a corner with Gemini, I know who to call.

Reasonable people can agree to disagree :)

Link to individual message.

Stephane Bortzmeyer <stephane (a) sources.org>

On Tue, Mar 02, 2021 at 04:32:05AM -0500,
 Sean Conner <sean at conman.org> wrote 
 a message of 28 lines which said:

> I only have one question for you then---IF I allowed TLS to be
> optional, how would a client know to use TLS, Wireguard or say, Tor?

Note that HTTP has this issue (HTTP 1.1? 1.2? Soon 1.3 which does not
even use TCP?) It is "solved" by some mixture of signaling in the DNS
<https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/>,
redirection when possible (Alt-Svc:) and intelligent guessing, probing
and memorization by the client.

Link to individual message.

Petite Abeille <petite.abeille (a) gmail.com>



> On Mar 2, 2021, at 18:26, Stephane Bortzmeyer <stephane at sources.org> wrote:
> 
> Note that HTTP has this issue (HTTP 1.1? 1.2? Soon 1.3 which does not
> even use TCP?) It is "solved" by some mixture of signaling in the DNS
> <https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/>,
> redirection when possible (Alt-Svc:) and intelligent guessing, probing
> and memorization by the client.

wow. and we thought we had problems. well done http!

?0?

Link to individual message.

Stephane Bortzmeyer <stephane (a) sources.org>

On Mon, Mar 01, 2021 at 07:52:41PM -0500,
 Sean Conner <sean at conman.org> wrote 
 a message of 22 lines which said:

>   Long anser:  If you want to explore alternative transport security
> methods, go to town with an implementation, get the crypto community to pass
> it and *then* present it to the Gemini community.  At that point, the
> discussion can commence.
> 
> One of the primary motivations of Gemini was adding TLS to gopher, and to
> avoid the whole http: vs https: that infests the web.

Note that we may have to address the QUIC issue. The RFCs on QUIC (a
transport protocol, alternative to TCP, with mandatory crypto) are
almost published, and we may have to consider wether to use it. QUIC
is very targeted towards the Web (for instance with multiplexing
because, unlike Gemini, Web pages are made of several resources) so it
may be better to ignore it, that's something to think about.

Link to individual message.

Sean Conner <sean (a) conman.org>

It was thus said that the Great Stephane Bortzmeyer once stated:
> On Mon, Mar 01, 2021 at 07:52:41PM -0500,
>  Sean Conner <sean at conman.org> wrote 
>  a message of 22 lines which said:
> 
> >   Long anser:  If you want to explore alternative transport security
> > methods, go to town with an implementation, get the crypto community to pass
> > it and *then* present it to the Gemini community.  At that point, the
> > discussion can commence.
> > 
> > One of the primary motivations of Gemini was adding TLS to gopher, and to
> > avoid the whole http: vs https: that infests the web.
> 
> Note that we may have to address the QUIC issue. The RFCs on QUIC (a
> transport protocol, alternative to TCP, with mandatory crypto) are
> almost published, and we may have to consider wether to use it. QUIC
> is very targeted towards the Web (for instance with multiplexing
> because, unlike Gemini, Web pages are made of several resources) so it
> may be better to ignore it, that's something to think about.

  My stance on QUIC is the same replacing TLS.  When someone finally gets
Gemini running over QUIC, then we can discuss it.  Until then, there's
nothing to discuss.  Besides, I doubt the Gemini community will go for it
(famous last words).

  -spc

Link to individual message.

Petite Abeille <petite.abeille (a) gmail.com>



> On Mar 2, 2021, at 19:58, Sean Conner <sean at conman.org> wrote:
> 
> I doubt the Gemini community

Is the "community" sentient? Or is it more of a turn of phrase, such as 
"Company Policy"? Or perhaps ?That?s the Way We Do Things Around Here??

?That?s the Way We Do Things Around Here?: An Overview of Organizational Culture
M. Jason Martin, Spring 2006
https://digitalcommons.unl.edu/cgi/viewcontent.cgi?article=1060&context=ejasljournal

?0?

Link to individual message.

Bradley D. Thornton <Bradley (a) NorthTech.US>



On 3/2/2021 10:58 AM, Sean Conner wrote:

> 
>   My stance on QUIC is the same replacing TLS.  When someone finally gets
> Gemini running over QUIC, then we can discuss it.  Until then, there's
> nothing to discuss.  Besides, I doubt the Gemini community will go for it
> (famous last words).
> 
>   -spc
> 

One of the reasons I most admire your tact and approach to opportunities
for solutions (aka: problems).

"Show me. If it works, then let's talk."

Case in point: BBN. Yeah, the IP stack that didn't stack up. Bill Joy is
famous for answering the question posed to him with, "It's simple. You
just read the specs and write the code" (paraphrased, of course).

I'm confident that Solderpunk found this about your character as an
important reason why he delgated AUTH to you for this part of the
project. You put your keyboard where everyone's discussions were and
wrote https://github.com/spc476/GLV-1.12556

It makes for a strong point of advocation when this happens, for pretty
much anything.

Kindest regards,


-- 
Bradley D. Thornton
Manager Network Services
http://NorthTech.US
TEL: +1.310.421.8268

Link to individual message.

---

Previous Thread: [announce] Website and FAQ changes

Next Thread: Alt text and media types for preformatted text