Authentication and server discovery

[vgarleanu]

There are currently a few UX problems with the way we connect to the dim servers and how we authenticate with them.

Users have to remember the IP address and port of their server in addition to a login and password.
Users, in most cases, will have to port forward dim manually. This is all tedious and too complicated.

To solve the first issue we can adopt a login method where a client would scan a QR code that would pair a device and authenticate it automatically (as seen in platforms like discord and WhatsApp).

To solve the second issue we can utilize a rendezvous server to initiate and create a P2P connection between the client and the server, all API requests then get tunnelled through the P2P connection.

What this means in practice is that our users will in most cases not need to mess with any router settings to be able to access their media from outside their LAN. This method also improves on security a bit because Dim cannot be accessed publicly directly.

To implement these features we can just use webrtc, which is supported in most modern browsers. Because webrtc is designing for high throughput low latency data streaming, the performance impact should be relatively minimal.

[vgarleanu]

I believe plex had a similar feature, but instead of tunneling traffic, they used a reverse proxy. Which is awfully slow.
We can use WebRTC to tunnel all fetch requests through with minimal bandwidth or performance losses since webrtc was designed for low latency high throughput.

[vgarleanu]

Using libp2p here could also work.

[Winterhuman]

It could, but, js-libp2p isn't in a great place right now, it actually relies on WebRTC as it's transport for the time being. (See ipfs/js-ipfs#3905)

This means it couldn't be used in browsers without needing centralized rendezvous servers which kind of negates using it over just WebRTC. (Hence why I deleted my initial reply about js-libp2p/js-ipfs)

[Winterhuman]

IPNS-Link is also something Dim could use, it's very early in it's development, but, it gets around needing the browser to do anything special: https://github.com/ipns-link/ipns-link

EDIT: Now a member of IPNS-Link btw. We're thinking about creating Private Gateways which would suit Dim's needs quite well, only a specific app which can scan the QR code can access the service, here's the concept discussion for it: ipns-link/specs#1

[gelven4sec]

Users, in most cases, will have to port forward dim manually. This is all tedious and too complicated.

People aren't supposed to manually forward a port every time they deploy a new web service. I usally set it up behind a reverse proxy and I think most people does that too.

Plex's reverse proxy is slow (I never tested though but I rely on your words) because it goes through their servers before your client. But on your own, it should be fine.

It's great that you're looking for a better solution, I'm a big fan of p2p exchange myself, but I think it should on top of Dim instead of integrated in.
Ipns-link is looks great anyway.

And I'm really looking forward a QR code authentication ! 👍

[TheRealGramdalf]

One thing I would love to see with dim is Oauth2/OIDC support - that would set it apart from the majority of the other multimedia servers. I'm personally using kanidm (another rust project) for SSO, it may be worth taking a peek to see if you could "borrow" any code :)

As for the rationale, OIDC (and rust) seem to be the next generation in coding, and it looks like OIDC will be sticking around for a while, what with google and microsoft making it "main stream".

This is just speculation, but it may even be simpler to implement, since most of the security details are delegated to the IdP - dim would only have to worry about it's connection to the auth provider being secure.

p.s. Depending on if/when this is implemented I might end up running dim personally - a quick response would be nice.