This question is effectively split from this topic. It was suggested that I move the Marketplace-specific portion here.
Firstly, I’m still confused about the production vs testing URLs. I can generate both URLs in the app configuration wizard, but only the “local testing” one works at the moment. (Trying to exchange the code for an OAuth token fails with a 4xx error.) I think I’ve seen it the other way round as well, but I’m not sure. (I was changing too many things to have paid much attention on that.) Is there a separate step required to make the “publishable URL” active instead of just the testing URL?
The terminology of “installing” and “uninstalling” an application is definitely confusing here. From my standpoint, I’m not installing anything - I’m authenticating or logging in. I assume that “uninstall” really means “invalidate previous token” but that’s unclear too.
Anyway, I’ll assume that this can all be sorted. My bigger concern is being able to create an application with very limited distribution without making it public on the Marketplace. Here’s my bigger context…
I have developed two applications, “Zoom and Enhance” (ZAE) and “At Your Service” (AYS). Both are basically to help me with A/V presentation for my local church, and both are Windows-based (WPF).
ZAE was started last year, and is effectively a Zoom productivity app. It’s designed for the situation where everyone in a church service is attending via Zoom, and is primarily about streamlining a few bits of functionality which are common within Zoom services - plus a few extras. It can:
- Change the spotlight from one user to another, muting everyone else and unmuting the new speaker, all with a single double-click
- Launch a PowerPoint presentation, video or web page, starting a screen share (either of a screen or the app), again muting everyone else - and again, all with a single double-click. (And importantly, you can prepare the list of videos etc beforehand, so you’re just clicking from one item to the next, via other speakers to spotlight.)
- Unmute everyone (e.g. for saying the Lord’s Prayer) - this is in the normal Zoom client as well of course, but it’s all in the same place as the rest of the functionality for ZAE.
- Automatically rename users as they join (e.g. to turn phone numbers into names)
- Provide crude-but-effective chat-based notification system, so that people can “subscribe” to notifications by chat when someone joins or leaves. That allows a few people to make sure that everyone is greeted as they arrive.
- Make it easy to switch between devices (e.g. different webcams, microphones, speakers) without going through settings menus
While I primarily built ZAE for myself, it now has maybe a dozen users. To avoid issues where the same SDK key was being used at the same time for an unpublished app, each user has registered themselves as a Zoom developer (under the advice of a Zoom engineer last year). I suspect that each user only needs to start meetings for a small handful of “normal” Zoom users (e.g. the account for the minister of that church, or the church council secretary) but it’s not necessarily just their own account.
AYS was started this spring, and is a complete replacement for the previous A/V system at my local church. Our “A/V stewards” are just volunteers who are technically literate, but not necessarily geeks, let’s say. I wanted to make things as simple as possible for them, in a world of hybrid worship where some people are on Zoom and some are in the church building. Before the pandemic, the A/V stewards would primarily need to worry about the sound via microphones, and what’s on the screen via a computer. Adding Zoom and cameras into the mix made it infeasible to have lots of separate pieces of hardware and software, so I’ve built a platform myself which controls:
- Sound via a digital mixer
- Presentation of videos/audio/pictures via VLC
- Song words and liturgy as text
- Multiple cameras (with control for pan/tilt/zoom)
- Window management for all of the above (e.g. to show singers with the song words overlaid, or a regular video overlaid with a camera shot in the corner)
- Starting the meeting for people to join
- Spotlighting people who are doing a reading (and then returning to show the church view)
- OBS for recording services
Again, the intention is to allow as much to be done with a single mouse double-click (or button-press on a Stream Deck) as possible.
Currently, the only installations of At Your Service are me for development and on the church computer. Other churches aren’t using it, partly as it’s very much geared towards our hardware.
Most of the meetings started by AYS are with the same account, although that’s a separate account from the one I’ve created the app in. (Church account vs my personal account.)
So these applications are only ever intended to be distributed by me personally - no-one is going to be able to install them without coming to me first. That’s why it would seem odd to have a Marketplace app that’s publicly visible: “Here’s an application that you can find out about - but you won’t actually be able to use” is odd messaging.
While it’s awkward, I could potentially create a new OAuth app which is never submitted for review, on each account where we host meetings - and ask the handful of ZAE users to do the same thing.
The other alternative is to go via the “Request to share this app outside this account” dialog in the Marketplace app management part. If the Zoom Marketplace Team would consider this an acceptable use case, that would be simpler. I’d need to get the published URL client id/secret to work but I’m sure that’s manageable. I note that this option is mentioned in the docs here, but it’s not clear to me what the user experience is. Who manages which user accounts have access to the app? Basically this feels like a half-way house between “in testing” and “published” which could do with a little more clarity.
I’m sure once we’ve worked out how many OAuth apps are required (in order to allow hosting from “multiple, but not a huge number” of other accounts), I can do the server-side OAuth management and then app-side ZAK-fetching relatively easily.
If you have any other ideas, I’d be very interested in hearing them. I hope all the above context is useful for the product team in terms of giving background as to how the Zoom SDK is being used in real life outside enterprises etc. (I’m sure enterprise use cases are much more important to the product team, of course - I don’t begrudge Zoom wanting to make money!)