[Enhancement] Native clients via Flutter

[schlagmichdoch]

This issue was deleted by GitHub (via hubot) as part of mistakenly marking this account as spam on 17th February 2024. The creation date is unclear. There are also links to the deleted issue that are not updated to this issue. I decided to manually recreate it anyway in order to complete the information the repo holds even though the restored information might be outdated:

Issue by @schlagmichdoch:

What problem is solved by the new feature

Browsers do not use the full potential of WebRTC and are not well suited to use big files.
I plan on wrapping PairDrop via Flutter to create clients for all devices.

Describe the feature

• Transfer speed
  • Using a proper WebRTC library would increase transfer speeds drastically
• Zero-Trust
  • As client files would not be downloaded from the server there is not need to trust the server anymore after implementing [Enhancement] Encrypt signaling and the possibility to mark devices as verified #180. Signaling would be encrypted so MITM is not possible anymore.
• Background service and tray icon
  • Run PairDrop in the background to always be discoverable
  • See discussion at enhancement: MacOS background app with file handler #90
• PairDrop Host
  • Host a PairDrop instance from the app in your local network and act as the signaling server:
  • Clients would go to the local IP-address of a host (like 192.168.178.77:3000)
  • All clients are shown to each other: No Pairing, no Public Rooms
  • This makes PairDrop usable completely offline
  • Only one device needs to have the app installed to host. Everyone else can use the browser or the app.

[schlagmichdoch]

The following comments were deleted by GitHub (via hubot) as part of mistakenly marking this account as spam on 17th February 2024. The correct thread order and the creation date is unclear. I decided to manually restore them anyway in order to complete the information this issue holds even though the restored information might be outdated:

Comment by @rohsaurus:

Would pairdrop become directly p2p with this implementation, or would it still allow for request to happen over the internet. I feel what makes pairdrop extremely powerful is the fact that I can transfer stuff to devices on different wifi networks, as well as within wifi networks that block p2p connections.

Comment by @schlagmichdoch:

would it still allow for request to happen over the internet

Absolutely! I aggree that internet transfers and autodiscovery makes PairDrop much more powerful and there will be no changes to the current transfer model or the user workflow!

The biggest USP of PairDrop imo is the "no setup" part. New users only have to open the webpage and everything just works.
This will always be the core of PairDrop.

The proposed changes offer increased speed, security and new features (offline capabilities and always on background service) for users that are willing to install an actual app.

Speed is the main issue for newest users and there is only so much browsers can do. Using native WebRTC libraries, we should be able to get close to the actual download / upload limits of the device.

Naturally, as all clients (webpage and flutter) talk to the same backend, the flutter clients will be perfectly compatible with users using the browser at pairdrop.net or your instance.

Would pairdrop become directly p2p with this implementation, or would it still allow for request to happen over the internet.

Nothing changes, but to clarify: Thanks to WebRTC "p2p" and "requests over the internet" do not contradict each other. Only connections were clients are behind different NATs need a TURN server. All connections are end-to-end encrypted.

Comment by @rohsaurus:

Oh, perfect! I can fork the repo and get started on first getting the webpage to display on Flutter?

Comment by @schlagmichdoch:

Maybe wait until I've deployed 1.10.0 next week which will include quite heavy refactoring and simplifications of the current codebase. It will be easier then.

Comment by @schlagmichdoch:

Alright, I'll stay tuned.

On Thu, Nov 2, 2023, 21:28 schlagmichdoch @.***> wrote:

Maybe wait until I've deployed 1.10.0 next week which will include quite
heavy refactoring and simplifications of the current codebase. It will be
easier then.

—
Reply to this email directly, view it on GitHub
https://github.com/schlagmichdoch/PairDrop/issues/198#issuecomment-1791776266,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANJZ2Y2SR4H2FHYS66Y6Q2LYCRCEPAVCNFSM6AAAAAA6Z3VS4GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJRG43TMMRWGY
.
You are receiving this because you commented.Message ID:
@.***>

Comment by @schlagmichdoch:

It took longer than expected as a lot of enhancements and heavy refactoring have been implemented into this new version (see #209).

It is done now. @rohsaurus Feel free to get started with the Flutter app! :)

Comment by @rohsaurus:

Sorry for the late response. I'll get started soon!

Comment by @rohsaurus:

Sorry I've been busy with everything. How would you suggest we do this? Would you suggest that I display pairdrop in a webview in a flutter app, or would you suggest more of building the flutter app from scratch?

Comment by @rohsaurus:

https://github.com/openwebf/webf
I found this which could be pretty useful and seems similar to a webview but with much improved performance.

Comment by @schlagmichdoch:

https://github.com/openwebf/webf I found this which could be pretty useful and seems similar to a webview but with much improved performance.

Wow, this looks really promising!

Using their API would be much nicer than handling another websocket in the dart code. I like! https://openwebf.com/docs/tutorials/guides-for-flutter-developer/dart_js_intercommunication

Sorry I've been busy with everything. How would you suggest we do this? Would you suggest that I display pairdrop in a webview in a flutter app, or would you suggest more of building the flutter app from scratch?

I wish to display PairDrop in a webview to reuse all of the GUI logic. But intercept the WebRTC part to use flutter-webrtc instead.

Simply showing local pages would be good a start.

Not sure how to approach communication. I think github issue might be a bit slow. Maybe we could start a discord or slack for short term communication?

Comment by @rohsaurus:

A discord should work, yeah.

On Tue, Feb 13, 2024, 12:43 schlagmichdoch @.***> wrote:

https://github.com/openwebf/webf I found this which could be pretty
useful and seems similar to a webview but with much improved performance.

Wow, this looks really promising!

Using their API would be much nicer than handling another websocket in the
dart code. I like!
https://openwebf.com/docs/tutorials/guides-for-flutter-developer/dart_js_intercommunication

Sorry I've been busy with everything. How would you suggest we do this?
Would you suggest that I display pairdrop in a webview in a flutter app, or
would you suggest more of building the flutter app from scratch?

I wish to display PairDrop in a webview to reuse all of the GUI logic. But
intercept the WebRTC part to use flutter-webrtc instead.

Simply showing local pages would be good a start.

Not sure how to approach communication. I think github issue might be a
bit slow. Maybe we could start a discord or slack for short term
communication?

—
Reply to this email directly, view it on GitHub
https://github.com/schlagmichdoch/PairDrop/issues/198#issuecomment-1942087146,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANJZ2Y5J7ZIJOG5NIVFUQXLYTOQ5TAVCNFSM6AAAAAA6Z3VS4GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNBSGA4DOMJUGY
.
You are receiving this because you were mentioned.Message ID:
@.***>