View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004116 | unreal | ircd | public | 2012-07-06 22:06 | 2019-10-14 15:19 |
| Reporter | katsklaw | Assigned To | syzop | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | no change required | ||
| Summary | 0004116: Add ircx style channel properties | ||||
| Description | UHG!! Yes i said it! IRCx style channel properties would be beneficial and doable in IRCv2, even though it should be in IRCv3 already *Stares at nenolod* What I'm thinking is that chanmodes are rather archaic. We can expand the channel record by an unlimited amount by using properties instead of chanmodes (there are only so many letters!!), not to mention setting modes for properties will be confusing as hell. Examples: /chanprop #Channel topic blah /chanprop #Channel banlist visible|chanop|admin|disabled (as requested in 0004112) /chanprop #Channel inherit #Source (think cloning channel records) We can also have IRCop only settings: /chanprop #Channel hold-open on|off (think nefarious's channel persistance) | ||||
| Additional Information | With todays computing power and bandwidth being much faster and cheaper than it was in 1994, there is less concern with resource usage. Namely for disk storage and bursts of bandwidth. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
You know, if this is implemented correctly, there would a very basic set of embedded Services :) /chanprop #Channel register MyPass [email protected] /chanprop #Channel chanbot L33tBot |
|
|
Another use would to be to replace/augment the existing set cmd and expand it to include both local and global settings. You could actually replace the need for remote includes with it by broadcasting global set options then rehash all servers. |
|
|
regarding IRCv3, there's a working group for integrating IRCX into the standard, but that seems kinda dead now. i don't think IRCX should just be implemented as it stands though, some things need to be fixed with it. |
|
|
I agree it would be nice if we could change settings in a more expansible and less obscure way than just channel modes (MODE) where you have to use mysterious channel mode characters which you have to know the meaning of ;P. Still.. IRCX............ hmmmmmmm........ I don't know ;) |
|
|
Using the term IRCx wasn't meant to be taken literally ;). I don't know how (in)efficient the IRCx standard is, the point was to (possibly) rid remote includes while still maintaining the ability to keep net wide set variables consistent and at the same time make things a bit more configurable and scalable for channel/user data without using even more channel/user modes. |
|
|
inspircd guys have picked up recently the efforts to integrate some parts of IRCX, i will look at their proposal and see if it's something we're interested in doing... |
|
|
hmmm, with respect. I think we should do this even if other ircds do not. One of the main reasons people switch from IRC is it's lack of development and lack of truly new features. I'm constantly thinking of new uses for this feature, for example the ability to have a default language set for channels and then using a /list filter to list a specific language. I also request the status changed to "feedback" please. |
|
|
ConferenceRoom had channel properties. They were a PITA and were always brought up by user confusion in help channels. The idea really never caught on with the networks I used and ended up being a tool to troll by channel ops and opers. It also made for some spammy fun too. |
|
|
Ok, changed to feedback. Please discuss. And as all of you may or may not know, our philosophy for the past 15 years or so has always been that we introduce new features and clients have to cope with them. We don't need an OK in advance or anything. That just doesn't work, for various reasons. That doesn't mean we don't consult them sometimes, though, that can only be helpful. Still, we do our best not to send too strange things to clients, if possible, features like CAP help with that. Back on topic... I think we should first write down what we're trying to do here. As mentioned I came up with two reasons, plus I now add another one: 1) Make channel settings less obscure, eg: instead of +k something you would write something with 'key' and 'something'. It's more clear what you are changing 2) More flexible (and possible less obscure) syntax, for example you can use spaces, you could use longer text, .. 3) You're no longer limited by letters/numbers (+a +b +c..). I haven't seen anyone hitting this limit yet :P, but OTOH we currently weigh in that channel settings consumes a channel mode which are reasonably scare resources and thus such a feature should be quite useful before it warrants one. When this is no longer the case, it lowers the bar. Are these correct? Are these valid reasons to warrant a change? Any others to add? Then, though this is more a detail, rather than the main question: Besides deciding on whatever method to change these, there's also the question of whether we want to broadcast any changes, and to who. Right now, everyone in the channel sees changes of channel properties, by means of MODE #chan .... Do we also want this when a new property is changed? Or perhaps only to chanops and above? (well, halfop and above) Or should it depend on the mode? With IRCX (IIRC) you could change channel properties without anyone else seeing it, which introduced security (or at least audit) problems. Note that I'm not sure if I'm favor of a change, I'm just trying to (re)start a more in-depth discussion. Also more examples will always be appreciated, to illustrate any need. |
|
|
Ok, I just seen https://bugs.unrealircd.org/view.php?id=4110 and I must say it kinda chaps my butt. What I proposed in this feature request would do exactly what 4110 just fixed. Storing/sharing various user/channel extra info as metadata. As far as more examples, really you aren't limited except by your imagination. All these metadata settings will be outside RFC1459 and completely inside the realm of s2s traffic. You can mark users/channels something like /msg operserv oinfo. You can store channel information that ChanOps want to share with others. Same for users. as far as non-oper users rw access to this metadata, they should be limited to which data they can set so we don't end up with a 500GB database. /userinfo flag registered-nick "user is shifty"; can be added to oper version of /whois output after said user is +r. /chaninfo #chan URL http://www.my.site; returns numeric 328 (RPL_CHANNEL_URL) Of course /chaninfo will likely require some form of channel persistance. Commands like /addoper and pretty much all oper blocks can be stored and shared at any level. /set oper nick +net-admin; pass UberPass; server *; // Broadcasted, thus no need for remote includes, yet can oper on any server after propagation. /set oper nick - // Broadcasted, removes oper from all servers at the speed of propagation. SQLite probably wouldn't hurt as a database as it could also be used by an ircd web interface. |
|
|
This is no longer under consideration at this point. So best to close this issue. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-07-06 22:06 | katsklaw | New Issue | |
| 2012-07-06 22:23 | katsklaw | Note Added: 0017032 | |
| 2012-07-07 12:11 | katsklaw | Note Added: 0017033 | |
| 2012-07-23 07:58 |
|
Note Added: 0017053 | |
| 2012-12-15 21:01 | syzop | Note Added: 0017270 | |
| 2012-12-19 22:03 | katsklaw | Note Added: 0017274 | |
| 2013-05-07 02:31 |
|
Note Added: 0017514 | |
| 2013-08-09 17:49 | katsklaw | Note Added: 0017742 | |
| 2013-08-11 03:35 | Stealth | Note Added: 0017745 | |
| 2013-08-14 10:15 | syzop | Note Added: 0017752 | |
| 2013-08-14 10:15 | syzop | Assigned To | => syzop |
| 2013-08-14 10:15 | syzop | Status | new => feedback |
| 2013-08-14 10:16 | syzop | Assigned To | syzop => |
| 2014-03-14 01:14 | peterkingalexander | Issue cloned: 0004290 | |
| 2015-05-26 00:51 | katsklaw | Note Added: 0018347 | |
| 2015-05-26 01:23 | katsklaw | Note Edited: 0018347 | |
| 2015-05-26 01:25 | katsklaw | Note Edited: 0018347 | |
| 2015-05-26 01:32 | katsklaw | Note Edited: 0018347 | |
| 2019-10-14 15:19 | syzop | Assigned To | => syzop |
| 2019-10-14 15:19 | syzop | Status | feedback => closed |
| 2019-10-14 15:19 | syzop | Resolution | open => no change required |
| 2019-10-14 15:19 | syzop | Note Added: 0020971 |
