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.
Commands:
HUB
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
Code: Select all
- M-S: ISUP ADBASE ADTIGR ADLINK
- S-M: HSUP ADBASE ADTIGR ADLINK
- M-S: ISID ABCD
- 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 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:
assumptions:
- 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?