Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Viber does not provide an open API for retrieving message history. In fact, the history is purely client-side in Viber.
However, Windows desktop Viber client uses an SQLite DB file as the storage of messages. The DB is not encrypted nor secured in any other way. Of course, hacking it is not officially supported and maybe even breaks some license agreements. But who cares? :)
In order to bring Viber messages in Consensus DB we need a client-side application running on Windows system alongside with Viber desktop client. This application should check Viber SQLite DB file periodically for new messages in the chats specified in params. We call this application Agent.
The agent, similarly to Consensus server, runs a set of data source handlers. Right now it is only Viber data source handler. In the future it can be also Skype or some non-messenger stuff (browsing history, etc.).
The agent binary is a part of back end application container in terms build and deployment. A download link is available in the web front end. Agent itself is UI-less and runs in the background. Upon first run it installs itself to an app data directory and configures itself to run on system boot. Agent is being updated automatically, again in the background.
Some trade-offs have been made:
unstable support in dotnet CLI (I was able to publish ClickOnce package successfully only from VisualStudio). Involving a third-party installer framework is an overkill for this project.
To do in the future: