-
-
Notifications
You must be signed in to change notification settings - Fork 251
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
Feature Request: Temporary Public Room #55
Comments
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 |
Yes! This is exactly what I mean. |
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.. |
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:
Demonstration of the basic idea:Device (Host):
Device (Client):
Devices (Host) and (Client):
Small UI/UX Editions with Additional Options
|
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:
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. Below in an approach that hopefully resolves the mentioned implications:
Other Enhancements:
I think the mentioned approach should resolve the implications. Looking forward to hearing your thoughts on this =) |
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. 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. In the lower half of the dialog we would have „Join room“, 5 char fields and two buttons „Close“ and „Join“. If you are inside a room on the bottom it will say ‚You can be discovered by everyone on this network and inside room 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:
Approach 1As 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:
Approach 2Devices are mainly differentiated into paired and not paired:
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? |
Glad that this is on roadmap! Here are my thoughts on the points you've mentioned.
Pairing remains the same, while rooms get the new 5 char digits.
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.
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:
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. |
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.
I like that. Cases:
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 |
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: 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 |
Tested all scenarios from my side, it is working perfectly. Can't express my gratitude enough, thank you for the efforts. A job well done! 🥳 |
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 :) |
@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. |
This is finally merged and released as v1.8.0 🎉 |
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 @schlagmichdoch:Thanks for thinking this through.
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. |
Similar to the current pairing mode where it is able to identify devices across different networks.
An option to just temporary create a room, and for other devices to enter these rooms for file sharing would be great.
This is useful when sharing files between family members across networks, but since they are not my own devices, I would not want them to be paired.
P.S: Thank you for this amazing stable fork ✔.
The text was updated successfully, but these errors were encountered: