Could it be more stable and fast?(implementation of "message agent module")

[selay01]

Notice:

I opened a new issues in TokTok/c-toxcore:TokTok#532,there we can talk about this issue and correct it.

This issues should be closed.

All below is still necessary to know before jumping in there:

How does the toxcore work，is there a brief and complete description about how does it work in detail?

Here, i assume that the toxcore is default using a "onion model"(if not,not too much influence yet).

Could it be more stable and fast,at least an option? :

Part "1":

so far, tox client can just send message when both are online. It's unstable(might because the NAT am in),and not fast enough especially sending a picture or big file, A/V is failed so far for me...

Part "2":

to make it stable and fast,provide a optional and not default "Message Queuing Transport Protocol" based on a customable and reliable message agent(in brief,MA) might be useful:

• 2.1
  a MA is not diffrent from a common node;

  a node maintain a "slaver-list",and has function <limited "message queuing" store-resend and "feedback queuing" store-resend,resend message directly to target node just when both are contained in its "slaver-list"> called functionMA ;

  functionMA just automatically started when the node accept to be another node's MA,and automatically stoped when "slaver-list" is empty;

  the node become a MA just when the "slaver-list" is not empty ,and just provide the functionMA for node in the "slaver-list".

• 2.2
  one node could send message to the MA at the highest priority for the first jump just when it "successfully chosed the MA as its message agent”.

  here "successfully chosed the MA as its message agent” means:
  first,a node should choice a MA(by the MA's id,just like add a new friend) as its message agent manually,and then,the MA should choice accept or deny("deny" is defalt) in a certain period manually,this kind of reliability is created by the person who owns the MA(in fact,another node) and the node too:if a node didn't choice the MA or the MA didn't accept,thus nothing will change.

• 2.3
  the node successfully chosed the MA as its message agent should store the MA info into its "MA-list",and the MA should store the accepted nodes's info into its "slaver-list";

  the node and the MA should keep update automatically,renew the id+ip+port+timestamps and ensure MA's "slaver-list" contains the node just when the node's "MA-list" contains the MA's id.

• 2.4
  a node could have several MA at the same time,but just one best that could send message to another node;

  a MA's "slaver-list" could contains many node_ids if it has the power.

• 2.5
  two nodes(node_A and node_B) want to chat by a model "node_A-MA-node_B",they should successfully chosed the same MA as its message agent respectively.

• 2.6
  client program should provide sevral model:"onion model"(or what's default at present),"MA model",and plus a "self define";

  defaul model should be one of the "onion model" and "MA model","self define" is at the highest priority.
  when using "MA model",and the "MA-list" is empty, it will directly send message;

  when active "self define",it could specially set a friend using "onion model" or "MA model",and others using default model.

• 2.7 when send message to a node using "MA model":

  if frind B of A is online,just exchange message directly and not by "onion model";

  if B is offline,and A has "successfully chosed the MA as its message agent”:
  a list(timestamp ,the message,hash on the timestamps and the message) called listA generated by A will be sent to the MA by A,A and the MA both store the listA in the message queuing;

  A and MA knows each other's online status,MA just send message when A is offline;

  if B get online,and A is still online,no matter MA is online or not,A should resend the message to B directly,B response a status to A, A will creat a listB(timestamp,hash),and send listB to MA(if MA is online) and delete the listA from its "message queuing",MA will delete the corresponding member from its "message queuing",if MA is offlin,A will store listB in its "feedback queuing" waiting to send to MA when A and MA both online;

  when B get online,and A is offline,MA will resend the listA to B,B will check if the message repeated and decided show it or not,and then response a status to MA, MA will creat the lisB like above,and store listB in its "feedback queuing",and then delete listA,waiting to send to A when A and MA both online;

  whenever A or MA offlined,when they get online again,the "feedback queuing" should be resend firstly and clean the listA and listB secondly,then waiting to resend the the "message queuing".

Part "3":reasons

• this design give up some privacy to solve problem in "1" to get the convenience;

  but for people has the problem in "1",they mostly in a NAT and has frequently changing IP,this is worthy for many of the people,they just need encryption their message and ensure send it successfully even not both online!

• by this design,people has the option to has their own server: a server on a cloud that is aways online,a computer that usually online,or even a voluntary mobile device!

• this will actuate a more active Tox DHT network,for zones that has little nodes is very effective.

• if more nodes were created,but many of them choice using a "MA model",people using "onion model"(if it has) will have more jump nodes to to protect their privacy.

[SkyzohKey]

Toxcore as moved to a newer repository. Please open your issues in TokTok/c-toxcore. Also please read your messages twice before sending them and apply formatting for long messages like this one. It will increase the readibility and by so help you getting faster answers to your questions. It also allow better understanding of your questions

To answer one of your questions, c-toxcore etablish a direct connection between you and your friend, there is no onion involved when messaging. Onion is mainly used in friend requests to prevent people to know your IP address if you didn't accepted/added them. Of course, you can use the Tor SOCKS5 proxy in combination with ToxCore to enable onion for every packet.

[selay01]

Because "irungentoo/toxcore" is the Toxcore most clients currently use,i didn't notice "TokTok/c-toxcore" too much.

"irungentoo/toxcore" referred to the URL "https://tox.chat/" the same as "TokTok/c-toxcore" has referred to,
but "irungentoo/toxcore" didn't mention "TokTok/c-toxcore" obviously.
I think info on "tox.chat" might prove that "Toxcore has moved to a newer repository".

But,now the question is:
Will "irungentoo/toxcore" and "TokTok/c-toxcore" compatible in the future,or has irungentoo abandoned "irungentoo/toxcore"?

[GrayHatter]

I'm highlighting @anoadragon453 because he's working on the offline messageing spec

[GrayHatter]

@selay01; @irungentoo has said he wants to pull from downstream once he's able to go over the source, and if it's better. He's not set a timeline for either, and it's not yet adding anything better than exists now.

[selay01]

@GrayHatter; @irungentoo
So,the "TokTok project plan" and its Roadmap will be the long-term direction?!

Things on TokTok project is specific and complete,and the most important is it's social collaboration and looks very high effective.

[selay01]

@SkyzohKey @GrayHatter

I have applied formatting,but changed little thing,even though the wrong assume that "the toxcore is default using a "onion model" " is still unchanged,because it just have little influence.

I opened a new issues in TokTok/c-toxcore:TokTok#532,there we can talk about this issue and correct it.

This issues should be closed.