I can totally see a "social layer for progress bars" and "Deep Research for progress bars" as valuable things to do on top of it. Like how decision markets and search fit in. Where is reputation and trust? Is metadata encryption needed?
There are developer UX improvements possible of course, as with most things. How exactly parent and child relationships and completions are best represented for an intuitive UX is an interesting circle to square while keeping a simple tqdm API.
I'd love it if this was open-source or zero-knowledge, though that may be a bit of a loaded term when actually wanting client side title / description metadata encryption. I guess you'd want a client doing simple but robust encryption on the metadata, but probably not progress values (or at least not at first, for sanity).
Any plans for a MCP API? It's pretty easy these days.
I must admit that idea behind this project is nice, but I'm not going to get dependent on someone else's infrastructure (and I think I'm not the only one thinking that way), can I host it myself or is the source not available? I don't see any links to sources or github, so decided to just ask here (and to also make the 1st comment here to see if your link would work now).
I'm happy to clean up the source a bit and put it on GitHub if people like it and prefer to host it themselves. I thought I'd host it myself under a short, memorable domain, so people can easily try it out and share short links to their progress bars.
If you are happy to share the code - I think quite some people would be happy. The openness doesn't guarantee, but usually leads to better security, performance, etc.
It is very nice of you to provide such a service (and for free, as I see), but your docs says we, users, better not update stuff faster than once per second and that's quite a big limitation for some big companies with lots of processes to track (which probably can't be grouped together into a single batch update as your docs suggest to do).
I'll work on cleaning up the code, adding some dev documentation and releasing it on GitHub when I find some time. Perhaps this weekend already!
Regarding the tight loops: Currently there is just basic rate limiting in place and the Python client batches updates by default. The app is not intended for short-lived progress bars with fast updates. These usually also don't have a good reason to be shared and live on the web. It's really much more useful for slowly updating, long running processes.
Although the practical use case is unclear.