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

Provide a URL redirecting service for share links #1540

Open
sschueller opened this issue Jan 8, 2019 · 6 comments
Open

Provide a URL redirecting service for share links #1540

sschueller opened this issue Jan 8, 2019 · 6 comments

Comments

@sschueller
Copy link
Contributor

sschueller commented Jan 8, 2019

On mobile devices it is currently not possible to automatically send links of videos to play in a native peertube app as the app can not register each instance's domain.

Matrix solves this by providing a URL redirecting service (https://matrix.to/) so only the domain matrix.to needs to be registered in the an app. Under android that would be a Deep Link: https://developer.android.com/training/app-links/deep-linking.

Although this would introduce some centralisation it would be a good feature to have. The share feature would also need to provide this redirect URL instead/in addition of the instances URL.

There might be some better way to solve this.

@Booteille
Copy link
Contributor

Does someone know how to bypass this issue without having a centralized service somewhere? If nobody comes with another solution, I think we could implement this one.

@sschueller
Copy link
Contributor Author

Maybe it can be done via IPFS, the domain would still be a single point of failure but the backend could be distributed on IPFS.

@Chocobozzz
Copy link
Owner

Having a single share URL could be useful on the web too, to automatically redirect users on their instance.

To prevent centralization, we could imagine 3 or 4 organizations providing this kind of service.

@sschueller Could you register 3 or 4 URLs in the android application?

@sschueller
Copy link
Contributor Author

sschueller commented Jan 10, 2019

@Chocobozzz Yes it should be possible to register multiple domains in the application.

Alternatively from what I understand it is possible to use Digital Asset Links instead which would support a wildcard domain. However the upper level domain needs to provide an assetlinks.json with fingerprint of the app signing certificate. It would need both a fingerprint from the key I use for the playstore and for the key used by fdroid (https://fdroid.gitlab.io/fdroid-website/en/docs/Release_Channels_and_Signing_Keys/). Any other apps could be added by the developers providing the fingerprint of their signing keys and it being added to the assetlinks.json file.

@LibreHacker
Copy link

Maybe application grab link - https://peertube.to/#peertube.server/watch/video (@peertube.server:video ? @video:peertube.server) and open self without browser, like making it NewPipe with youtube.com link?

If it's link (domain) open in browser, check PC or mobile platform and give instructions or open video in browser for watching (on PC in server from link)

@contrapunctus-1
Copy link

While I eagerly await mobile clients being able to open PeerTube links as easily as their YouTube counterparts, I wanted to confirm if the resolution service being proposed would have any privacy implications.

If a user has an application installed which can handle the deep link, is there still a network request made to the deep link domain? 🤔️ If so, would that mean that the proposed peertube.to service would have access to the IP of every user visiting a peertube.to link, as well as every video URL they open?

(I had a glance at the linked Android docs and did some searching, but couldn't find anything.)

Some developers I spoke to suggested making a custom URI scheme for PeerTube instead (e.g. peertube://), which would seemingly serve the same purpose without the SPoF and privacy implications.

cc @sschueller

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants