Feature Request: Temporary Public Room about pairdrop HOT 14 CLOSED

Really appreciate your full thoughts on this. The implications you have mentioned made me think that pairing should remain as pairing and rooms should be rooms. Hear me out, hopefully I am not over complicating this.

Pairing is usually conceived with the concept of "my devices" only. While rooms are usually perceived as something temporary for joiners only.

Both have their advantages and disadvantages, but they solve different problems:

• Pairing currently solves a main issue of "my devices" not discoverable because of different networks or other complications.
• Rooms solves a main issue for "other" joiners because of temporary file sharing needs.

Yet, the implications you mentioned for rooms are very valid and require effort to solve. Temporary pairing is nice and honestly it would solve my main concern. But I like PairDrop and would put the effort towards enhancing it optimally.
With that said, having rooms like wulingate seems like the best idea.

Below in an approach that hopefully resolves the mentioned implications:

• Create a 🚪 room prompts a dialog of 7-digit-pin and barcode that is valid for 10 minutes only. I am thinking that rooms should have 7-digit-pin instead of 6, because 6 digits will conflict with pairing and would decrease the ~5.2 * 10^114 possibilities.
  • In the dialog a message is shown to indicate you will be only discoverable to devices inside the room.
  • Also, the 10 minutes visibility will solve the concern of limited room numbers, and result in added security.
• Devices attempting to join will send a request to the host, and they can only join if the host accepts.
  • The host gets the option to Accept, Decline. Block is also an option if these 10 minutes of visibility could result in brute forcing, but I think 10 minutes validity is a sufficient counter measure.
  • This will solve the concern of unwanted users joining a room.

Other Enhancements:

• There should be a discovery icon 👁‍🗨 while inside the room, clicking it should show the PIN, barcode, time remaining for PIN expiry, and the option to [Stop Discovery], [Refresh Discovery], and [Cancel] to close the prompt.
  • Once the timer runs out the 👁‍🗨 is greyed out or crossed and clicking it should prompt a dialog with a new 7-digit-pin, barcode, and an option to [Create New Pin] for the room to be discoverable once again or [Cancel].
• The door 🚪 changes to leaving once inside a room, and clicking it shows a message that exiting the room will make you discoverable to only local and paired devices. With the option to [Leave] and [Cancel].
• Additionally, the pairing icons should be removed while in a room.

I think the mentioned approach should resolve the implications. Looking forward to hearing your thoughts on this =)

from pairdrop.

The only confusing part here, when inside a room being discovered to everyone feels like a disadvantage. I believe it is better to limit it discovery to room joiners only and disallow discovery within the same network / paired. Rooms should be private to joiners only.

One implication I can think of, if there are 3 different joiners from 3 different networks, then any device within these 3 networks will be discoverable once they access PairDrop. This will make things very confusing, and many additional devices will be shown to everyone running PairDrop in the network.

It is not the plan to combine multiple networks when individual devices are joining the same room. This would impose a great security risk and would be very confusing.
Just as it is with device pairing, only those that are in the same public 5-digit room are presented to you additionally. No one else. I'm sorry if that was not clear.

• Paired Devices (whether same network or not): Green Device Background

  • Devices not paired: Blue Device Background

  • Same Room: Yellow Device Background. (Basically, since my suggestion ensures that rooms are private to joiners, then any device joining will have Yellow Device Background) Which makes it very clear that these devices are discoverable due to same room.

I like that. Cases:

1. not paired, not same room -> blue
2. not paired, same room -> yellow
3. paired (independend of room) -> green

You can add a LAN / WAN icon to differentiate between same network vs public (bottom right of device icon or on top) / Applicable to all connection types and will not make a difference if discovered through paired or via a room. Because it offers clear representation by using a LAN / WAN icon.

I like that. There is also a unicode icon for that: 🖧 https://symbl.cc/en/1F5A7/ but probably we should go with sth like this: https://fontawesome.com/icons/circle-nodes

from pairdrop.

It's been a while but I finally got some time on my hands and implemented this while also polishing up all dialogs and the discovery field 🎉

@Eisa01 It would be great if you could test this thoroughly on this instance:
https://pairdrop.onrender.com/

I stuck with colors for now as I find them quite intuitive but feel free to tell me if it still feels confusing to you

from pairdrop.

Glad you like it! Thanks for the compliments!

Thank you for all the input!

I will then merge it into the translation feature branch and wait for the users that helped with the translations to catch up with the new strings. I guess this will become live on the official pairdrop.net at the start of next week :)

from pairdrop.

This is finally merged and released as v1.8.0 🎉
Therefore, I'll close this!

from pairdrop.

Glad you like it!

I’m not sure about your request though.. If I understand you correctly, your request would be like the implementation of https://wulingate.com, wouldn’t it?

It would make it quite complicated for the average user if there is a pairing and a room compatibility and it would obstruct the main user flow. It must be possible to always see devices in the same local network.

It could maybe be possible to make a temporary pairing with the same workflow. As soon as the session is closed, the pair key is thrown away

from pairdrop.

It could maybe be possible to make a temporary pairing with the same workflow. As soon as the session is closed, the pair key is thrown away.

Yes! This is exactly what I mean.

from pairdrop.

I mean, alternatively, you can just use a private tab when pairing should be temporary. Isn’t that enough? I don’t know whether an additional option would overwhelm most users as this feature would need to be available when initiating as well as when joining..

from pairdrop.

Incognito tab workaround is nice but having a proper implementation would be convenient. Workarounds could be hectic if used frequently. Having rooms similar to https://wulingate.com/ would make this package almost complete.

If it is done the way pairing is done, I believe it shouldn't create confusion, because your implementation of pairing is better than https://wulingate.com/. The concept of rooms is that they are usually private to joiners, however if you like it could also be customized by adding options in the room creation dialog with settings to:

• keep/remove the local networks,
• keep/remove paired devices
• Create a password for more privacy to joiners which should also resolve #54

Demonstration of the basic idea:

Device (Host):

• Click on the 🚪 icon shows the same pop-up that is available for pairing.

Device (Client):

• Click on the 🚪 icon and enter the 6-digit room number to join the room.
• Or scan the barcode to join

Devices (Host) and (Client):

• The message on bottom changes to:
  • You can only be discovered to devices connected to room 123456

Small UI/UX Editions with Additional Options

• Clicking on the room number in bottom message or the icon 🚪 in the top of the page, while in a room shows the same pop-up with barcode and room number,
• However, the buttons change to [Cancel] and [Leave Room].
  • [Cancel] just closes the pop-up
  • [Leave Room] to exit the room and return to be discoverable only within Local Network.

from pairdrop.

Thanks for thinking this through.
I see some issues with your draft though:

• I specifically moved away from rooms in the sense of a shared 6-digit code towards pairing as currently implemented because this resolved two issues:

  1. There is often a compromise between security and convenience. If the 6-digit code is the secret and the room, everyone that knows the code can join the room. Longer codes increase security but decrease convenience. The difference between wulingate.com and PairDrop is not only the different pairing dialog and another UX. The way the pairing functionality is implemented, the pair key used for pairing is a nonce. Once joined, this pair key is invalidated and there is no problem if anyone gets to know the pair key later (e.g. by decoding the link in the qr code). Someone who knows my wulingate room key can always join my room or see what devices are connected.
  2. A 6-digit code only allows for 10^6 possible rooms. Apart from making it easily possible to be exploited by brute forcing, it would not be enough as Snapdrop got million requests yearly. The current implementation uses a random 64 digit string with 62 different possible characters which results in ~5.2 * 10^114 possibilities.

• Therefor, a room like 123456 must always be seen as public and not private.

• The advanced settings would IMO overload the pairing dialog (esp. on small devices) and overcomplicate PairDrop for the average user if there are just too many variables. I am against the possibility to hide local devices as this would add many configuration states. Think about AirDrops discoverability states: "noone", "contacts only", "everyone for 10 min". Contacts only is a subgroup of everyone which is logical. "Everyone but contacts" would be rather complicated.

• I will not implement any password protection as this obstructs the user flow and better be done via apache and alike (see #54)

I think to pair all your devices individually is not a problem as this must only be done once. I see an use case for temporary device pairings but I'm not sure whether it is big enough to be implemented. If so, I would suggest something along the following:

When device joines successfully via the pairkey and one of the devices slider is toggled to "temporary" (with "persistent" beeing the default) both users are notified that the pairing is not persistent and is gone as soon as the session is closed.

But even that is somewhat clunky and overloaded.

from pairdrop.

First, thanks for your thoughts on this! You convinced me this could be useful for many users when there is a need for quick connections.

I think the discovery feature should be a separate request and is discussed at #104

I like the differentiation between connecting your own trusted devices via pairing and connecting other foreign devices via public rooms.
Room joining and pairing should be easily distinguishable. As the pair key is a six digit number (982 374) I think I will go for a public room key with a 5 digit string (G X 5 G 2). That way the length and the base differs which should be enough to differentiate the two codes.
26 letters + 10 digits = 36 chars -> 36^5 = 60 466 176 possibilities which is more than 10^7 possibilities we’d get with a 7 digit code. We could also flip this around with rooms having 6 number digits and pairing 5 char digits. What do you think?

I would like to only have one additional button in the header which shows the public room dialog and is always shown. For clarity I don’t want to hide the pairing buttons.

The public room dialog will look similar to the pairing dialog. When you click the header button the dialog opens and you automatically join a free room. In the upper half of the dialog the corresponding room key will be shown with a QR code. Bellow that, there’ll be a button to „Leave Room“ which results in leaving the room and closing the dialog.
The dialog will also be closed automatically when the first peer joins.

In the lower half of the dialog we would have „Join room“, 5 char fields and two buttons „Close“ and „Join“.
I’m not sure whether joining should only work if the room to be joined already exists (similar to pairing) or whether you will simply be the first in a room. With the second option users could choose their own room code but many users would probably use 00000. I’m not sure I like that. With option one there is the possibility to correct the room key if you mistyped it as the mistyped room most probably does not exist.

If you are inside a room on the bottom it will say ‚You can be discovered by everyone on this network and inside room G X 5 G 2‘. Clicking the room key should probably also open up the public room dialog.

Users can never join two rooms simultaneously and joining rooms will be rate limited.

I will however not implement a „join request“ as rooms are public anyway and all users inside a room have the same permissions (there is no host).

Order:

1. Paired Devices
2. Devices in the same public room
3. Devices on the same network

Approach 1

As currently implemented, devices are differentiated primarily into local and remote. Only those devices that would be gone if you left the room are shown with a yellow bg. Devices never change color when you join the same room or pair them.

Peers in the same room will have a yellow dot below and additionally have a yellow background if they are neither on the same network (blue) nor paired (green).

There will then be seven cases:

• on the same network (as in same public ip)
  • not paired and not same room: blue bg
  • paired and not same room: blue bg + green dot
  • paired and same room: blue bg + green dot + yellow dot
  • not paired and same room: blue bg + yellow dot
• not on the same network
  • paired and not same room: green bg + green dot
  • paired and same room: green bg + green dot + yellow dot
  • not paired and same room: yellow bg + yellow dot

Approach 2

Devices are mainly differentiated into paired and not paired:

• All devices that are paired: green bg
• same network: blue dot
• same room: yellow dot
• All devices that are not paired and in the same public room: yellow bg
• same network: blue dot
• All devices that are not paired and not in the same public room: blue bg

Devices in the same room would change color but order would be green, yellow, blue, which might look tidier.

Problem: unpaired devices on the same network and paired remote devices are only different in color and not in form anymore. We could add a green dot for paired devices but then there would be three dots for paired devices on the same network and in the same public room. Not sure whether that’s confusing.

@Eisa01 Any thoughts before I start implementing this?

from pairdrop.

Glad that this is on roadmap! Here are my thoughts on the points you've mentioned.

Room joining and pairing should be easily distinguishable. As the pair key is a six digit number (982 374) I think I will go for a public room key with a 5 digit string (G X 5 G 2). That way the length and the base differs which should be enough to differentiate the two codes.
26 letters + 10 digits = 36 chars -> 36^5 = 60 466 176 possibilities which is more than 10^7 possibilities we’d get with a 7 digit code. We could also flip this around with rooms having 6 number digits and pairing 5 char digits. What do you think?

Pairing remains the same, while rooms get the new 5 char digits.

In the lower half of the dialog we would have „Join room“, 5 char fields and two buttons „Close“ and „Join“.
I’m not sure whether joining should only work if the room to be joined already exists (similar to pairing) or whether you will simply be the first in a room. With the second option users could choose their own room code but many users would probably use 00000. I’m not sure I like that. With option one there is the possibility to correct the room key if you mistyped it as the mistyped room most probably does not exist.

I don't like the second option with users get to create their own room code. It feels like this will be confusing because providing an input means I actually want to join a room. Also like you stated this will kill correcting the room key if it was mistyped.

If you are inside a room on the bottom it will say ‚You can be discovered by everyone on this network and inside room G X 5 G 2‘. Clicking the room key should probably also open up the public room dialog.
Order:
1. Paired Devices
2. Devices in the same public room
3. Devices on the same network

The only confusing part here, when inside a room being discovered to everyone feels like a disadvantage. I believe it is better to limit it discovery to room joiners only and disallow discovery within the same network / paired. Rooms should be private to joiners only.

One implication I can think of, if there are 3 different joiners from 3 different networks, then any device within these 3 networks will be discoverable once they access PairDrop. This will make things very confusing, and many additional devices will be shown to everyone running PairDrop in the network.

Also, in regard to the 2 approaches mentioned, it feels confusing to have many different colors and adding dots to the equation makes it feel even more confusing. I'd prefer following this approach:

• Paired Devices (whether same network or not): Green Device Background
• Devices not paired: Blue Device Background
• Same Room: Yellow Device Background. (Basically, since my suggestion ensures that rooms are private to joiners, then any device joining will have Yellow Device Background) Which makes it very clear that these devices are discoverable due to same room.

You can add a LAN / WAN icon to differentiate between same network vs public (bottom right of device icon or on top) / Applicable to all connection types and will not make a difference if discovered through paired or via a room.
Because it offers clear representation by using a LAN / WAN icon.

from pairdrop.

Tested all scenarios from my side, it is working perfectly.
It is very intuitive and implemented even better than I imagined.
Also, after seeing the colors I love it, not confusing at all. It is perfect. ✔

Can't express my gratitude enough, thank you for the efforts. A job well done! 🥳

from pairdrop.

@Eisa01 If you like you can proofread the README page regarding the new feature:

https://github.com/schlagmichdoch/PairDrop/tree/translate#differences-to-snapdrop

Let me know if anything sounds unclear.

from pairdrop.