Chat APIs

[freaktechnik]

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