Protocol Extension Library

[sphaerophoria]

Hey toxcore devs.

I've been toying recently with the idea of a couple protocol extensions. For example in qTox I'd like the ability to properly show code blocks, or share custom smileys with a friend, or be able to pack multiple messages together into one.

All of these things currently I cannot do without hooking into the custom packet type, but that got me thinking that it would be quite hard to coordinate with other clients and could ruin the experience when interacting with other clients.

I was thinking that a decent solution to this would be to have a way of telling a friend which extensions you support and doing some form of client negotiation, to accomplish this I wanted to write a simple library (API design is not very flushed out yet due to my uncertainty that it would be accepted by the community). This library would wrap the custom packet type and have a slimmed down api along the lines of

typedef void(extension_callback_fn)(int friend_id, char data);
int register_extension(char* extension_uuid, extension_callback_fn);
int send_extension_data(char* extension_uuid, int friend_id, char* extension_data);
int check_friend_extension(char* extension_uuid, int friend_id);

Would this type of library be against the tox way? If I started then implementing extensions on top of this library would I be stepping on anyone's toes?

Thanks for the feedback!

[SkyzohKey]

• Show code blocks: Can be done with regular methods/events and handled client-side.
• Custom smiley: file transfers, handled client-side (inline image)
• Multiple message: client side stuff.

No need for custom packets here, just to use the ToxCore API. For the client coordination, we have The TaCoS for that (Tox Client Standard). 👌

[sphaerophoria]

How would you mark a custom smiley as a smiley? What happens if im using a different client as someone else? Do i just get garbage file transfers? What do you mean by "client side stuff" the clients need some way to coordinate what theyre doing right? Just because i send two messages back to back with the first being max packet size doesnt mean the next is part of the same message. I dont want to pollute messages with client specific garvage because that ruins the experience when interacting with other clients.

I think there are many cases where a defined way for clients to talk to eachother through a side channel not exposed to the user is very benneficial and could allow clients to implement features that currently would only be cleanly implemented by updating the protocol

[iphydf]

@sphaerophoria I'm very much in favour of building things on top of the custom packet functionality in toxcore. I'd be happy to review a concrete API proposal. Let me know when you have something, or if you want to chat about it some more.

[sphaerophoria]

@iphydf cool thanks. Just wanted to make sure I wasn't stepping on anyone's toes :).

Haven't quite decided how I wanna go about it yet but I'll keep you in the loop. Haven't done a lot of protocol design so it'll be nice to have your reviews when I've got something more concrete.

I notice you've marked this with a milestone, I was going to close this once I got a go ahead but I can leave it open for tracking purposes if you'd like.

[iphydf]

Would you prefer to contribute this library into toxcore, or as a separate repository? If the former, then we can keep this open until the first version of the library is merged. If the latter, we should rename the issue to make sure the title doesn't mislead people reading the changelog. Either way, every issue should be on a milestone, so its closure is associated with a release.

[sphaerophoria]

if that's an offer to sponsor the idea later as part of the toxcore project thats probably the ideal case for me :).

[iphydf]

This is still a good idea. If anyone wants to work on this, I'm happy to advise.

[Green-Sky]

https://github.com/toxext/toxext

related?

[iphydf]

Yes that's it, thanks. Let's discuss enhancements there.