View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003578 | unreal | ircd | public | 2008-01-16 23:57 | 2015-07-09 19:24 |
| Reporter | tabrisnet | Assigned To | syzop | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | no change required | ||
| Product Version | 4.0-devel | ||||
| Summary | 0003578: non-registered user jail | ||||
| Description | The idea here is that users connect, and may be designated with a jail-ID (non-unique) that identifies how they connected. I don't care if this is done via services or something. Then they are limited to joining channels with chmode +J jail-ID. If they register their nicks (or some other action that may be services defined) they are unjailed, and can join channels freely. Another way of looking at this is as an inverse to +R, where most channels cannot but joined unless they are registered. Except that I'd rather it not be requiring a reg'd nick to join, just that we know who they are. This would be used to a) prevent website portal users from overrunning the network, but allow them to remain in peace b) make it a lot harder for klined users to evade (they can't join any channels, so they can do a lot less damage). I'd _like_ this feature _right now_ but I wouldn't really expect this to exist until 4.0. To try to make this sound a little less 'out there' understand that a lot of the point of this is to make IRC identities mean a lot more. Right now it's much to easy to be on the network but unidentified, or to fake being another user. Thus we need better identity management. This doesn't necessarily mean tying identity to real-world identity (that's a per network decision) but rather that we know that a) badPerson cannot come back an wreak havoc no matter what they do b) that randomPerson today is the same randomPerson as last week. If possible, I may try to implement this feature, likely as a module (that I'd like to see become standard). Otoh, it may not be able to be implemented as a module, as it would require modifying the User struct, among other things. | ||||
| 3rd party modules | |||||
|
|
The idea is nice but cause the services part it'd be some troublesome. Rather than base, it'd be more proper with a module. Also, it wouldn't probably be necessary to modifying the structs. Instead, you can create struct for your own datas. |
|
|
This sounds more like something for a 3rd party module. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2008-01-16 23:57 | tabrisnet | New Issue | |
| 2008-02-18 13:29 | totalsolid | Note Added: 0015155 | |
| 2008-02-18 13:30 | totalsolid | Note Edited: 0015155 | |
| 2008-02-18 13:31 | totalsolid | Note Edited: 0015155 | |
| 2015-07-09 19:24 | syzop | Note Added: 0018445 | |
| 2015-07-09 19:24 | syzop | Status | new => closed |
| 2015-07-09 19:24 | syzop | Assigned To | => syzop |
| 2015-07-09 19:24 | syzop | Resolution | open => no change required |
