intiface / intiface-desktop Goto Github PK

In order to get windows installers running, node executable running was disabled. Need to readd capabilities for this.

If there's no network, "check updates" throws exceptions but they're never bubbled up to the frontend.

Red circle show location of random dot.

Turning on Websocket SSL flag doesn't cause SSL arguments to be passed to server executable.

Simple mode is incredibly broken, and if I'm gonna show this to users they shouldn't be able to get to it.

Otherwise we're stuck relying on the log (which we may not be able to see in some cases), or the file/console

Right now we rely on the cli server process just sending anything over the line and we call that good. We should have an actual protobuf message sent on connect to verify things are ok. This will also require updates to the CLI programs.

Intiface is still using buttplug icons. Should use Intiface placeholders until actual branding is done.

When selecting SSL/TLS in Server > Advanced > Websocket as only option the server fails to start. The server does seem to start when any of the two other options (or both) are selected. When no options are selected the server does not start.

We have a huge toolbar up top that we're not doing much with. Would be nice to put an "updates available" icon up there for when CheckUpdatesAtStartup is true.

Haven't gotten electron-update to work correctly once in production. May just fall back to using my own update code, since the engine updater works fine.

Application update checks work, and it appears an update is being downloaded, but it's never actually installed. Probably missing a call to QuitAndInstall or something?

If enginepath.txt is missing, or the path in it doesn't exist, or the executable we expect isn't there, don't allow running the server. Possibly also push user into update flow.

For those of us that have to actually debug the CLI, it'd be nice to be able to temporarily (per-session) reset the engine path, rather than having to actually change the engine path output file.

The core connector classes need message pairing similar to Buttplug, since we'll want to disable UI on the frontend while backend operations (like file downloads, update checking, process starting, etc) happen. Add ids to the protobuf messages so we can match transactions across frontend and backend.

Forgot to update values in the dialog type in the SetUp dialog, so it was just stalling.

Probably easier to put these in a Vuex store than to try and pass them everywhere from the core App.

Allow users to have update checks run on startup if they want.

The menu at Server > Advanced > Websocket has the option for Both / Insecure / Secure as non-mutually exclusive options.
Expectation would be mutually exclusive radio selection or two boxes for y/n secure and y/n insecure.

Throw to sentry if we have unhandled promise rejections or other exceptions.

Add ability for users to switch engines if their platform supports multiple implementations. Put warnings around this about switching from the default.

Application updates now seem to work, but still tend to stall on partial updates, or on SHA mismatches. We should actually catch those errors and redirect the user to download from github.

Error alerts are currently in their own block div in the content div. They should be relative positioned to the bottom (overlaying the router content), and the stack should grow upward if possible.

When we check for updates at start, there's a rendering delay for the frontend because the backend hasn't brought it up yet. Use a splash screen or something so the user isn't stuck.

The menu at Server > Advanced > Websocket has the option for Both / Insecure / Secure as non-mutually exclusive options.
Expectation would be mutually exclusive radio selection or two boxes for y/n secure and y/n insecure.

Fail if it doesn't, otherwise we'll have more version like v5. :(

Currently the display only shows "Disconnected". The CLI should be sending connection/disconnection updates and client names.

Currently we have some numeric masks, that's it. Should lock down length on strings, fix numeric ranges, etc.

Don't allow the user to turn off insecure and secure websockets. Either one or both must be on. Default to insecure.

Users shouldn't be able to click out of the download dialog without cancelling it, and cancel should actually stop downloads. May not be able to stop in-process installations though.

We don't currently set the HasCertificates flag after cert gen, meaning users have to restart to use SSL.

Currently, the engine installer step moves on after downloading the engine, even if it may not be completely installed yet. Have step wait until end of install.

The GithubReleaseManager backend can already query for engine and device file capabilities. We need UI in the front end to show that updates are available, and to trigger updates to run.

The cert generation step needs some instructions on when/why it should be used.

Allow buttplug-js to sort of reverse-proxy its server.

• buttplug-js server would connect as a websocket client (but Buttplug Server) to a desktop relay app.
• Other actual client desktop applications could connect to the desktop relay app.
• This would allow using the phone as a bluetooth device server via a webpage, while still using desktop apps.

This would only work on android, but means any time buttplug-js updated, we wouldn't have to do an app release, we could just update the relay webpage.

An Example:

A Windows 7 user wants to use their Launch with ScriptPlayer (https://github.com/FredTungsten/ScriptPlayer). However, using the Launch with Bluetooth on a desktop is only supported on Windows 10. The user also has an android phone.

• They bring up the Buttplug Web Relay application (a native C# application) on their desktop. This application acts as a Websocket server.
• They then bring up the Buttplug Web Relay Website on their android phone. This website contains the Buttplug-js library, as well as a way to connect via Websocket to the application on the Desktop.
• They connect the website on the phone to the app on the desktop via an interface on the website, using a special port to signify the connection will act as the server.
• They then bring up ScriptPlayer, and connect it via either Websocket or IPC (Named Pipe) to the Relay app on the desktop, using a special port to signify the connection will act as a client.
• Now ScriptPlayer can use the phone as a bluetooth device access point.

If we change the engine CLI or message output, we'll need to set the last known good version somewhere in Intiface so we don't have conflicts between the two.

Electron and Express will update differently and require their own APIs, but it'd be nice to have those updates exposed in similar ways to the IntifaceBackendManager, so we just have download process, update available, etc.

If a build is happening on master, it should require a match tag.

Starting the server without IPC or websocket selected is invalid. Start Server button should be disabled if neither is selected.

Need a better way to see application and process logs than the console.

Add a basic discovery page with links to Playground, Syncdink, ScriptPlayer, JFS, etc.

The installer retry in GitHubReleaseManager is a mess. Could be cleaner.

Add step to initial setup to allow users to deselect auto-update checking.

There's a good chance I'm going to release buggy crap in the future, and the last thing I want to do is block people from masturbating with my software. Add ability to pin engine versions so if a buggy version is released, users can roll back until it's fixed.

After starting the server, clicking settings, about and back to server. The server shows as disconnected.

In addition, starting it results in the following error.
{ "reason": "Command failed: D:\\Program Files\\IntifaceCLI\\IntifaceCLI.exe --guipipe --websocketserver --insecureport 12345\n\nUnhandled Exception: System.AggregateException: One or more errors occurred. ---> System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted\r\n at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress)\r\n at System.Net.Sockets.Socket.Bind(EndPoint localEP)\r\n at vtortola.WebSockets.Transports.Sockets.SocketListener..ctor(SocketTransport transport, EndPoint[] endPointsToListen, ProtocolType protocolType, WebSocketListenerOptions options)\r\n at vtortola.WebSockets.Transports.Tcp.TcpListener..ctor(TcpTransport transport, EndPoint[] endPointsToListen, WebSocketListenerOptions options)\r\n at vtortola.WebSockets.Transports.Tcp.TcpTransport.<ListenAsync>d__49.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at vtortola.WebSockets.WebSocketListener.<StartAsync>d__22.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at Buttplug.Server.Connectors.WebsocketServer.ButtplugWebsocketServer.<StartServerAsync>d__13.MoveNext()\r\n --- End of inner exception stack trace ---\r\n at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)\r\n at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)\r\n at IntifaceCLI.ServerCLI.RunServer(Options aOptions)\r\n at CommandLine.ParserResultExtensions.WithParsed[T](ParserResult1 result, Action1 action)\r\n at IntifaceCLI.Program.Main(String[] args)\n" }

In Simple mode the server will not turn on if 'it will listen' is enabled only for websocket connections. When IPC is enabled it will start. When neither are enabled it will also start.

Updating is too hard to deal with in a non-modal way, and since it's user triggered, it can be modal.