* BantFlags
A user script and backend enabling user created flags on [[https://boards.4chan.org/bant][/bant/]],
originally based on [[https://github.com/flaghunters/Extra-Flags-for-4chan][extraflags]].

 [[https://flags.plum.moe/bantflags.user.js][Install bantflags]]

** Userscript
The userscript takes advantage of =GM_xmlhttpRequest= to get and set flags with 
the backend. A user's flags are stored between pages using =GM_setValue= and
=GM_getValue=.

Old versions of GreaseMonkey will be able to recieve updates to the
script through use of the =@updateURL= and =@downloadURL= directives,
though these were depricated sometime in GreaseMonkey 3.x and updates
are only checked from the location the script was downloaded from so
be careful where you upload links.

On self hosting, changing =back_end= to your domain /should/ be all
you need to do, but don't take this as fact.

The userscript has been designed specifically to target ECMAScript
2015 (ES6), making liberal use of arrow functions, and const/let
declarations. Update your hecking browser.

** Backend
*** Prerequisites
- .NET core 3.1
- Mariadb / mysql

*** .NET dependancies
- Nito.AsyncEX
- Newtonsoft.Json
- MySql.Data
- Microsoft.AspNetCore.Mvc.NewtonsoftJson
- Microsoft.AspNetCore.StaticFiles
- Microsoft.EntityFrameworkCore.SqlServer
- Microsoft.EntityFrameworkCore.Tools

*** Setup
1. Install .NET
2. Clone and build the BantFlags .NET project.
3. Create the database using =database.sql=.
  + *Change the password*.
4. configure =BantFlags/appsettings.example.json= with your connection
   string and webroot (the directory you wish to serve the flags from)
   and rename it to =appsettings.json=
  + The location of the BantFlags application and the served content
    are not necessarly the same. If you leave it empty, or provide a
    nonexistant path the application will look for the =wwwroot=
    folder inside the working directory.
  + This should be placed either in inside the working directory or
    the same directory as the program.
5. Add flags to the backend (currently only possible by querying the
   database directly), and place image *with the same name* in
   ={webroot}/flags/=.
6. Configure your webserver of choice to forward requests to kestral
  + Example nginx config.
7. Run the application
8. ???
9. profit.

*** Database
Tables look like this:
*posts*
| id | post_nr | board |
|  1 |   12345 | bant  |
|  2 |   56789 | bant  |
*flags*
| id | flag      |
|  1 | patchouli |
|  2 | chen      |
*postflags*
| id | post_nr | flag |
|  1 |       1 |    1 |
|  2 |       1 |    2 |
|  2 |       2 |    2 |
where post_nr and flag in *postflags* are the id fields in their
respective tables. 

extraflags stores all of a post's flags in one table as a varchar,
seperated by "||", which is split and joined by the script when
getting and posting respectively. This is extraordinarily inefficient,
but for their purposes it's not such a glaring issue (the highest
amount of flags I've seen is 6). One aim of this rewrite is to
greatly increase the amount of flags usable at once, and this database
structure allows the maximum to be arbitrarily high.

*** API
The backend exposes three endpoints used by the userscript to get and
post flags, and a flags directory storing the images themselves.

| route      | purpse                                     |
|------------+--------------------------------------------|
| /api/get   | Get flags using post numbers in the thread |
| /api/post  | Add flags to the database                  |
| /api/flags | List the flags we support                  |
| /flags/*   | The flag images                            |

** Backwards Compatibility
The API is 1:1 compatable with all previous versions of bantflags,
but also encodes a new =version= variable when getting flags which
allows for breaking changes in the script while the backend only 
sends data it knows is parsable.