ircv3 / ircv3-specifications Goto Github PK
View Code? Open in Web Editor NEWIRCv3 specifications | Roadmap: https://git.io/IRCv3-Roadmap | Code of conduct: http://ircv3.net/conduct.html
Home Page: http://ircv3.net/
IRCv3 specifications | Roadmap: https://git.io/IRCv3-Roadmap | Code of conduct: http://ircv3.net/conduct.html
Home Page: http://ircv3.net/
This is what I had in mind when I proposed JSON encoding for IRC.
RFC1459: :kaniini!~kaniini@rabbit PRIVMSG #ircv3 :hello world\r\n
This: [{}, "kaniini!~kaniini@rabbit", "PRIVMSG", "#ircv3", "hello world"]\r\n
RFC1459: ERROR :Go away\r\n
This: [{}, null, "ERROR", "Go away"]\r\n
RFC1459: CAPAB \r\n
This: [{}, null, "CAPAB"]\r\n
IRCv3.2: @tag1=a;tag2=b :[email protected] PRIVMSG #ircv3 :hello\r\n
This: [{"tag1": "a", "tag2": "b"}, "[email protected]", "PRIVMSG", "#ircv3", "hello"]\r\n
IRCv3.2: @tag1=;tag2 :Kyth JOIN #ircv3\r\n
This: [{"tag1": "", "tag2": true}, "Kyth", "JOIN", "#ircv3"]\r\n
Incidentally, this is the only type of JSON encoding we have any interest in implementing in Tethys. The stuff on bug #55 will never ever happen there, so consider that proposal DOA.
Yes, it's based on a subset of JSON. This is also a subset of YAML, too. Furthermore, I do not care about some idiot on hacker news's pet protocol, XMPP, protobuf, or any other nonsense. We will not implement any of those in Tethys, so consider those proposals DOA too. It's either RFC1459 or this, period.
I believe that the website is presently organized suboptimally, in that most content is placed on one page. I propose, therefore, that it be migrated to Jekyll and that the following model be used for arranging documentation:
/index -- explain what IRCv3 is and what we're doing.
/$version/index -- explain, briefly, the goals of IRCv$version and enumerate the specifications therein.
/$version/$specname -- documents the relevant specification
/documentation/ -- contains all documentation relevant to IRCv3 implementations which is not itself a specification, e.g. SASL mechanisms.
/implementations -- lists all compliant implementations, probably by version.
I think Bootstrap would be a good basis for look & feel, however it shouldn't use the default colours.
It would be cool if all Markdown files had the .md
filename suffix – then Github itself could render them and I could link to a specific file when there's a delay in updating the main website.
There was some discussion on IRC about how this could be done, some of them were:
So, all three of these have their ups and downs:
Log-all
Pro: This would be nice because any user could at any time read the backlog of the channel.
Con: Not many people like the idea of public logging, and in the case of private information accidentally being put out, there's not a whole lot you can do.
Log-all + grep
Pro: This is good for the same reason as the first, with the added benifit of being able to select the 'terms'/issues you wished to read backlog for, the grepping wouldn't be 100% perfect but it would work well enough for this, I believe.
Con: This is also bad for the same reason as the first, not many people like public logging, etc. Also this has the added downfall of someone needing to write a script to grep + tag issues to lines or do it manually.
I thought this was a great idea when I suggested it but after taking some time to review how it would be implemented I don't think it would be worthwhile to take time to add this.
Open Github issues
Pro: This is without a doubt the easiest one to implement. Before bringing up a discussion on IRC open a GitHub issue with all the relevent information about what you are suggesting and then ask for comments on IRC about how to go about it. This would require that the GitHub issue be updated whenever new information came up.
Con: We may end up with lots of unused github issues and some github issues may not get updated with new information as they should.
All-in-all after looking over the three major options that were given on IRC, I'm in favor of the third option. This would require some slight changes to the way issues are updated but I think it would help sort out a couple of issues I see on IRC, those issues being:
Now the account-tag
issue for example, that went through at least 5 major changes since it was originally opened on github and due to there being no public log to why those changes happened some of them were reverted once and some multiple times, by the third or fourth itteration we were right back where the spec originally started before it changed again.
I think that all changes to a specification should not be squashed and the original commit messages should stand until it is ready to be merged into master so that during the on-going discussion there is a clear trail of what has happened and why.
Also, the issue-head should be updated each time the specification changes to reflect the new specification and to explain why something-X was chosen over something-Y. I think that by doing this the end-result will be less needless changes and a cleaner discussion platform for debates to happen on.
The topic says it all, would be nice to have test vectors that are 'officially' valid, and ones which are officially 'invalid' so we can test for conformance in the parser.
Updates to IRCv3 capability specification and sasl
extension were discussed; this is my TODO list for updating the actual text:
CAP 3.2:
CAP LS * caps…
from draft-mitchell-irc-capabilities-02CAP NEW caps…
or CAP LS + caps…
to announce newly available capabilities (syntax depends on whether multi-line LS is approved)CAP ACK -caps…
to announce capabilities no longer available (#33)CAP ACK -caps…
or CAP DEL caps…
sasl=PLAIN,EXTERNAL
)SASL updates:
AUTHENTICATE ?
to query for a mechanism listOther 3.2:
This has been removed, see #40.
A few things that imho must be done before 3.2 and isn't specific to any extension:
Implementing the enhancements in #44 would be good too, but I'm not aware of anyone working on those, so I propose we do this minimal treatment for now.
Since almost everyone uses an application to connect to IRC (instead of telnet 😀) it would be nice if IRC could handle OAuth as an authentication method.
This would enable SSO and make life easier when IRC is in a closed environment (e.g. enterprise or some other private endeavor).
Enableable by a cap json
E.g.
{
"source": "nick!user@host",
"verb": "PRIVMSG",
"params": [
"#channel",
"Hello world!"
],
"tags": {
"server-time": "2014-03-10T08:28:43.126Z"
}
}
One of issues solved by this: #54
The following has been written by @Aerdan and has been added to the first post for newcomers.
The IRC protocol is structurally limited and doesn't allow for sideband information (e.g. message tags) without extending the protocol format. In addition, the IRC protocol is standardized on a strict 512-byte message, CRLF included. This means that any extensions which aim to add functionality of interest to users is inherently limited in what it can do. (See extended-join
for an existing example of how adding features alters standard commands.)
JSON allows us to add new properties to messages without requiring clients to support those properties. They don't have to know, mind, or care about the size of those properties, either, because they are effectively invisible to clients which don't support them. This is not the case with message-tags, because every tag has a cost proportionate to the length of its name, plus the length + 1 of its contents, if it has a value, + 1 for each tag after the first.
JSON is the most appropriate choice because we want a text-friendly protocol that plays well with real humans. It is also widely-supported, with implementations for every language anyone could possibly want to write IRC software in, unlike other formats. We don't want XML because XML is inherently unsuitable for messaging, particularly when people routinely write messages with control codes inside.
What? You mean it's not already broken? CAP exists because there was no way for clients to negotiate new features. Many other IRCv3 features exist to make the IRC experience better, and almost all of them could not exist without CAP.
Any comments from this point on which are not constructive or additive to this debate will be purged with extreme prejudice. (Most of) You are adults. Act like it.
With the recent issues of backwards compatibility with CAP LS 3.2 things I propose changing the name of capabilities from name
to name-X.X
where X.X is the IRCv3 version it was released with.
So all current specifications would stay without a version and are defaulted to version 3.1, all 3.2 specs should be renamed to 'spec-3.2' before it's final release. (Eg: batch-3.2
)
The reasoning behind this is simple, new technology could come out that previous specifications would benefit from, extended-join
is a good example, it could use the account
tag from 3.2.
This would require absolutely ZERO change for the client author wanting to implement this, aside from requesting extended-join-3.2
for example instead of extended-join
.
So, let's say we release batch-3.2
with the IRCv3.2 release, batch
does fine for 4-5 versions before there finally needs to be a revision to it. It's as simple as adding the revisions and re-releasing it as batch-3.7
. Clients can update and start requesting batch-3.7
when the support it, and continue requesting batch-3.2
until they do.
But to think that these specifications will not change at all for the duration of IRCv3 is simply not possible. The extended-join
is just the first example of this, it will happen again.
This was originally a smaller post under issue #60 but I have moved it here as it is an entirely separate issue.
Adding support for OTP-login to services packages as of now would have to involve logging in SASL-users and prevent them from executing commands until the user provides an OTP token.
It is ugly, as it leads to the user being logged in, and getting their account name set, despite not having completed authentication. RPL_LOGGEDIN and RPL_SASLSUCCESS would also be somewhat misleading.
The simplest solution appears to me to be to tack OTP on top of what we already have.
When a SASL user with OTP enabled requests the mech-list, services would list its options prefixed with 'OTP-'. For example "OTP-PLAIN,OTP-EXTERNAL".
During authentication, the client would send its OTP token before doing the rest of the auth like normal. The OTP token should be verified after username and password.
Example with plain:
C: AUTHENTICATE OTP-PLAIN
S: AUTHENTICATE +
C: AUTHENTICATE MTIzNDU2
S: AUTHENTICATE +
C: AUTHENTICATE c2h1dHRlcgBzaHV0dGVyAHlheXBvbmllcw==
S: 900
S: 903
Example with external:
C: AUTHENTICATE OTP-EXTERNAL
S: AUTHENTICATE +
C: AUTHENTICATE MTIzNDU2
S: AUTHENTICATE +
C: AUTHENTICATE +
S: 900
S: 903
This should be fairly simple to implement in existing software, as it can handle authentication in the existing providers as normal after dealing with the OTP part.
I am not sure if the title says anything, but discussion started at atheme/atheme#415 (comment) and there it was said that this is ircv3 thing.
I open this issue, because no one else seems to do it.
During the transition period, the IRC server SHOULD perform this translation until a
point in time is reached where translation is no longer necessary.
I felt the need to point out that this should state it MUST perform this translation. not SHOULD perform it. Also IRCv3 should NOT be changing the way things currently work. This will break older clients years down the road.
It's entirely fine to create opt-in things to do stuff differently, but there should be no 'transition period' moving from the old way to the new way. The old way must always work.
As per IRCv3.1, the optional away-notify extension is designed to keep track of a user state. The same can be said for the proposed MONITOR extension in IRCv3.2 but for a different state, being online or offline. Rather than having 2 different commands with two different syntaxes that do the same thing it may be easier to merge the two together to provide some consistency while keeping backward compatibility on the already published away-notify extension.
I see two changes to merge the two extensions:
With the above changes, a client should be able to monitor multiple users without the need to be sharing a channel. This will enable clients "friends list" implementations to be developed far easier with more functionality while also keeping the syntax broad enough to allow future expansion with different states if required.
Possible MONITOR extension syntax changes
:<server> 730 <nick> <state>:target[,target2]*
Possible new syntax based upon away-notify
:nick!user@host STATE ONLINE|OFFLINE|AWAY [:message]
A lot of people asked what is the difference between WATCH and MONITOR, I think a reasoning should be added to the document.
Only projects who participate in IRCv3 should be listed on website. It's better not to confuse people.
With the recent discussion of JSON there have been mentions of making user<->services integration better. Before this happens I think that services themselves need to become a bit more standardized. (Discussed briefly during the course of issue #55)
This is one of the major things that needs to become standardized. Services should be allowed to support any db format they wish but MUST support using and converting to the IRCv3-standard format.
Flags: I believe these are the future. They should however be changed from single-letter identifiers to full-word. Or we'll have the same 52-letter limit issue that modes are currently having.
Some current flags and possible full-word names:
Letter | Fullname |
---|---|
v | CanSetVoice |
V | AutoVoice |
o | CanSetChanOp |
O | AutoChanOp |
s | CanSet(Setting1), CanSet(Setting2) |
i | CanInvite, CanGetKey |
r | CanKick, CanBan, CanUnban |
R | CanRecover, CanClear |
f | CanModifyFlags |
t | CanSetTopic |
A | CanViewFlags |
S | ChannelSuccessor |
F | ChannelFounder |
b | AutoBan |
XOP: The current XOP system (whatever that may be in it's specific implementation) should be removed and replaced with 'Templates'.
Templates: This is a perfect replacement for XOP. Network-wide templates should be set for certain levels like, VOP, OP, etc, and then those templates would translate to certain flags for the given level.
VOP could get AutoVoice
and CanViewFlags
, OP would get more like AutoChanOp
, CanSetChanOp
, CanKick
, CanBan
, CanUnban
, etc
Users could also edit the templates on a per-channel basis to suit their specific wants/needs.
Access/Levels: Personally I think this should be removed entirely. It's not flexible enough for me to want to fight to keep it. It's basically a slide-rule [---|-] and as you move up the rule you get more access. It's a 'you get this + everything below this point' kind of idea, and I'm against that.
Translating Access/Levels to Flags: This 'may' be possible to do, but I'm against it. I think that it would be a bit messy to do and we would have to map all flags to a default 'access-level', and I'm sure that would cause a ton of debate on which flags should be given at each level.
Title pretty much says it all. I will not participate in this any further until it occurs.
Right now replies for remote WHOIS can get lost due to server ping timeouts.
This is not ideal for e.g. znc which allows you to connect to it using multiple clients and if if you /whois someone ideally the whois reply should not go to all attached clients but only to a single one who did the /whois.
It would be much easier for the znc guys to handle this situation if they knew the whois is going to get a reply no matter what happens on the server side.
I propose a new token to be added to 005/ISUPPORT which, if present, would guarantee that every single whois sent to the server will receive a reply, though not necessarily in the same order as they were sent.
One of IRC's biggest drawbacks is that sessions are bound to the lifetime of a single TCP connection. This is what makes it unsuitable for the mobile networks of the current decade.
I suggest the following, provided that the client presents an SSL client certificate: Implement a "RESURRECT old-nickname
" command as an alternative to the normal NICK/USER on connect. Provided that the client certificate matches the client certificate on the session of old-nickname, old-nickname's connection will be terminated and replaced by the new TCP connection. Since the client already knows the state, this eliminates the current nasty quit/join as well as the retransmission of most of the state.
Things to consider:
write(2)
)Comments welcome, since this is a very rough draft (but something I would consider to be very important).
Edit: fixed markdown.
A conservative amount of numerics (10?) should be reserved for each vendor upon request to avoid single numeric reservation requests
Currently, there is some disparity in client support of the STATUSMSG extension. I would like to include provisions for STATUSMSG in IRCv3.The current "IRCv2" STATUSMSG implementation has a 005 token advertise that STATUSMSG is supported, and a client sends a STATUSMSG by prefixing a channel name with one of the characters found in the value of STATUSMSG, which corresponds to a PREFIX flag. This same construct is then sent to those clients that receive the message, but not all clients correctly handle all such cases.
I would like a CAP token be added for covering STATUSMSG support, with the following effects:
For clients that do not negotiate capabilities, IRCv2 fallback basically has us treating the client as if it had sent the token.
This includes/references all non-complete tasks from 25 January 2014 (#34).
CAP 3.2:
CAP LS
indicating support for IRCv3.2 CAP.cap-notify
for notifying on changes in cap availability, as a separate specification not tied to CAP 3.2.SCTP:
The index doesn't have full links to requirements so I had to copy-paste it and fix the links by myself (for https://github.com/ProgVal/Limnoria/issues/1015).
## IRCv3.1
### Base Extensions
* [ ] [IRC Version 3.1: Capability Negotiation](https://github.com/ircv3/ircv3-specifications/blob/master/specification/capability-negotiation-3.1)
* [ ] [IRC Version 3.1: `multi-prefix` Extension](https://github.com/ircv3/ircv3-specifications/blob/master/extensions/multi-prefix-3.1)
* [ ] [IRC Version 3.1: `sasl` Extension](https://github.com/ircv3/ircv3-specifications/blob/master/extensions/sasl-3.1)
### Optional Extensions
* [ ] [IRC Version 3.1: `account-notify` Extension](https://github.com/ircv3/ircv3-specifications/blob/master/extensions/account-notify-3.1)
* [ ] [IRC Version 3.1: `away-notify` Extension](https://github.com/ircv3/ircv3-specifications/blob/master/extensions/away-notify-3.1)
* [ ] [IRC Version 3.1: `extended-join` Extension](https://github.com/ircv3/ircv3-specifications/blob/master/extensions/extended-join-3.1)
* [ ] [IRC Version 3.1: `tls` Extension](https://github.com/ircv3/ircv3-specifications/blob/master/extensions/tls-3.1)
## IRCv3.2
* [ ] [IRC Version 3.2: Capability Negotiation 3.2](https://github.com/ircv3/ircv3-specifications/blob/master/specification/capability-negotiation-3.2.md)
* [ ] [IRC Version 3.2: Message Intents](https://github.com/ircv3/ircv3-specifications/blob/master/specification/message-intents-3.2.md)
* [ ] [IRC Version 3.2: Message Tags](https://github.com/ircv3/ircv3-specifications/blob/master/specification/message-tags-3.2.md)
* [ ] [IRC Version 3.2: Metadata](https://github.com/ircv3/ircv3-specifications/blob/master/specification/metadata-3.2.md)
* [ ] [IRC Version 3.2: `account-tag` Extension](https://github.com/ircv3/ircv3-specifications/blob/master/extensions/account-tag-3.2.md)
* [ ] [IRC Version 3.2: `monitor` Extension](https://github.com/ircv3/ircv3-specifications/blob/master/specification/monitor-3.2.md)
### Optional Extensions
* [ ] [IRC Version 3.2: `account-tag` Extension](https://github.com/ircv3/ircv3-specifications/blob/master/extensions/account-tag-3.2.md)
* [ ] [IRC Version 3.2: `batch` Extension](https://github.com/ircv3/ircv3-specifications/blob/master/extensions/batch-3.2.md)
* [ ] [IRC Version 3.2: `cap-notify` Extension](https://github.com/ircv3/ircv3-specifications/blob/master/extensions/cap-notify-3.2.md)
* [ ] [IRC Version 3.2: `chghost` Extension](https://github.com/ircv3/ircv3-specifications/blob/master/extensions/chghost-3.2.md)
* [ ] [IRC Version 3.2: `invite-notify` Extension](https://github.com/ircv3/ircv3-specifications/blob/master/extensions/invite-notify-3.2.md)
* [ ] [IRC Version 3.2: `sasl` Extension](https://github.com/ircv3/ircv3-specifications/blob/master/extensions/sasl-3.2.md)
* [ ] [IRC Version 3.2: `self-message` Extension](https://github.com/ircv3/ircv3-specifications/blob/master/extensions/self-message-3.2.md)
* [ ] [IRC Version 3.2: `server-time` Extension](https://github.com/ircv3/ircv3-specifications/blob/master/extensions/server-time-3.2.md)
* [ ] [IRC Version 3.2: `userhost-in-names` Extension](https://github.com/ircv3/ircv3-specifications/blob/master/extensions/userhost-in-names-3.2.md)
## Additional Documentation
* [ ] [SASL: DH-AES mechanism](https://github.com/ircv3/ircv3-specifications/blob/master/documentation/sasl-dh-aes.md)
* [ ] [SASL: DH-BLOWFISH mechanism](https://github.com/ircv3/ircv3-specifications/blob/master/documentation/sasl-dh-blowfish.md)
* [ ] [Batch: `netsplit` type](https://github.com/ircv3/ircv3-specifications/blob/master/extensions/batch/netsplit.md)
Simplify the version number in CAP LS (and the possible version
extension) to be an integer.
Hello,
I have noticed a glaring flaw in the spec for IRCv3. It is obvious that this flaw is intentional and is supposed to be a feature, but I'm going to point out why it's a bad idea.
Namely, the flaw involves the length of tags being unspecified.
"BUT FIXED-LENGTH BUFFERS SUCK"
No, they prevent an attacker from clogging the server with a tag that could be of theoretically unbound length, not to mention simplify the handling of buffers and parsing.
I know that the authors of the spec seem to be from the ZNC team and they have fancy C++ string functions and all that, but C doesn't like unbounded buffers. It means parsing and buffering becomes harder than it has to.
Even ignoring the previous issue, unbounded tags are a terrible idea. The obvious workaround is "clip at a sane limit."
But what should this limit be? Implementation-defined is not acceptable - it needlessly shifts the burden onto client authors for no reason except for server developer laziness. @kaniini thinks, based on discussions with him on IRC, it should be bound at 512. This still keeps the 512 char limit for messages, but also reserves 512 chars for tags. I think this is a sensible solution and makes it relatively quick and easy to implement tags if you update your parse() and add a separate buffer for them.
Thoughts? Feelings? Rotten tomatoes?
This was discussed briefly last night or the night before. Basic idea is allowing users to send queries to nick=accountname
instead of just nick
, similar to the nick@server
format that has been used before.
If =accountname
doesn't match the services account of the nick
the message is being sent to it should be rejected with an error.
The account-tag
CAP is using (at the time of writing this) the !service
account name for network-based services. If that is accepted then it should be used in this as well for conformity.
Since this doesn't require any additional client support a CAP to support it is unneeded. It should be denoted in the 005 numeric as ACCOUNTMSG
for servers that support this.
Edit :: SECUREMSG
was renamed to ACCOUNTMSG
due to the CAP that was going to use that name being renamed to account-tag
capability-negotiation
in my opinion, would be better served to users if it was a rolling version.
Currently we have just CAP LS
, but we want to add things to 3.2 which may break 3.1, see #34
My proposal is we keep a rolling version of CAP to be equal to the current version of the IRCv3.x spec.
CAP LS
will default to 3.1 and will send all 3.1 specs, as well as higher specs that can be sent in the 3.1 version of CAP.CAP LS v3.2
will send all specifications 3.2 and below, as well as higher specs that can be sent in the 3.2 version of CAP.Doing things this way means that updating CAP itself will not break clients who depend on a previous version of the spec, and will have time to rewrite their implementation before requesting the newer version to get the capabilities associated with it.
All new specifications being written should have a section denoting the lowest CAP-version they support, so authors will know not to send those to clients requesting a version lower than that.
Versioning capabilities was moved from this issue to #61
By not sending unknown commands to server, all the server side aliases break including /ns
, /nickserv
etc. This again can be viewed as security issue as those server side aliases usually check that the server is U-lined.
Currently most of clients require manual configuration
/set irc.network.send_unknown_commands on
I am opening this issue in hope something could be defined in the future to solve this issue.
Raised by @jwheare
Updated 3March2014
There's been a lot of discussion over IRC about the current implementation and how it appears to differ from implementation to implementation. Also some people don't like knock having it's own numerics.
In light of this, I think the best course is to go with a KNOCK cap, if it's enabled then we follow our implementation, if it's not enabled then we don't care. It'll fall-back to whatever the current server has decided to use for their implementation.
What we've got so far:
With no message: :knocking-user!ident@host KNOCK #chan
With message: :knocking-user!ident@host KNOCK #chan :user-message
We'll still need to form some sort of error message to give out if the channel is blocking knocks (+K on some servers) and similar. But this seems to be a good basis.
Adding away-notify and account-notify support to MONITOR. Users will get the 'updates' from away and account notify with MONITOR if they have those capabilities enabled.
The client should send MONITOR + <nick>
when the user PMs another person, NOT when the user recieves a PM. After so much inactivitiy the client should auto-remove the MONITOR
Normal usage:
:nick!user@host PRIVMSG nick2 :initial pm
MONITOR + nick2
:nick2!user@host ACCOUNT nick2
:nick2!user@host AWAY :I'm not currently here
and then after so much inactivity, the client can send MONITOR - nick2
In the case of the current MONITOR list being full, clients would need to respect the MONITOR=XXX
in the 005 numeric and remove a user before sending another, eg:
:nick!user@host PRIVMSG nick2 :initial pm
MONITOR - oldnick
MONITOR + nick2
:nick2!user@host ACCOUNT nick2
:nick2!user@host AWAY :I'm not currently here
Only clients that support away-notify
or account-notify
should be getting the AWAY/ACCOUNT messages, the rest would get the MONITOR-specific stuff.
Clients should maintain two lists for MONITOR, one that users specify in the clients that should be on the MONITOR list 100% of the time, and another that is used for the query-specific stuff.
If/When clients have to remove old nicknames they should never remove nicks from the list of nicks that users want to be on the list 100% of the time, only from the second list.
I made this topic to track the status of the IRC discussion, I think it all the non-metadata specific stuff in it, because quite frankly I don't understand the metadata stuff yet. I will update it with new information when/if new information is given.
If a server can no longer support a CAP that was requested by a client and ACKed by the server(e.g. a module being unloaded), what should the server send to the client so that the client can be aware of this?
Currently playback messages are treated as regular messages by bouncers and provide no indication to a client that they are replay messages. Certain clients such as Textual assume that replay messages is one with the server-time tag added. This is the current behavior of znc. There is no reason that a server cannot add a server-time tag to all messages, thus I propose that a new tag be added that indicates a playback message to clients.
Clients may like to specially handle playback messages. For example, Textual has an option to not post notifications for playback messages. There are other use cases such as handling joins and parts. If a client knows that the message is part of the playback it need not update it channel state. This issue was discussed in #znc where in order to support joins and parts in the playback buffer, either the znc bouncer would have to maintain an 'old state' which is from the start of the playback buffer or clients could simply print joins and parts from the playback buffer.
A new CAP would be needed to support this feature thereby enabling a bouncer to freely send joint, parts, etc. The responsibility of the client would be to understand messages with this tag do not reflect the current state of a channel and as such should not be acted upon.
Hello,
I brought this up with @kaniini and he asked me to file a bug. In the course of compiling numerics for my IRC library, I located the following conflicts between numeric 270:
Inspircd:
RPL_MAPUSERS - (comment: insp. specific)
RPL_PRIVS - charybdis (says it comes from ircu who added it in 2000, before inspircd existed ;p).
I think this is a bug, so I'm posting it here. Numeric conflicts aren't a good thing.
Client attaches a cookie to the request and get that same cookie back in the response message(s).
Useful for ZNC, when multiple clients are connected, instead of hacky http://wiki.znc.in/Route_replies
See #51
Note that some implementations in the wild have vendor specific variations. E.g. rules on case sensitivity, the H
(real host names) option, join-delayed channel members.
It would be useful to document the base compatibility case for new implementations and highlight any areas where vendor-extensions are possible.
https://github.com/quakenet/snircd/blob/master/doc/readme.who
http://faerion.sourceforge.net/doc/irc/whox.var
Allow clients to roam to another server and retain their complete state in case their server has to be shut down or rebooted (due to system upgrades, etc.).
What was talked about #111 at IRC.
Someone else can probably also explain this issue better. Have something in ISUPPORT to list the commands that the server supports and their syntax, so clients can know that server supports those commands and send those commands to server directly without /quote
. Primarily /nickserv
etc.
There was a discussion on IRC about not allowing MONITOR to accept hostmasks due to the amount of time you may have to spend doing lookups on connect/disconnect/away/account/etc if the server has many different hostmasks being monitored.
How hostmasks differ:
If you are matching nicks then when a user connects you could instantly lookup that nick. There would be no confusion about which MONITOR that nick belongs to.
With hostmasks, since you can do *!*@example.com
, or *[email protected]
, or even *!*@*.com
, a connecting user may match multiple different MONITORs and this would mean you would have to loop for every MONITOR to check which one(s) it matches.
This also means that if using away-notify and account-notify with MONITOR integration, you would need to loop for every MONITOR and do hostmask checks when away/account status changes.
Edit :: Added how hostmasks differ from nick lookups
I opened this to track the status of this discussion and will update the issue accordingly as new information comes in.
There's been some discussion over this and the simplest thing to do would be to add something like MSGLEN=512
to the 005 numeric. Similar to AWAYLEN
, NICKLEN
, and CHANNELLEN
, etc.
Reasons for doing this instead of a CAP
MSGLEN=XXX
If a CAP is added then users with the CAP should not be able to send messages over 512bytes to anywhere that contains a user without the CAP. It should not truncate or split the line, it should return an error.
Mode/topic/etc lines should error if the line is over 512 bytes with users in the channel that do not have the CAP enabled.
Two types of milestones
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.