Last-minute data missing

Expected behaviour

Data about platform, departure time or arrival are updated in order to keep up with delays, changes etc.

Actual behaviour

For last minute changes and delays there is no update to the provided train information.

Proposal

I propose two (possibly combinable) solutions to this issue

On-the-fly updates required by the user

The user is given the possibility to request a live update about the delay/platform of the train. Ideally the updated data are saved in the backend and in the local device cache, in order to avoid both multiple identical requests from the same user and requests about the same train by other users. Once the first update request for a train is executed by an user, the train ride details include an entry/tag/label such as updated and the time at which the last update was executed. To avoid massive and reiterated requests for updates for a train, some UX elements can be introduced in order to increase the friction between the user action of pressing the update button and the actual API call. For example a two-step menu with a compulsory confirmation by the user that he/she is willing to require an update.

Possible issues: the more the users, the more the number of update requests that would be triggered. Some caveats could be implemented to lower the easyness of an update request, but overall that could generate throughput issues.

Crowsourced live updates

The user is given the change to submit a manual live update. I imagine it like an option in the train ride details that returns a single-choice list of possible updates that the user could submit. For example:

Train delay
Signal a different departure platform

According to the choice, the user is provided with a prompt to insert the updated data. In order to avoid malevolent updates by users, some countermeasures can be taken:

The submitted "suggestion of update" is not going to replace the current value, but is going to be added on a "Live updates" menu in the details section;
The users have a "trust score" based on the validity and correctness of their past update submissions.

The second suggestion does require users to have an in-app identity, which is not ideal from a privacy standpoint. Some solutions to this identity issue are:

Adding the possibility to associate an external account to Muoversi (not ideal?/not feasible?)
Adding the possibility to submit Updates using an external "Identity solution" like Nostr. In this specific case I imagine the user to generate a private-public key pair once he/she wants to submit an update the first time. Then, the key is saved locally on the server and subsequent submissions are still executed with that key. Muoversi could even exploit Nostr Web of Trust features to rate the trusted submissions.

Possible issues: with the Nostr solution I see no issues other than the need of implementing submission events that are compatible with Nostr specs (NIPS). Keys generated locally are ideally exportable to provide maximum portability across device of the user submission reputation.

Thank you for the thoughtful and well-articulated suggestions!

For the on-the-fly updates, I agree with you it is something very much needed for the app, especially at the moment for the regional trains around Venice. Your idea about having the backend serving the updates was my initial thought as well, ever since I started developing the app. However as you say there may be concerns with the amount of data that needs to be parsed. For GTFS Realtime this would not be a problem, but since Trenitalia does not publish its static and realtime timetable data using GTFS, calls to the api every minute for all trains would be less efficient and subject to blocking. Going for a direct api call from the app may be more ideal at the beginning. Moreover, I will definitely consider your UX/UI suggestions in this case. Calling the Trenitalia private api just for the next-departing/arriving train should not be a issue and would also respect the potential rate limiter that they may have. But yeah I can confirm that this feature will be definitely implemented by the project.

The crowdsourcing part is so fascinating, thanks for the detail proposal. I agree as well that it is something that could be a great fit for the app and but more broadly for the server side. Since my worries in this area are the acts of vandalism and inaccurate information, what you propose about having a trust score and also your reference to a way to do it potentially with anonymous private/public key pairs would be a very cool thing. I need to read more stuff about it. However for this part, differently from the first one, the implementation needs to start from the server code and the app implementation would be the very last thing to do after we make sure that everything works there.

gsarrco / muoversi-app