It has been a while since we mentioned tus, but there have been some cool developments and we would like to refresh your memory.
So yeah, uploading is broken
At Transloadit, we care about providing a reliable upload service. Sometimes, however, it could happen that our servers misbehave, that a mobile user switches connections, or that your end user has unstable WiFi.
We are always doing what we can to limit cases like these, but also have to face the stark reality that too often an upload needs to be retried from the start.
This leads to a bad user experience, especially if it happens right in the middle of a 2 GB upload on a poor connection. What is even worse, the longer an upload takes, the longer it is exposed to this poor connection.
With media getting bigger and networks remaining fragile, we need a better way to handle these outages and hiccups.
Even though any decent network library implements retries, there is still much that can be improved. In an ideal situation, retries would pick up where the user left off and only upload the remaining bytes as soon as the connection is restored.
If this happens under the hood, so to speak, the user might not even notice that he had an interrupted connection, since the total upload time would barely be impacted.
Additionally, if we could redesign this in such a way that allows us to send multiple file parts simultaneously, the upload might even become faster.
However, for all of this to work, we first need resumable uploads.
There are many pieces of software and various implementations that already offer resumable uploads, but they are not as thorough or interoperable as we would like. They all speak a different dialect.
Imagine every web browser having its own incompatible HTTP dialect. We don't think that is how an open web should work.
A thousand incompatible one week projects that barely work, when all we need is one real project, done right.
And that is exactly what tus is.
Here is an example of what a simple back & forth would look like between a client and server that can speak tus 1.0:
# Client: > POST /files HTTP/1.1 > Host: tus.example.org > Content-Length: 0 > Entity-Length: 100 > TUS-Resumable: 1.0.0 > Metadata: filename d29ybGRfZG9taW5hdGlvbl9wbGFuLnBkZg== # Server: < HTTP/1.1 201 Created < Location: https://tus.example.org/files/24e533e02ec3bc40c387f1a0e460e216 < TUS-Resumable: 1.0.0 # Client: > PATCH /files/24e533e02ec3bc40c387f1a0e460e216 HTTP/1.1 > Host: tus.example.org > Content-Type: application/offset+octet-stream > Content-Length: 30 > Offset: 0 > TUS-Resumable: 1.0.0 > > [first 30 bytes] # Server: < HTTP/1.1 204 No Content < TUS-Resumable: 1.0.0
Apart from being a lightweight and well documented protocol, tus also provides two example implementations:
Additionally, there are many community provided implementations in languages like iOS, Android, Ruby, Node.js, Python, PHP, etc. Since we are building tus on top of plain HTTP, it is very straightforward to build implementations in your favorite language. If you fully implement the protocol and license it MIT, we will certainly consider adopting your project.
Nearing 1.0 - Last Call for Feedback
The news today is that we are really close to releasing a stable 1.0 version of the protocol and our reference implementations. For that reason, we are now calling for one last round of feedback over at our 1.0 pull request on GitHub.
Please don't be shy. We would love to hear your comments and recommendations on how to make tus 1.0 even better.
Finally, we encourage everybody who deals with uploads (yes, competitors too) to have have a look at tus and consider using it for your next release. Even though tus was started and funded by Transloadit, it is fully community owned and this will never change.
Here at Transloadit, we will be looking to implement tus in our upload and encoding service this year.
Welcoming comments on Hacker News