title | layout | work-in-progress | copyrights | |||||||
---|---|---|---|---|---|---|---|---|---|---|
Bikeshedding |
spec |
true |
|
title | layout | work-in-progress | copyrights | |||||||
---|---|---|---|---|---|---|---|---|---|---|
IRCv3 Message Modification |
spec |
true |
|
# COLOURS | |
set -g default-terminal "screen-256color" | |
# Status bar can have utf-8~ | |
set-option -g status-utf8 on | |
# Status bar has a dim gray background | |
set-option -g status-bg "#303030" | |
set-option -g status-fg "#f0f0f0" |
User changes from 127.0.0.1 to a cloaked hostname
User without CHGHOST
sees:
:dan!dan@127.0.0.1 QUIT :Changing host
:dan!dan@cloaked.host JOIN #coolchan
User with CHGHOST
sees:
:dan!dan@127.0.0.1 CHGHOST dan cloaked.host
diff --git a/_includes/software_list.html b/_includes/software_list.html | |
index bc5a4c1..add5006 100644 | |
--- a/_includes/software_list.html | |
+++ b/_includes/software_list.html | |
@@ -2,6 +2,4 @@ | |
{% if type.note %}{{ type.note | markdownify }}{% endif %} | |
-{% for support in site.data.irc_versions %} | |
{% include support_list.html %} |
class DataStore: | |
def __init__(): | |
self.store = {} | |
def set(key, value): | |
self.store[key] = value | |
def delete(key): | |
try: | |
del self.store[key] |
Daniel Oaks daniel@danieloaks.net
People like to use IRC to roleplay. In other words, to act out characters as part of a channel and between clients. Often, this means it's desirable to send messages with names other than the client's nickname, and to send messages not explicitly attached to a name at all.
Page explaining this regex: http://danieloaks.net/irc-regex/ | |
Raw regex: | |
^(?:@([^\r\n ]*) +|())(?::([^\r\n ]+) +|())([^\r\n ]+)(?: +([^:\r\n ]+[^\r\n ]*(?: +[^:\r\n ]+[^\r\n ]*)*)|())?(?: +:([^\r\n]*)| +())?[\r\n]*$ | |
Sample IRC messages: | |
foo bar baz asdf |
I propose that a group known as the "IRCv3 Security Council" is created.
This group is a separate part of the IRCv3 effort, will have their own section on the website just as the IRCv3 Working Group page is being split off from the landing page, and for most intents and purposes act independently of the IRCv3 Working Group.
Rationale: The traditional CA model has, widely, not worked with IRC today. Large portions of IRC networks out there today use self-signed certificates, and disabling certificate verification or otherwise working around the certificates not validating using traditional methods is fairly common.
This proposal would allow the creation of certificate bundles and revocation lists controlled by the IRCv3 Security Council, which when used by clients (instead of the traditional CA roots provided by operating systems) should solve the majority of these issues for IRC users and network operators.