Bluetooth Party Mode

[marcodejongh]

A big (first world problem) we have when climbing with a bunch of friends on our kilter, is that only 1 person knows what problem is currently on the board. It would be super sick if we could create a kilter "party" similar to how Spotify etc have such features.

Initially, that party mode could just show the current problem, and if people are logged in they could tick it. But if #79 is possible, more options become available, like putting new problems in the queue etc.

Happy to contribute this too, since the backend looks pretty light, I'd probably have a stab at doing this with WebRTC

[lemeryfertitta]

Worth reading through https://github.com/lemeryfertitta/Climbdex/issues/45 which already has some discussion about this feature - @gardaholm had some similar ideas.

Just a heads-up that I don't feel like I really finished a solid initial implementation of the Bluetooth feature. From my limited testing, I think it still needs some stability and UI work, especially around reconnection, indication of existing connection, etc. Might be worth playing around with it for a bit to see what you think, as improving the initial implementation to be at least as good as the official apps might be the first step on the road to more advanced functionality.

I'd also suggest we break this down into more specific issues as you mentioned. I agree that a nice first step would just be a sharable link that takes you to the current "session." Then the features from the "session" can be improved with things like ticking and adding climbs to the queue.

[marcodejongh]

Yeah I think the desire for more advanced features already pushed me in the direction of needing to overhaul stuff. It's currently all DOM state and HTML without a library, which becomes really cumbersome when pushing state changes from other places. So armed with ChatGPT, I spiked converting some of the UI to React this evening, and I got a proof of concept of editing a board and sharing between multiple browser sessions. The cool bit about webrtc is that it doesn't involve any backend changes, and since nobody would argue their kilter board session is mission critical that should be plenty sufficient.

[lemeryfertitta]

the desire for more advanced features already pushed me in the direction of needing to overhaul stuff. It's currently all DOM state and HTML without a library, which becomes really cumbersome when pushing state changes from other places.

Makes sense. The original intent of the app was just to provide search by hold functionality, so a heavy JS framework felt like overkill at the time. The scope has started to increase as it has become clear that Climbdex could fully replace and improve upon the functionality of the existing apps, and I can see an argument for the need of something more.

I spiked converting some of the UI to React this evening, and I got a proof of concept of editing a board and sharing between multiple browser sessions.

Nice! If you do end up with something that you'd like to contribute, I'd be happy to review and get it deployed. My only request is that we break the changes down into smaller components to avoid a massive PR that changes every file 😅. If there is a conversion of existing UI, let's keep that separate from new features, and ideally also separated by the different pages.

[gardaholm]

A big (first world problem) we have when climbing with a bunch of friends on our kilter, is that only 1 person knows what problem is currently on the board. It would be super sick if we could create a kilter "party" similar to how Spotify etc have such features.

this would be a real game-changer. we also have the same first world problem here, as we tend to use the tb2 in groups. a session mode would make things so much more comfortable – even if there is just one host (which can select climbs and light climbs) and all others in the session can only view (and log) the current climb. would be a great addition.

[marcodejongh]

@lemeryfertitta Yeah sounds good, I've put it behind a /react endpoint, it's relatively close to complete now, just haven't had a lot of time lately to finish it.

Random question: Does Flask have built-in SQL injection protection? I was looking at some of the select statements and I dont see anything that would suggest its protecting against sql injection, for example:

name = args.get("name")
    if name:
        sql += " AND climbs.name LIKE :name"
        binds["name"] = f"%{name}%"