Private Messages (not through the hub)

Archived discussion about features (predating the use of Bugzilla as a bug and feature tracker)

Moderator: Moderators

Locked
HaArD
Posts: 147
Joined: 2003-01-04 02:20
Location: Canada http://hub-link.sf.net
Contact:

Private Messages (not through the hub)

Post by HaArD » 2005-01-04 22:58

I was thinking today about PM's and how they are sent through the hub from one user to another, but when those two users want to share files they negotiate a connection via the hub and then leave the hub out of it.

Would it not be possible to implement a Client-to-Client extension via SUPPORTS for Private Messages? Not a full blown IM client, just something really simple that leverages off the initial hub connection.

There is a tiny bandwidth saving from my tests on a 250 user hub
For the users however there is the security of knowing that your message is not being viewed by a PM SPY hubowner/Op.
In order to control SPAM/Advertisers those connections should be handled as invitations to chat which must be accepted before any text/message is sent.

User A invites User B to a private p2p chat

User B accepts and a private p2p chat session is opened between the clients
or
User B ignores/does nothing and the invitation expires

I have searched the forum, trackers and bugzilla and I haven't found anything similar so I thought I'd post this here first for some discussion....

ivulfusbar
Posts: 506
Joined: 2003-01-03 07:33

Post by ivulfusbar » 2005-01-05 01:20

This would require CTCP to be introduced in DC. So far this has not been included and will probably never be. In ADC, this will be possible since you can authenticate a message by the magik cookies.. ;))

I can tell you more about it live some time. You might want to search the forum for CTCP aswell. ;)) (Or the chat-logs from the dev-hubs).
Everyone is supposed to download from the hubs, - I don´t know why, but I never do anymore.

HaArD
Posts: 147
Joined: 2003-01-04 02:20
Location: Canada http://hub-link.sf.net
Contact:

Post by HaArD » 2005-01-05 10:47

I don't agree that this would require CTCP. Sure, an implementation of CTCP could facilitate this concept, but I think that's going over the top... I'm not suggesting we turn DC++ into an IRC client (wasn't that done already anyway? ;))

I did search for CTCP in the forum and dev hub logs... it keeps being mentioned, but nothing specific/applicable is ever said. I can't find any refences to cookies in the ADC spec.

A relatively simple extension to the existing C2C protocol would allow for support of P2P messaging, bypassing the hub entirely.

Feature: $Supports P2PChat

Usage: Instead of GETing or SENDing a file the client can Invite or Accept a P2PChat session.

$P2PChat <Invite> <MyIP>|
is sent by the client requesting a P2PChat.<MyIP> is the IP of the user requesting the Chat and is used if the user wants to Accept the invitation.

$P2PChat <Accept>|
is sent by the client accepting a P2PChat invitation.

Some Possible Error conditions:
$P2PChat <Error> Chat invitation refused| <-- Client blocked/refused request.
$P2PChat <Error> No invitation is pending| <-- Accept rejected.

Once a P2PChat is established the existing protocol messages can be used ($To:, or a short hand could be developed since we've already established the To and From Nicks.

$P2P <Message>|

    - A P2PChat invitation would be held in the client as pending for a time period, let's say 5 minutes.
    - Favourite Users should have an option to Auto-Accept P2PChat invitations.
    - Pending invitations could be shown several ways:
    ---> 1. Leave the connection in the transfers pane with a Status of "P2PChat Invitation" and a context menu to ACCEPT if received or CANCEL if sent.
    ---> 2. Create a seperate Tab to show/accept P2PChat invitations sent/received.
    ---> 3. Try to update a User item within a hub userlist... (messy, ambiguous, not my perferred route)
    - A different Tab colour/style would be used to denote P2P Chat vs. regular PM's

ivulfusbar
Posts: 506
Joined: 2003-01-03 07:33

Post by ivulfusbar » 2005-01-06 04:32

The problem is that is no way to identify who the user is on the incoming connection. Thats why ADC uses a cookie/token in CTM. With the help of this cookie its possible to identify the client correctly.

Code: Select all

CTM <proto> <port> TO<token>

Types: D

Connect to me. Used by active clients that want to connect to someone, or in answer to RCM. Only TCP active clients may send this. TO is a string that can be used to identify the connection in once a direct connection has been made, but is not mandatory.

Its the token-part sometimes known as cookie. ;))

The point of CTCP in IRC is that no changes in the server-client protocol was needed. You simply hijacked ordinary commands and introduced ivul special chars \001 \002 as extra syntax. The same should happen in a NMDC-solution. There is no reason to extend this protocol anymore. I do agree that client<->client chat is usefull. And it can fairly simply be embedded in ADC with some degree of authentication atleast. ;))
Everyone is supposed to download from the hubs, - I don´t know why, but I never do anymore.

Locked