Talk:Extensions
From ADC Project
Please sign your comments!
Contents |
ADCS
- how should clients act if it receives a ADCS in support?
# Should it read/send all messages afterward as TLS communication? # Should it wait/send some sort of command? # Should it close this connection (if it is not a tls connection) and then start a new one?
- What algorithms should be supported?
- What TLS version should be used?
# Should we use the spec that allows OpenPGP?
--Flow84
Hi. I have thought about ADCS and how we can improve the world of Direct Connect, and the ADC network.
First, I looked over to see how DC++ ( and clones) create the certificates they use for ADCS connections. The certificate doesn't seem to be signed, and it's granted actually to that CID ( client's unique id ).
I want to propose something about how to make this more secure for both hubs and clients who want to connect ( mostly clients who have certain rights on the hub ). This is intented to replace password-based login.
First of all, let's start with a hub. After the hub is being set in normal ADC mode, the user needs to switch to ADCS. In this moment, the hub makes a certificate request to a CA [1], that temporarily grants him a certificate signed by this CA, hereby making the hub authoritative for it's own users.
[1] : I propose the CA to be somebody of trust in Direct Connect, that can also monitor hubs and even revoke certificates for the hubs that don't respect certain rules ( moral rules, the general direct connect rules...etc ). My first suggestion is a big hublist , with great influence ( these people also monitor hubs regularly ). Once the hub has this certificate from this CA, then users can connect to it safely ( It would be nice if clients could implement the CA's public key and check the certificate's signature, and at least warn users on login if the hub is not signed by the CA)
The second step of this thingy is to create user accounts on the hub. For this, each client creates a public and a private key. The hub should be able to have an input for a client's public key, and create a certificate for the client signed by the hub. This way, the client can login to the hub ( in which moment the hub checks if the certificate is signed correctly by itself ) and grant the respective user with all the rights given . No password needed, and the security greatly increases since the client's private key is never sent anywhere so he's the only one who can use the certificate, and only the hub who signed it can actually decipher it and accept it.
I'm in the disposition of implementing all this in DSHub for the hubsoft part.
( PS : there should be a way of getting the client's pub key by SSL services right? ( haven't tried them too much ))
--Pietry , 3 June 2008
REGX
If both AN ( or similar ) and RE are present, what should client do ?
Does RE replace other search tokens completely on this extension ?
--Pietry, 13 jan 2008
- Well, my guess is that the field doesn't exclude other fields. Using AN and RE means probably "I want everyone to send me back results, even if you don't support regex, and I'll just include the ANs that are similar to the RE." Regexs are just compact expressions, used instead of multiple fields. (Yes, I added the extension to the wiki, but I just copied it from the old spec.) --Ullner 11:59, 13 January 2008 (PST)
DFAV - Distributed Favorites
Some points of discussion:
1) Should there be passive support for distributed favorites, or is it to much traffic for the hub to allow such commands.
2) There is a field last succesfull login, what date/time format should there be used.
RGF
Contexts: T
Reverse GFA
Asks all users within the same hub with the correct feature to open a port where the user using reverse GFA will connect and get publicly available hubs. ( Connection to all is not mandatory ) Active clients could keep the port open all the time for some eventual connection. Question : in that case is the command necessary anymore? ( since active already have opened a port ) --pietry, 31 dec 2007
- I'd replace the GFA context with C, as the hub probably don't and shouldn't care. --Ullner 09:31, 1 January 2008 (PST)
- The only role the hub might take is cache the results. Pur 2 Jan 2008
- Is that an agreement on my suggestion, a comment that it should/could be both C and T, or a disagreement altogether? --Ullner 13:48, 3 January 2008 (PST)
- It is an agreement, and has been changed. Pur, 12 Jan 08
- Regarding 2), I think RFC 3339 - Date and Time on the Internet: Timestamps should be used. --Ullner 09:32, 2 January 2008 (PST)
- I quickly browsed through it, are you suggesting supporting the whole grammer as in rfc3339 or specify it futher down to one possible variant. Pur 4 Jan 2008
- To keep things simple, we could use the simplest format in the RFC; date-time = full-date "\s" partial-time. (That is, ignoring the offset). So, it's eg "LG2008-01-01\s12:12:12", which is simple for the client to parse. All times could, as in the RFC, be in UTC. --Ullner 06:55, 5 January 2008 (PST)
- Time/date format set as Dj_Offset suggested seconds after epoch (1970) UTC. Pur, 12 Jan 08
PING - Pinger extension
What is the purpose of the HH field? Don't the pinger know which address the hub has (how else did it know where to connect?)? How about adding the context T, and allow clients (well, hubs) (at this point, HH is valid) to connect to a "hublist hub" and send "hi, I'm a new hub and I want to be added. here's my info"? (Could of course signal a different extension ID.) --Ullner 09:31, 1 January 2008 (PST)
The purpose of HH field is very clear. Hub may have multiple DNS addresses. The owner must decide which address is the official one ( the one all new users must use ( like users coming from a hublist )). In case the address changes, the owner changes the HH so the hublist can display accordingly.
I will modify and add something about autoregistering , then.
--pietry Jan 01 2008
Considering that there are unncessary roundtrips in the hub-hublist connection, it would be better if that entire section was a completely own FCC, like "PIHH". (Not "PINX", as we should opt to use that for a future revision of PING.) --Ullner 14:04, 3 January 2008 (PST)
I rewrote the hub-hublist part, hope it makes more sense now. Waiting for more comments before we continue. -- Pietry, 13 jan 2008
- Nice. --Ullner 06:22, 13 January 2008 (PST)
- In this case, I will start implementing. If other things show up, I will handle them on the way. ( Going for the 2 requirements ;)
- -- Pietry, 13 jan 2008
- Added UP field to represent hub uptime in seconds, could be interesting for hublists ( users ) to see how reliable the hub is.
- -- Pietry, 22 jan 2008
- It's been a month since implementation was done ( 23 jan ) and no talk ( concensus done ). The extension should be completed. Next step is ? -- Pietry, 1 mar 2008
TYPE
Some comments:
- what is it about?
many of people who use ICQ or Jabber know about typeing notifications. they are rather useful. in ADC they will be useful too. nobody in LAN will setup jabber server, but will setup ADC server because of p2p sharing. on the other hand, if your day-to-day conversations are very active than it yummy to view who is typing reply for your message.
- why shold it be in INF SU?
hub will generate less traffic, because it shouldnt send TPN messages to users who aren't support this. also hub can ask clients who got them on to off them and so on.
- why this shouldnt be UDP messages?
there is no HUB-2-CLIENT UDP type of messages, but in nice to see typeing notifications in Mainchat too (not only in PM). UDP in insecure because than hub should share user IPs between clients even though they won't start CLIENT-2-CLIENT session.
OXIj 09:25, 3 January 2008 (PST)
Two comments; (1) the text "If client supports this feature - it should have at least per hub switcher (off/on) for this feature (because this exstension can generate a lot of traffic especially on big internet hubs). " isn't needed. It's a client policy, and shouldn't be required by the protocol. (2) the text " If user sends TPN to hub there it is not allowed - hub say STA 25 and then cliend must off this feature. " isn't needed as that's a default behaviour by the protocol... --Ullner 14:04, 3 January 2008 (PST)
I've revised the section; Removed above texts and cleaned up the rest of the text. (I have not changed any code.) --Ullner 05:28, 15 January 2008 (PST)
LINK
According to ADC specs , http://adc.sourceforge.net/ADC.html#_examples the hub sends its INF before waiting the INF coming from client. So your example
- M-S: ISID ABCD - S-M: HINF IDS... NIS... CT32 // slave sends his INF, ignores SID - M-S: IINF IDM... NIM... CT32 // master sends his INF
Is not entirely possible since it would go like this
- M-S: ISID ABCD - M-S: IINF HI1 CT32 NI.. DE.. - S-M: HINF IDS... NIS... CT32 // now M realises that S was in fact a linked hub.
Perhaps login procedure could change upon detection of LINK ext.
And I don't understand why some fields have 3 letters like IDS, IDM , probably counting for who send the message but thats not adc compliant since named parameters must have only 2 letters. ( or perhaps you ment its the S / M field )
Tiger hash extension has TIGR code ( same compliance, the extensions have only 4 letters).
-- Pietry, 13 jan 2008
- Hi, my example is really too confusing. what i mean is the following:
- S-M: HINF ID{cid_S} NI{nick_S} CT32 // slave sends his INF, ignores SID
- M-S: IINF ID{cid_M} NI{nick_M} CT32 // master sends his INF
- M-S: IHUB {cid_M} TIGR ACIINF\sID{cid_C}\sNI{nick_C}\sCT32\n TO{token_2} // master sends INF of other hubs
- M-S: IHUB {cid_M} TIGR ACHINF\sID{cid_D}\sNI{nick_D}\sCT32\n TO{token_3}
- M-S: IHUB {cid_M} TIGR ACHINF\sID{cid_S}\sNI{nick_S}\sCT32\n TO{token_4} // INF of slave...
- S-M: HHUB {cid_S} TIGR ACIINF\sID{cid_E}\sNI{nick_E}\sCT32\n TO{token_5} // slave sends INF of his other hubs
- S-E: HHUB {cid_S} TIGR ACIINF\sID{cid_M}\sNI{nick_M}\sCT32\n TO{token_2} // slave send INFs of master to his hubs (E)
- S-E: HHUB {cid_S} TIGR ACIINF\sID{cid_C}\sNI{nick_C}\sCT32\n TO{token_3}
- S-E: HHUB {cid_S} TIGR ACHINF\sID{cid_D}\sNI{nick_D}\sCT32\n TO{token_4}
- E-S: HHUB {cid_E} TIGR TMHello\sWorld DH{cid_M} TO{token_6} // E send welcome message to M
- S-M: HHUB {cid_E} TIGR TMHello\smy\smaster DH{cid_M} TO{token_6} // slave forwards message to master
- M-S: HHUB {cid_E} TIGR TMHello\sslave\s^^ TO{token_7} // master greets his new slaves
- i dont know if a server has to send his INF first, the ADC specs also says: "When a hub receives this message in the
- IDENTIFY state, it should verify the PD and ID fields, and proceed to the VERIFY state by sending a PAS request or
- NORMAL state by sending its own INF (unless it already did so previously),..."
- But i agree it makes more sense to change the login procedure when the LINK extension is detected.
- The "ADTIGER" was a typo, sorry :-)
- --Blastbeat 13:30, 13 January 2008
Hmm, the AC parameter is really weird. You say "escaped command". I see that you escape the separator ( space ) with \s. In the following AC message :
ACBMSG\s{sid}\shi\sim\ssome\sguy
\s represents separator and also escapes spaces inside the string..
How should the hub dispatch the chat message of other parameters then... ?
And whats the purpose of the TM field ? --Pietry, 13 jan 2008
- The AC was intended as a kind of container for ADC message. For example hub A wants to send his userlist to hub B. i
- think sending for example
- A-B: BINF {user_sid} ID{user_cid} NI{user_nick}
- makes no sense. the other hub dont know if it is a user from A or maybe a forwarded message from hub C. So hub A escapes
- BINF {user_sid} ID{user_cid} NI{user_nick}
- to
- BINF\s{user_sid}\sID{user_cid}\sNI{user_nick}\n
- adds its as body of AC and sends it with the HUB command.
- A-B: HHUB {hub_A_cid} TIGR ACBINF\s{user_sid}\sID{user_cid}\sNI{user_nick}\n TO{token}
- Hub B knows its a escaped ADC command an translates it back.
- He also knows where this message came from and where it has to go. Now it can add the user to his
- own userlist. he only has to provide a new internal sid because the {user_sid} is the internal sid of hub A.
- When the user now sends a BMSG in hub A, hub A can send it with the same method to hub B and hub B can send
- it with the own sid to his users as normal ADC message.
- A-B: HHUB {hub_A_cid} TIGR ACBMSG\s{user_sid}\sHello\\sWorld\n TO{token}
- The TM is the opposite of AC, it means do not use it as ADC message (for example it can be used as simple text message)
- --Blastbeat 14:07, 13 January 2008
- Notes;
- Why is "TIGR" constantly being sent?
- What's the purpose of an artificial restriction for the token, and why is it optional? It'd be simpler if you just had it as positional.
- Why isn't the "slave" sending its PID to the "master"?
- What information would the hub need that isn't a "ADC message" (in regards to the TM field)? Does the network hubs *really* care if they get "Hello, you're the third network hub"? That's... Quite pointless.
- --Ullner 06:22, 13 January 2008 (PST)
- Notes;
- 1: i dont know if this can happen, but maybe there are two hubs in network with different hash but same cid
- 2: agreed :-)
- 3: i thought its better to avoid faking. if a hub has pid and cid of another, he can abuse this.
- it makes no sense to send pids and cids through the hub network because you need only one to identify a hub
- and when every hub has pid and cid from the others hubs it has no effect to security
- 4: yes, maybe this is not needed
- --Blastbeat 15:50, 13 January 2008
- 1: I don't understand "maybe there are two hubs in network with different hash but same cid". What exactly do you mean? (The master hub has already said what hash should be used...) (It doesn't seem to answer my question anyway...)
- 3: I'm not saying that all hubs should know the PID, only the "master". It's the same as with the CID/PID with normal clients and hubs. Also, I'd require a GPA/PAS exchange to further increase the security; otherwise "anyone" could claim they should be part of the hub network.
- --Ullner 11:59, 13 January 2008 (PST)
- 1: Think about following: hub A connects to Master B, B wants hash1. Then hub B connects to Master C who wants hash2.
- Maybe the hashes have the same length, so a name clash could happen, and hub A shares the same CID with hub C.
- You can avoid this only by sendig the hash or only allowing one hash. That means after 2 hubs linked they have to remove all
- the other hashs from SUP. The drawback: if you have 2 hub networks which supports both the same hashs, but choosed
- different hashs, they cannot connect
- 3: Yes the only way for security is a password. You have to consider that a master can be a slave and you cannot confidence
- in PID or CID, because every hub can connect with all the other hubs in network. so when everyone has your PID and CID, i think
- it makes no sense anymore. PID/CID makes only sense when only one master exists and the slaves dont connect with each other.
- --Blastbeat 22:39, 13 January 2008
- Ah, sorry. I interpreted it as "there is only one master hub in the entire network". I can see and support your point now.
- Regarding the hash; It could be moved to the INF's SU field; A hub only need to know another hub's hash once (computers are good at storage :P).
- --Ullner 08:16, 14 January 2008 (PST)
- Assert the example from above: hub A connects to B and sends his CID and hash in SU. Hub B connects to C and C sends the
- same CID but with different hash in SU. If A and C are both connected to D and A sends a message with CID, but without hash,
- the message will arrive at B but B dont know from which hub it cames.
- --Blastbeat 21:12, 14 January 2008
- About the connection part, maybe something like "master should wait for slave INF before sending itself " should be added
- --Pietry, 13 jan 2008
- comments:
- - i'd rename "AC" ("ADC Command") to "RC" ("Raw Command").
- - in my view of masters and slaves, a master should dispatch messages it receives to all of its slaves; however, a slave shouldn't dispatch messages it receives to all of its masters. say you have slave S linked to both masters M1 and M2; when M1 sends a command to S, S dispatches it to all of S's slaves, but S doesn't forward that command to M2 (or with other words, M1 and M2 are the masters of 2 different networks S (with its slaves) is connected to). defining masters and slaves that way would probably simplify some of the details discussed above, particularly with the hash string being present in every command (which is ugly).
- --poy 08:23, 14 January 2008 (PST)
- Counter example: ( A -> B means A is master of B and can dispatch )
- A -> B -> C -> D -> E -> A and B has same cid but different hash as D in the network
- F -> E and F has same cid but different hash as B and D
- when B sends a message, its sends to A and C, and the message will arrive at A 2 times. But A knows where the message
- came from because B send it and it has the same token. But whats about E and F? A cannot know which hub sended it.
- Maybe one solution would be that every hub changes the CID of an incoming message to his own CID (and the SIDs to his internal SIDs)
- and there arent exist any master masers. So also a slave can send messages of his slaves to masters. When a hub gets a message
- with a token he already knows, he stops dispatching it. Also a hub has only to save user SIDs of hubs he is directly connected with.
- In this model you even dont need dispatch CIDs. But a hub in network dont know what and how many hubs are out there and where the
- users came from.
- --Blastbeat 21:12, 14 January 2008
- well my definition of masters and slaves, and how 2 masters of the same slave have to be independent, solves your issues.
- as for your example:
- - about A->...->A; a master shouldn't become a slave of one of his own slaves...
- - about A->...->E and F->E; that's the same as my previous example with A=M1, F=M2, E=S. there A, B, C, D are independent from F, and shouldn't care about messages F sends to E.
- - about different hashes used in A->B->C->D->E; it could probably be advised that all hubs from one network (or, using your words; all slaves from one master) use the same hash extension.
- --poy 06:07, 15 January 2008 (PST)
- When all hubs in the network only use one hash, there would be no need for master/slave dispatch restriction. I think
- messages spread faster when slaves also can send to its master masters. The words master/slave are maybe misleading,
- hubs are equivalent in the network.
- --Blastbeat 15:43, 15 January 2008
- ah, "hubs are equivalent in the network", that's a very different concept than the one i was thinking of.
- in that case, only way i can see to avoid having to send the hash string every time is that hubs using this extension should use one hash extension only. of course, this is a worst case solution...
- --poy 08:00, 15 January 2008 (PST)
- Did i understand you concept correctly:
- - both master and slave can send to each other, but a slave cannot forward a message of his slaves to his master
- - a master shouldnt become slave of his slaves
- ---> that means a master know only direct slaves below him, no slaves of slaves. There is no way to send a message back to a
- mastermaster. Than it would make no sense that a slave sends messages from a master to his slaves because his slaves cannot
- reply. Than the whole network makes no sense.
- So what is more worse, send 4 bytes more or restrict hash extensions? (at the moment the hash questions doesnt really matter,
- maybe its possible to allow different "link modes")
- Did i understand you concept correctly:
- --Blastbeat 17:34, 15 January 2008
- "both master and slave can send to each other, but a slave cannot forward a message of his slaves to his master" > no, that is allowed, masters can communicate with their slaves and sub-slaves. what i thought should be forbidden is when a master sends a message to a slave, then that slave shouldn't forward it to its other masters. if the slave receives a message from a sub-slave, then it can forward it to its masters (and to all of them).
- --poy 11:58, 15 January 2008 (PST)
- I see, a hub dispatchs a slave message to all other slaves and masters, but dispatches a master message only to slaves.
- You get a kind of tree without cycles. But if you allow only one hash per branch, and 2 branches connect, they must have the
- same hash and so the complete network has the same hash. But then the disptach restriction makes no sense.
- --Blastbeat 17:34, 15 January 2008
- "You get a kind of tree without cycles." > yes, that's what i had in mind, i would have liked to kind of draw it but didn't feel like doing ASCII-art here... but since you consider every hub as equivalent in the network, that scheme doesn't apply anymore anyway. however, wouldn't considering hubs linked as in a tree remove the need to have a token (which is added to avoid cycles)?
- the hash problem is indeed unrelated to that concept issue, and i wonder what's best between allowing only one hash extension to be used or dispatching the hash string in every command.
- (sorry for the late response) --poy 13:18, 18 January 2008 (PST)
- "however, wouldn't considering hubs linked as in a tree remove the need to have a token (which is added to avoid cycles)?"
- What about this situation: A -> B, A -> C, B -> C. When A sends a message without a token to B and C, and B sends the
- message to its slave C, then C will think its a new message an dispatch the same message twice to its slaves. I think
- tokens are really needed in every model
- --Blastbeat 23:46, 18 January 2008
- with the "tree concept", if A->B and A->C then B->C isn't supposed to be allowed, because B and C would be on the same level but on different branches (like a brother being a child of his own sister). B can still send a message to C indirectly, by sending a message to A, and telling A to dispatch it to all of its slaves. in that case, A will send a message only to C; but A won't send the message back to B because it will already know that the message comes from the B branch.
- so with that scheme, do you think tokens can be unnecessary? maybe i don't see all the possibilities but in the previous simple case, i think cycles were not possible.
- --poy 06:31, 19 January 2008 (PST)
- Yes, when brothers and sisters cannot connect, then tokens seems not to be needed. On the one hand there is less
- bandwidth, on the other hand messages have to go first to a node above and cannot be passed directly to another hub.
- Assert there is one hub at the top of the tree with two branches. Every branch has a lot of slaves and when slaves want
- to communicate with slaves of another branch, every message has first to go through the top hub. Seems not to be
- the fastest way.
- --Blastbeat 19:12, 19 January 2008
- "every message has first to go through the top hub" > this is indeed a trade-off and that top hub may get flooded if it has too many slaves. but in your example, is there a way for slaves to connect between themselves without going through their master hub? as far as i can see, they don't dispatch their connection info so i don't see how a slave could connect to another slave; all i see is 1 connection only, between 1 master and 1 slave.
- --poy 11:24, 20 January 2008 (PST)
- I dont know which example you exactly mean but i prefer the model where only one hash per network is allowed and the
- only restriction in communicating is: dont dispatch messages with a token you already know (and dont dispatch messages
- back to the one who sended it). An opinion of a network theory expert to this topic would be great^^
- --Blastbeat 23:45, 20 January 2008
- i meant the example in the main article; the connection info (IP/port) isn't dispatched, so as far as i can tell 1 hub will always only be able to communicate with the hubs that specifically connected to it (its slaves) and those it connected to (its masters). it can't connect to hubs in "other branches" if it can't know how to connect to them.
- in our current discussion, with A->B and A->C, is there a way for B to contact C directly, without going through A?
- --poy 09:11, 21 January 2008 (PST)
- No only when B knows the adress of C.
- --Blastbeat 19:39, 22 January 2008
