LINK extension

Ideas for ADC may be presented here for others to review and point out flaws or further improve the idea.
Forum rules
If you have an account on the wiki, remember to update the ADC Proposals page for new ideas.
Post Reply
Posts: 53
Joined: 10 Jan 2008, 19:56

LINK extension

Post by blastbeat » 17 Jan 2009, 21:25

LINK - Hublink

Description: This extension allows linking hubs together. So hubs can send messages to each other, share users and forward search requests or chats.

How it works: To link two hubs, one must be a master hub and the other a slave hub. Both should support the same Hash extensions and of course the LINK extension. They have to provide a hub CID and must hide the PID to other hubs. The connecting hub is the slave hub. When a slave connects to a master, the master thinks its a normal client, sends its SUP and a SID. The slave ignores the SID and returns his INF and the master notes its a hub. Instead of sending the INFs of the connected users, the master sends the INFs of other hubs, he is connected with (both master or slave) with HUB command. The communication of the hubs works with CIDs instead of SIDs, because a CID is (should be) unique. Hubs should use tokens to decide if a message has to be forwarded or not. Its also possible to share users or forward search requests: but the hub must translate the escaped adc commands. for example internal user SIDs of every hub must be translated to own SIDs to avoid SID name clashes.



HUB cid hash

Contexts: F, T

{cid} is a Base32 encoded CID from the originator of the msg, required
{hash} is the hash extention used for creating {cid}, required to avoid name clashes beetween CIDs
  • TO: Base32 token, at least 10 bytes long, optional. should be used to identify a message in the hub network to avoid endless cycles of forwarded messages
  • DH: CID of destination hub, optional. if destination is present, the hub which receives the message must send it to destination or to the hub which is linked to destination; else send it to all, but not to hub where message came from
  • AC: escaped ADC command, optional
  • TM: text message, optional
Example: 5 hubs: M(master), S(slave), C(M), D(M), E(S)

Code: Select all

 - 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
a while ago i thought about an extension to link multiple hubs together and
i would like to know if there is any interest to implement it.
meanwhile i have changed the first attempt a bit to make it as easy as possible:

- hubs should be linked without cycles, only trees are allowed (like irc)
- users should be only once connected to the network
- all hubs in network have to use the same hash (tiger at the moment)

the main question for me is how to identify a user in the linked hub network. here are 2 scenarios:

1. identify by cid:
every hub has its own sid namespace and when a hub sends a message of an own user to another hubs, he has to substitute the sid of the message with the cid of the user. if he receives a message of a user from another hub, he has to substitute the cid back.
this wont be adc spec i think

2. identify by sid:
all hubs in the linked network share one sid namespace. there a 32^4 possible sids, its much more
as one hub will ever need. so when every hub has a certain sid space which doesnt overlap, the hubs can send the messages without changing anything. this would be save a lot of traffic and substitution effort. just send or forward the original message. the question is how to determine which hub can use which sid.

so what do you think about it?


Re: LINK extension

Post by Toast » 17 Jan 2009, 21:52

Actually CyB is working on it :) embla already has support for link


Re: LINK extension

Post by Toast » 17 Jan 2009, 22:36

blastbeat was the one that proposed the protocol so he knows the part quite well since he made it :)

Posts: 53
Joined: 10 Jan 2008, 19:56

Re: LINK extension

Post by blastbeat » 18 Jan 2009, 00:23

yes and at the moment i think my first attemp wasnt very good, too much overhead. does cyb use this proposal or another one?

Junior Member
Posts: 15
Joined: 27 Oct 2008, 20:23

Re: LINK extension

Post by HaArD » 18 Jan 2009, 06:04

Ahh... Sorry.. no credits on that page and I didn't even check the discussion until now....

I'm not a big fan of the Master/Slave paradigm... it seems fine within the context of the connection processed as described on the Extension page but within the discussion it gets into Slaves being part of multiple networks and traffic only flowing downstream... I think that becomes a logistical nightmare....

I have been using an IRC mindset for hub-linking for years and it translates very well.... hubs can become part of a network but hubs are equals... they are peers in the same way that users within the hub are peers. What has been needed is a protocol standard for linking them (rather than a hubsoft specific standard).

Posts: 53
Joined: 15 Sep 2008, 21:48
Location: adcs://

Re: LINK extension

Post by Dj_Offset » 18 Jan 2009, 15:27

I have been thinking about this type of functionality for a long time, and I agree with many of the ideas from the OP, especially the tree model, shared hash, etc.

However, I would like each hub to be slightly more independent wrt SIDs. I don't see any point for all hubs to use synchronized SIDs (that might complicate the inter-hub communication).

So, linked hubs might assign different SIDs for different users, and inter-hub communication use CIDs (or something else) instead.

Post Reply