Provide a web interface to allow riders to add/remove themselves from the manifest

[rschnapp]

We often have riders who decide, during the day, that they will not be returning on the bus. It would be nice if they could remove themselves from the manifest so the driver knows not to wait for them.

Likewise, sometimes someone arrived at work by some other means, but intends to ride home. They ought to be able to add themselves to the manifest.

This would require a web-based service. It would also require upload of the manifest at the end of the ride to the destination, and a download of the manifest prior to boarding for the return trip.

Authentication and privacy becomes an issue, as well. It might be best if a rider can only access his/her own record. An administrator (e.g., the driver) might want to be able to remotely view the full manifest.

[shandilya22]

Hi,

I would like to write this interface. Would you please help me with the details like lang etc in which you need this to be coded?

[rschnapp]

I haven't really thought this through, at this point. My expertise is primarily in Android development. My web-side development is extremely out of date, i.e., using raw HTML and PERL CGI. Clearly, that's not "best practices" at in this decade! 8-)

I suspect that something like https://cloud.google.com/ might be one good place to start. You would need to have an authenticated api for the app to update/retrieve data.

[shandilya22]

Actually, I'm quite naive to GitHub..and this would be my very first code for an issue. i would really appreciate if you go through few doubts which i have as mentioned below and help me get clarification on this :- 1) this issue is still open right? so i can code it up and make a pull request? 2) i don't have an andriod phone..i've iPhone...so i think i need to run this app on andriod simulator... 3 ) "You would need to have an authenticated api for the app to update/retrieve data."....what is that API?

[EboMike]

Btw, I had some thoughts about it, and my idea was to combine this with the standalone app that replaces the NFC tags. Every time a user badges in using the standalone app, they get a random ID from the BusMan app. If they decide they don't need a ride back, they press a button on the standalone app which will send the random ID back to the BusMan app - this could be done with Firebase, for example, which is very simple to set up.

The reason I'm thinking about using a random ID is to make sure this will pass all privacy concerns. Once we're talking about a web interface where a user needs to be identified, we need to be extremely careful with the right approach. The system I mentioned would only ever send a single-use random integer across the network, everything else is local on the apps.

Problem is that this would only work with Android, iOS doesn't even have NFC fwik, so even if we were to use Flutter, we couldn't use it.

[rschnapp]

@shandilya22 Yes, this issue is still open. There is no iphone version of this app yet. Someone would need to write it. I don't think you can run an Android emulator on an iphone. There are emulators for Mac, Windows, and Linux, of course. Or you can probably pick up a used Android device with NFC for under $100. I haven't specified an API. This is something that would need some research and a proposal.

@EboMike In one sense, I like the idea of incorporating the remote functionality into a BusMan companion app that does the NFC tag emulation -- it does provide a convenient solution to the privacy probem -- but there are some downsides: The functionality would only work once there's that companion app with NFC tag emulation, and then only for those who check in using the app. Some folks might find it less convenient to use their phone to check in/out; furthermore, this technique would only work for folks who checked in and then later decided to NOT check out. It wouldn't work for folks who did not check in, but then later decided they DO want to ride home.

As for iOS, I was under the impression that Apple is opening up the NFC interface to apps in the latest version -- though it may only be open for scanning tags, and not for emulating them. So, basically, someone might be able to write a variant of the current BusMan app for iOS, but not the companion app we're contemplating.

[shandilya22]

I'm planning to code the web interface in Django...a user would click on a link present in Busman app..this link would take him/her to this interface...then the user could either add or remove him/her to that manifest...different authentication would be there in this interface for normal passengers and driver...let me know if it sounds good so that i can start coding....also...what info do you think should be present in that manifest....i think..passenger name, sex and location and timing are enough...is there anything else which i am missing here?

[EboMike]

Users don't really have an app. They just have an NFC tag that was generated with the app. Only the driver has the BusMan app.

And BusMan is deployed in places where the privacy of the users needs to be protected with the utmost concern, so we can't have sex or location in the manifest. There needs to be a level of indirection so ideally entries can be removed with a simple ID number, but that's not easy to pull off if users don't actually have an app, just an NFC tag. At the least, we generate a permanent ID when we create the NFC tag, and this ID can be used in the web app, but even that isn't as good as a single-use ID.

[rschnapp]

Mike's got it right. We have no need of nor desire for any demographic information -- as soon as you start collecting that sort of stuff, you become subject to all sorts of regulations.

In order to implement remote management of rider status, here's what I think might work:

1) you need to create a web service with two types of accounts: riders and route managers. Both are authenticatable accounts (rider id, password, route id, perhaps 2nd factor auth). A rider can access and change only their own manifest status; A route manager can access and change any rider's manifest status on their route. 2) The BusMan app would store the credentials of the route manager. 3) The NFC tag would store the rider id (not the full credentials) 4) Upon scanning the tag, the BusMan app would immediately update the local manifest, as it does now. And it would connect to the cloud service as soon as possible, using the route manager credentials, to sync with the cloud-based version of the manifest. 5) Riders could then access the cloud service (via web interface or some rider app) in order to add or remove themselves from the route manifest.

Synchronization can get tricky, of course...