Haw. I made quite the same service, curl compliant and stuff except it encrypts the file on disk upon reception (creating an AES cipher, piping the file through it while receiving it) and sending back the id of the file and the key that allows decryption of said file. If anyone is interested there's plenty of documentation, even a client that allows to take screenshots and upload them on the fly.
Very cool, though I find it a little odd. If someone is going the extra mile to store the file encrypted, it stands to reason that trusting the service with the initial unencrypted byte stream is a no-go. The file being uploaded over HTTPS, and your assurance that the stream is piped directly through encryption, is of little consequence if you or an infiltrator to your server were to choose to be malicious.
I understand it's impossible to tool the concept to work with a very simple shell one-liner, and without a further dependency like an openssl binary. I like the concept, but I'd rather have to perform a one-time install of openssl or similar and copy a 10-20 line bash script to have true security rather than your current setup that comes with a technically flawed security model.
Obviously you are aware of this, and chose the path of convenience and "good for most uses". Kudos for a clean tool!
Obviously it comes to personal judgment when people use my tools. I mean they could also do as described in transfer.sh, pipe first the data through gpg. The server accepts any kind of data as long as it doesn't overflow the current set size limit.
But indeed I do agree that I can't guarantee or even prove that I can't access the files on my server. That's why I offer a quick and simple way for people to setup this on their own machine, so they can have this lightweight server and use it as if it was mine just by modifying a line in the configuration file of the client (or changing the URL in the curl commands)
I also made a similar service, mostly for my own needs so it's kinda spartan, I find it convenient for grabbing stuff off my clipboard and screenshots/captures:
Targeting the JVM seems like a trending practice nowadays. But I can't really see why it's so great. You'll need to install the JVM to your platform before you can execute anything. You'll also need to install it on your server to serve a web application. I don't know how that works but it sure adds some complexity to the deployment.
People like JVMs because they provide a lot of services that are really useful, such as:
• State of the art garbage collectors, which you can tune for throughput or low pause times (there's a fundamental tradeoff here, there's no one-size-fits-all GC algorithm)
• Visual debugging that always works, including remotely
• Stack traces that always works
• Advanced profiler and monitoring tools
• Very robust and portable build systems
• Extremely fast compiles (this is touted as an advantage of Go, but I never find myself waiting for a compiler when working with Java or Kotlin).
• Giant standard library and even larger ecosystem of well designed and documented libraries to do many different tasks
• Language interop - you can normally use libraries written in one JVM language from others. This obviously helps with the former point.
• In some cases (e.g. actor frameworks and big web servers) code hotswapping and dynamic loading.
The Go runtime lacks a good chunk of these useful features: the last time I worked with a Go shop they told me debugging hardly worked, because error handling was "propagate an error code" they never had stack traces in their logs for failures, profiling was primitive or not available at all depending on platform, the standard library was small (compared to the JDK), and language interop was "it can call C". Also the GC sucked, though I heard they have a better one now. But it's still a one-size-fits-all approach, which has well known problems.
It seems to me that the majority of those features are a result of Java being 20 years old. It's entirely possible Go could achieve or surpass those features by its 20th birthday.
Maybe we should stop fighting over languages and focus on the things you can create with them ? I honestly see no point in creating blog posts about "Why this language sucks". It's quite always a subjective point of view, and the whole goal of this kind of article is generally to drag people away from a language.
People are using Go. They create content with Go, they create amazing stuff, sometimes they realize that Go isn't the best language to create this or that and so they switch to something else. What's the point there ? If a language doesn't fit your exact use cases, then it's a bad language ?
Stop the impossible standards of the perfect language. Real languages have flaws !
https://up.depado.eu
So yeah it's limited to 30MB for now because I don't have a lot of storage but hey I use that daily hehe