PtokaX forum

PtokaX => Support => Topic started by: Requiem on 03 April, 2005, 15:45:59

Title: Feature Request, Share hiding...
Post by: Requiem on 03 April, 2005, 15:45:59
As Typhoon? mentioned here (http://board.univ-angers.fr/thread.php?threadid=4114&boardid=28&sid=f85336d0b95eb9141933d455019cf099&page=1#8), I will request a feature.

Like in YnHub ( but Skrollster told (http://board.univ-angers.fr/thread.php?threadid=4114&boardid=28&styleid=1&sid=f85336d0b95eb9141933d455019cf099&page=1#9) 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...
Title:
Post by: PPK on 03 April, 2005, 20:33:41
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)  ?(  :]
Title:
Post by: bastya_elvtars on 03 April, 2005, 20:49:37
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.
Title:
Post by: Daywalker on 03 April, 2005, 21:03:17
QuoteThis 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  :D
Title:
Post by: Requiem on 03 April, 2005, 22:18:51
QuoteOriginally 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..
Title:
Post by: PPK on 04 April, 2005, 00:28:36
QuoteOriginally 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 :(
Title:
Post by: Requiem on 04 April, 2005, 01:02:50
And what I get from this is, this request of mine is only possible to work perfectly under ADC protocol?
Title:
Post by: Requiem on 05 April, 2005, 17:47:06
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 :(
Title:
Post by: Herodes on 05 April, 2005, 23:35:28
QuoteOriginally 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 ...
Title:
Post by: Pothead on 06 April, 2005, 01:52:36
True. It stops people getting your share, but people who got stuff queued up, will still get it. :)
Title:
Post by: bastya_elvtars on 06 April, 2005, 02:21:13
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.  8)
Title:
Post by: imby on 06 April, 2005, 02:37:02
QuoteOriginally 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.  8)

Concur, op's aren't Gods  :]
Title:
Post by: Pothead on 06 April, 2005, 11:26:42
QuoteOriginally 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. :)
Title:
Post by: bastya_elvtars on 06 April, 2005, 14:39:02
QuoteOriginally 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.
Title:
Post by: Fangs404 on 23 April, 2005, 10:24:00
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.
Title:
Post by: Dessamator on 23 April, 2005, 11:59:27
well its simple, u dont want users to see ur share, DONT SHARE ANYTHING, keep it simple,
Title:
Post by: bastya_elvtars on 23 April, 2005, 12:38:10
Quotesure, 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?
Title:
Post by: ptaczek on 23 April, 2005, 12:47:32
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.
Title:
Post by: Pothead on 23 April, 2005, 12:47:38
QuoteOriginally 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 ?
Title:
Post by: GeceBekcisi on 23 April, 2005, 18:46:21
QuoteOriginally 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.
QuoteOriginally 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.
Title:
Post by: Fangs404 on 24 April, 2005, 03:10:28
i completely agree with GeceBekcisi.

QuoteOriginally 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.

QuoteOriginally 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.

QuoteOriginally 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?
Title:
Post by: PPK on 24 April, 2005, 03:39:55
QuoteOriginally 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 :]

QuoteOriginally 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
Title:
Post by: Fangs404 on 24 April, 2005, 03:44:25
QuoteOriginally posted by PPK
QuoteOriginally 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?
Title:
Post by: PPK on 24 April, 2005, 04:23:12
QuoteOriginally 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 :)
Title:
Post by: Fangs404 on 24 April, 2005, 05:28:56
QuoteOriginally posted by PPK
QuoteOriginally 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.
Title:
Post by: ruler on 24 April, 2005, 09:33:18
oops wrong section
Title:
Post by: Dessamator on 24 April, 2005, 13:15:06
QuoteOriginally posted by Fangs404
i completely agree with GeceBekcisi.

QuoteOriginally 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.

yap , only if u use a reallllly lame client, will u have that prob, normally u just have to share it once, even removing it from dc, it will still be stored in the file, and u wont have to repeat the process,u just need to add it later, i only takes a sec, mayb less

as ive said many times b4,

pls, research b4 u post , dont argue about something u dont know !!
Title:
Post by: bastya_elvtars on 24 April, 2005, 14:24:56
Quotedid 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.

I ask again:

2 clients?