irungentoo/toxcore — pull request #1148 by ittner (2014-11-02 23:06:30+00:00)
Title: Allows tagging file transfers with MIME-type information

To start with, **this change breaks both the API and the file transfer protocol**

Rationale: To implement this feature, it was necessary to change the format of the file send request and the related API calls and callbacks. It would be easy to avoid the breakage by aliasing the old packet IDs and API calls to the new ones, but this would create some bloat in the library and in the protocol. As we are alpha, I suppose it's better break the protocol and keep the things elegant. An input from the Tox developer community is required here and, ideally, code should be readied to fix this in the major clients before this branch is merged (If there is interest on this, I'm ready to submit fixes to uTox and Toxic).

This commit adds support for tagging file transfers with MIME type information, as proposed in issue #1084, allowing clients to implement some features which need reliable background transfer of arbitrary data. This effectively creates a RPC sub-protocol in Tox, with all features and options defined at client level and without more changes to the Tox core protocol. Typical applications are support for WhatsApp-like voice clips (issue #1080), better handling of inline images, and customized stickers (issue #1106). Other applications may include automatic synchronization of node lists, etc.

For this feature be useful, client developers must agree in some standardized MIME types, which rules should be applied, and how to handle unsupported message types. For example, Speex-encoded short audio messages may be send as a file transfer tagged with the type "message/x-tox-short-message-speex" and the client may accept it automatically if they come from authorized friends and are within some limits (e.g. each friend can send up to x messages of at most y KB each).

Ideally, receiving clients should reject ANY file transfer tagged with "message/x-tox-*" unless they support that specific feature and sending clients should behave accordingly (e.g. showing the error message "Your friend's client does not accept recorded audio messages" instead of "File transfer rejected").