💾 Archived View for rawtext.club › ~sloum › geminilist › 000455.gmi captured on 2020-09-24 at 02:33:30. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Ciprian Dorin Craciun ciprian.craciun at gmail.com
Sat Feb 29 07:35:02 GMT 2020
- - - - - - - - - - - - - - - - - - - ``` On Sat, Feb 29, 2020 at 1:42 AM Sean Conner <sean at conman.org> wrote: > Perhaps it's me, but I don't mind looking up things if I don't recall > them. I've been programming in C for 30 years now. I *still* have to look > up the details to strftime() every single time I use it, but I recall that > rand() returns a number between 0 and MAX_RAND (inclusive), yet I use > strftime() way more often than I do rand(). When one is developing code then yes, looking up things in thedocumentation is OK. However when one is reading code, looking in thedocumentation breaks your focus. > > OK, reading that email the answer seems to be "because other protocols > > have it"... And even you admit that in your own code you also handle > > just `LF`. [...] > > True, but there's the 800-pound gorilla to consider---Windows. On > Windows, a call like: > [...] > > So there's a lot of protocols defined for the Internet that use CRLF. > Could a switch be made to just LF? Sure. It's also about as likely as the > Internet byte order being switched from big-endian to little-endian. OK, I'll drop the CRLF thing, but I find it odd that the only argumentto this is "because systems and protocols designed many years ago didthis (i.e. CRLF)", and to that you add "but anyway, all these systemsjust ignore all that and behave internally like it wasn't so (i.e.convert CRLF into LF)"... As a minor note, I've seen C mentioned a lot of times, but please takeinto account that many projects aren't developed in C anymore, butinstead in Python / Ruby / Go / Rust / other "newer" languages, thatare much easier to develop in than C. Case in point, out of the 3clients for Gemini, one is in Go, one in Rust and the other inPython... > > > Okay, we use NaCL. Now what? What's needed to secure the communication > > > channel? A key exchange. Again, rule 1---never implement crypto. > > > > > > Given that one has the public key of the server (more on that later), > > one could use the following on client / server sides: > > > > https://libsodium.gitbook.io/doc/public-key_cryptography/sealed_boxes > > The linked page just talks about an API for signing and ecrypting data. > It says nothing about negotiating the cipher, key size, or anything remotely > like a protocol. (I have a hunch that you are not "acquainted" with NaCL / `libsodium`; the short story is this: the designers of NaCL (again includingDaniel J. Bernstein) wanted to design and implement a secure, simpleto use, high level cryptographic library, that makes all the choicesfor its users, so that ciphers, key sizes, padding, nonces, etc.,aren't required to be handled by the user, and thus no mistakes wouldbe made on this front.) In fact that link does say at the end under the section `Algorithmdetails` what happens behind the scenes: ~~~~Sealed boxes leverage the crypto_box construction (X25519, XSalsa20-Poly1305). The format of a sealed box is: ephemeral_pk || box(m, recipient_pk, ephemeral_sk,nonce=blake2b(ephemeral_pk || recipient_pk))~~~~ > I would ask that if you feel this strongly about it, *do > it!* Implement a client and server that uses these alternative crypto > systems and then we'll have something to talk about. What is the chance you'll change your mind about TLS? 0.01%? Are youactually considering to compare TLS vs another proposal without biastowards "legacy `gemini://` implementations currently using TLS"? > You can argue for an idea. But an idea *and an implementation* is > stronger than just the idea. I think that's why my Gemini server is so > featureful---I went ahead and implemented my ideas to help argue for/against > ideas, or even to just present *something* to talk about (when I have no > opinion one way or the other). Perhaps I'll throw a proof-of-concept in Python or Go. (Although assaid above, I think it won't change anything, as there is already alot of "investment" in TLS...) > > > One problem with that---incentives. What's my incentive to make all this > > > information more easily machine readable? On the web, you do that, and what > > > happens? Google comes along, munches on all that sweet machine readable > > > data and serves it up directly to users, meaning the user just has to go to > > > Google for the information, not your server. Given those incentives, I have > > > no reason to make my data easily machine readable when it means less > > > traffic. > > > > The incentive is a clear one: for the end-user. Given that we can > > standardize on such an "index", then we can create better > > "user-agents" that are more useful to our actual users. (And I'm not > > even touching on the persons that have various disabilities that > > hamper their interaction with computers.) > > Okay, how does that incentivise me? I don't know what incentives one to publish content; some just wantto push their ideas on the internet, others might want to help othersthrough tutorials or documentation, others hope that by sharing theyadvertise themselves, and so on... However all of the above reasons (perhaps except the first one) doneed to care about their users. > It's easy enough to add machine readable annotations to HTML. Heck, there > are plenty of semantic tags in HTML to help with machine readability. Yet > why don't more people hand-code HTML? Why is Markdown, which, I will add, > has no defined way of adding metadata except by including HTML, so popular? I don't know where the HTML micro-formats popped out in thisdiscussion, as I advocated against this approach. :) > > I'm not advocating for RDF (it was quite convoluted) or semantic web, > > or GraphQL, etc. I'm just advocating something better than the Gopher > > map. > > Okay, create a format and post it. That's the best way to get this > started. OK, I'll try to take a stab at that. (Although like in the case ofTLS, I think there is already too much "investment" in the current waythings are done.) > > > Hey, go ahead and implement that. I'd like to see that ... > > > > There is already FreeNet and IPFS that implement content-based > > addressing. I just wanted something in between that is still > > "location" driven, but is "content identity" aware. > > Again, what's stopping you from just doing it? Waiting for consensus? Yes, a little bit of consensus won't hurt anybody... Else we end-upwith TLS transient client certificates that act like cookies and whichrequire about 2 or 3 separate status codes to signal theirmanagement... :) Ciprian.