Thoughts about an ADC-hubsoftware

As you might already know, on clientside, ADC does work more or less. You can chat, you can download, you can search, you can browse other user’s file lists. Sure it has bugs, but it works.

But what about ADC-hubs? There are several, but none of them are mature yet, it lacks services which nmdc hubowners already got used to. And there are differences which the developers need to think about. Well, I collected some of them. Not to be wise or whatever, just because I think someone shall start it :)

Ok.. Well, let’s see:

  1. Hubsoftware must ensure that the CID matches the PID and not allow users entering the hub if they couldn’t provide a valid CID for their PID
  2. Hubsoftware must not store, broadcast or make available anyone’s PID to someone else including hubowners and scripts too. This would weaken the security of the system. People should not use or install hubsoftwares which does this to protect their operators and users.
  3. It’s a good option to register users using their CIDs, but the hub should note the users that their registration will lost if they modify or lost their PID/CID. Moreover, it’s a good idea to store the last nick for every registration to disallow other users to connect and talk in the name of someone else while that other user is offline. This protects the users’ reputation.
  4. Filtering commands is the hub’s job, not the client’s. So hubs must ensure that regular users are not allowed to send mass messages to other users for example by adding a PM flag to their BMSG.

Sure there is a lot more, but I think it’s enough for now. Feel free to comment.

One Response to Thoughts about an ADC-hubsoftware

  1. djoffset says:

    Step 1, reminds me of the pointless $Lock mechanism we saw in NMDC, but fair enough… Let’s keep it for now…

    Step 2, “Must not broadcast PID”, fair enough, but it has absolutely nothing to do with security. Since it is needed for step 1, we must send it to the hub, and we must implicitly *trust* the hub not to do anything bad with it. This is a very bad assumption, and it is therefore easy to obtain the PID by “tricking” someone to connect to your hub (Did I mention hybrid ADC client+hub implementations?).

    Step 3, Yes register using CIDs are nice, and if you want to protect your CID, use a password. We got passwords (almost) right in ADC.

    Step 4, I agree… but I’m not sure if I follow your BMSG example. But then again, the ADC spec doesn’t really address how “group SIDs” are supposed to work. I am sure we will need to clarify this, or specify it better.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: