Jamey Sharp @jamey@toot.cat

@keithzg @garbados I mostly liked it in this case for the position of its name in alphabetical order. I've never tried actually using it. 😅 So I'm super interested to hear what you've just said about it!

@garbados excellent, as always 😁

I kinda want to extend "From BitTorrent to Mastodon" to mention YaCy, 'cause you start with the second letter of the alphabet and only make it to the middle 😆

Also I tripped over "Napster is dead" because there's still a thing by that name today that traces lineage back to the original; but it's just a corporate music streaming service now, barely a shadow of its former self.

Anyway I love it. Even just the advice on auth{n,z} by itself is super useful, I've been meaning to dig up trustworthy sources for exactly those questions.

@woozle Ah-hah, after reading the last draft spec for SFTP: it does allow sending new requests before previous ones have completed. So a client could in theory do everything you want with it, limited only by how many requests the server is willing to read before blocking. Unfortunately people rarely bother using those sorts of features correctly 😢

@woozle Oh, even though I saw that you were talking about file managers I still managed to get confused. 😅

I don't think rsync ever uses sftp? It can tunnel over SSH, and sftp also tunnels over SSH, but as far as I know they don't have anything else in common.

I don't know anything about what protocol sftp uses. I wouldn't be surprised if it requires a separate request from the client for each file, but I would be disappointed.

Tunneling tar or zip over SSH is easy and the client could do that without any special provisions on the server. So as long as the server has either rsync or an archiver installed, any file manager that can use sftp could use that instead. I agree, it's weird that they don't!

@woozle I think the answer to "why is it slower" is that rsync first determines what files to transfer, then streams them all back-to-back; while HTTP clients generally have to make a separate request for each file, so you get extra delay due to round-trip-time between each file. In the worst case, the HTTP client might close and re-open the TCP connection every time, which would also trigger TCP's slow-start behavior.

I think it might be easy to encapsulate the rsync protocol in a single HTTP request, at least if you're retrieving files from the server, but that would require special code on both the client and the server.

You'd get a similarly good result if your server could hand you a single tarball or zip file of all the files you want. That, at least, would work with an unmodified HTTP client, so you'd only need server-side support.

Whether that's worth implementing is another question 🤔🤷

@brennen how do you feel about capitalizing "Internet"?

I finally got talked out of both the hyphen in "email" and the capital "I" in "internet" a year ago or so, but I respect your commitment

@charlag I love using Nix as a language-agnostic alternative to Python virtualenv or cabal sandbox or etc, but to some extent I think that just moves @djsundog's concern to the centralization of the Nix or Guix packages set. You can write your own local packages easily or pull in somebody's package overlays, but many of these language-specific tools offer similar options and that doesn't help if the concern is that people usually only look in one place to find things.

That said I think this is fundamentally a search/discovery question, which nobody's had too much success at decentralizing yet, I think because everyone kinda fundamentally wants to have one place to look for everything. (I know about YaCy et al and maybe someday that sort of thing will be the answer, but that's not at all clear yet.)

@HTHR yes please?