{"action":"created","issue":{"url":"https://api.github.com/repos/TokTok/c-toxcore/issues/843","repository_url":"https://api.github.com/repos/TokTok/c-toxcore","labels_url":"https://api.github.com/repos/TokTok/c-toxcore/issues/843/labels{/name}","comments_url":"https://api.github.com/repos/TokTok/c-toxcore/issues/843/comments","events_url":"https://api.github.com/repos/TokTok/c-toxcore/issues/843/events","html_url":"https://github.com/TokTok/c-toxcore/issues/843","id":305756265,"number":843,"title":"[RFC] Capability flags and message V2, alternative implementation","user":{"login":"sudden6","id":5585762,"avatar_url":"https://avatars2.githubusercontent.com/u/5585762?v=4","gravatar_id":"","url":"https://api.github.com/users/sudden6","html_url":"https://github.com/sudden6","followers_url":"https://api.github.com/users/sudden6/followers","following_url":"https://api.github.com/users/sudden6/following{/other_user}","gists_url":"https://api.github.com/users/sudden6/gists{/gist_id}","starred_url":"https://api.github.com/users/sudden6/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sudden6/subscriptions","organizations_url":"https://api.github.com/users/sudden6/orgs","repos_url":"https://api.github.com/users/sudden6/repos","events_url":"https://api.github.com/users/sudden6/events{/privacy}","received_events_url":"https://api.github.com/users/sudden6/received_events","type":"User","site_admin":false},"labels":[{"id":836103236,"url":"https://api.github.com/repos/TokTok/c-toxcore/labels/CAT:proposal","name":"CAT:proposal","color":"8effa5","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":17,"created_at":"2018-03-15T23:41:54Z","updated_at":"2018-03-17T22:32:47Z","closed_at":null,"author_association":"NONE","body":"As the first part, to handle backwards compatibility in a nice way, we should build on the idea of @isotoxin \r\n\r\n> Current core accepts only 1-byte length PACKET_ID_ONLINE.\r\nMy proposal is use this fact as end of capability sequence.\r\nOld core sends 1-byte PACKET_ID_ONLINE and new core interprets it as end of sequence, so no capability info received.\r\nNew core sends number of PACKET_ID_ONLINE with capabilities with last 1-byte length PACKET_ID_ONLINE. Old core accepts only 1-byte PACKET_ID_ONLINE and works normally. New core concatenates all >1 byte PACKET_ID_ONLINE and provides complete capability info to client.\r\n\r\n> pros:\r\n> - Full compatibility between old and new cores\r\n> - Client can access to capability info just in tox_callback_friend_connection_status\r\n> - Isotoxin already uses this scheme (except concatenation)\r\n> \r\n> cons:\r\n> \r\n>     ?\r\n\r\nFor the second part, the actual encoding, I recently came across a very promising format, http://cbor.io/ or https://tools.ietf.org/html/rfc7049 (despite the .io domain it doesn't seem to be hipster technology).\r\nIn short this is like an improved and binary encoded JSON/MsgPack combination which seems to gain traction in the IETF, especially in the world of embedded systems and IoT, because of low resource usage.\r\n\r\nThe proposed format for capabilities would be a map of features, e.g.:\r\n\r\n```\r\n[\r\n    audio : bool,\r\n    video : bool,\r\n    groups : bool,\r\n    files : bool,\r\n    client-id : tstr,\r\n    bot : bool\r\n    ...\r\n]\r\n```\r\n\r\nFor Message V2:\r\n\r\n```\r\n[\r\n    msg : tstr,\r\n    sent_hint : int\r\n    ...\r\n]\r\n```\r\n\r\nThis would then be serialized using CBOR and split into multiple packets as stated above and get passed from toxcore directly to the client.\r\n\r\nPros:\r\n- very flexible and extensible, more than a struct\r\n- binary format -> lower encoding space needed than any text based format\r\n- seems to be future proof, client picks only keys it's interested in, others are ignored\r\n- there are CBOR parsers form many languages\r\n- supports arbitrary extension, even client specific ones without breaking other clients\r\n- we could base message V2 on this, to do it in a more flexible way this time\r\n\r\nCons:\r\n- needs a solid CBOR implementation, which as any parser is not easy to get correct\r\n- a struct is still smaller, but way less flexible"},"comment":{"url":"https://api.github.com/repos/TokTok/c-toxcore/issues/comments/373957756","html_url":"https://github.com/TokTok/c-toxcore/issues/843#issuecomment-373957756","issue_url":"https://api.github.com/repos/TokTok/c-toxcore/issues/843","id":373957756,"user":{"login":"sudden6","id":5585762,"avatar_url":"https://avatars2.githubusercontent.com/u/5585762?v=4","gravatar_id":"","url":"https://api.github.com/users/sudden6","html_url":"https://github.com/sudden6","followers_url":"https://api.github.com/users/sudden6/followers","following_url":"https://api.github.com/users/sudden6/following{/other_user}","gists_url":"https://api.github.com/users/sudden6/gists{/gist_id}","starred_url":"https://api.github.com/users/sudden6/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sudden6/subscriptions","organizations_url":"https://api.github.com/users/sudden6/orgs","repos_url":"https://api.github.com/users/sudden6/repos","events_url":"https://api.github.com/users/sudden6/events{/privacy}","received_events_url":"https://api.github.com/users/sudden6/received_events","type":"User","site_admin":false},"created_at":"2018-03-17T22:32:47Z","updated_at":"2018-03-17T22:32:47Z","author_association":"NONE","body":"I think clients definitely need the ability to have access to the raw data to quickly integrate new extensions without needing a new c-toxcore release every time. I can live with additionally letting c-toxcore decode the well known or standardize elements to a struct, though."}}
{"actor":{"display_login":"sudden6"}}