Currently we have no concept of Users and rely purely on the data provided to us via the Message object. We should add an internal concept of Users that allows us to refer to the same physical user across all of the different connection handlers. For simplicity, all group conversations/rooms should be treated as a single user (and therefore can exist across multiple connection handlers) We currently use the MessageTarget class to provide a nice interface to physical users, although this has no ability to cross different connection handles.
The new User class should act as a collection of MessageTarget classes. When a message is sent to a User, it should be sent via the most recently active MessageTarget (typically the last one to be used?), unless the User is no longer online via that MessageTarget (in which case the next one should be attempted). MessageTargets that don't have the ability to be offline (i.e. Facebook) should be attempted last. A User should also provide additional methods for sending to all MessageTargets.
Example intended usage:
message.getSender().sendMessage("hey hey!");
=> sends a message to the last active MessageTarget
message.getSender().sendMessageAll("hey hey!")
=> sends a message to all online MessageTargets
shadow.getUser("R4wizard").sendMessage("hey hey!")
=> sends a message directly to 'R4wizard's last active MessageTarget
shadow.getUser("R4wizard").sendMessageAll("hey hey!")
=> sends a message directly to all of 'R4wizard's online MessageTargets
Because all channels/rooms are considered a User too. This allows sending message to a room/conversation/channel that exists across multiple connection handlers; for example:
shadow.getUser("#shadowacre").sendMessageAll("hey hey!");
=> sends a message to the 'shadowacre' group across all connection handlers.
The non-All versions of this functions make little sense when used like this, but are still available.
Users should also support a concept of aliasing. This will require creating a shadowbot plugin (shadowbot-plugin-aliases) for managing these aliases.
Users should also support a concept of authentication confirmation. For example, with IRC a nickname can be protected using NickServ but there are situations where the name can still be used without authentication - this can be resolved by quickly checking the user is correctly authenticated with nickserv before proceeding. This would likely be used as follows:
message.getSender().checkAuthentication().then(/* do something */).catch(/* failed auth */);
This is not a substitute for a permissions system, that should be implimented using other methods. This purely should be used for confirming the user is who they say they are (and in some connection handlers this has absolutely no use as the user is always authenticated (i.e. Facebook)
Currently we have no concept of Users and rely purely on the data provided to us via the Message object. We should add an internal concept of Users that allows us to refer to the same physical user across all of the different connection handlers. For simplicity, all group conversations/rooms should be treated as a single user (and therefore can exist across multiple connection handlers) We currently use the MessageTarget class to provide a nice interface to physical users, although this has no ability to cross different connection handles.
The new User class should act as a collection of MessageTarget classes. When a message is sent to a User, it should be sent via the most recently active MessageTarget (typically the last one to be used?), unless the User is no longer online via that MessageTarget (in which case the next one should be attempted). MessageTargets that don't have the ability to be offline (i.e. Facebook) should be attempted last. A User should also provide additional methods for sending to all MessageTargets.
Example intended usage:
Because all channels/rooms are considered a User too. This allows sending message to a room/conversation/channel that exists across multiple connection handlers; for example:
The non-All versions of this functions make little sense when used like this, but are still available.
Users should also support a concept of aliasing. This will require creating a shadowbot plugin (
shadowbot-plugin-aliases) for managing these aliases.Users should also support a concept of authentication confirmation. For example, with IRC a nickname can be protected using NickServ but there are situations where the name can still be used without authentication - this can be resolved by quickly checking the user is correctly authenticated with nickserv before proceeding. This would likely be used as follows:
This is not a substitute for a permissions system, that should be implimented using other methods. This purely should be used for confirming the user is who they say they are (and in some connection handlers this has absolutely no use as the user is always authenticated (i.e. Facebook)