Currently mod menu developers are having their entire accounts/organizations flagged for no apparent reason on Github. This also applies to normal developers who have been flagged for no reason at all.
When they are flagged, it also breaks mod downloads as well.
A solution for this would be to utilize a different service for users to download mods.
Flow:
- Developer uploads a mod
- Index downloads the .geode file and uploads it to a bucket (
mods/{modid}/{version}). (Example: mods/geode.node-ids/v1.2.3, the mods being the bucket.)
- The URL of the download is set to the object url.
- Users who download the mod will download from that object url.
- Any pre-existing mods should have the option to migrate over
Include in .env both access & secret for R2/S3 to upload to bucket. (R2 can function similarly to an S3-compatible API)
(example)
S3_ENDPOINT_URL=
S3_BUCKET_NAME=
S3_REGION=
AWS_ACCESS_KEY_ID=
AWS_SECRET_ACCESS_KEY=
This could also be used for downloading Geode as well, in case users can't download from github due to their internet or if Github flags the geode-sdk organization for no reason.
Currently mod menu developers are having their entire accounts/organizations flagged for no apparent reason on Github. This also applies to normal developers who have been flagged for no reason at all.
When they are flagged, it also breaks mod downloads as well.
A solution for this would be to utilize a different service for users to download mods.
Flow:
mods/{modid}/{version}). (Example:mods/geode.node-ids/v1.2.3, themodsbeing the bucket.)Include in
.envboth access & secret for R2/S3 to upload to bucket. (R2 can function similarly to an S3-compatible API)(example)
This could also be used for downloading Geode as well, in case users can't download from github due to their internet or if Github flags the geode-sdk organization for no reason.