shabados / presenter

Desktop app for presenting the Shabad OS Database on projectors, TVs, and live streams
https://shabados.com
MIT License
19 stars 15 forks source link

Add remote control without wifi / "Shabad OS Connect" #416

Open bhajneet opened 4 years ago

bhajneet commented 4 years ago

Add some kind of method to connect and control Shabad OS without the wifi. So basically what we already allow with browsers on the network, but without the network part...

Allows multiple streamers to pull captioning from one central shabad os without requiring all streamers to share gurdwara internet bandwidth

Allows users to remote control shabad os when the gurdwara wifi is locked down (passwords not shared)

Allows elderly people to connect for reader purposes again in the same scenario above where the wifi is not shared in gurdwaras or is set up by non gurdwara committee members.

Allows people to follow along on live streams started on phones (so facebook / youtube for smartphones) where captioning isn't available.

Will be needed for mobile app anyways. Part of the idea of "Connnect to Shabad OS Nearby" or via some ID. Can use 4 non-ambiguous upper case letters (24) to get about 24^4 = 330k unique ids. I doubt that we will have that many concurrent users, but can always go for 3 pairs of numbers which is a million unique IDs.

Marking it high since it will be used in the future for a second project. Marking it "in research" to try and spec it out before any work is done. So if you have any UI questions or user flows, let's figure it out here first.

Harjot1Singh commented 4 years ago

Main spec points needed are:

1) where do we display such a code? In the controller itself? Or in the remote settings tab (if we add one)

2) where does one enter the code? Do we have something like shabados.com/connect?

bhajneet commented 4 years ago
  1. The code could be in settings > connect tab (have to add one). This code could be "sticky messaged" via #392 if someone wanted to display it. The connect tab would require a "kick all connected users" and some kind of security to allow control. Maybe a different code for control? I would imagine with the code changing that's "security" enough.

  2. I like the idea of user entering it on a website shabados.com/connect which opens a display/overlay for read or the controller for read/write access. Could also do it where read is done on the website and read or read/write is done through the desktop app? So that they can only access a small static page for display (without control) or overlay through the website. Might want a separate page for the website which is kind of like iGurbani and other mobile apps which show all the lines of the shabad that a user can scroll through on their own and highlight (but not hijack scroll) of the line that is activated?

swissarmykirpan commented 4 years ago

We should expose this functionality in the API

Harjot1Singh commented 4 years ago
  1. The code could be in settings > connect tab (have to add one). This code could be "sticky messaged" via #392 if someone wanted to display it. The connect tab would require a "kick all connected users" and some kind of security to allow control. Maybe a different code for control? I would imagine with the code changing that's "security" enough.

Interesting. So the options we have are: 1) Read code + PIN to write (could tie in with the way we do things locally) 2) Read code + write code

Leaning towards 1 actually. With a refresh button to regenerate the PIN. If we can get that to work over our current setup, it should just seamlessly tie-in when we add remote. Related #24.

  1. I like the idea of user entering it on a website shabados.com/connect which opens a display/overlay for read or the controller for read/write access. Could also do it where read is done on the website and read or read/write is done through the desktop app? So that they can only access a small static page for display (without control) or overlay through the website. Might want a separate page for the website which is kind of like iGurbani and other mobile apps which show all the lines of the shabad that a user can scroll through on their own and highlight (but not hijack scroll) of the line that is activated?

Here's the way I see it: Shabad OS connect will effectively form a tunnel to the host. That means you'll be able to do everything you could do if you were on the same network, including the different endpoints. I reckon this approach is best, and then the idea of a reader view for mobile devices, we should probably just add that to the app for local users/readers anyway (we used to have the Kobo endpoint).

We should expose this functionality in the API

Certainly. Though I'm of the opinion that it's totally unrelated to the data stuff, so we can just open up a new repo and create a microservice that handles anything to do with connect.

bhajneet commented 4 years ago

So example of the website shabados.com/156484 (random 6 digits) and then the endpoints added on the end like shabados.com/156484/overlay ?

What is hosted on our servers vs being served by the host device?

From a practical example:

Read code + PIN to write (could tie in with the way we do things locally)

This is also fine. I was thinking it would be one less step for the user if it were combined as a write code which changes on each start up. So instead of the 6 digit read code they just input the 6 digit write code as the URL and it gives you control. Instead of having to add some way for the user to put in a PIN after typing in the read code. Could maybe make it so the PIN is added on to the read code? So it's like 156484 is the read and 23 is the write so it becomes 15648423 to write?

Harjot1Singh commented 4 years ago

So example of the website shabados.com/156484 (random 6 digits) and then the endpoints added on the end like shabados.com/156484/overlay ?

Exactly

What is hosted on our servers vs being served by the host device?

From a practical example:

  • Gurdwara is running shabad os
  • Live streamer wants to connect to read the overlay
  • Sevadaar wants to connect from their mobile device to control

Session server - host device Relay - our servers Frontend - host device/our servers

The code is received by the connect API, and then it provides a HTTP + WebSocket connection/relay to the host device.

Read code + PIN to write (could tie in with the way we do things locally)

This is also fine. I was thinking it would be one less step for the user if it were combined as a write code which changes on each start up. So instead of the 6 digit read code they just input the 6 digit write code as the URL and it gives you control. Instead of having to add some way for the user to put in a PIN after typing in the read code. Could maybe make it so the PIN is added on to the read code? So it's like 156484 is the read and 23 is the write so it becomes 15648423 to write?

It might actually just be less tedious to have the link sent over to the mobile device etc.

But actually, if we had a write code, does this not conflict with having a PIN too? Or cause confusion? It depends on how the PIN code would be entered normally on the local network. Maybe a write code could automatically enter the PIN. It’s possible to have it in the URL like that, though not sure if it’s a good idea yet. I think it’d be ok to include it in query parameters ?pin=1828, and thinking about it now, that’d be how you could use it locally too if you wanted.

bhajneet commented 4 years ago

Having the link sent is the least tedious method. If the pin is shown in the url as a parameter it's kind of the same as sending it as a write code. Either way allows user to easily connect to write with one url.

The PIN does not work alongside the write code. It's one or the other. So you always have a read code. So the question is do you want a separate code for write access or do you want a pin on top of the read to gain write access?

I think a separate write code is easier, since we're not running out of codes any time soon haha. In the off chance they have to type it manually and don't have the link sent to them. But again, either way is fine.

Estimated time to develop? This would be related to hukamnama issue spec if someone wants to access the overlay/hukamnama from a different wifi or cloud service.

Harjot1Singh commented 4 years ago

So would this work?

1) I want to read - Read Code 2) I want to control - Write Code 3) I'm on the local network and have entered the IP (so am reading) - enter write code somewhere inside shabad os 4) I was reading, but want to control now - Read code, but enter write code inside shabad os

Harjot1Singh commented 4 years ago

Rough work required:

preetcharan commented 4 years ago

@Harjot1Singh @bhajneet interesting conversation thanks for looking into it. Is there provision for a broadcast computer running shabad os and then a projector computer that e.g. Is old, doesn't have Internet for us to come in, with a wifi hotpot, open a browser, save us from installing and opening a display with full display settings capability? (Not just overlay)

Harjot1Singh commented 4 years ago

@preetcharan yeah, this proposal would support your scenario. Basically, you'd be able to access all current Shabad OS facilities as if on the local network in the first place

bhajneet commented 4 years ago

So would this work?

  1. I want to read - Read Code
  2. I want to control - Write Code
  3. I'm on the local network and have entered the IP (so am reading) - enter write code somewhere inside shabad os
  4. I was reading, but want to control now - Read code, but enter write code inside shabad os

1 and 2 obviously fine.

  1. Entering IP on local network is basically control mode. That's pretty advanced stuff. I don't think anyone can memorize the IP that easily but we can add an "eye" icon to show/hide the IP. If you want to read on the the local network, then you can probably use the internet to "read" like you would in scenario 1.

  2. Same as 2. Wherever you're entering the read code would be where you enter the write code. Idk where the code is, but it's a singular place to enter either a read or a write. It's a connect code. The code gives you permissions, but the process is same for either.

Could be you want some website or whatever our online browser version of connect would be to somehow point you to a local IP address if it detects you're on the same network. In that case you would have to add a read / write mode of IP addresses for point 3. But I'm not sure what the point of connecting locally this way would be?