I'm actually tempted to fork this repo, to make my own (actually updated) version as this one seems somewhat outdated and no longer maintained at all.

Looking at this, couldn't this cause conflicts? In a JSON file f.e. do you have a strict format, which may not be of good use for this site here.
The main point I get from this site is to render raw content as if it was an actual Discord message, so having to render JSON here seems pointless as you could also just download and open the file yourself to see the content of it.

There are several concerns with this, which is why I haven't merged it.

• Allowing arbitrary files could lead to attempting to load non-plaintext (such as binary) files, which could have unintended or poor results, especially if these files are large.
• The Discord client already automatically converts messages longer than 2000 characters to .txt if you have upload permissions. This doesn't detract from supporting more file types, but just makes them less necessary.
• If the parameter syntax would change, I would prioritizing switching to url fragment syntax (#), as sending the query parameter (?txt=) to the webpage itself isn't necessary (since all data loading is done locally).

Looking at this, couldn't this cause conflicts? In a JSON file f.e. do you have a strict format, which may not be of good use for this site here.

The intention of this PR was so that things log debug.log that people directly upload, no parsing are done--all files are treated as if they are text files.

Allowing arbitrary files could lead to attempting to load non-plaintext (such as binary) files, which could have unintended or poor results, especially if these files are large.
Indeed a problem, and simply saying the user know what they are doing is a bit unideal.

File size should be doable (have to do some research). However I don't know if there is a way to detect binary vs text file in the client, and they could rename a binary file as message.txt anyways.

If the parameter syntax would change, I would prioritizing switching to url fragment syntax (#), as sending the query parameter (?txt=) to the webpage itself isn't necessary (since all data loading is done locally).

Sure, do you want to me to do it in the same PR (asked because some people hate multi-purpose PRs)