Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Viber data source #1

Merged
merged 13 commits into from
Jan 9, 2022
Merged

Viber data source #1

merged 13 commits into from
Jan 9, 2022

Conversation

ikesler
Copy link
Owner

@ikesler ikesler commented Jan 9, 2022

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:

  • Custom installer (built-in to the application). The option which comes with .NET out of the box for installing Windows apps is ClickOnce installer. However, it has several drawbacks in .NET 6 (and also 5): cannot build ClickOnce package in Docker and
    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.
  • Unfortunately, assembly trimming does not play well with Entity Framework and was disabled. It could be very helpful because the size of the agent application does matter.

To do in the future:

  • Authentication. Not only for Agent - for the system in general - right now it is single-user.
  • Add Quartz.NET to Agent app - same way as we use it on the server side. Schedules should be taken from the API. Right now Viber data source handler is woke up every minute - hardcoded.
  • Some sort of Agent web dashboard - which agents are connected to the API, last connection time, version, etc.

ikesler added 13 commits January 4, 2022 23:24
ClickOnce was not good solution because
1. Cannot build ClickOnce package in Docker
2. Unstable support in dotnet CLI. I was able to publish ClickOnce package successfully only from VisualStudio. dotnet or event msbuild CLI - no luck, only errors
unfortunately, trimming is not working with EF yet: dotnet/efcore#26383 and dotnet/efcore#218

SQLLite EF provider includes an unmanaged module which is not part of single-file publish - IncludeNativeLibrariesForSelfExtract option required
single-file build cannot be debugged - this is why PublishSingleFile msbuild property is used in dockerfie only
hide console window. In Windows application mode the console host still appeared:
AvaloniaUI/Avalonia#6672 and dotnet/runtime#3828
@ikesler ikesler merged commit e311cab into master Jan 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant