support for private messages?

[axelmoreen]

is this possible? I couldn't exactly find an api endpoint for it, but I could be missing something important.

[anjanms]

Private messages are not currently supported by DubAPI. Though are potentially something for a future release.

Current Dubtrack PM endpoints are

• GET https://api.dubtrack.fm/message - Get conversations
• POST https://api.dubtrack.fm/message - Create conversation
• GET https://api.dubtrack.fm/message/new - Poll for new messages
• GET https://api.dubtrack.fm/message/%CONVID% - Get messages in a given conversation
• POST https://api.dubtrack.fm/message/%CONVID% - Send message in given conversation
• POST https://api.dubtrack.fm/message/%CONVID%/read - Mark conversation as read

[nine1six]

Is this a feature that will be pursued in the future? Sending commands to the Bot via PM's would be awesome.

[anjanms]

Yes, it's something I'd like to do. I just haven't been able to work on DubAPI as much as I'd like to.

[hedgehog1029]

I've started work on this over in my fork, and there's currently support for sending PMs. It's kind of annoying that you have to poll for new messages, rather than being able to receive them via PubNub (slower too), but I'll look into implementing that next.

[FranciscoG]

+1 for this feature request

[hedgehog1029]

Gonna revive this - I haven't tested merging the latest commits with my fork, but now we're on a regular websocket connection, does dubtrack finally have support for receiving DMs over it? The way it's handled by dubtrack currently is fine for the web client but terrible for bots.

[FranciscoG]

@hedgehog1029 I've asked on the discord developer channel to see if the last major update changed the way DM's work. I know they switched from using a third party (PubNub) to rolling their own websockets pubsub server.

I'm ok with with polling, there's an expectation of chat being real-time, but DMs don't need to be. You can set up a polling of something like every minute and I'd be fine with that.

[hedgehog1029]

Polling is annoying, given that we have a websocket connection anyway, but just about acceptable. The real issue is the way Dubtrack polls and downloads DMs - it polls one endpoint (/new) but then calls another endpoint to actually download the DMs, and they get downloaded as one big JSON blob, rather than giving you only new DMs. This also means you get the entire DM history of the account, which is gonna be a pain for big bots. Polling on the client only downloads the number of unread DMs, which it then displays as the little notification.

[FranciscoG]

yeah I'm realizing this now as I'm trying to figure this out myself. so annoying. I'm trying to see if there's something lodash can do to compare previous download of messages to a subsequent one... and also after polling, comparing to check for new, we also have to mark each new one as read via a separate call. geez

[hedgehog1029]

@FranciscoG one of the front-end devs on Discord mentioned that the websocket now has a new-message event for dealing with DMs.

[FranciscoG]

that's awesome! so much better than polling.

I assume we still have to mark that message as read. This only replaces the GET https://api.dubtrack.fm/message/new - Poll for new messages

[FranciscoG]

so I tried listening to the new-message event, but getting nothing so far. Maybe @anjanms needs to make an update to eventHandler.js

[hedgehog1029]

try listening to the * event and dumping the result with console.dir

[qaisjp]

Just bumping this...

[hedgehog1029]

A quick test with my personal library shows absolutely no websocket events are recieved when a DM is recieved. My library isn't quite ready for release but I'll look into implementing both sending and polling for DMs at some point.