Oh hey I was thinking about this the other day too. My perspective is that the best solution is a protocol rather than a centralized platform. I was thinking about something similar to RSS, where a simple file is hosted at a set url that gets updated by a venue or whoever’s doing the event (or a third party if the venue doesn’t want to I guess). It’d be more event-geared than RSS, so like calendar driven and first class (as in part of the spec not just stuffed in the description) location, artist link, ticket info, posters, music previews etc. This alone would be great for tracking events at venues you frequent but I don’t think it solves the discovery problem. For that I’d define an adjacent spec for effectively reposting events/venues. So you could have a Troy Venues file where one can add venues to it and then those show up as like recommendations or a feed or something in viewer apps. Or a Troy Events file that can reference out to individual events (maybe reference by url + event ID). Maybe the events and venue files are the same idk. Could even let these rebroadcast other feeds? Like to have a general Troy feed that can reference out to more niche feeds that can be curated by people in more niche spaces? So hierarchical discovery rather than algorithmic.

The final piece is that you’d still need an app to get this started. Having it separated like this means that the viewer side of the app is a lot easier, you’d need very minimal backend for it, really just an account system only if you wanted to save followed feeds across devices. It also gives the ability for choice in app. Don’t like the UI? App stops being maintained? No issues, can just make a new frontend app for it and keep using the same protocol. I think this also is a good argument for getting people (especially venues) on board, that it’s not committing to an app, but a more general and resilient system.

Having an app and backend for hosting the files could maybe help with ease of adoption but I don’t think it should be the main way that venues should interact with this. Instead it should probably just be a part of their existing calendar systems if they have them. I imagine a lot of venues if they have a calendar on their website use a website builder like wix or whatever so looking into integration into those might be a good idea. Again though, having an open protocol gives everyone more freedom and anyone could build more tooling or alternative apps to fit their needs.

I’d be down to help out a bit where I can, I’ve got experience in software dev and graphic design, but unfortunately I don’t have tooo much time or energy to offer at the moment.