Overwolf and changes to the API

[torkus]

The Overwolf/Curseforge organisation have made their intention to severely curb the usage of their API clear: https://mailchi.mp/overwolf/whats-new-with-overwolf-curseforge-november3

Which has lead to Cursebreaker and others throwing in the towel.

I don't agree with the terms and conditions of their API so Strongbox will be removing support for Curseforge as an addon host in an upcoming release.

This leaves us with wowinterface.com, Tukui, Github, Gitlab ~and soon Wago.io~^* as addon hosts.

Github may be gaining a catalogue soon enough, thanks to @layday's work crawling github repositories.

---

Personally, I stopped playing WoW a long time ago and Strongbox is mostly a software development hobby in how to incrementally improve a program. I get to explore all sorts of problems through it and it's gratifying to see it pop up and start working or flying through it's tests. I like being able to make ethical decisions regarding privacy and user agency and having solid UX. The software I admire most is long lived and resistant to change and that requires a different set of motivations than praise, money or a temporary curiosity.

---

^* Regarding wago.io, it looks like if you want access to their catalogue one must serve advertising and this is something strongbox doesn't do.

[torkus]

4.8.0 is out. It took a little longer than I expected but I'm now free to work on how to remove curseforge support.

There will be a 4.9.0 release that will help users migrate from Curseforge addons to wowinterface.com and Github/Gitlab alternatives.

There is no hard cutoff according to the Overwolf timeline, just an API deprecation for Feb so I'm planning a 5.0 major release that month that will remove support for Curseforge and perhaps a few other things.

[mooreatv]

Github may be gaining a catalogue soon enough, thanks to @layday's work crawling github repositories.

can you shed more light on how? using some (to become) standard tag on the repo? (I use wow-addon on mine, when I don't forget)

https://github.com/topics/wow-addon

[layday]

It looks for BigWigs packager metadata, see https://github.com/layday/github-wow-addon-catalogue/blob/main/collect.py.

Edit: added topic search in https://github.com/layday/github-wow-addon-catalogue/commit/d9a71ab461df07541f1096ceded742f1b615ba4b.

[torkus]

can you shed more light on how?

I haven't approached that problem yet, but I would like a mixture of:

1. automated catalogue building, which means using the Github search api to find potential repos, including any tricks like common topics.
2. publicly submitted addons, where anyone can nominate a repository that will get vetted
3. author submitted addons, where an author can use Github to authenticate and then add their addon repos.

Number 3 would introduce some complexity but it would allow an addon owner to assume ownership over a collection of repositories which I imagine could be very helpful.

For the time being Strongbox is using a static list of addons that @layday just pointed at until I've implemented a way to help migrate users from curseforge addons to alternative sources. This will partly rely on the x-<source>-id fields in the .toc file.

If you have any suggestions I'd love to hear them.

[mooreatv]

It doesn’t find my addons somehow

[layday]

Your add-ons don't have release.json releases. @torkus has suggested that I relax this restriction but for the time being the catalogue will filter out add-ons without a release.json.

[mooreatv]

I use an older fork of the packager that doesn't generate that file; never heard of that file before btw, yet my addons work fine in wowup etc for instance you could use the presence of https://github.com/mooreatv/PixelPerfectAlign/blob/master/pkgmeta.yaml or more simply of release AddonName*.zip in releases?

[mooreatv]

topic wow-addon + language lua should find most (and exclude external apps / non lua stuff)

[layday]

release.json is a file which is attached to GH releases. It exists to help with installing add-ons from releases. It maps release archives to WoW flavours and versions. We'd otherwise have to guess compatibility from the filename or download the archive and inspect the TOC file, which is both slow and wasteful if the add-on is revealed to be incompatible.

[mooreatv]

you can cache whatever results you got from getting the zip

excluding addons based on absence of a file produced only (and only recently) by 1 packager seems quite limiting

there isn't quite a standard unfortunately see also https://github.com/WowUp/WowUp/issues/552

[layday]

packager is the de facto standard packager for multi-host add-ons. Is there something preventing you from merging the changes from upstream?

[torkus]

Your add-ons don't have release.json releases. @torkus has suggested that I relax this restriction but for the time being the catalogue will filter out add-ons without a release.json.

I think it should be emphasised that this implementation of a Github catalogue is still very new and nothing is set in stone. Attempting to capture every edge case can lead to an explosion of complexity.

That said, my own intent is to be as broadly inclusive as practical, so if your addon doesn't use the (undocumented, unspecified) release.json file and is excluded from the automated catalogue building, but can be downloaded as a release, even if it means inspecting some toc files, then it should find it's way into the catalogue regardless.

Not using a release.json file won't make you some second class citizen.

[mooreatv]

Not using a release.json file won't make you some second class citizen.

Thanks, sounds good!

[layday]

Of course, nothing is set in stone, but I’d still be interested to hear if there’s something you don’t like about release.json that you are unwilling to adopt it since it was added at my behest.

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Sunday, December 19th, 2021 at 05:54, mooreatv @.***> wrote:

Not using a release.json file won't make you some second class citizen.

Thanks, sounds good!

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: @.***>

[torkus]

There's nothing wrong with it. A specification with a version number would also be nice. Something in the BigWigs docs that says "this file, if present, adds metadata to a release's assets" etc. I found nothing when I went looking, I had to guess from the content and structure of addons implementing it.

[...] that you are unwilling to adopt it

BigWigs has adopted it, Strongbox has adopted it, it was used to create the current Github catalogue ... it's been adopted and it's value is obvious.

I don't think there is a reason to force addon devs to use BigWigs, or a specific version of BigWigs, however. Or even that the absence of a release.json file should preclude their work from being in a catalogue of addons hosted on Github. The answer to inaccurate catalogue data because a release.json file is missing is to include one and leave the "how" up to the addon dev.

[layday]

Well, I was genuinely interested to hear @mooreatv's reservations because I know that he's been a proponent of using GH as an add-on host. I agree that we should not 'discriminate' based on the presence of release.json in a general-purpose catalogue and I definitely don't want to force anybody to use it.

[torkus]

4.9.0 has been released with tools to enable migration of addons from one addon host to another. It's not fantastic, but it's better than nothing.

5.0.0, to be released Feb 1st, is next up and will see curseforge support removed entirely. It's so completely integrated it will be tricky, but this ticket will be closed when it gets released.

[torkus]

5.0.0 has been released