There should be a namespace to interact with chat. The following is an old draft of mine of what that could look like:
APIs (ordered by namespaces)
chat
conversations
Conversation
id
accountId
muc
name
room
buddyId
unreadCount
mentionCount
lastReadMessage
topic
Participants: Array of Participant
Participant
id
name
conversationId
avatar
status
statusText
metaDetails
mode (OP etc.)
create
accountId
room?
buddyId?
update
conversationId
index?
unread progress/state?
selected?
query
selected?
index?
providerId?
accountId?
muc?
conversationId?
close
conversationId
getParticipants
conversationId
updateParticipant
participantId
updatedParticipant
onCreated
onUpdated
onClosed
onTooltip -> allows adding data to the tooltip
buddies
Buddy
id
accountId
status
statusText
create
accountId
buddy login or whatever
nickname
update
nickname
query
buddyId?
nickname?
accountId?
providerId?
remove
buddyId
onCreated
onUpdated
onRemoved
providers
Provider
id
name
canMuc
canBuddy
canTopic etc.
IRC
onCAP
onCommand
onTag
onISUPPORTs or whatever
etc.
XMPP
I don't know XMPP, just that it has something similar to the CAP system.
onStanza
get
onRegistered
onUnregistered
accounts
Account
id
providerId
server
nickname
password
autoJoinedRooms
create
update
query
remove
onCreated
onUpdated
onRemoved
presence
Presence
avatar
status
statusText
get
update
onUpdated (with reasons like auto idle)
messages
Message
id (not sure)
text
rawText
userName
buddyId?
participantId?
incoming
system
timestamp
conversationId
create
conversationId
text?
raw? (so you can send custom XMPP and IRC etc. payloads)
query
conversationId
buddyId?
onReceive
allows filtering/changing a message
onSend
ditto
onCommand
or should commands be declarative in the manifest.json?
menus
add extra targets for messages, conversations, buddies and participants
That's about it for APIs. But as you will notice, nothing about themes, emote sets or new providers in there. That's because that should be statically declared in the manifest.json:
provider
name
icon
entry_point -> html file that gets special APIs described later on
capabilities
topic
buddy
muc
presences
?
setup
type (oauth vs. pw/login)
fields
username
server
password
port
TLS
defaults
defaults for fields -> set OAuth URL here?
emote_set
not sure how this'd look. Probably a key value map?
theme
even less sure how that'd work. In Firefox themes have been abstracted far away from the "bare metal" to essentially CSS var tweaks, which is definitely way less than what chat themes have been able to do. Given the APIs above I think a theme should just be able to do everything themselves, they just provide the HTML file to load in the conversations frame and then there's some API for them to know what conversation they're in and that's about it. Requires it to be the last one to get the events, so probably needs a specific implementation for themes.
permissions
accounts
conversations
messages
buddies
providers
presence
irc
xmpp
The provider API
Provider pages would essentially get some additional APIs to either build on top of an existing provider or build their own (and since TCP sockets are not exposed to extensions atm some socket would have to be exposed...)
Not sure if some APIs should be restricted from here, so the socket part can run in its own thread and all the front-end stuff that doesn't actually need the socket would be forced to the classic extension background script and they could communicate by messaging.
The exposed socket things would be classes that could be extended? Not sure. All the events from the other APIs should only be sent for changes coming from outside the provider, so the provicer can use the create, update and remove methods for UI changes.
providers
IRC
XMPP
Socket
conversations
addParticipant
removeParticipant
messages
create
from
providerInstance
setConnectionStatus
onConnected (user/autoconnect)
onDisconnected (user disconnect)
???? -> probably mostly event handlers -> many type specific handlers are already present in the API above, maybe add shortcuts that don't require filtering for providers
There should be a namespace to interact with chat. The following is an old draft of mine of what that could look like:
APIs (ordered by namespaces)
That's about it for APIs. But as you will notice, nothing about themes, emote sets or new providers in there. That's because that should be statically declared in the manifest.json:
The provider API
Provider pages would essentially get some additional APIs to either build on top of an existing provider or build their own (and since TCP sockets are not exposed to extensions atm some socket would have to be exposed...) Not sure if some APIs should be restricted from here, so the socket part can run in its own thread and all the front-end stuff that doesn't actually need the socket would be forced to the classic extension background script and they could communicate by messaging. The exposed socket things would be classes that could be extended? Not sure. All the events from the other APIs should only be sent for changes coming from outside the provider, so the provicer can use the create, update and remove methods for UI changes.