LBRYCommunity/lbry-desktop
1
0
Fork 0
Code Issues 596 Pull requests 6 Projects Releases 238 Packages Wiki Activity

Add support for sandbox applications #2178

Merged
skhameneh merged 1 commit from lbry-format-sandbox into master 2019-01-16 17:06:26 +01:00
Conversation 2 Commits 1 Files changed 10 +414 -193
skhameneh commented 2019-01-11 07:45:15 +01:00 (Migrated from github.com)
Copy link

Can test with lbry://FriendsOrFood#40b303c6714775a9863c8c1bda97bf396359c0c6

This should be close to final working functionality for this app (minimum functionality, wallet APIs have not been started).

I have investigated WebView and BrowserView, concluding that BrowserView lacks in functionality and may introduce additional security concerns. With the current implementation of WebView, there is no IPC access (I consider this a good thing, since module exploits should be rendered null), as a result I am working on an acceptable IPC channel. I am currently consider WebSocket support for IPC communication as this will be the most platform agnostic communication that also offers adequate API security.

This current implementation has no finalized API channel for packages to request funds from the user. This implementation for the in-app container is final (100% of a static view area is usable for all packages, just like an iframe would provide on other platforms).

Can test with `lbry://FriendsOrFood#40b303c6714775a9863c8c1bda97bf396359c0c6` This should be close to final working functionality for this app (minimum functionality, wallet APIs have not been started). I have investigated WebView and BrowserView, concluding that BrowserView lacks in functionality and may introduce additional security concerns. With the current implementation of WebView, there is no IPC access (I consider this a good thing, since module exploits should be rendered null), as a result I am working on an acceptable IPC channel. I am currently consider WebSocket support for IPC communication as this will be the most platform agnostic communication that also offers adequate API security. This current implementation has no finalized API channel for packages to request funds from the user. This implementation for the in-app container is final (100% of a static view area is usable for all packages, just like an iframe would provide on other platforms).
neb-b commented 2019-01-11 17:54:08 +01:00 (Migrated from github.com)
Copy link
screen shot 2019-01-11 at 11 53 38 am

Seeing this when I try and run the game

<img width="1558" alt="screen shot 2019-01-11 at 11 53 38 am" src="https://user-images.githubusercontent.com/16882830/51047878-94ab2580-1597-11e9-8528-026dfe8655ea.png"> Seeing this when I try and run the game
neb-b (Migrated from github.com) reviewed 2019-01-14 21:42:09 +01:00
neb-b (Migrated from github.com) left a comment
Copy link

A couple changes/comments.

A couple changes/comments.
package.json
@ -57,6 +59,7 @@
"mime": "^2.3.1",
"mixpanel-browser": "^2.17.1",
"moment": "^2.22.0",
"node-fetch": "^2.3.0",
neb-b (Migrated from github.com) commented 2019-01-14 21:17:56 +01:00
Copy link

We aleady bring in axios for fetching in the build process. I'm in favor of using node-fetch for the main process, it might help to dump axios while were adding this.
https://github.com/lbryio/lbry-desktop/blob/master/build/downloadDaemon.js#L46

We aleady bring in `axios` for fetching in the build process. I'm in favor of using `node-fetch` for the main process, it might help to dump axios while were adding this. https://github.com/lbryio/lbry-desktop/blob/master/build/downloadDaemon.js#L46
src/main/startSandbox.js
@ -0,0 +6,4 @@
global.window = global;
// eslint-disable-next-line import/no-commonjs,global-require
const { Lbry } = require('lbry-redux');
neb-b (Migrated from github.com) commented 2019-01-14 21:20:43 +01:00
Copy link

Does this need to be here? Or could we use import and move it to the top, then remove the eslint disable line.

Does this need to be here? Or could we use `import` and move it to the top, then remove the eslint disable line.
src/main/startSandbox.js
@ -0,0 +8,4 @@
// eslint-disable-next-line import/no-commonjs,global-require
const { Lbry } = require('lbry-redux');
delete global.window;
neb-b (Migrated from github.com) commented 2019-01-14 21:18:52 +01:00
Copy link

Why delete this?

Why delete this?
src/main/startSandbox.js
@ -0,0 +20,4 @@
sandbox.use(`/sandbox/${outpoint}/`, express.static(resolvedPath));
res.send(`/sandbox/${outpoint}/`);
neb-b (Migrated from github.com) commented 2019-01-14 21:22:41 +01:00
Copy link

Is this needed?

Is this needed?
src/renderer/component/fileRender/view.jsx
neb-b (Migrated from github.com) commented 2019-01-14 21:31:42 +01:00
Copy link

I'm not able to enter full screen. Is this added?

I'm not able to enter full screen. Is this added?
src/renderer/component/fileViewer/internal/player.jsx
neb-b (Migrated from github.com) commented 2019-01-14 21:35:53 +01:00
Copy link

This endpoint should be a constant

This endpoint should be a constant
src/renderer/component/fileViewer/internal/player.jsx
neb-b (Migrated from github.com) commented 2019-01-14 21:39:38 +01:00
Copy link

Can this just be replaced with the this.supportedType() function?

Can this just be replaced with the `this.supportedType()` function?
src/renderer/component/fileViewer/internal/player.jsx
neb-b (Migrated from github.com) commented 2019-01-14 21:41:40 +01:00
Copy link

Nevermind, I see it's used down here. It just seems kinda weird having very similar functionality. Maybe isLbryPackage can be moved to its own function?

Nevermind, I see it's used down here. It just seems kinda weird having very similar functionality. Maybe `isLbryPackage` can be moved to its own function?
skhameneh (Migrated from github.com) reviewed 2019-01-14 22:54:06 +01:00
src/main/startSandbox.js
@ -0,0 +8,4 @@
// eslint-disable-next-line import/no-commonjs,global-require
const { Lbry } = require('lbry-redux');
delete global.window;
skhameneh (Migrated from github.com) commented 2019-01-14 22:54:06 +01:00
Copy link

Should never try to emulate window inside Node, can cause side effects with other applications.
This is a patch to force this to work with lbry-redux, which I don't need, but Lbry is bundled with it, which I do need so I can make a daemon call for the file list.

See line 7. This was grouped (spacing) with line 7. The linter forced my grouping to break.

Should never try to emulate window inside Node, can cause side effects with other applications. This is a patch to force this to work with `lbry-redux`, which I don't need, but `Lbry` is bundled with it, which I do need so I can make a daemon call for the file list. See line 7. This was grouped (spacing) with line 7. The linter forced my grouping to break.
skhameneh (Migrated from github.com) reviewed 2019-01-14 22:55:01 +01:00
src/main/startSandbox.js
@ -0,0 +6,4 @@
global.window = global;
// eslint-disable-next-line import/no-commonjs,global-require
const { Lbry } = require('lbry-redux');
skhameneh (Migrated from github.com) commented 2019-01-14 22:55:00 +01:00
Copy link

Try it with import, doesn't work. See my other comment.

Try it with `import`, doesn't work. See my other comment.
skhameneh (Migrated from github.com) reviewed 2019-01-14 22:57:02 +01:00
src/renderer/component/fileRender/view.jsx
skhameneh (Migrated from github.com) commented 2019-01-14 22:57:02 +01:00
Copy link

Not yet, a lot of work needs to be done to make it work with Electron sandboxing.
The request from the sandbox goes through, but there are issues with dynamically sizing content that has already request a WebGL context.

Not yet, a lot of work needs to be done to make it work with Electron sandboxing. The request from the sandbox goes through, but there are issues with dynamically sizing content that has already request a WebGL context.
skhameneh (Migrated from github.com) reviewed 2019-01-14 22:59:22 +01:00
src/renderer/component/fileViewer/internal/player.jsx
skhameneh (Migrated from github.com) commented 2019-01-14 22:59:22 +01:00
Copy link

See next comment

See next comment
skhameneh (Migrated from github.com) reviewed 2019-01-14 22:59:26 +01:00
src/renderer/component/fileViewer/internal/player.jsx
skhameneh (Migrated from github.com) commented 2019-01-14 22:59:26 +01:00
Copy link

If you have logic written out for this, I'm all ears.
See the original line 263, I'm doing this to avoid breaking existing logic.

If you have logic written out for this, I'm all ears. See the original line 263, I'm doing this to avoid breaking existing logic.
skhameneh (Migrated from github.com) reviewed 2019-01-14 23:00:36 +01:00
src/main/startSandbox.js
@ -0,0 +20,4 @@
sandbox.use(`/sandbox/${outpoint}/`, express.static(resolvedPath));
res.send(`/sandbox/${outpoint}/`);
skhameneh (Migrated from github.com) commented 2019-01-14 23:00:31 +01:00
Copy link

Yes, see src/renderer/component/fileViewer/internal/player.jsx, it uses the response to know where to go when the sandbox is ready.

Yes, see `src/renderer/component/fileViewer/internal/player.jsx`, it uses the response to know where to go when the sandbox is ready.
skhameneh (Migrated from github.com) reviewed 2019-01-14 23:04:11 +01:00
package.json
@ -57,6 +59,7 @@
"mime": "^2.3.1",
"mixpanel-browser": "^2.17.1",
"moment": "^2.22.0",
"node-fetch": "^2.3.0",
skhameneh (Migrated from github.com) commented 2019-01-14 23:04:11 +01:00
Copy link

I am in favor of this, do we want to do this now? (upcoming release, at the edge of release)
That entire function could use a rewrite to async/await.

I am in favor of this, do we want to do this now? (upcoming release, at the edge of release) That entire function could use a rewrite to `async`/`await`.
skhameneh (Migrated from github.com) reviewed 2019-01-14 23:05:33 +01:00
src/renderer/component/fileRender/view.jsx
skhameneh (Migrated from github.com) commented 2019-01-14 23:05:33 +01:00
Copy link

This is added so if fullscreen happens, the user can always escape. Nothing is stopping existing apps from requesting it. *It can't be cancelled but it can be exited, Electron team hardcoded the events.

This is added so if fullscreen happens, the user can always escape. Nothing is stopping existing apps from requesting it. *It can't be cancelled but it can be exited, Electron team hardcoded the events.
neb-b (Migrated from github.com) reviewed 2019-01-15 16:59:36 +01:00
package.json
@ -57,6 +59,7 @@
"mime": "^2.3.1",
"mixpanel-browser": "^2.17.1",
"moment": "^2.22.0",
"node-fetch": "^2.3.0",
neb-b (Migrated from github.com) commented 2019-01-15 16:59:36 +01:00
Copy link

I think we might as well do it now. the async/await stuff might add a lot of work though. It should be super simple to swap axios for fetch in downloadDaemon.js

I think we might as well do it now. the `async/await` stuff might add a lot of work though. It should be super simple to swap axios for fetch in `downloadDaemon.js`
neb-b commented 2019-01-15 16:59:48 +01:00 (Migrated from github.com)
Copy link

This looks good (pending removal of axios). Lets wait until the release to merge this.

This looks good (pending removal of axios). Lets wait until the release to merge this.
kauffj (Migrated from github.com) reviewed 2019-01-15 17:58:00 +01:00
src/renderer/component/fileViewer/internal/player.jsx
@ -11,7 +11,10 @@ import LoadingScreen from 'component/common/loading-screen';
class MediaPlayer extends React.PureComponent {
static MP3_CONTENT_TYPES = ['audio/mpeg3', 'audio/mpeg'];
static SANDBOX_TYPES = ['application/x-lbry', 'application/x-ext-lbry'];
kauffj (Migrated from github.com) commented 2019-01-15 17:58:00 +01:00
Copy link

This is the most/only objectionable part for me. I would still strongly like to seek a way of triggering this behavior that does not require switching on a custom media type. This is not me saying a custom media type is wrong; it is me saying that only being able to trigger to the sandbox behavior via media type is wrong.

Please at least file/determine what metadata and sdk changes need to happen to facilitate this behavior without requiring this. @eukreign @lyoshenka

This is the most/only objectionable part for me. I would still strongly like to seek a way of triggering this behavior that does not require switching on a custom media type. This is not me saying a custom media type is wrong; it is me saying that _only_ being able to trigger to the sandbox behavior via media type is wrong. Please at least file/determine what metadata and sdk changes need to happen to facilitate this behavior without requiring this. @eukreign @lyoshenka
eukreign (Migrated from github.com) reviewed 2019-01-15 20:22:02 +01:00
src/renderer/component/fileViewer/internal/player.jsx
@ -11,7 +11,10 @@ import LoadingScreen from 'component/common/loading-screen';
class MediaPlayer extends React.PureComponent {
static MP3_CONTENT_TYPES = ['audio/mpeg3', 'audio/mpeg'];
static SANDBOX_TYPES = ['application/x-lbry', 'application/x-ext-lbry'];
eukreign (Migrated from github.com) commented 2019-01-15 20:22:01 +01:00
Copy link

There is a W3C proposal for something that seems very similar to .lbry, could we use that proposal instead of having our own?

Proposal: https://github.com/WICG/webpackage

The extension suggested in that proposal is .wpk:

https://github.com/WICG/webpackage/blob/master/draft-yasskin-dispatch-web-packaging.md#internet-media-type-registration

There is a W3C proposal for something that seems very similar to `.lbry`, could we use that proposal instead of having our own? Proposal: https://github.com/WICG/webpackage The extension suggested in that proposal is `.wpk`: https://github.com/WICG/webpackage/blob/master/draft-yasskin-dispatch-web-packaging.md#internet-media-type-registration
skhameneh (Migrated from github.com) reviewed 2019-01-15 20:56:55 +01:00
src/renderer/component/fileViewer/internal/player.jsx
@ -11,7 +11,10 @@ import LoadingScreen from 'component/common/loading-screen';
class MediaPlayer extends React.PureComponent {
static MP3_CONTENT_TYPES = ['audio/mpeg3', 'audio/mpeg'];
static SANDBOX_TYPES = ['application/x-lbry', 'application/x-ext-lbry'];
skhameneh (Migrated from github.com) commented 2019-01-15 20:56:55 +01:00
Copy link

A lot that makes sense, but it's a proposal 19 years in the making with zero adoption and no working tools.

I will reach out to the current maintainer.

A lot that makes sense, but it's a proposal 19 years in the making with zero adoption and no working tools. I will reach out to the current maintainer.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
accessibility

   
app-parity

   
area: creator

   
area: daemon

   
area: design

   
area: devops

   
area: discovery

   
area: docs

   
area: installer

   
area: internal

   
area: livestream

   
area: performance

   
area: proposal

Work is part of a proposal

  
area: reposts

   
area: rewards

   
area: search

   
area: security

   
area: subscriptions

   
area: sync

   
area: ux

   
area: viewer

   
area: wallet

   
BEAMER

Beamer is waiting on you!

  
channel

   
comments

   
community PR

   
consider soon

Discuss this issue at the next planning meeting, then remove this label

  
core team

   
css

   
dependencies

   
electron

   
Epic

   
feature request

   
first-timers-only

   
good first issue

   
hacktoberfest

Welcome to Hacktoberfest

  
help wanted

   
hub-dependent

   
icebox

Long-term storage

  
Invalid

   
level: 0

   
level: 1

No knowledge of the existing code required

  
level: 2

Some knowledge of the existing code is recommended

  
level: 3

Significant knowledge of the existing code is recommended

  
level: 4

Intimate knowledge of the existing code is recommended

  
merge when green

   
needs: exploration

Solution unclear, needs research

  
needs: grooming

Issue needs to be groomed before work can start

  
needs: priority

Priority level needs to be defined

  
needs: repro

Issue needs step-by-step instructions on how to reproduce in latest code

  
needs: tech design

Needs technical design signoff before implementation can begin

  
notifications

   
odysee

   
on hold

Temporarily paused

  
playlists

   
priority: blocker

Issue is blocking release, do ASAP

  
priority: high

Work needs to be moved into sprint ASAP

  
priority: low

Work should be done but can stay in the backlog for now

  
priority: medium

Work needs to be done within 2-3 sprints

  
protocol dependent

   
recsys

   
redesign

general redesign not prioritize for anyone release

  
regression

   
resilience

   
sdk dependent

Requires work on lbry-sdk repo

  
Tom's Wishlist

   
trending

   
type: bug

Existing functionality is wrong or broken

  
type: discussion

A conversation. No specific changes requested

  
type: improvement

Existing (or partially existing) functionality needs to be changed

  
type: new feature

New functionality that does not exist yet

  
type: refactor

Minimal user-visible changes, but significant internal work

  
type: task

Either work that's not related to the code, or a small chore that does not fit into other categories

  
type: testing

Solution needs additional user testing

  
unplanned

Work that was not planned into the spirnt, took priority over planned work

  
windows
No labels
accessibility
app-parity
area: creator
area: daemon
area: design
area: devops
area: discovery
area: docs
area: installer
area: internal
area: livestream
area: performance
area: proposal
area: reposts
area: rewards
area: search
area: security
area: subscriptions
area: sync
area: ux
area: viewer
area: wallet
BEAMER
channel
comments
community PR
consider soon
core team
css
dependencies
electron
Epic
feature request
first-timers-only
good first issue
hacktoberfest
help wanted
hub-dependent
icebox
Invalid
level: 0
level: 1
level: 2
level: 3
level: 4
merge when green
needs: exploration
needs: grooming
needs: priority
needs: repro
needs: tech design
notifications
odysee
on hold
playlists
priority: blocker
priority: high
priority: low
priority: medium
protocol dependent
recsys
redesign
regression
resilience
sdk dependent
Tom's Wishlist
trending
type: bug
type: discussion
type: improvement
type: new feature
type: refactor
type: task
type: testing
unplanned
windows
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: LBRYCommunity/lbry-desktop#2178
No description provided.
Delete branch "lbry-format-sandbox"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?