An Open Content Exchange Standard

Every year, computer hardware is becoming more powerful and efficient, which means the software running on it should utilize its capabilities as efficiently as possible, and this may become a challenge when the software is proprietary, and only its creator can change or improve it.

Most protocols are an example of this because usually, they are not open to the use of other solutions, causing inconsistency when the users are out of the ecosystem they support.

An open protocol can fix this issue by enabling developers to create new solutions and allowing those to communicate with each other.

What is the problem?

Most protocols are either not open enough by not documenting how they work or proprietary, making it harder for third-party solutions to support them.

Apple's AirDrop and other similar solutions will work as long as you are using them in the environment that their developers intended them for. You are out of luck if you use AirDrop to send a file to a device running ShareIt because their protocols are incompatible.

If you were to create a new solution that would work with any of these, you would need to log the communication process and replicate it, which is not intuitive and may be illegal.

What may be the reason for this disconnectedness?

This problem doesn't gain any traction because everyone has their number one solution for transferring content, and it works for them. You send A to B with C, and when C is missing, you install it, and if it is not available in any way, you do D.

If you ask people what they use to solve the content exchange problem, you will receive many replies suggesting a different approach, but they will never recommend a solution that does it all. They will say this has this thing missing or that doesn't work on that and similar.

We don't pay too much attention to this inconvenience because we know one solution will work in the end. However, we forget it takes more time to do a simple task when nothing works.

What will this fix?

If developers can adopt an open protocol, users will not need to use a specific solution. They will be able to use any solution made by anyone. After all, what they choose will have little importance in the case of transferring files. They will have the freedom to pick any solution based on their platform and quality.

What do users gain?

Most people have limited resources when it comes to paid services. The internet may be limited or slow; they may not have the proper hardware or the configuration, or they may be in a place where their existing solutions don't work.

Because most solutions are nowadays proprietary, it looks as though the need for this type of protocol is unnecessary. However, this view has proved itself wrong after Xiaomi, OPPO and Vivo launched Peer-to-Peer Transmission Alliance¹ for better compatibility between their products. But they didn't post the details for the protocol they use, which shows somebody has to take the lead and do it for the community.

With an open specification, users won't need to wait for an alliance to include their feature requests. They can join the discussion at any time.

Why not existing protocols?

Existing protocols—FTP, BitTorrent, SAMBA, and others—are not end-user friendly. They need a central server configured beforehand, or, as in the case of BitTorrent, they need trackers distributing peers.

Another problem is these protocols are trust-oriented. FTP and SAMBA have users, paths, and permissions to manage. For a better user experience, servers and clients should be unaware of each other before introduction and become acquainted after the first communication.

Isn't there an existing protocol addressing this problem?

BitTorrent is near perfect, but it is too far away from the experience I would like to have with TrebleShot and other solutions in general. It doesn't have a validation process for the clients, and adding on top of it may need unnecessary work.

Teleport² defines a simple diagram with the HTTP protocol on top, but it is too simple to be useful, and HTTP may be unnecessarily over-bloated for a task like this. The new standard should be easy to port to different OSes and frameworks. The base protocol should at least be related to file operations similar to FTP and BitTorrent are.

Development process

Because many things are undecided at the moment, everything is open for discussion. I have experimented with TrebleShot and created CoolSocket³, a TCP messaging library, but I haven't looked into other standards that may be better.

If a proper protocol surfaces before the development begins, we can build on top of it. However, there seems to be none at the moment.

I have created a GitHub organization for an experimental protocol called Universal Content Transportation Protocol⁴ or uprotocol for short. The names are also open for discussion.

I hope that the protocol will take shape in the coming months, and we will be able to implement it in apps like TrebleShot soon. The specs will be defined and showcased in the specs⁵ repo in the uprotocol organization.

If you are interested, create a discussion by opening an issue.