Document protocol extensions.

[meh]

I'm the author of ruby-torchat and I was going to extend the protocol myself to add groupchat support but I see you've done something about it yourself.

I'm probably gonna support my own groupchat anyway but I'd probably like to support jtorchat's implementation too.

To make it understandable for both parties you could add the support packet I added that tells the other end what extensions it supports. It's a simple packet that contains a space separated list of extension names. It is sent after the client and version packets.

[zerotamaitsu]

never heard of ruby-torchat before, that's really cool! I think it would be better if we come together with a common standard for groupchat, instead of disjointed standards. Groupchat is planned, however we need to focus on ensuring stable codebase first before we can jump towards groupchat. How is your project so far? How far along and stable is it?

You may also be interested in the planned, 'broadcast mode' and 'remote addressbook'.

So by the way, why ruby? Why not original python, or java? We chose java because of the availability of volunteer programmers and the fact it can be used in many platforms.

There are talks between us about what to do after jtorchat, and one of the idea is to develop a 'network agnostic' IM/Email protocol that will operate in both i2p and tor and future anonymous networks. I believe it would involve usage of DHS tables.

On Thu, Apr 12, 2012 at 12:01 PM, meh. < reply@reply.github.com

wrote:

I'm the author of ruby-torchat and I was going to extend the protocol myself to add groupchat support but I see you've done something about it yourself.

I'm probably gonna support my own groupchat anyway but I'd probably like to support jtorchat's implementation too.

To make it understandable for both parties you could add the [support]( https://github.com/meh/ruby-torchat/blob/master/lib/torchat/protocol/standard.rb#L109-127] packet I added that tells the other end what extensions it supports. It's a simple packet that contains a space separated list of extension names.

---

Reply to this email directly or view it on GitHub: https://github.com/jtorchat/jtorchat/issues/14

[meh]

Agree on trying to come up with something together, I already designed the groupchat protocol though, I just have to implement it.

It's pretty stable, same goes for the bitlbee plugin, the only missing part from the standard protocol is implementing an usable interface for file transfers.

I am interested in all extensions, I want to ensure that ruby-torchat is compatible with most implementations as possible.

Ruby because I don't like Python nor Java. ruby-torchat is not an implementation with GUI and such, it's a library to deal with ruby-torchat, you can code anything from that. The usable implementation from the user point of view is torchatd, which is a daemon to interface to the torchat protocol with a simple connection (netcat or the like). I implemented it this way to implement a functioning bitlbee plugin.

Ruby can be used on many platforms too by the way.

As of now my target is only to support torchat in bitlbee properly but it could be interesting to think about a network agnostic IM protocol.

[zerotamaitsu]

You already designed a groupchat protocol? Can you show us the design paper, I would like to see how it stacks up with our current proposal, have a look at https://github.com/jtorchat/jtorchat/issues/7 for instance.

Essentially it relies on a common 'member list', where everyone has a direct connection to each other, it also has a limited resilience against partial disconnection within the network. Ours current design however drops the p2p broadcast method which would require cryptographic signing to prevent spoofing, as it would be more complex to implement (and thus is less likely to be adopted by other projects like yours). It can still have the potential for 'message verification' via cryptographic signing in the future thought with a 'flag', I'm sure.

If there are some differences between us, then what are some of the things you recommend to keep or drop between our proposed group chat protocols.

[Oh I also forgot another jtorchat only extension: you may also be interested in the fact we also have a 'page' system, to share small amount of text automatically between users. (kind of like a personal pastebin) ]

idea for your ruby-torchat daemon: IRC bouncer gateway. (allow torchat users to hang around an IRC channel anonymously, but with a consistent identity)

On Thu, Apr 12, 2012 at 12:46 PM, meh. < reply@reply.github.com

wrote:

Agree on trying to come up with something together, I already designed the groupchat protocol though, I just have to implement it.

It's pretty stable, same goes for the bitlbee plugin, the only missing part from the standard protocol is implementing an usable interface for file transfers.

I am interested in all extensions, I want to ensure that ruby-torchat is compatible with most implementations as possible.

Ruby because I don't like Python nor Java. ruby-torchat is not an implementation with GUI and such, it's a library to deal with ruby-torchat, you can code anything from that. The usable implementation from the user point of view is torchatd, which is a daemon to interface to the torchat protocol with a simple connection (netcat or the like). I implemented it this way to implement a functioning bitlbee plugin.

Ruby can be used on many platforms too by the way.

As of now my target is only to support torchat in bitlbee properly but it could be interesting to think about a network agnostic IM protocol.

---

Reply to this email directly or view it on GitHub: https://github.com/jtorchat/jtorchat/issues/14#issuecomment-5090090

[meh]

I haven't written it down properly, I just wrote the design succintly in a notebook while I was out. I will write it down soon in the source within the packet implementation in my source code though, as soon as I have it I'll link it here.

There's no message verification in my design, you'll see, I should be done writing down the design and the packets before this evening, I'll report back as soon as I have it.

Apropos the IRC bouncer, I'm not much interested about it because with BitlBee you already get all the IRC goods.

By the way, if you could document all the extensions in the wiki or somewhere else and point me to it I'll look into implementing those extensions.

[zerotamaitsu]

I see. Do you think our implementation still counts as a sort of 'message verification', and what do you think about it? This is referring to the 'trust ratio' aspect of message received indirectly from sender.

Do you think you can integrate that idea with your design?

On Thu, Apr 12, 2012 at 1:38 PM, meh. < reply@reply.github.com

wrote:

I haven't written it down properly, I just wrote the design succintly in a notebook while I was out. I will write it down soon in the source within the packet implementation in my source code though, as soon as I have it I'll link it here.

There's no message verification in my design, you'll see, I should be done writing down the design and the packets before this evening, I'll report back as soon as I have it.

Apropos the IRC bouncer, I'm not much interested about it because with BitlBee you already get all the IRC goods.

---

Reply to this email directly or view it on GitHub: https://github.com/jtorchat/jtorchat/issues/14#issuecomment-5091080

[zerotamaitsu]

Oh, as for the other extension, we are not ready to codefy it as it may potentially change before V1

On Thu, Apr 12, 2012 at 3:01 PM, Eliza Burkes jtorchat@gmail.com wrote:

I see. Do you think our implementation still counts as a sort of 'message verification', and what do you think about it? This is referring to the 'trust ratio' aspect of message received indirectly from sender.

Do you think you can integrate that idea with your design?

On Thu, Apr 12, 2012 at 1:38 PM, meh. < reply@reply.github.com

wrote:

I haven't written it down properly, I just wrote the design succintly in a notebook while I was out. I will write it down soon in the source within the packet implementation in my source code though, as soon as I have it I'll link it here.

There's no message verification in my design, you'll see, I should be done writing down the design and the packets before this evening, I'll report back as soon as I have it.

Apropos the IRC bouncer, I'm not much interested about it because with BitlBee you already get all the IRC goods.

---

Reply to this email directly or view it on GitHub: https://github.com/jtorchat/jtorchat/issues/14#issuecomment-5091080

[meh]

I see. Do you think our implementation still counts as a sort of 'message verification', and what do you think about it? This is referring to the 'trust ratio' aspect of message received indirectly from sender. Do you think you can integrate that idea with your design?

I avoid indirect message sending completely, I think it's better to avoid that kind of thing in a groupchat implementation related to torchat. If someone dies he dies. Though if someone died it could be asked a groupchat_history or something.

I'm almost done commenting the packets.

[meh]

Here it is, if you want you can add me on torchat and we can discuss the thing a bit more thoroughly. Or on IRC, choice is yours.

[jtorchat]

What is our Tor ID? My is: bgboqr35plm637wp

Can you please write in a document all Tags from your Groupchat so it is easier for me write it on jtorchat and we can post this in the wiki and help people to learn more over it.

[meh]

I'll write a markdown file with a more thorough explanation including the description of all packets.

On an unrelated note I think I will write some documentation for the standard protocol too, including my supports packet, it could always be useful to other implementors.

[meh]

Here it is, I also added a typing notice extension which could be useful.

If you need any more clarifications just ask and I'll add it to the documentation.

[meh]

I noticed I forgot to put here my id, it's 7acbk6jpofsanyfp, if anyone wants to discuss about protocol extensions I'll be glad to do it, if I'm awake I'm also on torchat, unless I'm testing some new feature.

[zerotamaitsu]

Had a look at your implementation documentation. I see that 'group member list' is centrally managed by the 'organizer', but that also means that if the organizer 'goes offline' the group also goes offline.

[meh]

No, the group member list is not managed by the organizer.

The group member list is noticed to the invited on invitation, that's all. The organizer only happens to be the first that invites someone, then everyone can invite anyone. In addition every participant can ask other participants their list of participants to keep in sync with it.

[zerotamaitsu]

Okay thanks. Closing this issue now as we have agreed upon the standard in https://github.com/meh/ruby-torchat/tree/doc/doc/protocol regarding groupchat.