I believe we have worked out your issue with the failures, via your examining the payload returned from your webhook request. We do want to add a tracker and viewer of failed webhook calls for inside the client, though.

At the moment, we limit you to 10 messages/second, 60 in a minute, or 500 in an hour. That limit will be fluid as we keep an eye on usage of this feature and make sure we're not causing any undo stress on our systems.

Thank you for this report. We did push out an update yesterday for a different Android notification issue, where the application would get into a "bad state" and stop showing push notifications. That seems to have been fixed with yesterday's build, with verification coming in from users, but we will test the navigation for Direct Messages.

Note that for post/comment notifications, we don't take you to the forum/team/user, but to the NOTIFICATIONS tab, but that doesn't sound like your issue.

Hi Austin,

That is very strange on the "catch up" behavior! We'll so some research on that. When we receive the real-time event for the notification, and we push that to the App Shell API, we are done with it at that point. I can't think of any place in our code where a bunch of them would get "saved up" such that we could send them rapidly later. So I'm wondering where that could be happening.

Hi Todd - We definitely have push notifictions for iOS. There two most common things that cause people to report not getting them are:

1. They still have a Ryver client active someplace, such as on their desktop. As long as you are active and being reported as Available (green) to other users, we do not send out push notifications.

2. People are expecting to get notifications of ALL messages in a Forum/Team chat room, not just @mentions. It doesn't sound like this is your issue, as you mentioned not getting a Direct Message. Note, though, that over the next couple of weeks, we will be working on adding support for push notification of all messages in specified teams/forums.

If you're still not getting push notifications, please contact Support and we'll try to dig into what might be happening in your particular case.

I verified that pasting the original text doesn't cause the command help to pop up anymore, but it would definitely still be best practice to use the back-ticks for any embedded code in messages.

We're now talking about ways to put a formatting helper into the chat textbox area, which should help.

This should have been fixed. Please make sure you have version 1.2.0 under Help > About. Also, please note that we have added auto-update support in the 1.2.0 build for future releases. You can download this version of the desktop app on the Ryver downloads page.

Thanks.

Hi Austin. The reason for the failure would get returned to your calling code. However, we agree that in the next round of work on this feature, it would be good to provide a log for the failures.

I'll add something to this article on the most likely reason for failures, which would include passing an invalid JSON format, passing the wrong content type in the header, or passing too many webhooks over a given period of time and having the rate limiter kick in.

Sorry about the continued issues with scroll position and embedded content. With the latest upgrade, we have put the foundation in to start tracking embed size in messages so that the scroll window can be nudged the appropriate distance. Now we just need to schedule the work to finish that up.

We are still seeing the desktop client automatically set presence status to "Away" after 5 minutes (used to be 15) of inactivity. Though, we have had a handful of reports of this not working. We're hoping we'll be able to identify a particular combination of software running on a computer that would cause this problem, as we're using standard Windows API calls to get reports of any keyboard or mouse activity.

If you are on Windows 10, you should be seeing messages reported through the Action Center as of the last couple of versions of the desktop shell. Though, there is a known bug in the Open Source project we are using for the shell in which the messages don't persist in the action center. For earlier versions of Windows, we fall back on older APIs that will show the message above the task tray in the lower corner.

In our next round of "desktop client" work, we will be looking into the additional Action Center bug if that hasn't been solved already in the latest version of the Electron shell.