Maps API as MediaWiki extension

[simison]

With Hitchwiki Maps broken (reading works, writing doesn't) and codebase being so legacy that it literally doesn't make any sense to touch it, I'd propose we:

• Implement a MediaWiki extension for writing content to the same database the old web client is using
• The same for reading, but with much lower priority
• Enable authentication against MediaWiki API with Hitchwiki account

The first pragmatic step for using this API would be to make it possible for MyHitchhiking spots app to "liberate" both reading AND writing the maps data. Folks can then build mobile apps.

Another aspect is authentication. The API should be writable only with the Hitchwiki account — as long as we implement this as MediaWiki Extension, clients can authenticate against MediaWiki API.

For now, the website version would continue being read-only. With the new API, might be someone will eventually write a new modern client. :-) All these should anyway use the same API and same database, and same authentication.

The extension should be pretty generic, so I'd suggest you just set up a basic MediaWiki locally. Write to me and I'll send you the hitchwiki SQL database dump.

Spec

MediaWiki extension

• See these guides
• Reading and writing should be handled by the same extension
• Handles authentication layer for writing; reading is open for everyone
• Reuses as much MediaWiki core functions as possible. The less code there is in the extension, the easier it'll be to maintain.
• If you need to use external PHP libraries, please use Composer to manage them so that it'll be easier to maintain.
• Keep it simple. We cannot afford complexity. :-)

Authentication

I don't know the state of API authentication at Hitchwiki.org (there might be some captchas complicating it, or some configs need adjusting). It's ok if signup, password reset, etc works just on the web, especially since those work in the mobile web anyway.

Writing

• Higher priority since this is currently broken.
• Identify what is the minimum we need for recording hitchhiking spots; I'd suggest that first version we launch implements only user ID, coordinates, date, and rating.
• It needs to validate and sanitize those values before storing anything to DB
• Identify what needs to be stored next up; comments, waiting times, descriptions, etc
• The old API and DB supports multi-language for descriptions. While a great idea on paper, it had extremely low use. Hence I suggest we don't implement this for now, or treat it as low priority. Let's just roll in English for now. Lemme know if you disagree or otherwise have questions about this. We can implement some kind of automated inline-translations and make sure the UI of our apps and websites is translated, as that'll likely be more useful pragmatically.

Reading

• Lower priority since this already works
• We need to understand what kind of data reading would be useful for mobile apps, considering offline use.
• @leocarona could you help outline what us useful and what doesn't work with the current API?

cc @Akronix @leocarona @omelnyk

[Akronix]

Thank you for the follow up Mikael!

I have much other stuff in my priority list right now. But if I find a time slot for it I'll let you know.