You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I had an idea years ago to negotiate commands on burst. It would be useful for determining whether to send outgoing commands to servers. Servers could also notify opers of protocol mismatches when things don't add up. My original idea was to include parameter information too, but I don't think that has any true benefit.
Once the JELP protocol is versioned and standardized, we can simplify this by adding definitions for commands in a certain protocol version. The receiving server will be certain to have at least the commands in that set if the version in the SERVER command is greater than or equal to the one specified.
A bit tricky will be determining which modules/commands were added and removed during a RELOAD. We certainly do not want to send it all over again each time we do that.
How it might look
During burst, include a parameter which is a stable modeset ID (JELP version):
:0 MOD :Channel::Access,11.2 Channel::Invite,4.4 Grant,9.1 Git,0.6 Reload,2.1 Ban,15.3 Cloak,0.5 DNSBL,0.2
:0 CMD 1.67 :GRANT UPDATE RELOAD BAN BANINFO BANIDK BANDEL
When a module is loaded, such as Ban:
:0 MOD :Ban,10.2 Ban::JELP,5.4
:0 CMD :BAN BANINFO BANIDK BANDEL
When a module is unloaded:
:0 CMD -BAN -BANINFO -BANIDK -BANDEL
:0 MOD -Ban -Ban::JELP
Example
GRANT currently sends out UMODE and OPER commands which will one day be invalid (#91). Adding a command which enables oper flags and sets umode +o would fix this. But what if you want to GRANT a user who does not have the grant module?
if (!$t_user->server->has_cmd('GRANT')) {
$user->server_notice(grant=>'Grant is not available on the destination server');
return;
}
Brainstorming
Other random ideas:
Check if servers have a module with $server->has_mod('Cloak')
Check if servers have a command with $server->has_cmd('GRANT')
MODESYNC (MODESYNC #63) could automatically be initiated by MOD. If we see that a remote server now has a module which provides channel modes, send our modes!
The text was updated successfully, but these errors were encountered:
Concept
I had an idea years ago to negotiate commands on burst. It would be useful for determining whether to send outgoing commands to servers. Servers could also notify opers of protocol mismatches when things don't add up. My original idea was to include parameter information too, but I don't think that has any true benefit.
Once the JELP protocol is versioned and standardized, we can simplify this by adding definitions for commands in a certain protocol version. The receiving server will be certain to have at least the commands in that set if the version in the SERVER command is greater than or equal to the one specified.
A bit tricky will be determining which modules/commands were added and removed during a RELOAD. We certainly do not want to send it all over again each time we do that.
How it might look
During burst, include a parameter which is a stable modeset ID (JELP version):
When a module is loaded, such as Ban:
When a module is unloaded:
Example
GRANT currently sends out UMODE and OPER commands which will one day be invalid (#91). Adding a command which enables oper flags and sets umode +o would fix this. But what if you want to GRANT a user who does not have the grant module?
Brainstorming
Other random ideas:
$server->has_mod('Cloak')
$server->has_cmd('GRANT')
MOD
. If we see that a remote server now has a module which provides channel modes, send our modes!The text was updated successfully, but these errors were encountered: