Stateless File Sharing: Source Attachment and Wrap-Up
pubsub.movim.eu / Dino · Saturday, 12 November - 00:00 · 2 minutes
Stateless file sharing (sfs) is a generic file sharing message which, alongside metadata, sends a list of sources where the file can be retrieved from. It is generic in the sense, that sources can be from different kinds of file transfer methods. HTTP, Jingle and any other file transfers can be encapsulated with it. The big idea is that functionality can be implemented for all file transfer methods at once, thanks to this wrapper.
The idea is simple: Once somebody started sfs, anybody can contribute more sources to the list of sources. A sfs-attachment consists of the message id of the original sfs, as well as a list of sources that should be attached.
You might ask: “But why? I have used many messengers and never heard of such a feature, why should somebody else in the chat be able to do that?”
I was surprised as well, but there actually are some reasonable use cases.
- Peer-to-Peer file sharing in groups
- Reviving dead download links
- Announcing file uploads before the upload is finished
We obviously have to prevent the possibility of other members attaching wrong files to other people’s sfs. To prevent this, sources can only be attached to sfs, which have checksums in their metadata.
Clients need to dismiss source attachments,
- if the sfs didn’t provide a checksum
- if the checksum algorithm is not trusted or unknown
- if the checksum of the downloaded file doesn’t match
Google Summer of Code Retrospect
This was the first time with Google Summer of Code and honestly, it’s been a nice ride. I’ve come to enjoy my stay and take pride in finishing the different components.
When I started earlier this year, I had developed a bit of an Imposter syndrome . For one I wasn’t sure if I understood the full scope of the project, but I was also uncertain if I had the skill to work on it.
Confidence came over time, when I managed to get an overview of everything that needed to be done. Everything suddenly looks much more manageable, when you understand the purpose and inner workings of each subcomponent that will be required over the way. Of course, it’s not completely straight forward. I often had to realize that I will need another component somewhere, but one thing at a time is manageable. Since I had my mentor to back me up whenever I got stuck, working on the project didn’t get frustrating.
Parallel to working on the project, we were expected to publish blog posts. Originally I was going for a weekly interval, but yea…
I don’t think writing the blog posts helped me in any meaningful way. However, I do think writing blogs is a good habit and hope that
- I improved my blog writing skills
- The blogs will someday help someone
The GSoC period has already finished. See my pull request .