Consider making the Leopard website static

[adroitwhiz]

Right now, the Leopard website is deployed using a Vercel free plan, meaning it can't live in this organization.

However, the site doesn't appear to require much in the way of a backend. The only persistent state we're using is a list of converted projects, which I'd like to get rid of anyway due to privacy concerns.

Since sb-edit runs in the browser, it would be possible to convert projects client-side, which might also be faster. I'm not sure if CodeSandbox's API can be used entirely client-side, which might be an issue.

[towerofnix]

Just to touch on the privacy concerns a little, currently there's no way to "privately" convert a project to Leopard in the browser. We indiscriminately track all converted projects, which are publicly visible and probably go back pretty far (I was able to "load more" at least a week of results).

Technically users can't make changes to a public Leopard project once it's been generated — any changes they make will be saved on a fork rather than the original CodeSandbox project. However, we do save a snapshot of the current project state. There's no way for the creator of the project to take it down, in case they realize it contained anything they don't want publicly shared; once an export is made and publicized, it's effectively archived, and that's it.

It's also possible to work around Scratch moderation concerns by temporarily putting something explicit or inappropriate in a shared Scratch project, converting that project via Leopard, and then editing the project to remove the content or just unsharing it. The archive will be saved online and unless the Scratch Team keeps record of every project change, it may be trivial to dodge proof of anything inappropriate. (Unshared projects are another barrier/inconvenience to reporting.)

The Leopard project list serves as a way to discover projects people are trying out in Leopard, and... that's about it. Because Leopard doesn't have a community website (#116), visitors can't discover any projects created with Leopard or edits made to existing projects. It's basically just a tech demo.

I think we can serve that purpose better by showing a hand-picked selection of projects (maybe bringing to front random ones each reload / day) which we've confirmed load and function well in Leopard. It'll work as an effective demo, and bypasses all moderation and privacy concerns (as long as we generate the project on the client rather than retaining a cache / public archive).

[towerofnix]

(Let's think about including a "download zip" feature for more advanced computer-users who would rather work offline, too, though that's for another issue. It would obviously still be great to generate CodeSandbox links from a static site if possible.)

[towerofnix]

See also #139.

[PullJosh]

I hadn't even considered running sb-edit in the browser. That seems like a good idea to me.

[PullJosh]

Also, I would be alright with removing the recently converted projects list if y'all want to. When I added it to the website, I was looking for an easy way to help Leopard users find each other, see what others are doing with Leopard, share their work, etc. I also thought it might be nice to have some social proof on the website ("other people are using Leopard too, like this"). However, I don't think it's really doing a very good job of serving the former need.

Are there other things we could do to help Leopard users find each other/share their work/etc? Building out a more robust project editing/sharing website (replacing the need for CodeSandbox) is the only real solution to this problem I can think of, but maybe there's something simpler we could do?