💾 Archived View for gemi.dev › gemini-mailing-list › 000816.gmi captured on 2023-11-04 at 13:07:49. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Over at Gitlab, people are discussing [1] a potential deprecation of status code 11 (sensitive input). A few points. Firstly, for certain (possibly many) use cases password authentication (combined with shorter- or longer-lived "session" client certificates) is the right choice over only using client certificates. Some examples I could quickly think of:
On Sat, Mar 13, 2021 at 09:03:30PM +0100, PJ vM wrote: > Over at Gitlab, people are discussing [1] a potential deprecation of > status code 11 (sensitive input). A few points. > > Firstly, for certain (possibly many) use cases password authentication > (combined with shorter- or longer-lived "session" client certificates) > is the right choice over only using client certificates. Some examples I > could quickly think of: > > * a Gemini interface to a service for which the user already has login > credentials (and other cases where one needs to confirm the user is the > same as an identity previously established by other means than a > certificate) > * any use case for which client certs are simply not portable enough > * the equivalent of "changing one's password" seems (not certain about > this) quite tedious to do in a world with only client certs, for use > cases where the users are pseudonymous Agree, especially that it's easier memorize an even complex password than a client cert if you use different machines. > It seems clear to me that login credentials and certs are sufficiently > different in practical aspects that certs cannot replace password > authentication for all use cases. > > So, and this is really my key point: whether one likes it or not, I > think password authentication will keep being used as long as there is a > way to give input to the server. > > Secondly, let's look at why exactly it is considered a bad idea to put > sensitive information in a URL. The reasons given by RFC 3986 ?7.5 > (quoted at the Gitlab issue) are: > > > URIs are frequently displayed by browsers, stored in clear text > > bookmarks, and logged by user agent history and intermediary > > applications (proxies) > The last problem can be avoided by not using relay-type proxies (by > which I mean proxies where the TLS connection is with the proxy rather > than with the destination). Note that all the other problems can be > addressed by client software IF it's possible to distinguish between > sensitive and non-sensitive input. When the server sends 11, the client > can hide the input the user is typing, and throw away the query after > sending the request, before displaying the URL in the URL bar or saving > it in the browsing history. Agree. Gemini universe can come up with smart enough clients without a lot of technical complexity. > So actually, if we reason from the assumption that password > authentication will happen anyway (as I've argued above), removing > status code 11 has rather negative consequences, as it removes the > ability to distinguish between sensitive and non-sensitive input. Agree. > My conclusion is that removing status code 11 would be unwise, and > instead it would be better to include a recommendation in the best > practices document to throw away the query part after sending a request > that results from user input on a 11 page. Maybe there should also be a > recommendation to store client certs in a password-encrypted vault, as > of course storing long-lived certs unencrypted is about as much of a > problem as storing sensitive queries in the browsing history. > Thirdly and lastly, about Gitlab. I strongly dislike the fact that > discussions which can have quite an impact on all Gemini users are > happening in Gitlab issues; to stay up-to-date on all these requires > regularly going through multiple webpages, and to comment requires a > Gitlab account! I think this is a mistake. Agree, even with this one. > Please excuse the length of this email. > > [1] https://gitlab.com/gemini-specification/protocol/-/issues/17 > > -- > pjvm I agree pretty much entirely with pjvm's points.
On Sat, Mar 13, 2021 at 08:30:19PM -0700, Thomas Frohwein <tfrohwein at fastmail.com> wrote a message of 79 lines which said: > > Thirdly and lastly, about Gitlab. I strongly dislike the fact that > > discussions which can have quite an impact on all Gemini users are > > happening in Gitlab issues; to stay up-to-date on all these > > requires regularly going through multiple webpages, and to comment > > requires a Gitlab account! I think this is a mistake. > > Agree, even with this one. Group work is funny. When the discussion on the specification was on the mailing list, everybody complained that it made a lot of messages, that it was difficult to follow, to know for sure what was decided or not, etc. (I did share some of these complaints but not all; many problems were simply because some people do not use some features of their email client, such as threading and full-text search.) Nobody defended the mailing list and asked for the specification discussion to remain there. Now that we moved to another system, people (but may be not the same) complain about the new system. My (long) experience with "groupware" is that it is impossible to find a solution that will please everyone. I just note that an issue tracking system is used by some SDO (for instance the IETF) with success. (And, of course, it is used by many programming teams.) Regarding Gitlab, there is not yet (I regret it) a well-known and widely used decentralized issue tracking system allowing not to have an account of the central system. (There are many experiments, but nothing solid yet.) So, it had to be a centralized system. We may discuss about gitlab vs. gitea and about one given gitlab hoster vs. another one but I regard this as details.
On 13-Mar-2021 20:03, PJ vM wrote: > Over at Gitlab, people are discussing [1] a potential deprecation of > status code 11 (sensitive input). A few points. > > Firstly, for certain (possibly many) use cases password authentication > (combined with shorter- or longer-lived "session" client certificates) > is the right choice over only using client certificates. Some examples I > could quickly think of: > > * a Gemini interface to a service for which the user already has login > credentials (and other cases where one needs to confirm the user is the > same as an identity previously established by other means than a > certificate) > * any use case for which client certs are simply not portable enough > * the equivalent of "changing one's password" seems (not certain about > this) quite tedious to do in a world with only client certs, for use > cases where the users are pseudonymous > > It seems clear to me that login credentials and certs are sufficiently > different in practical aspects that certs cannot replace password > authentication for all use cases. > > So, and this is really my key point: whether one likes it or not, I > think password authentication will keep being used as long as there is a > way to give input to the server. Gemini is really a read-only medium as its method is GET only - there is no idempotent method to send data. Servers that attempt to put transient state with side effects (changing a password among other things) by putting these into the URI is poor design IMO. URIs are designed to be shared, bookmarked - they are a publicly persistable reference of server state (see Fielding et al). They are a massive success on the internet as such. A URI query should be thought of as a query parameterisation - a way to address server state, rather than as a way to send state to the server. To send state properly you need an idempotent mechanism, which Gemini doesnt have. The web does, as incidentally did early gopher before it adopted URIs. This seems to be a conscious design choice of Gemini. My view is that status 11 is a kind of security theatre - it gives a false sense of security, when in fact it is logically equivalent to status 10 - and in fact the spec allows valid clients to only interpret the first digit, so a client may actually not know. We should not be encouraging its use or authors or users to form a view it is "protecting" them in any significant sense. > Secondly, let's look at why exactly it is considered a bad idea to put > sensitive information in a URL. The reasons given by RFC 3986 ?7.5 > (quoted at the Gitlab issue) are: > >> URIs are frequently displayed by browsers, stored in clear text >> bookmarks, and logged by user agent history and intermediary >> applications (proxies) > The last problem can be avoided by not using relay-type proxies (by > which I mean proxies where the TLS connection is with the proxy rather > than with the destination). Note that all the other problems can be > addressed by client software IF it's possible to distinguish between > sensitive and non-sensitive input. When the server sends 11, the client > can hide the input the user is typing, and throw away the query after > sending the request, before displaying the URL in the URL bar or saving > it in the browsing history. No, its not possible for either clients nor servers to know which URIs are "sensitive" Q: here is a URI - should a client, proxy or server be prevented from recording or sharing it: gemini://example.com/foo?bar Ans: there is *no* way to know. It depends on the semantics of the application and foo and bar. > So actually, if we reason from the assumption that password > authentication will happen anyway (as I've argued above), removing > status code 11 has rather negative consequences, as it removes the > ability to distinguish between sensitive and non-sensitive input. Status 10 and 11 are currently logically indistinguishable and status 11 is misleading. If we keep status 11, the FAQ could warn off its use and I think clients should warn users to say something like "The server requested to mask the input, however be aware that the parameter will be simply appended in the clear to the subsequent URI, and this does not offer a genuine security feature." > My conclusion is that removing status code 11 would be unwise, and > instead it would be better to include a recommendation in the best > practices document to throw away the query part after sending a request > that results from user input on a 11 page. Maybe there should also be a > recommendation to store client certs in a password-encrypted vault, as > of course storing long-lived certs unencrypted is about as much of a > problem as storing sensitive queries in the browsing history. > > Thirdly and lastly, about Gitlab. I strongly dislike the fact that > discussions which can have quite an impact on all Gemini users are > happening in Gitlab issues; to stay up-to-date on all these requires > regularly going through multiple webpages, and to comment requires a > Gitlab account! I think this is a mistake. I don't think its a big deal - if the BDFN finds it a useful and practical way to gather issues with the spec, I'm happy to contribute wherever the conversation may happen. > [1] https://gitlab.com/gemini-specification/protocol/-/issues/17 - Luke
On Sun, Mar 14, 2021 at 10:08:48AM +0100, Stephane Bortzmeyer wrote: >We may > discuss about gitlab vs. gitea and about one given gitlab hoster > vs. another one but I regard this as details. I think using an issue tracker is an huge improvement for this project and I would like to use gitlab and participate to the discussion there but I am not, for example, able to even make an account on gitlab.com (the website keeps checking my browser, whatever this means). My ideal solution would be a self-hosted gitea instance, but i found friendly, privacy aware and comfortable the instance at https://codeberg.org/. Anyway i hope proposals discussed here could be forwarded to gitlab, if they are considered valid, of course. Bye! C.
On Sun, Mar 14, 2021 at 10:41:59AM +0100, cage <cage-dev at twistfold.it> wrote a message of 19 lines which said: > I am not, for example, able to even make an account on gitlab.com > (the website keeps checking my browser, whatever this means). They are hosted at Cloudflare and this is probably the Cloudflare proxy doing some checks before relaying your request. It is annoying and it sometimes block things such as the Tor browser. You may have to change/modify your configuration :-( > ideal solution would be a self-hosted gitea instance, It is some work to install your own instance and there are many of existing instances of Gitlab or Gitea. (Personnally, I use Framagit, a Gitlab instance.) But, as I said, this is a detail, there is no perfect solution and the BDFL choosed.
Apologies - I should improve my proof reading - there were a couple of typos - some missing negations. Here is a fix, but in summary I meant to say - Gemini's request method *is* idempotent (equivalent to the web's GET) - Gemini does not have a *non* idempotent method (safe for sending state to the server) On 14-Mar-2021 09:32, Luke Emmet wrote: > Gemini is really a read-only medium as its method is GET only - there is > no idempotent method to send data. Servers that attempt to put transient > state with side effects (changing a password among other things) by > putting these into the URI is poor design IMO. Gemini's method *is* an idempotent method, there is no non-idempotent method in Gemini. > A URI query should be thought of as a query parameterisation - a way to > address server state, rather than as a way to send state to the server. > To send state properly you need an idempotent mechanism, which Gemini > doesnt have. The web does, as incidentally did early gopher before it > adopted URIs. This seems to be a conscious design choice of Gemini. [...] To send state properly you need a *non*-idempotent mechanism, [...] > My view is that status 11 is a kind of security theatre - it gives a > false sense of security, when in fact it is logically equivalent to > status 10 - and in fact the spec allows valid clients to only interpret > the first digit, so a client may actually not know. We should not be > encouraging its use or authors or users to form a view it is > "protecting" them in any significant sense. > > >> Secondly, let's look at why exactly it is considered a bad idea to put >> sensitive information in a URL. The reasons given by RFC 3986 ?7.5 >> (quoted at the Gitlab issue) are: >> >>> URIs are frequently displayed by browsers, stored in clear text >>> bookmarks, and logged by user agent history and intermediary >>> applications (proxies) > The last problem can be avoided by not using >>> relay-type proxies (by >> which I mean proxies where the TLS connection is with the proxy rather >> than with the destination). Note that all the other problems can be >> addressed by client software IF it's possible to distinguish between >> sensitive and non-sensitive input. When the server sends 11, the client >> can hide the input the user is typing, and throw away the query after >> sending the request, before displaying the URL in the URL bar or saving >> it in the browsing history. > > No, its not possible for either clients nor servers to know which URIs > are "sensitive" > > Q: here is a URI - should a client, proxy or server be prevented from > recording or sharing it: > > gemini://example.com/foo?bar > > Ans: there is *no* way to know. It depends on the semantics of the > application and foo and bar. > >> So actually, if we reason from the assumption that password >> authentication will happen anyway (as I've argued above), removing >> status code 11 has rather negative consequences, as it removes the >> ability to distinguish between sensitive and non-sensitive input. > > Status 10 and 11 are currently logically indistinguishable and status 11 > is misleading. > > If we keep status 11, the FAQ could warn off its use and I think clients > should warn users to say something like "The server requested to mask > the input, however be aware that the parameter will be simply appended > in the clear to the subsequent URI, and this does not offer a genuine > security feature." > >> My conclusion is that removing status code 11 would be unwise, and >> instead it would be better to include a recommendation in the best >> practices document to throw away the query part after sending a request >> that results from user input on a 11 page. Maybe there should also be a >> recommendation to store client certs in a password-encrypted vault, as >> of course storing long-lived certs unencrypted is about as much of a >> problem as storing sensitive queries in the browsing history. >> >> Thirdly and lastly, about Gitlab. I strongly dislike the fact that >> discussions which can have quite an impact on all Gemini users are >> happening in Gitlab issues; to stay up-to-date on all these requires >> regularly going through multiple webpages, and to comment requires a >> Gitlab account! I think this is a mistake. > > I don't think its a big deal - if the BDFN finds it a useful and > practical way to gather issues with the spec, I'm happy to contribute > wherever the conversation may happen. > >> [1] https://gitlab.com/gemini-specification/protocol/-/issues/17 > > ?- Luke
On 2021-03-14T10:08+01:00, St?phane Bortzmeyer wrote: > On Sat, Mar 13, 2021 at 08:30:19PM -0700, >? Thomas Frohwein <tfrohwein at fastmail.com> wrote >? a message of 79 lines which said: > >>> Thirdly and lastly, about Gitlab. I strongly dislike the fact that >>> discussions which can have quite an impact on all Gemini users are >>> happening in Gitlab issues; to stay up-to-date on all these >>> requires regularly going through multiple webpages, and to comment >>> requires a Gitlab account! I think this is a mistake. >> >> Agree, even with this one. > > Group work is funny. When the discussion on the specification was on > the mailing list, everybody complained that it made a lot of messages, > that it was difficult to follow, to know for sure what was decided or > not, etc. (I did share some of these complaints but not all; many > problems were simply because some people do not use some features of > their email client, such as threading and full-text search.) Nobody > defended the mailing list and asked for the specification discussion > to remain there. I think that was because nobody (or at least not many people) had the idea to ever switch to another system. The mailing list seemed to be the chosen system by Solderpunk at the time so nobody questioned it. And since it is pretty easy to find a point that makes you not like something, switching was bound to make some people unhappy. That said, I want to do some complaining too, hoping that somebody has a solution: Imagine that as with the mailing list before, I (only) want to read all the discussions without going through all the separate issue pages (I think that's what PJ vM was trying to point out). I found that Gitlab provides an atom feed[1], which I hoped would do exactly what I wanted. But there are several problems with it: a) It is not a valid atom feed [2]. b) It seems that it only contains the first comment of each issue and to ?? follow the discussion, I once again have to go through all the pages. I hope that I was just too stupid to find the link that lets me look at all comments in a feed format. Or if Gitlab does not provide that, maybe someone can build a thing that lets us do that. I think that would be really helpful. Regards, Johann [1]: https://gitlab.com/gemini-specification/protocol/-/issues.atom [2]: https://validator.w3.org/feed/check.cgi?url=https%3A%2F%2Fgitlab.com%2 Fgemini-specification%2Fprotocol%2F-%2Fissues.atom -- You can verify the digital signature on this email with the public key available through web key discovery. Try e.g. `gpg --locate-keys`... or go to <https://qwertqwefsday.eu/.well-known/openpgpkey/hu/spd3xecxhotzgyu1p3eqdqdp31ba6rif>.
On Sun, Mar 14, 2021 at 11:17:46AM +0100, Johann Galle <johann at qwertqwefsday.eu> wrote a message of 214 lines which said: > I found that Gitlab provides an atom feed[1], which I hoped would do > exactly what I wanted. But there are several problems with it: I myself follow the specification work through syndication and, while I did not test the technical validity of the feed, I can guarantee that, each time there is a comment, I see a new entry in my syndication reader. https://gitlab.com/gemini-specification.atom
Stephane Bortzmeyer <stephane at sources.org> wrote: > Regarding Gitlab, there is not yet (I regret it) a well-known and > widely used decentralized issue tracking system allowing not to have > an account of the central system. (There are many experiments, but > nothing solid yet.) So, it had to be a centralized system. We may > discuss about gitlab vs. gitea and about one given gitlab hoster > vs. another one but I regard this as details. SourceHut[1]'s todo tracker [2] satisfies this exactly, allowing anonymous users (identified simply by their e-mail) to comment on issues, with fine-grained permission control available. Repositories, mailing lists, and issue trackers work independently, can be tied together using integrations, and can be housed under a single name using projects. It's probably too late to migrate to it from GitLab, but I suggest you at least take a look and experiment a bit. It's completely free and open-source software, and anybody can host their own instance. [1]: https://sourcehut.org [2]: https://todo.sr.ht
The purpose for this status code is in case someone is looking over your shoulder in the same physical location. That's why it's fine to be an LSD (least significant digit / optional) code, it's a snazzy feature that's nice to have but not mandatory. I think it's a good feature. It doesn't send it unencrypted (i.e. same as any other request) so it's not security theatre. It's there so people in the same location don't see your password.
On 14/03/2021 10:32, Luke Emmet wrote: > URIs are designed to be shared, bookmarked - they are a publicly > persistable reference of server state (see Fielding et al). They are > a massive success on the internet as such. > > A URI query should be thought of as a query parameterisation - a way > to address server state, rather than as a way to send state to the > server. Key is "*should* be thought of". You have a clear concept of the URI as only an identifier and nothing more. However, you cannot expect everyone else to only use URIs in the way you think they should be used. Fact is that it's *possible* to use the URI query as an input mechanism, and that in the Gemini protocol it is the *only* thing that can be used as an input mechanism. It's possible, so people *will* do it. They will also use it to convey passwords. You can keep telling the world that you think it's poor design, and people will keep doing it anyway. This is my point: people are going to do it, and status code 11 is necessary to allow doing it safely. > To send state properly you need an idempotent mechanism, which > Gemini doesnt have. The web does, as incidentally did early gopher > before it adopted URIs. This seems to be a conscious design choice of > Gemini. Creating separate status codes for "input", one of which for sensitive input, was a conscious design choice of Gemini. > My view is that status 11 is a kind of security theatre - it gives a > false sense of security, when in fact it is logically equivalent to > status 10 - and in fact the spec allows valid clients to only > interpret the first digit, so a client may actually not know. We > should not be encouraging its use or authors or users to form a view > it is "protecting" them in any significant sense. How in the world do you get to the position that status codes 10 and 11 are "logically equivalent"? What? They are different codes, they are defined to mean different things... Sensitive input *is* protected in a significant sense, IF the client recognises status code 11 and acts on it. If you are submitting sensitive information via a URI query, someone looking over your shoulder or someone gaining temporary access to your device and looking through your browsing history are both legitimate threats, and status code 11 allows clients to protect against these threats by not showing the query on the screen and not storing it in the browsing history. > No, its not possible for either clients nor servers to know which > URIs are "sensitive" > > Q: here is a URI - should a client, proxy or server be prevented > from recording or sharing it: > > gemini://example.com/foo?bar > > Ans: there is *no* way to know. It depends on the semantics of the > application and foo and bar. Your reasoning is very flawed here. Sure, there is no way to know *for a random person just by looking at the URI*. Note that the site creator is NOT a random person just looking at the URI. On the server side, the creator specifies what question is asked when "example.com/foo" is requested, specifies if that is a sensitive question, so the server knows whether the question should be asked with a 10 or a 11. Then, by the server giving a 10 or a 11, the client can know whether the question is sensitive and consequently how it should treat the input. > the parameter will be simply appended in the clear to the subsequent > URI "in the clear" reads to me as suggesting the query is not encrypted between the client and the server. Note that the query is in the request, which is TLS-encrypted. -- pjvm
On 14/03/2021 11:51, nothien at uber.space wrote: > Stephane Bortzmeyer <stephane at sources.org> wrote: >> Regarding Gitlab, there is not yet (I regret it) a well-known and >> widely used decentralized issue tracking system allowing not to have >> an account of the central system. (There are many experiments, but >> nothing solid yet.) So, it had to be a centralized system. We may >> discuss about gitlab vs. gitea and about one given gitlab hoster >> vs. another one but I regard this as details. > > SourceHut[1]'s todo tracker [2] satisfies this exactly, allowing > anonymous users (identified simply by their e-mail) to comment on > issues, with fine-grained permission control available. Also, everything seems to work without javascript, quite unlike the javascript-heavy Gitlab webpages. Taken together with the ability to comment on issues via email and to apparently also follow issues via email, this seems like a much better fit for the Gemini project. -- pjvm
On Sun, 14 Mar 2021 16:18:13 +0100, PJ vM wrote: >> SourceHut[1]'s todo tracker [2] satisfies this exactly, allowing >> anonymous users (identified simply by their e-mail) to comment on >> issues, with fine-grained permission control available. > > Also, everything seems to work without javascript, quite unlike the > javascript-heavy Gitlab webpages. Taken together with the ability to > comment on issues via email and to apparently also follow issues via > email, this seems like a much better fit for the Gemini project. Big fan of Wikis here, thus I think another alternative could be Wikiversity (a project of the "not-for-profit corporation" Wikimedia): No accounts needed, though encouraged (IP stated otherwise). Accounts offer individual Atom feeds, covering recent changes of watched (starred) pages and discussions. No email address is needed to create an account. The Gemini specification could be published and edited there as well, with unwanted edits easily reverted, as these should be concluded upon via discussions first, probably. Discussions to specific topics, e. g. response codes, could be sections in the Discuss tab to the Specification article or even own discussion pages in case the topic is covered by its own (sub-)article. The URL could be https://en.wikiversity.org/wiki/Gemini/Specification Sorry to bring this up only at a moment where Gitlab already files 20 Protocol and 7 Gemini text issues with ongoing discussions, and users already having created Gitlab accounts.
I did find the GitLab move strange. IMO it's not very "mission coherent" to develop a lightweight alternative to the web on a site that shows a blank white page without JavaScript enabled. The suggestion of SourceHut sounds like a good compromise if it's true that one can participate without an account. I've only been a watcher of the spec process so far, but if contributing involved making a GitLab account and keeping up with changes there then that's not a barrier I'd cross. But I haven't been contributing so that opinion weighs very little.
On 14/03/2021 17:27, text at sdfeu.org wrote: > Big fan of Wikis here, thus I think another alternative could be > Wikiversity (a project of the "not-for-profit corporation" > Wikimedia): > > [...] > > The Gemini specification could be published and edited there as > well, with unwanted edits easily reverted, as these should be > concluded upon via discussions first, probably. > > Discussions to specific topics, e. g. response codes, could be > sections in the Discuss tab to the Specification article or even own > discussion pages in case the topic is covered by its own > (sub-)article. According to [1], Wikiversity is intended for *learning resources*, specifically learning resources different from what Wikipedia and Wikibooks offer. I fear that if we were to try to use it as a platform to develop the Gemini specification, rather than just learning materials around Gemini, Wikiversity editors would not accept this. If one were to create such pages on Wikiversity, they would probably be quickly removed using Wikiversity's speedy deletion guideline [2]; the very first criterion listed for speedy deletion is "No educational objectives". [1] https://en.wikiversity.org/wiki/Wikiversity:Mission [2] https://en.wikiversity.org/wiki/Wikiversity:Deletions -- pjvm
On Sun, Mar 14, 2021 at 05:05:55PM +0000, Liam <liam at lmcm.io> wrote a message of 5 lines which said: > The suggestion of SourceHut sounds like a good compromise if it's > true that one can participate without an account. >From their page: "Sourcehut is currently available as a public alpha." It all depends on whether we want to work on the specification, or if we want to help test/develop SourceHut. Installation instructions are quite scary <https://man.sr.ht/installation.md>.
On 14/03/2021 17:34, Stephane Bortzmeyer wrote: > Installation instructions are quite scary I assumed we'd use the official instance, not setup a new one. In the same way that gitlab.com is currently being used, not Gemini's own GitLab instance.
Stephane Bortzmeyer <stephane at sources.org> wrote: > From their page: "Sourcehut is currently available as a public alpha." > It all depends on whether we want to work on the specification, or if > we want to help test/develop SourceHut. That's a really aggressive outlook. SourceHut has a great track record. In fact, check out GitLab's status page [0], look through the incident history, and compare that with that of SourceHut [1]. SourceHut, although technically in alpha, is extremely reliable and has multiple layers of redundancy [2], and has a complete public operations manual [3] documenting how carefully the instance is maintained. I suggest you check it out before making rash assumptions like this. > Installation instructions are quite scary > <https://man.sr.ht/installation.md>. It's not great, I agree, but you don't have to set up one - just use <https://sr.ht>. As I've explained above, it's extremely well-maintained. [0]: https://status.gitlab.com [1]: https://status.sr.ht [2]: https://man.sr.ht/ops/backups.md [3]: https://man.sr.ht/ops
> On Mar 14, 2021, at 19:37, nothien at uber.space wrote: > > just use <https://sr.ht>. As I've explained above, it's extremely well-maintained. Actually, sourcehut looks really good, both technically, and culturally speaking. A much better fit for Gemini indeed. ?0?
On 2021-03-14 06:34PM, Stephane Bortzmeyer wrote: > From their page: "Sourcehut is currently available as a public alpha." > It all depends on whether we want to work on the specification, or if > we want to help test/develop SourceHut. Sourcehut is very stable. It's still called an "alpha" primarily because it's missing features that they want to implement in the future---namely some APIs and user-groups/organizations---not because it's buggy or unstable. Until I just recently started self-hosting my git I used sourcehut for all my git projects and there was not one single issue I ran into. https://sourcehut.org/alpha-details/ > Installation instructions are quite scary > <https://man.sr.ht/installation.md>. Other than needing a mail server it's no scarier than installing any other self-hosted stuff. If you're running an OS they provide repos for (alpine, arch, and debian) then you literally just install the package, and since it natively supports nginx you don't even have to deal with php/cgi bullshit like you do with a lot of other services. I will say that since you don't need an account to participate anyways then it'd be unnecesary to worry about self-hosting it at all unless we really wanted to. ~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/
It was thus said that the Great Liam once stated: > I did find the GitLab move strange. IMO it's not very "mission coherent" to > develop a lightweight alternative to the web on a site that shows a blank > white page without JavaScript enabled. First off, as St?phane has pointed out, people (and it was many people, by the way) were complaining about all the talk on the mailing list. The mailing list was created *to talk about the Gemini protocol* and to hash the details out. Perhaps that wasn't stated strongly enough on the sign up page, but I do have to wonder what other people expectd out the list. Personally, I never found the volumn overwhelming, but then again, I've been on lists that have had 100+ messages per day, sustained (and a person high of 500 messages in a single day). Second, about that "lightweight alternative to the web" bit ... having been involved with Gemini since before the mailing list, it was clear to me that Gemini was never about a "lightweight alternative to the web" but an improved gopher. I think thinking of Gemini in terms of the web leads to all these proposed extensions (size, caching, uploads, etc.). I think it's a failure to set expectations, but that's me. Third, a bit more about that "lightweight alternative to the web" bit ... here's a TL;DR summary of the protocol: The client connects to TCP port 1965 using TLS 1.2 or higher. The client then sends a URI and a CR, LF pair to make a request. The server then replies with a status line consisting of two digits, a space, some additional information depending upon the status, a CR, LF pair, and then in the case of success, the conent. The server then closes the connection. Simple right? TLS---people bitched about that. Drop support for 1.2. Drop TLS and use this alternative scheme I just read about. Drop TLS entirely. Make TLS optional! TLS certificates---people bitched about that. Let's Encypt certificates? TOFU? How to TOFU? What to save for TOFU? Don't use Let's Encrypt. Don't bother with validating server certificates. URI---people bitched about that. ASCII only? Use IRIs! That's too hard! Is not! Is too! S'not! S'too! What about fragemnts? What about them? Hey! data: is a URI! No, ban those! No, they're valid URIs! They'll allow inlined images! So? That's bad! The CR, LF pair---people bitched about that. Why both? Why not just LF? It saves a byte! It's too hard to deal with! Saving a byte? What, with the overhead of TCP (40 bytes per packet)? And TLS (several additional packets). The status line---people bitched about that! There are too few status codes! There are too many status codes! Let's use single digit status codes! Let's use tripple digit status codes! Let's use double digit status codes! We need redirection! We don't need redirection! Yes we do! And Gone. Really? We need senstive input. No we don't, it's security theater. The MIME type for status 20---people bitched about that! Not about the MIME bit directly, but about the parameters! It allows extensions! Strictly limit the parameters! That will complicate clients because there are a lot of MIME types, with a lot of different parameters! But extentions! And this is *JUST* for the protocol. Please check the mailing list archives from 2019 onward---the bikeshedding that went on about text/gemini makes the above look trivial in nature. Simple? Ha ha ha ha ha ha ha ha! > The suggestion of SourceHut sounds like a good compromise if it's true that > one can participate without an account. I'm the one responsible for setting up the gitlab issue tracker for Gemini. It was suggested I set one up using gitlab (and no, I won't say who made the suggestion). I knew that github was off the table for this crowd, so I bit the bullet, created a gitlab account and went to town. I was not familiar with the other alternatives at the time, and people were *massively bitching* about the volume on the mailing list. I completely disagree with participation without an account. I'm sorry, but my experience with Gemini has shown that it's all too easy to bitch about it than to do anything about it. That IRI thing? As far as I know, only *two* people (and I'm one of them) actually bothered implementing IRI support, just to see how difficult it was. TWO! There are way more than TWO people who demand IRIs, and about an equal number who decry IRIs, and out of this lot, only TWO people bothered to try, and right now, between those two peple, 50% are ready to dump the idea into the dumpster fire out back (for the record, I'm that 50%), because the two camps are mostly talking about theory. Anyway, to get back onto the point---if you want to bitch about Gemini, I think it's fair to have some skin, however minimal, in the game. If setting up an account is too much, tough! I AM aware that there may be some technical difficulties in using gitlab and there are some who would participate that are otherwise unable to do so. For them, yes, the mailing list is still good---I do follow both (and yes, that means I hit *each and every* issue page on gitlab nearly everyday, even if I don't reply). > I've only been a watcher of the spec process so far, but if contributing > involved making a GitLab account and keeping up with changes there then > that's not a barrier I'd cross. But I haven't been contributing so that > opinion weighs very little. You don't need an account to follow the gitlab issues. You just can't comment on them without an account. -spc
On Sun, Mar 14, 2021 at 4:46 PM Sean Conner <sean at conman.org> wrote: > It was thus said that the Great Liam once stated: > > I did find the GitLab move strange. IMO it's not very "mission coherent" > to > > develop a lightweight alternative to the web on a site that shows a > blank > > white page without JavaScript enabled. > > First off, as St?phane has pointed out, people (and it was many people, > by > the way) were complaining about all the talk on the mailing list. The > mailing list was created *to talk about the Gemini protocol* and to hash > the > details out. Perhaps that wasn't stated strongly enough on the sign up > page, but I do have to wonder what other people expectd out the list. > Personally, I never found the volumn overwhelming, but then again, I've > been > on lists that have had 100+ messages per day, sustained (and a person high > of 500 messages in a single day). <snip> > I completely disagree with participation without an account. I'm sorry, > but my experience with Gemini has shown that it's all too easy to bitch > about it than to do anything about it. That IRI thing? As far as I know, > only *two* people (and I'm one of them) actually bothered implementing IRI > support, just to see how difficult it was. TWO! There are way more than > TWO people who demand IRIs, and about an equal number who decry IRIs, and > out of this lot, only TWO people bothered to try, and right now, between > those two peple, 50% are ready to dump the idea into the dumpster fire out > back (for the record, I'm that 50%), because the two camps are mostly > talking about theory. Anyway, to get back onto the point---if you want to > bitch about Gemini, I think it's fair to have some skin, however minimal, > in > the game. If setting up an account is too much, tough! > <snip> > You don't need an account to follow the gitlab issues. You just can't > comment on them without an account. > > -spc > I *think* I implemented/tested/tried the IRI thing and I'm thinking that I'm not in the group-size-two that you referred to. The sentence I just wrote is *not* my point - I'm totally cool with the above (what I and you and others wrote/expressed) - my point is... I was thinking... If I *thought* I tried out the IRI thing, but wanted to check, where would I go? What would I test? How would I 'certify'? If I wanted to be a part of the discussion in a trying-to-implement-this-new-experiment way, what should I do? I'm guessing that maybe an email to the list or a comment on a gitlab issue to the effect of: "I think this is what it means to test out the IRI thing. I think I did it, you can try out my implementation like this..." That feels... good to me... Thoughts?
It was thus said that the Great Mansfield once stated: > > I *think* I implemented/tested/tried the IRI thing and I'm thinking that > I'm not in the group-size-two that you referred to. First off, I want to thank you if you have implemented IDNs (no matter how good or bad---just the fact that you did is wonderful). Second, you are right, you are the third (if I recall correctly, not many people mentioned it) to do so. > The sentence I just wrote is *not* my point - I'm totally cool with the > above (what I and you and others wrote/expressed) - my point is... I was > thinking... > > If I *thought* I tried out the IRI thing, but wanted to check, where would > I go? What would I test? How would I 'certify'? > > If I wanted to be a part of the discussion in a > trying-to-implement-this-new-experiment way, what should I do? A great question, and fortunately, there is an answer, at least for clients: try fetching the following IRI: gemini://caf?.mozz.us/files/?????.txt Not my site, but the size of the other person who bothered to experiment with this stuff. And as for details, it would be nice to know: operating system implementation language possible libraries in use and if it works, what you had to do in order to get it to work. > I'm guessing that maybe an email to the list or a comment on a gitlab issue > to the effect of: "I think this is what it means to test out the IRI thing. > I think I did it, you can try out my implementation like this..." > > That feels... good to me... There is an issue with how I think it should work: https://gitlab.com/gemini-specification/protocol/-/issues/1 but I've been told that no, what I wrote is *wrong*, but as of yet, no one has given a concrete approach for clients to follow to get this to work. That's what pisses me off about this---I wrote what worked for me, but it's wrong [1], but no one has told me how to go about doing it right, and I'm very close to closing the ticket with prejudice [2], with the only way to get IRIs back on the table is to convince Solderpunk, the BDFL (I'm only the BDFLA, the Benevolent Dictator For Life's Assistant). So the more concrete information I get for OR against it, the better. -spc [1] Mostly about resolving IDNs. [2] An American legal term meaning---when a legal case is dismissed with prejudice, the case is closed, and there is NO means of appeal. It's not used often, and when it does happen, it means the judge was royally pissed off.
On Sun, Mar 14, 2021 at 8:10 PM Sean Conner <sean at conman.org> wrote: > It was thus said that the Great Mansfield once stated: > > > > I *think* I implemented/tested/tried the IRI thing and I'm thinking that > > I'm not in the group-size-two that you referred to. > > First off, I want to thank you if you have implemented IDNs (no matter > how > good or bad---just the fact that you did is wonderful). Second, you are > right, you are the third (if I recall correctly, not many people mentioned > it) to do so. > You're welcome! I kinda wish we or I could be more organized around what experiments everyone is running so that we could swarm several implementations on any that others liked or disliked. IMO that could be an advantage of something like gitlab - label issues as 'experiments' and look for implementations/tests/urls/etc on the issues. Maybe I'll throw up some of my experiments as issues in gitlab... FWIW - I *really* like the "implement your idea in code and then let's talk" approach, since Gemini is soo stinking simple to get a foot in the door on. > The sentence I just wrote is *not* my point - I'm totally cool with the > > above (what I and you and others wrote/expressed) - my point is... I was > > thinking... > > > > If I *thought* I tried out the IRI thing, but wanted to check, where > would > > I go? What would I test? How would I 'certify'? > > > > If I wanted to be a part of the discussion in a > > trying-to-implement-this-new-experiment way, what should I do? > > A great question, and fortunately, there is an answer, at least for > clients: try fetching the following IRI: > > gemini://caf?.mozz.us/files/ <http://xn--caf-dma.mozz.us/files/> > ?????.txt > Seemed to work fine. I ran my client from the CLI with that host/path as the destination and it seemed to work. Then I used the in-client method of editing/setting the destination and pasted that host/path and it returned the same result - not that *going* there would have been any different, but that I wanted to make sure that editing the location in the client supported what the CLI had supported. Thanks to mozz.us for providing that - it felt good to run a test that wasn't something I had contrived! > Not my site, but the size of the other person who bothered to experiment > with this stuff. And as for details, it would be nice to know: > > operating system > implementation language > possible libraries in use > > and if it works, what you had to do in order to get it to work. # OS Linux... I can try it on a windows machine later, but I'm guessing it might work the same depending on which windows cli I use. (Using the wrong cli in windows, it'll probably fail... but who knows until it's tried?) # Lang Golang # Libraries ... net and net/url of course... and golang.org/x/net/idna ... and... that
On 3/14/2021 1:08 AM, Stephane Bortzmeyer wrote: > On Sat, Mar 13, 2021 at 08:30:19PM -0700, > Thomas Frohwein <tfrohwein at fastmail.com> wrote > a message of 79 lines which said: > >>> Thirdly and lastly, about Gitlab. I strongly dislike the fact that >>> discussions which can have quite an impact on all Gemini users are >>> happening in Gitlab issues; to stay up-to-date on all these >>> requires regularly going through multiple webpages, and to comment >>> requires a Gitlab account! I think this is a mistake. >> >> Agree, even with this one. > > Group work is funny. When the discussion on the specification was on > the mailing list, everybody complained that it made a lot of messages, > that it was difficult to follow, to know for sure what was decided or > not, etc. (I did share some of these complaints but not all; many > problems were simply because some people do not use some features of > their email client, such as threading and full-text search.) Nobody > defended the mailing list and asked for the specification discussion > to remain there. > > Now that we moved to another system, people (but may be not the same) > complain about the new system. My (long) experience with "groupware" > is that it is impossible to find a solution that will please > everyone. Yes, it is the nature of an email list to become noisy when the population and popularity of that list increases. So the WG style discussions for finalizing the Gemini spec have migrated to a platform which is [also] well suited for such purposes. As a platform, it is Perhaps even better equipped to compartmentalize and focus upon each particularity that needs focused attention. Issues can be isolated and related discussions can remain on topic there in the issue tracker much more coherently. I don't see how lamenting the move to a Gitlab issue tracker system elswhere (here on this list) is going to facilitate the discussions occuring there, and to be certain, one can participate there if those are important issues for them or they can choose not to participate. As far as what I've observed (I'm still going back over all of the archives on my mail server) with respect to people leaving the list due to complaints related to traffic, I've noticed that most of those were folks that were of the, let's say, 'user' class, who found the nebulous and arcane joo joo black arts of the core development and standardization process too overhwelming to enjoy. I've also noticed, not as many, but several technically minded folks leaving citing disdain for banter and discussion that isn't specifically related to the canonization of Gemini protocol specifications and the development cycle of software. I think this list will evolve over time to be a more user centric resource medium with the more occasional announcements related to core dev topics, with a lot more of the development related discussions taking place in arenas more centric to actual development. That's just kinda what I figure. But it does little to no good to complain here about a discussion taking place elsewhere when anyone's invited - if it is something important to a person, it stands to reason that they'll make their positions heard where the majority of such impactful discussions are currently taking place. In the end, it really is a matter of what, "Is, is", and right now, those matters are being *decided* elsewhere. I hope that helps :) Kindest regards, -- Bradley D. Thornton Manager Network Services http://NorthTech.US TEL: +1.310.421.8268
On 3/14/2021 3:17 AM, Johann Galle wrote: > > I hope that I was just too stupid to find the link that lets me look at all > comments in a feed format. Or if Gitlab does not provide that, maybe > someone Hi, Johann :) I've always told all of my students that the only stupid question is the one that didn't get asked, because you probably should have asked. Thanks for asking, and I'm hoping that this provides at least a partial solution for you - it also includes an avenue of direct participation for you. In the signature block at the bottom of all emails from your subscribed topics, in the second to the last line, is the following: "Reply to this email directly or view it on GitLab. " Yes, it requires one to go and follow/watch, but you can read in entirety and even respond directly. I hope that helps :) Kindest regards, -- Bradley D. Thornton Manager Network Services http://NorthTech.US TEL: +1.310.421.8268
On 3/14/2021 7:10 PM, Sean Conner wrote: > It was thus said that the Great Mansfield once stated: >> >> >> If I *thought* I tried out the IRI thing, but wanted to check, where would >> I go? What would I test? How would I 'certify'? >> >> If I wanted to be a part of the discussion in a >> trying-to-implement-this-new-experiment way, what should I do? > > A great question, and fortunately, there is an answer, at least for > clients: try fetching the following IRI: > > gemini://caf?.mozz.us/files/?????.txt > https://gitlab.com/gemini-specification/protocol/-/issues/1#note_529261448 I hope that helps :) Kindest regards, -- Bradley D. Thornton Manager Network Services http://NorthTech.US TEL: +1.310.421.8268
On 14/03/2021 23:46, Sean Conner wrote: > It was thus said that the Great Liam once stated: >> I did find the GitLab move strange. IMO it's not very "mission >> coherent" to develop a lightweight alternative to the web on a site >> that shows a blank white page without JavaScript enabled. > > [...] > > Second, about that "lightweight alternative to the web" bit ... > having been involved with Gemini since before the mailing list, it > was clear to me that Gemini was never about a "lightweight > alternative to the web" but an improved gopher. I think thinking of > Gemini in terms of the web leads to all these proposed extensions > (size, caching, uploads, etc.). I think it's a failure to set > expectations, but that's me. I've seen you say something to the extent of "Gemini is not an alternative to the web but an improvement on Gopher" multiple times. I think you're treating this as a one-or-the-other thing when in reality it's both. Now for sure, Gemini is not a /compromise/ between Gopher and the web. It does not meet the web in the middle, it's much, much closer to Gopher. Most of the inspiration taken from the web is in the form of pitfalls to avoid. But it is definitely an alternative to the web: Gemini can do many of the useful things that the web can do. And a lot of people who come to Gemini are fleeing from the web. Anyway, simply because many people interested in Gemini absolutely despise the web, I do think Liam's point that Gitlab is not "mission coherent" stands. Or perhaps not "audience coherent" is a better term. > It was suggested I set one up using gitlab (and no, I won't say who > made the suggestion). You mean repeat. You said who suggested it when you announced it. > I completely disagree with participation without an account. I'm > sorry, but my experience with Gemini has shown that it's all too easy > to bitch about it than to do anything about it. [...] Anyway, to > get back onto the point---if you want to bitch about Gemini, I think > it's fair to have some skin, however minimal, in the game. If > setting up an account is too much, tough! > > I AM aware that there may be some technical difficulties in using > gitlab and there are some who would participate that are otherwise > unable to do so. For them, yes, the mailing list is still good---I do > follow both (and yes, that means I hit *each and every* issue page on > gitlab nearly everyday, even if I don't reply). So first of all I don't really see the point - if people want to "bitch" without creating a gitlab account, they can just send an email to the list. Secondly, it matters how broad the scope of the gitlab issue tracker is. If it was just something for you in your role as "BDFLA" and was restricted to things over which Solderpunk gave you authority - "addressing edge cases, removing ambiguities and increasing overall consistency" - if issues that suggest major changes (such as removing a status code) were closed immediately with the comment "not my remit" - if that was the case it'd be fine for you to decide that gitlab is the right platform for this and that making an account should be required, because then it's for you. But if you are going to let issues that suggest major changes stand, then it becomes a platform with as broad a scope as the [spec] topic of the mailing list, and frankly in that case your opinion about whether an account should be required to comment
Mansfield writes:
> If I *thought* I tried out the IRI thing, but wanted to check, where
> would I go? What would I test? How would I 'certify'?
Eventually, I'm sure we'll add IRI support to the client torture test
suite. Until then, posting your experiments to the gitlab issue or a
dedicated thread in the mailing list should be fine.
--
Jason McBrayer | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
| but stranger still is lost Carcosa.?
| ? Robert W. Chambers,The King in Yellow
Hello all, Sean Conner <sean at conman.org> writes: > It was thus said that the Great Liam once stated: >> I did find the GitLab move strange. IMO it's not very "mission coherent" to >> develop a lightweight alternative to the web on a site that shows a blank >> white page without JavaScript enabled. > >snip< > I'm the one responsible for setting up the gitlab issue tracker for > Gemini. It was suggested I set one up using gitlab (and no, I won't say who > made the suggestion). I knew that github was off the table for this crowd, > so I bit the bullet, created a gitlab account and went to town. I was not > familiar with the other alternatives at the time, and people were *massively > bitching* about the volume on the mailing list. Thanks Sean, for all the effort you put into this. Everyone else please note, the one, who does the "driving" (or the work), is the one, who decides. Cheers, Erich -- Keep it simple!
On Sun, Mar 14, 2021 at 10:10:18PM -0400, Sean Conner wrote: Hi! [...] > > > > If I wanted to be a part of the discussion in a > > trying-to-implement-this-new-experiment way, what should I do? > > A great question, and fortunately, there is an answer, at least for > clients: try fetching the following IRI: > > gemini://caf?.mozz.us/files/?????.txt > > Not my site, but the size of the other person who bothered to experiment > with this stuff. And as for details, it would be nice to know: FWIW my client? was able to get the text from the IRI above (after fixed a little bug in the IRI parser ;-)) > operating system Debian GNU/linux > implementation language Common Lisp > possible libraries in use I wrote the IRI parser and punycode encoding procedure but i know there are libraries that deal with this stuff even if i never used some of them. Hope this helps! Bye! C. ? https://www.autistici.org/interzona/tinmop.html
On 15/03/2021 18:24, ew.gemini wrote: > Everyone else, please note: the one who does the "driving" (or > the work) is the one who decides. (punctuation corrected) I find this statement ridiculous. Let me show why with some snarky ironic questions: I fail to see how spc (or anyone else) is the "driver" in this analogy... Is he perfecting the spec on his own, coming up with the right answer through internal dialogue? Decision-making is a responsibility and it is work, but it's not all the work. And then you seem to be suggesting that everyone beside the driver should just shut up? That having discussions with the driver is of no benefit, because the driver has infinite wisdom? That the driver should not listen to anyone else in the car? I'm sorry about the snark, that wasn't very friendly. But suggesting that finalising the Gemini specification is a one-person effort (ie that others' contributions are worth nothing) is also not very friendly. It is also not friendly to suggest that spc's reasoning is beyond discussion, or that his decisions (/especially/ on matters other than the spec itself) should always be accepted silently. Sorry for this disproportionately long reply; I just really dislike it when people try to shut down discussion this way. -- pjvm
It was thus said that the Great Sandra Snan once stated: > The purpose for this status code is in case someone is looking over your > shoulder in the same physical location. That's why it's fine to be an > LSD (least significant digit / optional) code, it's a snazzy feature > that's nice to have but not mandatory. I think it's a good feature. > > It doesn't send it unencrypted (i.e. same as any other request) so it's > not security theatre. It's there so people in the same location don't > see your password. Do current Gemini browsers include the query string when displaying the location? If they do in the case of a 10 status, perhaps they should not for an 11? -spc
On Mon, Mar 15, 2021, at 5:35 AM, PJ vM wrote: > Lastly, I strongly doubt that requiring an account to comment benefits > the quality of discussion in any way. Your thinking about "skin in the > game" is interesting, but not more than interesting. In fact, I think > using gitlab is bad for the discussion quality for a few reasons: > > * because of it being split across multiple webpages that few people > look at unless they're linked to a specific issue, the discussion is not > visible enough, there is not enough scrutiny. This can lead to nonsense > arguments not being countered for weeks (probably acquiring multiple > thumbs up from uncritical readers), or even a "the person who files the > issue is more likely to win"-type situation > * you turn away those who are least tolerant of the web, those who are > not favoured by cloudflare, and those who refuse to make a gitlab > account for this because they feel they shouldn't have to I'll be the first to admit that this doesn't address all your issues, since I had an old GitLab account that was just lying around, CloudFlare doesn't hate me, and I'm not particularly web-intolerant, but... As a lurker, the interface for spec discussion on GitLab is a *lot* like spec discussion on the main list. I went to the protocol and gemtext pages, opted to get all notifications, and then e-mails started coming into my inbox. I set up a couple filters on my end, and now they get auto-filed into folders. At the bottom of all GitLab e-mails is some text saying I can reply directly to the e-mail or visit the GitLab website to reply. As someone who's fine with mailing lists and likes his e-mail client, this is not an unpleasant steady state of affairs.
On 15-Mar-2021 23:59, Sean Conner wrote:
> It was thus said that the Great Sandra Snan once stated:
>> The purpose for this status code is in case someone is looking over your
>> shoulder in the same physical location. That's why it's fine to be an
>> LSD (least significant digit / optional) code, it's a snazzy feature
>> that's nice to have but not mandatory. I think it's a good feature.
>>
>> It doesn't send it unencrypted (i.e. same as any other request) so it's
>> not security theatre. It's there so people in the same location don't
>> see your password.
>
> Do current Gemini browsers include the query string when displaying the
> location? If they do in the case of a 10 status, perhaps they should not
> for an 11?
Hello
GemiNaut displays the full URI of the current resource being shown - as
you might see when using a normal web browser.
My view is that the client should be transparent to the user about the
location of the resource they are looking at. It is important they are
informed of the actual location and the client should not obfuscate the
location. If we start hiding content, the user may not be able to
readily actually see the location, which may be a security concern in
its own right.
We should not be trying to invent a new semantics for URLs - the
population at large understand what they are, how they are used etc.
Ironically the gemini URI scheme does not permit users to put user info
(user name or password) into the URI. However the status 11 allows it
back in - this is the primary role of this code as far as I understand
how people want to use it:
"In particular, the authority component is allowed and required,
but its userinfo subcomponent is NOT allowed."
So no I won't be attempting to obfuscate URIs in GemiNaut and it will
warn users if the server invites them to put sensitive info into the URI.
- Luke
On 16/03/2021 02:18, Luke Emmet wrote: > the user may not be able to readily actually see the location, which > may be a security concern in its own right. The hidden part of the URI would always be something that the user typed in a short while ago. Also, unless one holds your view that a URI must contain only location information (in that view SC11 is invalid), in the case of SC11 the query would not really be considered part of the location. > Ironically the gemini URI scheme does not permit users to put user > info (user name or password) into the URI. Allowing both the userinfo component and the query component would mean two different methods for input/parametrisation, one of which can contain one string and one of which can contain either one or two, and they could potentially both be used in one URI. For consistency's and simplicity's sake, allowing only the query component and not the userinfo component is a logical choice. > So no I won't be attempting to obfuscate URIs in GemiNaut and it > will warn users if the server invites them to put sensitive info into > the URI. Do as you wish with your client. -- pjvm
Hello PJ, PJ vM <pjvm742 at disroot.org> writes: > On 15/03/2021 18:24, ew.gemini wrote: >> Everyone else, please note: the one who does the "driving" (or >> the work) is the one who decides. > (punctuation corrected) > > I find this statement ridiculous. Let me show why with some snarky > ironic questions: > > I fail to see how spc (or anyone else) is the "driver" in this > analogy... Is he perfecting the spec on his own, coming up with the > right answer through internal dialogue? Decision-making is a > responsibility and it is work, but it's not all the work. You read more into my statement, than I intented. Or in other words: I was not precise enough. The one who creates the account is the one who decides where to do it. At the time Sean did not know about sourcehut iirc. So be it. Better now? > > And then you seem to be suggesting that everyone beside the driver > should just shut up? That having discussions with the driver is of no > benefit, because the driver has infinite wisdom? That the driver should > not listen to anyone else in the car? > > I'm sorry about the snark, that wasn't very friendly. But suggesting > that finalising the Gemini specification is a one-person effort (ie that > others' contributions are worth nothing) is also not very friendly. It > is also not friendly to suggest that spc's reasoning is beyond > discussion, or that his decisions (/especially/ on matters other than > the spec itself) should always be accepted silently. > > Sorry for this disproportionately long reply; I just really dislike it > when people try to shut down discussion this way. Have a nice day, Erich -- Keep it simple!
Luke wrote: > So no I won't be attempting to obfuscate URIs in GemiNaut That's fine.? It's optional. That's why the status codes are two digits: the first is mandatory and the second is for snazzy extra features. If either client or server doesn't support that LSD, then it doesn't happen. It's just there in case both client and servers support it.
---