Feature Request, Share hiding...

[Requiem]

As Typhoon? mentioned here, I will request a feature.

Like in YnHub ( but Skrollster told it was not perfect ) can we have an option to hide shares for OPs or any profile we'd like to?

Thanks Ptaczek & PPK for this beautiful hub soft...

[PPK]

Hide share mean only to have for OPs (profiles) in userlist 0 share (very easy to do) or/and with no search responding (it is not too easy but not hard to do) or/and with no connections to OPs (very hard to do for pasives)  ?(  :]

[bastya_elvtars]

This function is useless, as it introduces false security. And the OPs should be the first to share and upload. Use ProtoWall if you wanna avoid being busted. Even if you add it, PPK, make it optional.

[Daywalker]

This function is useless, as it introduces false security. And the OPs should be the first to share and upload. Use ProtoWall if you wanna avoid being busted. Even if you add it, PPK, make it optional.

Disagree....why wld i choose to lag my computer with all this software like protowall or peerguardian for a simple button in PtokaX to hide my share.

If u can add it PPK...then add it, i like the option altough some opclients have that option to lately

Keep up the good work Ptaczek & PPK  

[Requiem]

Originally posted by PPK
Hide share mean only to have for OPs (profiles) in userlist 0 share (very easy to do) or/and with no search responding (it is not too easy but not hard to do) or/and with no connections to OPs (very hard to do for pasives)  ?(  :]

You know what to do, PPK.. What I want is emulating what happens when I share nothing in the hub.. If possible, please implement this into PtokaX as an option..

Thank you for your all efforts..

[PPK]

Originally posted by Requiem
What I want is emulating what happens when I share nothing in the hub..

Is possible to add it for active user (and is not too hard to do it)... but is impossible to get it good work with pasive user -> if hidding pasive try to download from "another user" and this "another user" want in same time to do download from hidding pasive then it fail and sometimes "other user" is allowed to download from hidding pasive

[Requiem]

And what I get from this is, this request of mine is only possible to work perfectly under ADC protocol?

[Requiem]

I found that DCDM++'s share hiding option is leaky too.. When I try to connect actively or passively it doesnt matter, I get a full list of an op which is shown as 0 bytes sharing in hub

[Herodes]

Originally posted by Requiem
I found that DCDM++'s share hiding option is leaky too.. When I try to connect actively or passively it doesnt matter, I get a full list of an op which is shown as 0 bytes sharing in hub :(

it says Hide share,.. not block downloads ...

[Pothead]

True. It stops people getting your share, but people who got stuff queued up, will still get it.

[bastya_elvtars]

The problem is that if you only send myinfo with 0 share you can still respond to searches, and CTMs/rCTMs, so your IP can be available, providing enough info to RIAA et al. Only IP-based blocklists or the blocking of unknown/unregged users can solve this problem. It is untolerable for me to block the facility to download from Ops. In TGA, ops have a share amount of 1.5-2 TBytes statically. Sharing is fun.  

[imby]

Originally posted by bastya_elvtars
The problem is that if you only send myinfo with 0 share you can still respond to searches, and CTMs/rCTMs, so your IP can be available, providing enough info to RIAA et al. Only IP-based blocklists or the blocking of unknown/unregged users can solve this problem. It is untolerable for me to block the facility to download from Ops. In TGA, ops have a share amount of 1.5-2 TBytes statically. Sharing is fun.  

Concur, op's aren't Gods  :]

[Pothead]

Originally posted by bastya_elvtars
The problem is that if you only send myinfo with 0 share you can still respond to searches, and CTMs/rCTMs, so your IP can be available, providing enough info to RIAA et al.

Doesn't respond to searchs which aren't from sharing hubs.

[bastya_elvtars]

Originally posted by imby Concur, op's aren't Gods  :]

Yes, I said this, too. Legal issues are only when you share files directly from HUB PC, but AFAIK, it is enough to set a minimum share. If FleetCommand was here, he could tell how angry I am usually when ops do not share , and this is an equivalent.

[Fangs404]

i second this feature request.  i have a very large need for this (and i really, really liked this feature when i used ynhub).  i currently host a hub at my university.  we have to pay for our internet, and we're only alotted a certain amount of bandwidth per week to outside connections.  we have unlimited intracampus bandwidth.  because of this, i have put an IP-blocker in place that i wrote (with the aid of plop) that will restrict connections to only people that pass the ip range test.

this is great and all, but i have several ops that live off campus and i allow to be immune to the IP test.  when i was using ynhub, they would just type !hideshare so that users couldn't download their filelists or their files.  this was an excellent way to prevent bandwidth leakage by mistakingly downloading a file from an off-campus op.

sure, the ops can manually unshare their files.  but then they have to go through the hashing process every time they want to join a public hub.  we all know how tedius that can be, especially if you're sharing something significant like 200gb.

it may be tough to implement, but i feel that this feature would definitely be used not only by me but many others in my situation (i know i'm not alone).

if it's easier to code, maybe something like !blockaccess would be nice.  it wouldn't necessarily hide their shares, but it would block any attempts to connect and download files from the user.

[Dessamator]

well its simple, u dont want users to see ur share, DONT SHARE ANYTHING, keep it simple,

[bastya_elvtars]

sure, the ops can manually unshare their files. but then they have to go through the hashing process every time they want to join a public hub.

2 clients?

[ptaczek]

Hmm this just flashed in my mind: if I can remember the DC protocol well, (1) the $Search cmds are dispatched by the hub, (2) the $MyINFO is dispatched by the hub, (3) $ConnectToMe and $RevConnectToMe are passed to/from specific user by the hub.
Forget all "what if" scenarios for a while and imagine a brand new virgin hub, where nobody has anything in download queue. Now set the hubsoft to don't send the (1) and (3) to ops from other users and modify the (2) to show 0 share.
If my calculations are correct, it will completely immunize the operators from:
a) getting any search requests from others
b) being contacted by any other user (or to send reverse connection request to other user, if that user is passive)
c) showing their sharesize

Tell me if Im not correct.

[Pothead]

Originally posted by Fangs404
sure, the ops can manually unshare their files.  but then they have to go through the hashing process every time they want to join a public hub.  we all know how tedius that can be, especially if you're sharing something significant like 200gb.

Backup DCplusplus.xml HashIndex.xml and HashData.dat ?

[GeceBekcisi]

Originally posted by ptaczek
If my calculations are correct, it will completely immunize the operators from:
a) getting any search requests from others
b) being contacted by any other user (or to send reverse connection request to other user, if that user is passive)
c) showing their sharesize

Tell me if Im not correct.

As far as I can imagine yes you are.

Originally posted by Pothead
Backup DCplusplus.xml HashIndex.xml and HashData.dat ?

Why doing these everytime & and trying to update your XML files with every change in them instead of such a simple thing?

As ptaczek mentioned; this can be done just sth like
(i dunno programming a bit, just trying to show what is in my mind)

-OpHideShare (on/off)
	Options for OpHideShare
	(options are revealed if OpHideShare on)
	-BlockSearch
	-BlockConnect
	-ShowShareZero

 so everyone can set their ShareHide option for their needs and and if 3 sub-options are enable OPs have to enter hub second time with a normal user profile for enabling blocked functions.

[Fangs404]

i completely agree with GeceBekcisi.

Originally posted by Dessamator
well its simple, u dont want users to see ur share, DONT SHARE ANYTHING, keep it simple,

did you even read my argument against that?  that's a huge pain in the ass if you share any substantial amount of files because of the hashing process.

Originally posted by bastya_elvtars
2 clients?

that is such a waste of harddrive space.  it's illogical to require every op and every off-campus register user on my hub to have 2 clients.

Originally posted by Pothead
Backup DCplusplus.xml HashIndex.xml and HashData.dat ?

again, this is illogical and shouldn't need to be done.  why go through all this trouble when there could be a nice !hideshare command?

[PPK]

Originally posted by Fangs404
but then they have to go through the hashing process every time they want to join a public hub.

No, with good client is not needed to hash files twice. Only new files need to hash, old file hashes have (DC++ based) client stored in HashIndex.xml :]

Originally posted by Fangs404
why go through all this trouble when there could be a nice !hideshare command?

If you know how to do it _WORKING_ hideshare then do it with script

[Fangs404]

Originally posted by PPK

Originally posted by Fangs404
why go through all this trouble when there could be a nice !hideshare command?

If you know how to do it _WORKING_ hideshare then do it with script :D

you know, i was just about to ask that.  :)  is it possible to do it via a script?

[PPK]

Originally posted by Fangs404
is it possible to do it via a script?

Is posible to block search requests and connection requests by script... is not posible to change user share in userlist

[Fangs404]

Originally posted by PPK

Originally posted by Fangs404
is it possible to do it via a script?

Is posible to block search requests and connection requests by script... is not posible to change user share in userlist :)

good to know.  i'll probably just write a script then unless you plan to implement this feature.